[PATCH 0/6] drm/exynos: g2d: rework sleep and runtime PM

Hello Marek, Marek Szyprowski wrote: > Dear Tobias, > > > On 2016-09-27 17:50, Tobias Jakobi wrote: >> Hello everyone, >> >> as discussed with Marek I have broken down my initial patch into >> smaller piecer. >> >> Anyway, this series fixes a regression introduced by commit >>

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

-- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/a0132cb0/attachment.html>

[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM

https://bugzilla.kernel.org/show_bug.cgi?id=141741 David Martos changed: What|Removed |Added CC||davidmartos96 at gmail.com --- Comment

[PATCH V2 2/2] drm/imx: Switch to drm_fb_cma_extract_and_attach_fence() helper

Remove the common code from the driver and use the drm_fb_cma_extract_and_attach_fence() helper instead. Moveover, call the helper from prepare_fb() plane hook . Signed-off-by: Marek Vasut Cc: Daniel Vetter Cc: Lucas Stach --- V2: - Rename the function to drm_fb_cma_extract_and_attach_fence()

[PATCH V2 1/2] drm/fb_cma_helper: Add drm_fb_cma_extract_and_attach_fence() helper

Add new drm_fb_cma_extract_and_attach_fence() helper function extracted from the imx-drm driver. This function checks if the plane has DMABUF attached to it, extracts the exclusive fence from it and attaches it to the plane state for the atomic helper to wait on it. Signed-off-by: Marek Vasut

[PATCH 2/2] drm/imx: Switch to drm_fb_cma_setup_fence() helper

On 09/28/2016 03:57 PM, Lucas Stach wrote: > Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut: >> Remove the common code from the driver and use the drm_fb_cma_setup_fence() >> helper instead. Moveover, call the helper from prepare_fb() plane hook . >> >> Signed-off-by: Marek Vasut >>

[PATCH 1/2] drm/fb_cma_helper: Add drm_fb_cma_setup_fence() helper

On 09/28/2016 03:55 PM, Lucas Stach wrote: > Hi Marek, > > Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut: >> Add new drm_fb_cma_setup_fence() helper function extracted from the >> imx-drm driver. This function checks if the plane has DMABUF attached >> to it and if so, sets up the

linux-next: Tree for Sep 28 (drivers/gpu/drm/amd/amdgpu/amdgpu.ko)

ove-DRM_AMD_POWERPLAY.patch Type: application/octet-stream Size: 5600 bytes Desc: 0001-drm-amdgpu-remove-DRM_AMD_POWERPLAY.patch URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/1382d16c/attachment-0001.obj>

[PATCH] drm: Add frame CRC debugfs files only for drivers that have CRTC

vgem does not do modeset, looping through non-existent CRTC's while registering drm_minor in 'commit 48c787899882 ("drm: Add API for capturing frame CRCs")' caused kernel oops. So, let's add CRC debugfs files only for those drivers that do modeset. Signed-off-by: Dhinakaran Pandiyan

[Bug 76490] Hang during boot when DPM is on (R9 270X)

e receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/3d2646b9/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

edesktop.org/archives/dri-devel/attachments/20160928/f32ddfa7/attachment.html>

[PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

ERLACE) { > if (adjust_flags & CRTC_INTERLACE_HALVE_V) { > p->crtc_vdisplay /= 2; > p->crtc_vsync_start /= 2; > p->crtc_vsync_end /= 2; > p->crtc_vtotal /= 2; > } > } That would require setting up the adjust_flags, and I thought in the DRM we were trying to move away from using it. Also it would be pretty strange to use just this one field from crtc_*. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/2cdd9eed/attachment.sig>

[PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

We just needed to initialize a few more fields. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 drivers/gpu/drm/vc4/vc4_regs.h | 3 +++ 3 files changed, 25 insertions(+), 7 deletions(-) diff --git

[PATCH 1/2] drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.

Fixes occasional debug spew at boot when connected directly through HDMI, and probably confusing the HDMI state machine when we go trying to poke registers for the enable sequence too soon. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Inki Dae wrote: > 2016-09-28 18:06 GMT+09:00 Tobias Jakobi : >> Hello Inki, >> >> >> Inki Dae wrote: >>> >>> >>> 2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글: Hey Inki, Inki Dae wrote: > > > 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글:

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

stats for radeonsi. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/4b003535/attachment-0001.html>

[PATCH libdrm] modetest: Allow the user to specify the plane ID

From: Ville Syrjälä Devices can have multiple planes, so allow the user to choose between them. Signed-off-by: Ville Syrjälä --- tests/modetest/modetest.c | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/986d2aa7/attachment.html>

-next trees

On Tue, Sep 27, 2016 at 11:31 PM, Dave Airlie wrote: > Hey all, > > Back from a week off, I've hoovered up everything and backmerged -rc8 on top. > > If I've missed anything please let me know, I haven't seen next trees > for exynos or nouveau, as possibly a few others, but those are the > main

[pull] radeon and amdgpu drm-next-4.9

Hi Dave, Some additional fixes for 4.9: - The rest of Christian's GTT rework which fixes a long standing bug in the GPUVM code among other things - Changes to the pci shutdown callbacks for certain hypervisors - Fix hpd interrupt storms on eDP panels which have the hpd interrupt enabled by

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

From: Ville Syrjälä It's perfectly legal for the sink to support 12bpc only for some lower resolution modes, while the higher resolution modes can only be used with 8bpc. So let's take the sink's max TMDS clock into account before we go and decide that a

[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

From: Ville Syrjälä Reduce the eyesore with a local variable. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[PATCH 08/10] drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()

From: Ville Syrjälä drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't even get

[PATCH 07/10] drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID

From: Ville Syrjälä It's not a good idea to leave stale cea_rev in the drm_display_info. The current EDID might not even have a CEA ext block in which case we'd end up leaving the stale value in place. Signed-off-by: Ville Syrjälä Acked-by: Christian König

[PATCH 06/10] drm/edid: Reduce the number of times we parse the CEA extension block

From: Ville Syrjälä Instead of parsing parts of the CEA extension block in two places to determine supported color formats and whatnot, let's just consolidate it to one function. This also makes it possible to neatly flatten drm_assign_hdmi_deep_color_info().

[PATCH 05/10] drm/edid: Don't pass around drm_display_info needlessly

From: Ville Syrjälä We already pass the connector to drm_add_display_info() and drm_assign_hdmi_deep_color_info(), so passing the connector->display_info also is pointless. Signed-off-by: Ville Syrjälä Acked-by: Christian König ---

[PATCH v2 04/10] drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info

From: Ville Syrjälä We have the drm_display_info for storing information about the sink, so let's move dvi_dual and max_tmds_clock in there. v2: Deal with superfluous code shuffling Document dvi_dual and max_tmds_clock too Cc: Alex Deucher Cc: "Christian

[PATCH v2 03/10] drm/edid: Make max_tmds_clock kHz instead of MHz

From: Ville Syrjälä We generally store clocks in kHz, so let's do that for the HDMI max TMDS clock value as well. Less surpising. v2: Deal with superfluous code shuffling Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä Reviewed-by:

[PATCH 02/10] drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID

From: Ville Syrjälä Clear out old max_tmds_clock and dvi_dual information (possibly from a previous EDID) before parsing the current EDID. Tne current EDID might not even have these in its HDMI VSDB, which would mean that we'd leave the old stale values in place.

[PATCH 01/10] drm/edid: Clear old audio latency values before parsing the new EDID

From: Ville Syrjälä Clear out stale audio latency information (potentially from a previous EDID) before constructing the ELD from the EDID. Signed-off-by: Ville Syrjälä Acked-by: Christian König --- drivers/gpu/drm/drm_edid.c | 7 +++ 1 file changed, 7

[PATCH v2 00/10] drm/edid: Clean up display_info stuff

From: Ville Syrjälä Rebased the series (previous version [1]) mostly due to code shuffling. i915 specific bits still need to be eyeballed by someone. Series available here: git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_4 [1]

[PATCH v5] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

Gamma correction is optional and can be used to adjust the color output values to match the gamut of a particular TFT LCD panel Split the DCU regs into "regs", "palette", "gamma" and "cursor". Create a second regmap for gamma memory space using little endian. The registers after the first address

[PATCH 0/6] drm/exynos: g2d: rework sleep and runtime PM

Dear Tobias, On 2016-09-27 17:50, Tobias Jakobi wrote: > Hello everyone, > > as discussed with Marek I have broken down my initial patch into smaller > piecer. > > Anyway, this series fixes a regression introduced by commit > b05984e21a7e000bf5074ace00d7a574944b2c16. > > With best wishes, >

[PATCH 2/2] drm/imx: Switch to drm_fb_cma_setup_fence() helper

Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut: > Remove the common code from the driver and use the drm_fb_cma_setup_fence() > helper instead. Moveover, call the helper from prepare_fb() plane hook . > > Signed-off-by: Marek Vasut > Cc: Daniel Vetter > Cc: Lucas Stach One nit

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

ied to apply on top of ROCK kernel) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/87addfba/attachment.html>

[PATCH 1/2] drm/fb_cma_helper: Add drm_fb_cma_setup_fence() helper

Hi Marek, Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut: > Add new drm_fb_cma_setup_fence() helper function extracted from the > imx-drm driver. This function checks if the plane has DMABUF attached > to it and if so, sets up the fence on which the atomic helper can wait. > >

[PATCH v2 00/10] drm/edid: Clean up display_info stuff

On Wed, Sep 28, 2016 at 9:51 AM, wrote: > From: Ville Syrjälä > > Rebased the series (previous version [1]) mostly due to code > shuffling. i915 specific bits still need to be eyeballed by someone. > > Series available here: > git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_4 > > [1]

[PATCH] drm: tilcdc: add a workaround for failed clk_set_rate()

URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/5377aea6/attachment-0001.sig>

[PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

Some architectures don't use the common clock framework and don't implement all the clk interfaces for every clock. This is the case for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1. Trying to set the clock rate for the LCDC clock results in -EINVAL being returned. As a

[Bug 97961] radeon: Failed to allocate virtual address for buffer

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/04fde68f/attachment.html>

[Bug 97961] radeon: Failed to allocate virtual address for buffer

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/64f41177/attachment-0001.html>

[PATCH] drm: tilcdc: add a workaround for failed clk_set_rate()

lcd_clk, crtc->mode.clock, clkdiv); > @@ -664,7 +682,6 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc) > tilcdc_set(dev, LCDC_CLK_ENABLE_REG, > LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN | > LCDC_V2_CORE_CLK_EN); > - Extra change here. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/3c81d92d/attachment.sig>

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

errors, but I don't yet see where that would be exactly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/1226e

[PATCH] drm: tilcdc: add a workaround for failed clk_set_rate()

On 09/27/16 18:29, Bartosz Golaszewski wrote: > Some architectures don't use the common clock framework and don't > implement all the clk interfaces for every clock. This is the case > for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1. > > Trying to set the clock rate for the LCDC

[PATCH] drm: tilcdc: add a workaround for failed clk_set_rate()

+ Sekhar 2016-09-28 13:19 GMT+02:00 Tomi Valkeinen : > Hi, > > On 27/09/16 18:29, Bartosz Golaszewski wrote: >> Some architectures don't use the common clock framework and don't >> implement all the clk interfaces for every clock. This is the case >> for da850-lcdk where clk_set_rate() only works

-next trees

Hey all, Back from a week off, I've hoovered up everything and backmerged -rc8 on top. If I've missed anything please let me know, I haven't seen next trees for exynos or nouveau, as possibly a few others, but those are the main two I noticed. Dave.

linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform

[Bug 97887] llvm segfault in janusvr -render vive

shader. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/06291fca/attachment.html>

[Bug 97852] Unreal Engine corrupted preview viewport

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/4c4e4355/attachment.html>

[Bug 173041] New: Nouveau random hangs in g84_gr_tlb_flush (NVIDIA GT240)

https://bugzilla.kernel.org/show_bug.cgi?id=173041 Bug ID: 173041 Summary: Nouveau random hangs in g84_gr_tlb_flush (NVIDIA GT240) Product: Drivers Version: 2.5 Kernel Version: 4.7.4 Hardware: x86-64

[PATCH v4] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

Gamma correction is optional and can be used to adjust the color output values to match the gamut of a particular TFT LCD panel Errata: Gamma_R, Gamma_G and Gamma_B registers are little-endian registers while the rest of the address-space in 2D-ACE is big-endian. Workaround: Split the DCU regs

[PATCH 2/7] drm/doc: Polish for drm_plane.[hc]

On Wed, 28 Sep 2016, Rafael Antognolli wrote: > Hi Daniel, > > On Wed, Sep 21, 2016 at 10:59:25AM +0200, Daniel Vetter wrote: >> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h >> index 1407715736a5..256219bfd07b 100644 >> --- a/include/drm/drm_plane.h >> +++

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Hello Inki, Inki Dae wrote: > > > 2016년 09월 28일 09:12에 Tobias Jakobi 이(가) 쓴 글: >> Hello Inki, >> >> >> Inki Dae wrote: >>> >>> >>> 2016년 09월 28일 08:31에 Inki Dae 이(가) 쓴 글: 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: > Hello

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Hello Inki, Inki Dae wrote: > > > 2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글: >> Hey Inki, >> >> >> Inki Dae wrote: >>> >>> >>> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: Hello Andrzej, Andrzej Hajda wrote: > On 27.09.2016 13:22,

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Inki Dae wrote: > > > 2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글: >> Hey Inki, >> >> >> Inki Dae wrote: >>> >>> >>> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: Hello Andrzej, Andrzej Hajda wrote: > On 27.09.2016 13:22, Tobias Jakobi

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글: > Hey Inki, > > > Inki Dae wrote: >> >> >> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: >>> Hello Andrzej, >>> >>> >>> Andrzej Hajda wrote: On 27.09.2016 13:22, Tobias Jakobi wrote: > Hello Inki, > >

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 26일 20:36에 Tobias Jakobi 이(가) 쓴 글: > Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once > in mixer_cfg_layer(). > Trigger this via atomic flush. > > Changes in v2: > - issue mixer_cfg_layer() in mixer_disable() > - rename fields as suggested by Andrzej > -

[Bug 97917] Enabling sisched gives Assertion `!NodePtr->isKnownSentinel()' failed

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/83f97e9c/attachment.html>

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 28일 09:12에 Tobias Jakobi 이(가) 쓴 글: > Hello Inki, > > > Inki Dae wrote: >> >> >> 2016년 09월 28일 08:31에 Inki Dae 이(가) 쓴 글: >>> >>> >>> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: Hello Andrzej, Andrzej Hajda wrote:

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글: > Hey Inki, > > > Inki Dae wrote: >> >> >> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: >>> Hello Andrzej, >>> >>> >>> Andrzej Hajda wrote: On 27.09.2016 13:22, Tobias Jakobi wrote: > Hello Inki, > >

linux-next: Tree for Sep 28 (drivers/gpu/drm/amd/amdgpu/amdgpu.ko)

On 09/27/16 23:56, Stephen Rothwell wrote: > Hi all, > > Changes since 20160927: > on i386: ERROR: "amd_set_clockgating_by_smu" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! Full randconfig file is attached. -- ~Randy -- next part -- # # Automatically generated

[PATCH] drm/sti: mark symbols static where possible

Yes true, patch from Ville https://lists.freedesktop.org/archives/dri-devel/2016-September/118631.html; already fix patches sent by Baoyou. Vincent On 09/27/2016 09:07 PM, Benjamin Gaignard wrote: > I think that create conflicts with what is already in Vincent pull > request where we have fix

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 28일 08:31에 Inki Dae 이(가) 쓴 글: > > > 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: >> Hello Andrzej, >> >> >> Andrzej Hajda wrote: >>> On 27.09.2016 13:22, Tobias Jakobi wrote: Hello Inki, Inki Dae wrote: > 2016년 09월 26일

[PATCH] drm/vc4: Fix races when the CS reads from render targets.

With the introduction of bin/render pipelining, the previous job may not be completed when we start binning the next one. If the previous job wrote our VBO, IB, or CS textures, then the binning stage might get stale or uninitialized results. Fixes the major rendering failure in glmark2 -b

[PATCH 0/6] drm/exynos: g2d: rework sleep and runtime PM

We would need to review this patch series for -next in a hurry. I have to request git-pull soon. 2016년 09월 28일 00:50에 Tobias Jakobi 이(가) 쓴 글: > Hello everyone, > > as discussed with Marek I have broken down my initial patch into smaller > piecer. > > Anyway, this series fixes a

[PATCH 2/7] drm/doc: Polish for drm_plane.[hc]

On Wed, Sep 28, 2016 at 11:11:52AM +0300, Jani Nikula wrote: > On Wed, 28 Sep 2016, Rafael Antognolli wrote: > > Hi Daniel, > > > > On Wed, Sep 21, 2016 at 10:59:25AM +0200, Daniel Vetter wrote: > >> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > >> index

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 27일 20:22에 Tobias Jakobi 이(가) 쓴 글: > Hey Inki, > > > Inki Dae wrote: >> 2016년 09월 27일 14:40에 Tobias Jakobi 이(가) 쓴 글: >>> Inki Dae wrote: 2016년 09월 26일 20:36에 Tobias Jakobi 이(가) 쓴 글: > Only manipulate the MXR_CFG and

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: > Hello Andrzej, > > > Andrzej Hajda wrote: >> On 27.09.2016 13:22, Tobias Jakobi wrote: >>> Hello Inki, >>> >>> >>> Inki Dae wrote: 2016년 09월 26일 20:36에 Tobias Jakobi 이(가) 쓴 글: > Only manipulate the MXR_CFG

[Bug 97857] card detects non-existent monitor on display port

uts, the regression happened between upstream versions 4.5.1 and 4.5.5. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/12

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

y here. But that doesn't mean nothing can be done about the shader compilation issue. -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Hello Inki, Inki Dae wrote: > > > 2016년 09월 28일 08:31에 Inki Dae 이(가) 쓴 글: >> >> >> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: >>> Hello Andrzej, >>> >>> >>> Andrzej Hajda wrote: On 27.09.2016 13:22, Tobias Jakobi wrote: > Hello Inki, > > >

[PATCH 0/6] drm/exynos: g2d: rework sleep and runtime PM

Hello, Inki Dae wrote: > We would need to review this patch series for -next in a hurry. > I have to request git-pull soon. I just want to point out that I have yet to test the split series. Currently it's only compile-tested. But I have done a stress test with both sync and async execution

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

Hey Inki, Inki Dae wrote: > > > 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글: >> Hello Andrzej, >> >> >> Andrzej Hajda wrote: >>> On 27.09.2016 13:22, Tobias Jakobi wrote: Hello Inki, Inki Dae wrote: > 2016년 09월 26일 20:36에 Tobias Jakobi 이(가)

[PATCH v3 12/20] drm: omapdrm: Prevent processing the same event multiple times

Hi Laurent, On Mon, Sep 19, 2016 at 8:27 PM, Laurent Pinchart wrote: > The vblank interrupt is disabled after one occurrence, preventing the > atomic update event from being processed twice. However, this also > prevents the software frame counter from being updated correctly that > would

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

https://bugs.freedesktop.org/show_bug.cgi?id=97471 --- Comment #8 from Alex Deucher --- Created attachment 126818 --> https://bugs.freedesktop.org/attachment.cgi?id=126818=edit possible fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug.