Re: [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

Regards Shashank On 7/12/2017 10:54 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote: LSPCON chips can't pick the HDMI AVI infoframes from direct link. In order to pass AVI infoframes from display controller to LSPCON, we have to write infoframe

Re: [PATCH 02/20] drm/edid: complete CEA modedb(VIC 1-107)

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:30PM +0530, Shashank Sharma wrote: CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64

Re: [PATCH 07/20] drm/edid: parse ycbcr 420 deep color information

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:35PM +0530, Shashank Sharma wrote: CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420

Re: [PATCH 06/20] drm: add helper to validate YCBCR420 modes

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote: YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This

Re: [PATCH 09/20] drm: add helper functions for YCBCR420 handling

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:37PM +0530, Shashank Sharma wrote: This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is

Re: [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote: This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote: To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI

Re: [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote: To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color

Re: [PATCH 08/20] drm: set output colorspace in AVI infoframe

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote: A source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. This patch adds a function to add the

Re: [PATCH 16/20] drm: add function to read vendor OUI

Regads Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote: This patch adds a helper function in DP dual mode layer to read the vendor's IEEE OUI signature from a Dual mode adapter. This will be used to differentiate between

Re: [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

Regards Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:46PM +0530, Shashank Sharma wrote: LSPCON chips support YCBCR420 outputs. To be able to get YCBCR420 output from LSPCON chip, the source should: - Generate YCBCR444 HDMI output - Set AVI infoframes for

Re: [PATCH 19/20] drm/i915: Move AVI infoframe function to DDI layer

Thanks for the review, Ville. My comments, inline. Regards Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:47PM +0530, Shashank Sharma wrote: We have an existing function to prepare AVI infoframes for HDMI, this patch moves that function from HDMI layer, to

[git pull] drm fixes (and mediatek) for 4.13-rc1

Hi Linus, Some fixes tree came in since the main pull request for rc1, primarily i915 and drm-misc and one amd fix. The drm core vblank regression fix is probably the most important thing. I've also added the mediatek feature pull, it wasn't that big and didn't look like it would have any impact

[pull] radeon drm-next-4.13

Hi Dave, Just one small fix for r7xx cards for 4.13. The following changes since commit 00fc2c26bc46a64545cdf95a1511461ea9acecb4: drm: Remove unused drm_file parameter to drm_syncobj_replace_fence() (2017-07-06 15:53:00 +1000) are available in the git repository at:

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

https://bugs.freedesktop.org/show_bug.cgi?id=96868 almo...@gmail.com changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

https://bugs.freedesktop.org/show_bug.cgi?id=96868 --- Comment #30 from almo...@gmail.com --- Testing stable linux 4.12.1 was a mixed bag. 2560x1440p@143.9Hz no longer flickers or causes display corruption, but graphics memory run at full speed and card heats up. It would seem any refresh rate

Re: [PATCH 01/12] drm/amdgpu: implement vm_operations_struct.access

On 13/07/17 02:27 AM, Felix Kuehling wrote: > On 17-07-12 04:01 AM, Michel Dänzer wrote: >> On 12/07/17 02:37 PM, Felix Kuehling wrote: >>> Any comments on this one? >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä wrote: > > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: > > > > > In several instances the driver passes an 'enum pipe' value

[PATCH v4 2/3] drm/panel: Add support for s6e63j0x03 panel driver

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver which uses mipi_dsi bus to communicate with panel. The panel has 320×320 resolution in 1.63" physical panel. This panel is used in Samsung Galaxy Gear 2. Signed-off-by: Inki Dae Signed-off-by: Hyungwon Hwang

[PATCH v4 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using MIPI-DSI interfaces. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda Acked-by: Rob Herring --- .../bindings/display/panel/samsung,s6e63j0x03.txt | 24

[PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

Hi Andrzej, Thank you for your review. The purpose of this patch is add support for s6e63j0x03 AMOLED panel on the rinato board(Samsung Galaxy Gear 2). Changes for V4: - Added Reviewed-by: Andrzej Hajda (2/3 patch). - Fixed the style of macro function. Changes for V3: -

[PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

The display-timing and delay are included in the panel driver. So it should be removed in dts. Signed-off-by: Hoegeun Kwon --- arch/arm/boot/dts/exynos3250-rinato.dts | 22 -- 1 file changed, 22 deletions(-) diff --git

Re: drm: Add missing field copy in compat_drm_version

Hi guys, i was testing this on arm64 base chromeos(with arm32 userspace). and the libdrm crashed: drmVersionPtr drmGetVersion(int fd) { ... memclear(*version); if (drmIoctl(fd, DRM_IOCTL_VERSION, version)) { ... if (version->name_len)

Re: [PATCH v2 3/5] drm/rockchip: vop: move line_flag_num to interrupt registers

On 2017年07月13日 01:54, Sean Paul wrote: On Wed, Jul 12, 2017 at 10:03:46AM +0800, Mark Yao wrote: Again, please add commit message describing the what and why of this change. You can also add: Reviewed-by: Sean Paul Thanks for the review, will fix it at next version.

Re: [PATCH v2 2/5] drm/rockchip: vop: support verify registers with vop version

On 2017年07月13日 01:53, Sean Paul wrote: On Wed, Jul 12, 2017 at 10:03:38AM +0800, Mark Yao wrote: Please add a commit message describing *what* and *why* you are making the change. Got it, I will fix it at next version. Thanks. Signed-off-by: Mark Yao ---

Re: [PATCH v2 1/5] drm/rockchip: vop: get rid of register init table

On 2017年07月13日 00:47, Sean Paul wrote: On Wed, Jul 12, 2017 at 10:03:27AM +0800, Mark Yao wrote: Register init table use un-document define, it is unreadable, And sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for difference chips. While

Re: [PATCH v2 4/5] drm/rockchip: vop: add a series of vop support

On 2017年07月13日 02:33, Sean Paul wrote: On Wed, Jul 12, 2017 at 10:03:54AM +0800, Mark Yao wrote: Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #12 from Shmerl --- May be I'm doing somethin wrong. I tried to record a trace (using Mesa built from source which I load using a script). I recorded a small amount - starting menu first, but when replaying it,

Re: [PATCH 1/6] drm: Add helper to cast DMA-buf to GEM object

Hi Daniel, On 17-07-12 04:11 AM, Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 01:29:22AM -0400, Felix Kuehling wrote: >> Signed-off-by: Felix Kuehling >> --- >> drivers/gpu/drm/drm_prime.c | 25 + >> include/drm/drmP.h | 2 ++ >> 2

[PATCH 1/1] drm/amdgpu: implement vm_operations_struct.access v2

Allows gdb to access contents of user mode mapped BOs. v2: * Add range check * Map only the pages we're accessing rather than the entire BO Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 138 +++-

[Bug 101769] 2X performance regression on Mesa 17.1 vs 17.0

https://bugs.freedesktop.org/show_bug.cgi?id=101769 Bug ID: 101769 Summary: 2X performance regression on Mesa 17.1 vs 17.0 Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

[PATCH for 4.13] cec: cec_transmit_attempt_done: ignore CEC_TX_STATUS_MAX_RETRIES

The switch in cec_transmit_attempt_done() should ignore the CEC_TX_STATUS_MAX_RETRIES status bit. Calling this function with e.g. CEC_TX_STATUS_NACK | CEC_TX_STATUS_MAX_RETRIES is perfectly legal and should not trigger the WARN(1). Signed-off-by: Hans Verkuil --- After

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/12/17 7:19 PM, Mike Galbraith wrote: On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: Some display

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for

Re: [PATCH 4/4] drm/vc4: add HDMI CEC support

On 12/07/17 21:02, Eric Anholt wrote: > Hans Verkuil writes: > >> From: Hans Verkuil >> >> This patch adds support to VC4 for CEC. >> >> To prevent the firmware from eating the CEC interrupts you need to add this >> to >> your config.txt: >> >>

Re: [PATCH 2/4] drm/vc4: prepare for CEC support

On 12/07/17 20:42, Eric Anholt wrote: > Hans Verkuil writes: > >> From: Hans Verkuil >> >> In order to support CEC the hsm clock needs to be enabled in >> vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't >> be able to support

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote: > Daniel, > > Thank you for reviewing the patch in short time. My views are below. > > > On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote: > > On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote: > > > DRM connector

Re: [PATCH 4/4] drm/vc4: add HDMI CEC support

Hans Verkuil writes: > From: Hans Verkuil > > This patch adds support to VC4 for CEC. > > To prevent the firmware from eating the CEC interrupts you need to add this to > your config.txt: > > mask_gpu_interrupt1=0x100 > > Signed-off-by: Hans Verkuil

Re: [PATCH 2/4] drm/vc4: prepare for CEC support

Hans Verkuil writes: > From: Hans Verkuil > > In order to support CEC the hsm clock needs to be enabled in > vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't > be able to support CEC when there is no hotplug detect signal,

Re: [PATCH v2 4/5] drm/rockchip: vop: add a series of vop support

On Wed, Jul 12, 2017 at 10:03:54AM +0800, Mark Yao wrote: > Vop Full framework now has following vops: > IP versionchipname > 3.1 rk3288 > 3.2 rk3368 > 3.4 rk3366 > 3.5 rk3399 big > 3.6 rk3399 lit Below you say little vop is major ==

Re: [PATCH 3/4] drm/vc4: Add register defines for CEC.

Hans Verkuil writes: > From: Eric Anholt > > Basic usage: > > poweron: HSM clock should be running. Set the bit clock divider, > set all the other _US timeouts based on bit clock rate. Bring RX/TX > reset up and then down. > > powerdown: Set RX/TX reset. >

Re: [PATCH v2 3/5] drm/rockchip: vop: move line_flag_num to interrupt registers

On Wed, Jul 12, 2017 at 10:03:46AM +0800, Mark Yao wrote: Again, please add commit message describing the what and why of this change. You can also add: Reviewed-by: Sean Paul > Signed-off-by: Mark Yao > --- >

Re: [PATCH v2 2/5] drm/rockchip: vop: support verify registers with vop version

On Wed, Jul 12, 2017 at 10:03:38AM +0800, Mark Yao wrote: Please add a commit message describing *what* and *why* you are making the change. > Signed-off-by: Mark Yao > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 66 > + >

Re: [PATCH 1/3] drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly

On Wed, 2017-07-12 at 18:51 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On failure drm_atomic_get_private_obj_state() returns and error > pointer instead of NULL. Adjust the checks in the callers to match. > > Cc: sta...@vger.kernel.org >

Re: [PATCH 01/12] drm/amdgpu: implement vm_operations_struct.access

On 17-07-12 04:01 AM, Michel Dänzer wrote: > On 12/07/17 02:37 PM, Felix Kuehling wrote: >> Any comments on this one? >> >> This was requested by the HSA runtime team a long time ago as a >> debugging feature. It allows gdb to access the content of CPU-mapped >> BOs. I imagine this may be useful

Re: [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote: > LSPCON chips can't pick the HDMI AVI infoframes from direct link. > In order to pass AVI infoframes from display controller to LSPCON, > we have to write infoframe packets into vendor specified AUX address. > > Also, LSPCON

Re: [PATCH 09/20] drm: add helper functions for YCBCR420 handling

On Mon, Jul 10, 2017 at 04:48:37PM +0530, Shashank Sharma wrote: > This patch adds helper functions for YCBCR 420 handling. > These functions do: > - check if a given video mode is YCBCR 420 only mode. > - check if a given video mode is YCBCR 420 also mode. > > V2: Added YCBCR functions as

Re: [PATCH 02/20] drm/edid: complete CEA modedb(VIC 1-107)

On Mon, Jul 10, 2017 at 04:48:30PM +0530, Shashank Sharma wrote: > CEA-861-F specs defines new video modes to be used with > HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to > 1-107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to parse new

Re: [PATCH 06/20] drm: add helper to validate YCBCR420 modes

On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote: > YCBCR420 modes are supported only on HDMI 2.0 capable sources. > This patch adds: > - A drm helper to validate YCBCR420-only mode on a particular > connector. This function will help pruning the YCBCR420-only > modes from the

Re: [PATCH 07/20] drm/edid: parse ycbcr 420 deep color information

On Mon, Jul 10, 2017 at 04:48:35PM +0530, Shashank Sharma wrote: > CEA-861-F spec adds ycbcr420 deep color support information > in hf-vsdb block. This patch extends the existing hf-vsdb parsing > function by adding parsing of ycbcr420 deep color support from the > EDID and adding it into display

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote: > To get a YCBCR420 output from intel platforms, we need one > scaler to scale down YCBCR444 samples to YCBCR420 samples. > > This patch: > - Does scaler allocation for HDMI ycbcr420 outputs. > - Programs PIPE_MISC register for

Re: [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote: > This patch checks encoder level support for YCBCR420 outputs. > The logic goes as simple as this: > If the input mode is YCBCR420-only mode: prepare HDMI for > YCBCR420 output, else continue with RGB output mode. > > It checks if

Re: [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote: > To support ycbcr output, we need a pipe CSC block to do > RGB->YCBCR conversion. > > Current Intel platforms have only one pipe CSC unit, so > we can either do color correction using it, or we can perform > RGB->YCBCR conversion.

Re: [PATCH v2 2/3] drm: rcar-du: Fix planes to CRTC assignment when using the VSP

Hi Laurent, Thanks for the patch Only a minor nit on one comment, but aside from that, On 11/07/17 23:29, Laurent Pinchart wrote: > The DU can compose the output of a VSP with other planes on Gen2 > hardware, and of two VSPs on Gen3 hardware. Neither of these features > are supported by the

Re: [PATCH 2/2] drm: rcar-du: Add HDMI outputs to R8A7796 device description

Hi Laurent, This looks good to me. Table 35.1 (in the DU datasheet) certainly shows that there is only an HDMI-IF0 on the M3, but it's amusing that (and I was confused by the fact that) my r8a7796 board (Salvator-X) still has the HDMI1 populated. Of course I presume this is populated to keep the

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > > too much trouble, a bisect would be pretty useful. > > Bisection seemingly went fine, but the result

Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

Hi Laurent, On 28/06/17 19:50, Laurent Pinchart wrote: > Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC > start to CRTC resume") changed the order of the plane commit and CRTC > enable operations to accommodate the runtime PM requirements. However, > this introduced

Re: [PATCH 08/20] drm: set output colorspace in AVI infoframe

On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote: > A source must set output colorspace information in AVI > infoframes, so that the sink can decode upcoming frames > accordingly. > > This patch adds a function to add the output colorspace > information in the AVI infoframes. > >

Re: [PATCH 2/2] drm: rcar-du: Add HDMI outputs to R8A7796 device description

Hi Geert, > Indeed. > > BTW, the M3-W version also has unconnected USB3 and SATA connectors. Thanks for the heads up :) - I've just put a post it note over those, +HDMI1-OUT (or rather the text on the top lid) to prevent any confusion for me down the line. -- Kieran

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > too much trouble, a bisect would be pretty useful. Bisection seemingly went fine, but the result is odd. e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad

Re: [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

On Wed, Jul 12, 2017 at 3:21 AM, Maxime Ripard wrote: > On Mon, Jul 10, 2017 at 04:55:04PM +1000, Jonathan Liu wrote: >> The drm_driver lastclose callback is called when the last userspace >> DRM client has closed. Call drm_fbdev_cma_restore_mode to restore >>

Re: [PATCH v4 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths

On 2017-07-12 09:03, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 02:12:26PM +0200, Peter Rosin wrote: >> On 2017-07-11 10:10, Daniel Vetter wrote: >>> Tiny nit you might want to improve (since you need to respin for my naming >>> bikeshed of the property_replace_blob function anyway):

Re: [PATCH] dt-bindings: display: sunxi: Improve endpoint ID scheme readability

On Wed, Jul 12, 2017 at 3:31 AM, Maxime Ripard wrote: > On Mon, Jul 10, 2017 at 11:48:00PM +0800, Chen-Yu Tsai wrote: >> On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote: >> > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote: >>

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 20:53 +0200, Mike Galbraith wrote: > On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > > too much trouble, a bisect would be pretty useful. > > Vacation -> back to work happens in the very

Re: [PATCH] drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

Hi Jose, On Tue, 2017-06-27 at 15:36 +0100, Jose Abreu wrote: > Currently we expect that clock driver produces the exact same value > as we are requiring. There can, and will, be some deviation however > so we need to take into account that instead of rejecting the mode. > > According to HDMI

Re: [PATCH v2 1/3] drm: rcar-du: Use the VBK interrupt for vblank events

Hi Laurent, On 11/07/17 23:29, Laurent Pinchart wrote: > When implementing support for interlaced modes, the driver switched from > reporting vblank events on the vertical blanking (VBK) interrupt to the > frame end interrupt (FRM). This incorrectly divided the reported refresh > rate by two. Fix

Re: [PATCH 16/20] drm: add function to read vendor OUI

On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote: > This patch adds a helper function in DP dual mode layer to > read the vendor's IEEE OUI signature from a Dual mode adapter. > This will be used to differentiate between different LSPCON > vendors, to address their custom

Re: [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

On Mon, Jul 10, 2017 at 04:48:46PM +0530, Shashank Sharma wrote: > LSPCON chips support YCBCR420 outputs. To be able to get > YCBCR420 output from LSPCON chip, the source should: > - Generate YCBCR444 HDMI output > - Set AVI infoframes for a YCBCR420 output. > > LSPCON FW gets the information

Re: [PATCH 19/20] drm/i915: Move AVI infoframe function to DDI layer

On Mon, Jul 10, 2017 at 04:48:47PM +0530, Shashank Sharma wrote: > We have an existing function to prepare AVI infoframes for HDMI, > this patch moves that function from HDMI layer, to DDI layer, so > that we can reuse the function for DP(LSPCON) displays too. > > This patch: > - Moves the

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 12, 2017 at 9:45 AM, Christian König wrote: > Am 12.07.2017 um 17:53 schrieb Jason Ekstrand: > > [SNIP] > > >> Is that easier than just waiting in the kernel, I'm not sure how >> optimised we need this path to be. >> > > I don't think so. I think it's

[PATCH] drm: rcar-du: Fix comments to comply with the kernel coding style

To avoid mixing comment styles when new comments complying with the kernel coding style are introduced, fix all multiline comments in one go. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 24 --

Re: [PATCH v2 1/5] drm/rockchip: vop: get rid of register init table

On Wed, Jul 12, 2017 at 10:03:27AM +0800, Mark Yao wrote: > Register init table use un-document define, it is unreadable, > And sometimes we only want to update tiny bits, init table > method is not friendly, it's diffcult to reuse for difference > chips. While I'm happy to see the init_table

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB/BSW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 --- Comment #33 from maria guadalupe --- correction* test = igt@gem_reset_stats@defer-hangcheck-blt igt@gem_reset_stats@defer-hangcheck-bsd

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 12.07.2017 um 17:53 schrieb Jason Ekstrand: [SNIP] Is that easier than just waiting in the kernel, I'm not sure how optimised we need this path to be. I don't think so. I think it's more-or-less the same code regardless of how it's done. The advantage of doing it in the kernel

Re: [PATCH v2] fbdev: make get_fb_unmapped_area depends of !MMU

On Wednesday, July 12, 2017 09:43:07 AM Benjamin Gaignard wrote: > Even if CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA flag is selected > do not compile and use get_fb_unmapped_area() if CONFIG_MMU is > also set. This will avoid mmap errors when compiling multi > architectures at same time. > >

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #11 from Philipp Überbacher --- (In reply to Shmerl from comment #10) > Created attachment 132626 [details] > The Witcher 3 crash save (GOG/GOTY version). > > With latest Mesa built from source, it now

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB/BSW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 --- Comment #32 from maria guadalupe --- issue is still present over BDW with the following configuration test = igt@gem_reset_stats@defer-hangcheck-blt

[Bug 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=101768 --- Comment #1 from Luis Botello --- Created attachment 132638 --> https://bugs.freedesktop.org/attachment.cgi?id=132638=edit IGToutput -- You are receiving this mail because: You are the assignee for the

[Bug 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=101768 Bug ID: 101768 Summary: [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang Product: DRI Version: DRI git Hardware: x86-64

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 12, 2017 at 1:39 AM, Dave Airlie wrote: > On 12 July 2017 at 17:39, Christian König wrote: > > Am 11.07.2017 um 17:43 schrieb Jason Ekstrand: > > > > On Tue, Jul 11, 2017 at 12:17 AM, Christian König < > deathsim...@vodafone.de> > > wrote:

Re: [PATCH] drm/amdgpu: Off by one sanity checks

On Wed, Jul 12, 2017 at 3:42 AM, Christian König wrote: > Am 11.07.2017 um 21:53 schrieb Dan Carpenter: >> >> This is just future proofing code, not something that can be triggered >> in real life. We're testing to make sure we don't shift wrap when we >> do "1ull << i"

[PATCH] drm/dp/mst: Use memchr_inv() instead of memcmp() against a zeroed array

From: Ville Syrjälä We have memch_inv(), so no need to memcmp() against a zeroed temp array. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_mst_topology.c | 18 ++ 1 file changed, 10 insertions(+), 8

[PATCH 3/3] drm/atomic: Make private objs proper objects

From: Ville Syrjälä Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector

[PATCH 2/3] drm/atomic: Remove pointless private object NULL state check

From: Ville Syrjälä We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan Reviewed-by: Daniel Vetter Signed-off-by: Ville

[PATCH 1/3] drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly

From: Ville Syrjälä On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: sta...@vger.kernel.org Cc: Dhinakaran Pandiyan Cc: Harry Wentland

Re: [PATCH] fbdev: Nuke FBINFO_MODULE

On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz wrote: > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote:

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

Daniel, Thank you for reviewing the patch in short time. My views are below. On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote: On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote: DRM connector property is created as bitmask to receive HDCP enable/disable request along with

Re: [PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

On 12.07.2017 15:25, Andrzej Hajda wrote: > On 27.06.2017 04:11, Hoegeun Kwon wrote: >> This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver >> which uses mipi_dsi bus to communicate with panel. The panel has >> 320×320 resolution in 1.63" physical panel. This panel is used in >>

Re: [PATCH 2/2] drm: rcar-du: Add HDMI outputs to R8A7796 device description

Hi Kieran, On Wed, Jul 12, 2017 at 3:51 PM, Kieran Bingham wrote: > Table 35.1 (in the DU datasheet) certainly shows that there is only an > HDMI-IF0 > on the M3, but it's amusing that (and I was confused by the fact that) my > r8a7796 board (Salvator-X)

Re: [PATCH v2 3/3] drm/panel: Add support for otm8009a panel driver

On 10.07.2017 11:02, Philippe CORNU wrote: > This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD > panel driver (MIPI-DSI video mode). The panel backlight is > managed through the DSI link. This panel driver is used in > several STM32 boards. > > Signed-off-by: Philippe CORNU

[RFC 3/7] drm/fb-helper: Support shadow buffer with deferred io

This adds support for using a shadow buffer for fbdev that is copied to the real buffer during dirty flushing. shmem buffers doesn't work with the fbdev deferred io functions, because it touches page->mapping and page->lru. Signed-off-by: Noralf Trønnes ---

[RFC 5/7] drm: Add library for shmem backed GEM objects

This adds a library for shmem backed GEM objects with the necessary drm_driver callbacks. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Kconfig| 6 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem_shmem_helper.c | 628

[RFC 7/7] drm/tinydrm: Switch from CMA to shmem buffers

This move makes tinydrm useful for more drivers. tinydrm doesn't need continous memory, but at the time it was convinient to use the CMA library. The spi core can do dma on vmalloc addresses making this possible. Signed-off-by: Noralf Trønnes ---

[RFC 4/7] drm/fb-helper: Add simple init/fini functions

This adds some simple init/fini/fb_probe helpers for drivers that don't need anything special in their fbdev emulation. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 208 include/drm/drm_fb_helper.h | 42

[RFC 2/7] drm: Add GEM backed framebuffer library

Add a library for drivers that can use a simple representation of a GEM backed framebuffer. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_fb_gem_helper.c | 248

[RFC 0/7] drm: Add shmem GEM library

This patchset adds a library for shmem backed GEM objects. I'm putting out an rfc to find out if I'm on the right track with this. The shmem library is very similar to the cma library, so I have tried to pull out the common bits. A couple of questions: - What should the default cache mode be? -

[RFC 1/7] drm/gem: Add drm_gem_dumb_map_offset()

Add a common drm_driver.dumb_map_offset function for GEM backed drivers. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_gem.c | 35 +++ include/drm/drm_gem.h | 2 ++ 2 files changed, 37 insertions(+) diff --git

[RFC 6/7] drm: Add kms library for shmem backed GEM

This adds kms helpers for the shmem gem library. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Kconfig | 11 +++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_fb_shmem_helper.c | 168 ++

Re: [PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

On 27.06.2017 04:11, Hoegeun Kwon wrote: > This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver > which uses mipi_dsi bus to communicate with panel. The panel has > 320×320 resolution in 1.63" physical panel. This panel is used in > Samsung Galaxy Gear 2. > > Signed-off-by: Inki Dae

Re: [PATCH] fbdev: Nuke FBINFO_MODULE

On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > > > Instead check info->ops->owner, which amounts to the same. > > > > > > Spotted because I

  1   2   3   >