Re: [PATCH v8 5/6] drm/i915: enable scrambling

On Wed, 2017-03-08 at 19:07 +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

Re: linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681: suspicious mask ?

Hello David, Thanks for report. 2017년 03월 06일 19:05에 David Binderman 이(가) 쓴 글: > Hello there, > > linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681]: (warning) > Result of operator '|' is always true if one operand is non-zero. Did you > intend to use '&'? > Right. this is

Re: [PATCH v2 03/12] drm/exynos/decon5433: fix vblank event handling

On 09.03.2017 04:54, Michel Dänzer wrote: > On 08/03/17 11:58 PM, Andrzej Hajda wrote: >> Current implementation of event handling assumes that vblank interrupt is >> always called at the right time. It is not true, it can be delayed due to >> various reasons. As a result different races can

[Bug 100104] Gallium-9 hitting LLVM assert when trying to start EVE-Online

https://bugs.freedesktop.org/show_bug.cgi?id=100104 --- Comment #3 from Michel Dänzer --- Here is fine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 100104] Gallium-9 hitting LLVM assert when trying to start EVE-Online

https://bugs.freedesktop.org/show_bug.cgi?id=100104 --- Comment #2 from Mathieu Belanger --- Work fine with LLVM4-rc3 ang mesa git so I assume the but is in LLVM. Where do I post LLVM bisect if I do it as I did not yet get a response for manually subscribe to the bugzilla? --

[Bug 99718] RX480 - MCLK stuck at 300

https://bugs.freedesktop.org/show_bug.cgi?id=99718 Mathieu Belanger changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH 15/24] drm/radeon: Merge pre/postclose hooks

On Wed, Mar 8, 2017 at 9:25 AM, Christian König wrote: > Reviewed-by: Christian König for this one and > #19. Applied both. Thanks! Alex > > Christian. > > > Am 08.03.2017 um 15:12 schrieb Daniel Vetter: >> >> Again no apparent explanation

Re: [PATCH v2 03/12] drm/exynos/decon5433: fix vblank event handling

On 08/03/17 11:58 PM, Andrzej Hajda wrote: > Current implementation of event handling assumes that vblank interrupt is > always called at the right time. It is not true, it can be delayed due to > various reasons. As a result different races can happen. The patch fixes > the issue by using

Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch

Hi Heiko and Brain On 03/09/2017 09:02 AM, Heiko Stübner wrote: Am Mittwoch, 8. März 2017, 16:39:23 CET schrieb Brian Norris: On Fri, Feb 10, 2017 at 03:44:13PM +0800, Chris Zhong wrote: There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence only one PHY can connect to DP

[PATCH] intel: fix a conversion format mismatch

To avoid the warning: external/libdrm/intel/intel_bufmgr.c:362:20: warning: more '%' conversions than data arguments [-Wformat] fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n"); ~^ Change-Id: I6c1b0a9e3004aacde0d64662de1144cadff30132 ---

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #1 from Mig --- The same problem occurs when running the mat-mul example taken from https://cgit.freedesktop.org/~tstellar/opencl-example [mig@antergos-mig opencl-example]$ ./mat-mul There are 1 platforms.

Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch

Am Mittwoch, 8. März 2017, 16:39:23 CET schrieb Brian Norris: > On Fri, Feb 10, 2017 at 03:44:13PM +0800, Chris Zhong wrote: > > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence > > only one PHY can connect to DP controller at one time, the other should > > be disconnected. The

Re: [linux-sunxi] [PATCH 14/15] ARM: sun5i: a10s: Add the HDMI controller node

Hi, On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The A10s has an HDMI controller connected to the second TCON channel. Add > it to our DT. > > Signed-off-by: Maxime Ripard > --- > arch/arm/boot/dts/sun5i-a10s.dtsi |

Re: [kbuild-all] 0day 'make htmldocs' testing (was: Re: [PATCH] drm/dp: Add missing description to parameter)

On Wed, Mar 08, 2017 at 10:41:37AM +0200, Jani Nikula wrote: > On Wed, 08 Mar 2017, Jani Nikula wrote: > > On Wed, 08 Mar 2017, Sean Paul wrote: > >> On Tue, Mar 07, 2017 at 09:35:11PM +0100, Tomeu Vizoso wrote: > >>> Gabriel Krisman reported

Re: [PATCH 15/15] ARM: sun5i: a10s-olinuxino: Enable HDMI

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The A10s Olinuxino has an HDMI connector. Make sure we can use it. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai

Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > One of the possible output of the display pipeline, on the SoCs that have > it, is the HDMI controller. > > Add a binding for it. > > Signed-off-by: Maxime Ripard Acked-by:

Re: [PATCH v5 1/5] arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node

On Wed, Mar 08, 2017 at 01:54:08PM +0900, Hoegeun Kwon wrote: > Add the burst and esc clock frequency properties to the parent (DSI node). > Currently the clock is parsed from the port node, while it should be > taken from the dsi node. > > Signed-off-by: Hoegeun Kwon >

[PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD

Currently, the irq handler that monitores changes for HPD anx RX_SENSE relies on the status of the bridge for updating the status of the HPD. The update is done only when the bridge is enabled. However, on Rockchip platforms we have found use cases where it could be a problem. When HDMI is being

Re: [PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

On Mon, Mar 06, 2017 at 03:27:16PM +0530, Archit Taneja wrote: Hi Archit, > Hi, > > On 3/3/2017 9:27 PM, Peter Senna Tschudin wrote: > > The video processing pipeline on the second output on the GE B850v3: > > > > Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output > > >

Re: [PATCH v11 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

On Wed, Mar 08, 2017 at 10:42:37AM +0900, Hoegeun Kwon wrote: > From: Hyungwon Hwang > > This patch add the panel device tree node for S6E3HA2 display > controller to TM2 dts. > > Signed-off-by: Hyungwon Hwang > Signed-off-by: Andrzej Hajda

Re: [PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

Am Mittwoch, den 08.03.2017, 10:42 +0100 schrieb Peter Senna Tschudin: > On Mon, Mar 06, 2017 at 03:27:16PM +0530, Archit Taneja wrote: > Hi Archit, > > > Hi, > > > > On 3/3/2017 9:27 PM, Peter Senna Tschudin wrote: > > > The video processing pipeline on the second output on the GE B850v3: > > >

Re: [PATCH 10/15] drm/sun4i: tcon: Switch mux on only for composite

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > Even though that mux is undocumented, it seems like it needs to be set to 1 > when using composite, and 0 when using HDMI. > > Signed-off-by: Maxime Ripard > --- >

Re: iommu/rockchip: Fix bugs and enable on ARM64

Shunqian, something is depending on these patches, can you resend these patches to solve the compile errors? -Caesar 在 2016年07月16日 00:16, Joerg Roedel 写道: On Fri, Jul 15, 2016 at 05:32:02PM +0200, Matthias Brugger wrote: The drm rockchip patches are dependent on iommu/rockchip patches, can

Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner, tcon-channel property

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The Allwinner Timings Controller has two, mutually exclusive, channels. > When the binding has been introduced, it was assumed that there would be > only a single user per channel in the system. > > While

Re: [PATCH 2/3] drm/etnaviv: move fence allocation out of etnaviv_gpu_submit()

On Wed, Mar 08, 2017 at 11:42:17AM -0300, Gustavo Padovan wrote: > Hi Philipp, > > 2017-03-08 Philipp Zabel : > > > The next patch will need the dma_fence to create the sync_file in > > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. > > > >

Re: [PATCH v5 2/5] arm: dts: Add the burst and esc clock frequency properties to DSI node

On Wed, Mar 08, 2017 at 01:54:09PM +0900, Hoegeun Kwon wrote: > Add the burst and esc clock frequency properties to the parent (DSI node). > Currently the clock is parsed from the port node, while it should be > taken from the dsi node. > > Signed-off-by: Hoegeun Kwon >

Re: linux-next: build failure after merge of the rcu tree

On Wed, Mar 08, 2017 at 11:13:38AM +0100, Daniel Vetter wrote: > On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote: > > Hi Paul, > > > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > In file included from

Re: [PATCH V3 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

On Fri, Mar 03, 2017 at 04:57:10PM +0100, Peter Senna Tschudin wrote: Hi Shawn Guo, Now that the driver and binding are in, can you pick this up? Thank you! > Configures the megachips-stdp-ge-b850v3-fw bridges on the GE > B850v3 dts file. > > Cc: Laurent Pinchart

Re: [PATCH v5 2/5] arm: dts: Add the burst and esc clock frequency properties to DSI node

On Wed, Mar 08, 2017 at 01:54:09PM +0900, Hoegeun Kwon wrote: > Add the burst and esc clock frequency properties to the parent (DSI node). > Currently the clock is parsed from the port node, while it should be > taken from the dsi node. > > Signed-off-by: Hoegeun Kwon >

Re: [PATCH v5 1/5] arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node

On Wed, Mar 08, 2017 at 01:54:08PM +0900, Hoegeun Kwon wrote: > Add the burst and esc clock frequency properties to the parent (DSI node). > Currently the clock is parsed from the port node, while it should be > taken from the dsi node. > > Signed-off-by: Hoegeun Kwon >

Re: [PATCH 8/15] drm/sun4i: tcon: Add channel debug

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > While all functions have debug logs, the channel enable and disable are not > logged. Make sure this is the case. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai

[PATCH] drm/rockchip: Refactor the component match logic.

Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen --- drivers/gpu/drm/rockchip/Kconfig|

Re: [PATCH 11/15] drm/sun4i: tcon: Fix tcon channel 1 backporch calculation

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > It seems like what's called a backporch in the datasheet is actually the > backporch plus the sync period. Fix that in our driver. > > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH 4/5] drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo

On Wed, Mar 8, 2017 at 12:01 AM, Lukas Wunner wrote: > On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote: >> On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner wrote: >> > An external Thunderbolt GPU can neither drive the laptop's panel nor be >> > powered

[Bug 100089] Space Run rendering prolems

https://bugs.freedesktop.org/show_bug.cgi?id=100089 --- Comment #2 from Kenneth Graunke --- Also, can you supply an apitrace? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 100089] Space Run rendering prolems

https://bugs.freedesktop.org/show_bug.cgi?id=100089 --- Comment #1 from Kenneth Graunke --- What graphics card(s) are you seeing this issue on? -- You are receiving this mail because: You are the assignee for the bug.___

Re: [PATCH 18/24] drm/etnaviv: switch to postclose

On Wed, Mar 08, 2017 at 05:09:45PM +0100, Lucas Stach wrote: > Am Mittwoch, den 08.03.2017, 15:12 +0100 schrieb Daniel Vetter: > > I didn't spot anything that would require ordering here (well not > > anywhere else either), and I'm trying to unify at least modern > > drivers > > on one close hook.

Re: [PATCH v8 5/6] drm/i915: enable scrambling

Regards Shashank On 3/8/2017 7:56 PM, Ville Syrjälä wrote: On Wed, Mar 08, 2017 at 07:50:45PM +0200, Sharma, Shashank wrote: Regards Shashank On 3/8/2017 7:44 PM, Ville Syrjälä wrote: On Wed, Mar 08, 2017 at 07:26:45PM +0200, Sharma, Shashank wrote: Regards Shashank On 3/8/2017 7:17

Re: [PATCH v8 5/6] drm/i915: enable scrambling

On Wed, Mar 08, 2017 at 07:50:45PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/8/2017 7:44 PM, Ville Syrjälä wrote: > > On Wed, Mar 08, 2017 at 07:26:45PM +0200, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 3/8/2017 7:17 PM, Ville Syrjälä wrote:

Re: [PATCH v8 5/6] drm/i915: enable scrambling

Regards Shashank On 3/8/2017 7:44 PM, Ville Syrjälä wrote: On Wed, Mar 08, 2017 at 07:26:45PM +0200, Sharma, Shashank wrote: Regards Shashank On 3/8/2017 7:17 PM, Ville Syrjälä wrote: On Wed, Mar 08, 2017 at 07:07:48PM +0530, Shashank Sharma wrote: Geminilake platform sports a native

Re: [PATCH v8 5/6] drm/i915: enable scrambling

On Wed, Mar 08, 2017 at 07:26:45PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/8/2017 7:17 PM, Ville Syrjälä wrote: > > On Wed, Mar 08, 2017 at 07:07:48PM +0530, Shashank Sharma wrote: > >> Geminilake platform sports a native HDMI 2.0 controller, and is > >> capable of

Re: [PATCH v8 5/6] drm/i915: enable scrambling

Regards Shashank On 3/8/2017 7:17 PM, Ville Syrjälä wrote: On Wed, Mar 08, 2017 at 07:07:48PM +0530, Shashank Sharma wrote: Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher

Re: [PATCH v8 5/6] drm/i915: enable scrambling

On Wed, Mar 08, 2017 at 07:07:48PM +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

The calculation of the framebuffer's start address was wrongly using the CRTC's x and y position rather than the one of the source framebuffer. To fix that we need to update the plane_check code to call drm_plane_helper_check_state() to clip the src and dst coordinates. While there so some minor

Re: [PATCH 18/24] drm/etnaviv: switch to postclose

Am Mittwoch, den 08.03.2017, 15:12 +0100 schrieb Daniel Vetter: > I didn't spot anything that would require ordering here (well not > anywhere else either), and I'm trying to unify at least modern > drivers > on one close hook. > > Cc: Lucas Stach > Cc: Russell King

Re: [PATCH 12/24] drm/i915: Merge pre/postclose hooks

On Wed, Mar 08, 2017 at 03:07:48PM +, Chris Wilson wrote: > On Wed, Mar 08, 2017 at 03:12:45PM +0100, Daniel Vetter wrote: > > There's really not a reason afaics that we can't just clean up > > everything at the end, in the terminal postclose hook: Since this is > > closing a file descriptor

[PATCH v3 1/3] drm: Add mode_config .get_format_info() hook

From: Ville Syrjälä Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent) Don't pass 'dev' to the new hook (Laurent) v3:

[PATCH v4 2/3] drm/i915: Implement .get_format_info() hook for CCS

From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are

[PATCH v2 0/3] drm/i915: SKL+ render decompression support

From: Ville Syrjälä Here's the remainder of CCS scanout support. All the i915 prep stuff has now landed, and we're left with just these three patches. What's changed since the last time? * CCS tile is now considered to be 128Bx32 since Jason wants it that way * A

[PATCH v3 3/3] drm/i915: Add render decompression support

From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are

Re: [Intel-gfx] [PATCH 01/24] drm/doc: Add todo about connector_list_iter

On Wed, Mar 08, 2017 at 03:12:34PM +0100, Daniel Vetter wrote: > At least radeon, amdgpu and nouveau should be converted. We have > patches for i915 already. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 13 + > 1 file changed, 13

Re: [PATCH 3/3] drm/qxl: Remove qxl_debugfs_remove_files()

On Wed, Mar 08, 2017 at 12:33:01PM +0100, Gerd Hoffmann wrote: > On Mi, 2017-03-08 at 10:52 +0100, Daniel Vetter wrote: > > On Wed, Mar 08, 2017 at 08:45:13AM +0100, Gerd Hoffmann wrote: > > > On Di, 2017-03-07 at 21:49 +0100, Noralf Trønnes wrote: > > > > drm_debugfs_cleanup() now removes all

Re: [PATCH 12/24] drm/i915: Merge pre/postclose hooks

On Wed, Mar 08, 2017 at 03:12:45PM +0100, Daniel Vetter wrote: > There's really not a reason afaics that we can't just clean up > everything at the end, in the terminal postclose hook: Since this is > closing a file descriptor we know no one else can have a reference or > a thread doing something

Re: [PATCH 09/24] drm: Extract drm_file.h

2017-03-08 Daniel Vetter : > I'm torn on whether drm_minor really should be here or somewhere else. > Maybe with more clarity after untangling drmP.h more this is easier to > decide, for now I've put a FIXME comment right next to it. Right now > we need struct drm_minor

Re: [Intel-gfx] [PATCH 07/24] drm: rename drm_fops.c to drm_file.c

2017-03-08 Daniel Vetter : > It's not just file ops, but drm_file stuff in general. This is prep > work to extracting a drm_file.h header in the next patch. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-internals.rst| 4

Re: [Intel-gfx] [PATCH 05/24] drm: Remove drmP.h include from drm_kms_helper_common.c

2017-03-08 Daniel Vetter : > An easy one as a drive-by. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_kms_helper_common.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git

[PATCH v2 10/12] drm/exynos: set plane possible_crtcs in exynos_plane_init

All Exynos planes are assigned to exactly one CRTC, it allows to simplify initialization by moving setting of possible_crtcs to exynos_plane_init. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-

Re: [Intel-gfx] [PATCH 04/24] drm: Extract drm_pci.h

2017-03-08 Daniel Vetter : > Just another step in finally making drmP.h obsolete. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_pci.c | 7 + > include/drm/drmP.h| 43 +++--- > include/drm/drm_pci.h

[PATCH v2 03/12] drm/exynos/decon5433: fix vblank event handling

Current implementation of event handling assumes that vblank interrupt is always called at the right time. It is not true, it can be delayed due to various reasons. As a result different races can happen. The patch fixes the issue by using hardware frame counter present in DECON to serialize

[PATCH v2 11/12] drm/exynos: kill pipe field from drivers contexts

Since possible_crtcs are set by Exynos core helper pipe fields have no raison d'etre. The only place it was used, as a hack, is fimd_clear_channels, to avoid calling drm_crtc_handle_vblank, but DRM core has already other protection mechanism (vblank->enabled), so it could be safely removed.

[PATCH v2 09/12] drm/exynos: kill exynos_drm_private::pipe

The field duplicates drm_dev->mode_config.num_crtc. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 -- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 11 ++- drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---

[PATCH v2 07/12] drm/exynos/decon5433: fix software trigger mask

The patch fixes copy/paste bug introduced during code refactoring. Reported-by: Dan Carpenter Fixes: b93c2e8b5d9d ("drm/exynos/decon5433: configure sysreg in case of hardware trigger")Fixes: Signed-off-by: Andrzej Hajda ---

[PATCH v2 12/12] drm/exynos: kill mode_set_nofb callback

All Exynos CRTCs are fully configured by .enable callback. The only users of mode_set_nofb actually did nothing in their callbacks - they immediately returned because devices were in suspend state - mode_set_nofb is always called on disabled device. Signed-off-by: Andrzej Hajda

[PATCH v2 08/12] drm/exynos: kill exynos_drm_crtc::pipe

Since crtc index is stored in drm_crtc pipe field became redundant. The patch beside removing the field simplifies also exynos_drm_crtc_get_pipe_from_type. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--

[PATCH v2 04/12] drm/exynos/decon5433: implement frame counter

DECON in Exynos5433 has frame counter, it can be used to implement get_vblank_counter callback. Signed-off-by: Andrzej Hajda --- v2: - reuse decon_get_frame_count function already implemented in previous patch --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12

[PATCH v2 00/12] drm/exynos: rework vblank handling

Hi Inki, This patchset fixes long standing issue with occassional page faults or vblank event timeouts on TM2 targets due to delayed vblank handling. DECON driver should now handle properly all scenarios described in drm docs [1][2], at least it was my intention. The patchset also: - adds frame

[PATCH v2 02/12] drm/exynos: simplify completion event handling

All Exynos CRTC drivers shouldn't fail at referencing vblank events, alternate path is actually dead code. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git

[PATCH v2 05/12] drm/exynos/decon5433: signal frame done interrupt at front porch

DECON in case of video mode generates interrupt by default at start of vertical back porch. As this interrupt is used to generate VBLANK events more optimal point is start of vertical front porch. Signed-off-by: Andrzej Hajda ---

[PATCH v2 01/12] drm/exynos: move crtc event handling to drivers callbacks

CRTC event is currently send with next vblank, or instantly in case crtc is being disabled. This approach usually works, but in corner cases it can result in premature event generation. Only device driver is able to verify if the event can be sent. This patch is a first step in that direction - it

[PATCH v2 06/12] drm/exynos/fimd: signal frame done interrupt at front porch

VBLANK interrupt should be signalled as soon as scanout ends, front porch is the best moment. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 15/24] drm/radeon: Merge pre/postclose hooks

Reviewed-by: Christian König for this one and #19. Christian. Am 08.03.2017 um 15:12 schrieb Daniel Vetter: Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runtime pm

Re: [Intel-gfx] [PATCH 03/24] drm: Move drm_lock_data out of drmP.h

2017-03-08 Daniel Vetter : > And remove the semi-kernel-doc stuff, to make sure no one uses this. > > Signed-off-by: Daniel Vetter > --- > include/drm/drmP.h | 15 --- > include/drm/drm_auth.h | 17 + > 2 files

Re: [PATCH 06/24] drm/doc: document fallback behaviour for atomic events

Hi Daniel, Thank you for the patch. On Wednesday 08 Mar 2017 15:12:39 Daniel Vetter wrote: > Worst case if the hw can't support completion signalling in a > race-free way we want the event to be too late, not too early. > > Text adapted from a proposal from Laurent - the other side of how to >

Re: [PATCH 02/24] drm: Extract drm_prime.h

Hi Daniel, 2017-03-08 Daniel Vetter : > Plus a little bit more documentation. > > v2: Untangle the missing forward decls to make drm_prime|gem.h > free-standing. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-mm.rst | 3 ++ >

Re: [PATCH 3/3] drm/etnaviv: submit support for out-fences

Hi Philipp, 2017-03-08 Philipp Zabel : > Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences"). > We increment the minor driver version so userspace can detect explicit > fence support. > > Signed-off-by: Philipp Zabel > --- >

Re: [PATCH 2/3] drm/etnaviv: move fence allocation out of etnaviv_gpu_submit()

Hi Philipp, 2017-03-08 Philipp Zabel : > The next patch will need the dma_fence to create the sync_file in > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. > > Signed-off-by: Philipp Zabel > --- >

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

Hi Philipp, 2017-03-08 Philipp Zabel : > Loosely based on commit f0a42bb5423a ("drm/msm: submit support for > in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have > a flags field yet, so we have to extend the structure and trust that > drm_ioctl will

Re: [PATCH 4/5] drm/amd/display: Add HDMI Stereo 3D (DC) support

I have easy access to an LG 3D television, though I do not have model information handy at the moment. This is the only display I have tested on so far. I have tested all three modes, and in each case the signal is recognized as 3D (the TV pops up a message to this effect), and the content is

[PATCH 22/24] drm: Nerf the preclose callback for modern drivers

With all drivers converted there's only legacy dri1 drivers using it. Not going to touch those, instead just hide it like we've done with other dri1 driver hooks like firstopen. In all this I didn't find any real reason why we'd needed 2 hooks, and having symmetry between open and close just

[PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

Less code ftw. This converts all drivers except the tinydrm helper module. That one needs more work, since it gets the THIS_MODULE reference from tinydrm.ko instead of the actual driver module like it should. Probably needs a similar trick like I used here with generating the entire struct with a

Re: [PATCH 5/5] drm/amd/display: Allow HDMI capabilities over DVI connector (DC)

This did work for me, including stereo 3D, so that is rather disappointing. (DVI output of the card -> DVI/HDMI adapter -> HDMI Cable -> HDMI TV input) Is it that HDMI signaling passing through a DVI connector is dis-allowed on the whole, or is there something more subtle that I am missing?

[PATCH 24/24] drm/gem: Add DEFINE_DRM_GEM_FOPS

Sadly there's only 1 driver which can use it, everyone else is special for some reason: - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't really work but meh. - i915 needs special compat_ioctl handler because regrets. - arcgpu needs to fixup the pgprot because (no idea why

[PATCH 14/24] drm/nouveau: Merge pre/postclose hooks

Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runtime pm refdancing. Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter ---

Re: [PATCH 08/24] drm: Remove DRM_MINOR_CNT

Hi On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter wrote: > This was originally added by David Herrmann for range checks, but > entirely unused. It confused me, so let's remove it. > > Cc: David Herrmann > Signed-off-by: Daniel Vetter

[PATCH 20/24] drm/exynos: Merge pre/postclose hooks

Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runtime pm refdancing. Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc:

[PATCH 07/24] drm: rename drm_fops.c to drm_file.c

It's not just file ops, but drm_file stuff in general. This is prep work to extracting a drm_file.h header in the next patch. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst| 4 ++-- drivers/gpu/drm/Makefile | 2 +-

[PATCH 19/24] drm/amdgpu: Merge pre/postclose hooks

Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runtime pm refdancing. Cc: Alex Deucher Cc: Christian König Cc: amd-...@lists.freedesktop.org

[PATCH 16/24] drm/tegra: switch to postclose

I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Thierry Reding Cc: linux-te...@vger.kernel.org Signed-off-by: Daniel Vetter ---

[PATCH 21/24] drm/msm: Simplify vblank event delivery

The core takes care of handling the send_event vs. close() issues, we can remove that driver code. Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Daniel Vetter ---

[PATCH 18/24] drm/etnaviv: switch to postclose

I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner

[PATCH 10/24] drm: Remove drm_pending_event->pid

We might as well dump the drm_file pointer, that's about as useful a cookie as the pid. Noticed while typing docs for drm_file and friends. Since the only consumer of this is the tracepoints I think we can safely change this - those tracepoints should not be uapi relevant at all. It all goes back

[PATCH 11/24] drm/doc: Document drm_file.[hc]

Well, mostly drm_file.h, and clean up all related things: - I didnt' figure out the difference between preclose and postclose. The existing explanation in drm-internals.rst didn't convince me, since it's also really outdated - we clean up pending DRM events in the core nowadays. I put a

[PATCH 17/24] drm/vgem: switch to postclose

I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vgem/vgem_drv.c | 4

[PATCH 15/24] drm/radeon: Merge pre/postclose hooks

Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runtime pm refdancing. Cc: Alex Deucher Cc: Christian König Cc: amd-...@lists.freedesktop.org

[PATCH 12/24] drm/i915: Merge pre/postclose hooks

There's really not a reason afaics that we can't just clean up everything at the end, in the terminal postclose hook: Since this is closing a file descriptor we know no one else can have a reference or a thread doing something with that drm_file except the close code. Ordering shouldn't matter, as

[PATCH 13/24] drm/msm: switch to postclose

I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Daniel Vetter

[PATCH 04/24] drm: Extract drm_pci.h

Just another step in finally making drmP.h obsolete. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_pci.c | 7 + include/drm/drmP.h| 43 +++--- include/drm/drm_pci.h | 78 +++ 3 files

[PATCH 08/24] drm: Remove DRM_MINOR_CNT

This was originally added by David Herrmann for range checks, but entirely unused. It confused me, so let's remove it. Cc: David Herrmann Signed-off-by: Daniel Vetter --- include/drm/drmP.h | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 09/24] drm: Extract drm_file.h

I'm torn on whether drm_minor really should be here or somewhere else. Maybe with more clarity after untangling drmP.h more this is easier to decide, for now I've put a FIXME comment right next to it. Right now we need struct drm_minor for the inline drm_file type helpers, and so it does kinda

[PATCH 05/24] drm: Remove drmP.h include from drm_kms_helper_common.c

An easy one as a drive-by. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_kms_helper_common.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_kms_helper_common.c b/drivers/gpu/drm/drm_kms_helper_common.c index

  1   2   >