[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

https://bugs.freedesktop.org/show_bug.cgi?id=103370 --- Comment #45 from Shih-Yuan Lee --- I can still reduplicate this issue on Ubuntu 18.04 by `seq 100 | while read i; do echo Loop $i; DRI_PRIME=1 glxgears -info|head -n2; done`. -- You are receiving this mail because:

[Bug 105515] hw_init of IP block failed

https://bugs.freedesktop.org/show_bug.cgi?id=105515 --- Comment #1 from Edward Kigwana --- Linux version 4.16.0-rc5 (root@i7-tower) (gcc version 7.3.0 (Gentoo 7.3.0 p1.0)) #5 SMP Thu Mar 15 02:57:39 UTC 2018 -- You are receiving this mail because: You are the assignee for

[Bug 105515] hw_init of IP block failed

https://bugs.freedesktop.org/show_bug.cgi?id=105515 Bug ID: 105515 Summary: hw_init of IP block failed Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal

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

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: sound/pci/hda/hda_intel.c between commits: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist") 40088dc4e1ea ("ALSA: hda - Revert power_save option default value") from Linus' tree and commit: 07f4f97d7b4b

[drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58 commit: d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece [15/1373] drm/amdgpu: Add KFD eviction fence config: frv-allyesconfig (attached as .config) compiler: frv-linux-gcc (GCC) 7.2.0 reproduce:

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

On 2018-03-14 08:14, Sean Paul wrote: On Tue, Mar 13, 2018 at 04:57:35PM -0700, Jeykumar Sankaran wrote: On 2018-03-12 13:21, Sean Paul wrote: > On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote: > > On 2018-02-28 11:18, Sean Paul wrote: > > > Instead, shuffle things around so

[Bug 198123] Console is the wrong color at boot with radeon 6670

https://bugzilla.kernel.org/show_bug.cgi?id=198123 --- Comment #37 from sh...@tuta.io --- (In reply to Michel Dänzer from comment #36) > Can you try the latest test patch attached here, and attach the dmesg output > from running with it? With the patch, the background is always black. I guess,

[Bug 105442] Hang when running nine ff lighting shader

https://bugs.freedesktop.org/show_bug.cgi?id=105442 Axel Davy changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop

[PATCH] drm/tilcdc: Fix setting clock divider for omap-l138

This fixes setting the clock divider on the TI OMAP-L138 LCDK board. The clock drivers for OMAP-L138 are being covernted to the common clock framework. When this happens, clk_set_rate() will no longer return an error. However, on this SoC, the clock rate cannot actually be changed because the

[PULL] drm-intel-fixes

Hi Dave, Here goes drm-intel-fixes-2018-03-14: - 1 display fix for bxt - 1 gem fix for fences - 1 gem/pm fix for rps freq Thanks, Rodrigo. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 14, 2018 at 01:20:06PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities.

[pull] radeon and amdgpu drm-fixes-4.16

Hi Dave, A few fixes for 4.16: - Fix a backlight S/R regression on amdgpu - Fix prime teardown on radeon and amdgpu - DP fix for amdgpu The following changes since commit b0655d668fc4faf0c1985e828820f9b9ca13abe6: Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux into

[PATCH 1/3] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that provides the default implementations of the drm_fb_helper functions for struct fb_ops. Now the driver implements an additional member of the struct fb_ops: .fb_ioctl = drm_fb_helper_ioctl This change is not

[PATCH 0/3] Final round for DRM_FB_HELPER_DEFAULT_OPS usage

Hi folks, this is a follow up patch set to my initial tree wide refactoring Subject: Introduce DRM_FB_HELPER_DEFAULT_OPS for struct fb_ops https://patchwork.freedesktop.org/series/13099/ nearly one and a half year ago. It contains three patches for drivers ast, hisilicon and

[PATCH 3/3] drm/mgag200: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that provides the default implementations of the drm_fb_helper functions for struct fb_ops. Now the driver implements three additional members of the struct fb_ops: .fb_debug_enter = drm_fb_helper_debug_enter,

[PATCH 2/3] drm/hisilicon: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that provides the default implementations of the drm_fb_helper functions for struct fb_ops. Now the driver implements three additional members of the struct fb_ops: .fb_debug_enter = drm_fb_helper_debug_enter,

[Bug 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

https://bugs.freedesktop.org/show_bug.cgi?id=105502 cd changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 14, 2018 at 10:40:08AM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities.

Re: [PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

On Wed, Mar 14, 2018 at 11:55 AM, Robert Foss wrote: > Hey John, > > Pushed to master That's great! Thanks so much to you and everyone who provided review input! -john ___ dri-devel mailing list

Re: [PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

Hey John, Pushed to master On 03/14/2018 12:51 AM, John Stultz wrote: This allows for importing buffers allocated from the hikey and hikey960 gralloc implementations. Cc: Marissa Wall Cc: Sean Paul Cc: Dmitry Shmidt Cc: Robert

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Hi Sergei, thanks for review On Wed, Mar 14, 2018 at 08:09:52PM +0300, Sergei Shtylyov wrote: > On 03/13/2018 05:30 PM, Jacopo Mondi wrote: > > > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > > output decoder. > > > > Signed-off-by: Jacopo Mondi

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 03/14/2018 09:04 PM, jacopo mondi wrote: >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel >>> output decoder. >>> >>> Signed-off-by: Jacopo Mondi >> [...] >>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c >>>

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

On Wed, Mar 14, 2018 at 10:21 AM, Emil Velikov wrote: > On 14 March 2018 at 16:47, John Stultz wrote: >> When building AOSP after updating libdrm project to the >> freedesktop/master branch, I've seen the following build errors: >> >>

Re: [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

On Tue, Mar 13, 2018 at 07:24:20PM -0400, Lyude Paul wrote: > On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote: > > On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote: > > > While having the modeset_retry_work in intel_connector makes sense with > > > SST, this paradigm doesn't make

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

On 14 March 2018 at 16:47, John Stultz wrote: > When building AOSP after updating libdrm project to the > freedesktop/master branch, I've seen the following build errors: > > external/libdrm/intel/Android.mk: error: libdrm_intel > (SHARED_LIBRARIES android-arm64) missing

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 03/13/2018 05:30 PM, Jacopo Mondi wrote: > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > output decoder. > > Signed-off-by: Jacopo Mondi [...] > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c > b/drivers/gpu/drm/bridge/thc63lvd1024.c

[PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

When building AOSP after updating libdrm project to the freedesktop/master branch, I've seen the following build errors: external/libdrm/intel/Android.mk: error: libdrm_intel (SHARED_LIBRARIES android-arm64) missing libpciaccess (SHARED_LIBRARIES android-arm64) You can set

[PATCH 18/47] fbdev: s1d13xxxfb: remove m32r specific hacks

The m32r architecture is being removed, so this is no longer needed. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/s1d13xxxfb.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c index

[PATCH 17/47] fbdev: remove blackfin drivers

The blackfin architecture is getting removed, this removes the associated fbdev drivers as well. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/Kconfig| 103 drivers/video/fbdev/Makefile | 5 - drivers/video/fbdev/bf537-lq035.c | 891

[PATCH 16/47] video/logo: remove obsolete logo files

The blackfin and m32r architectures are getting removed, so it's time to clean up the logos as well. Signed-off-by: Arnd Bergmann --- drivers/video/logo/Kconfig | 15 - drivers/video/logo/Makefile |3 - drivers/video/logo/logo.c

Re: [PATCH] drm/bridge: dw-hdmi: Remove unused hdmi_enable_overflow_interrupts()

Hi Laurent, On Mon, Feb 19, 2018 at 4:50 PM, Laurent Pinchart wrote: > Hi Fabio, > > Thank you for the patch. > > On Friday, 16 February 2018 22:16:10 EET Fabio Estevam wrote: >> From: Fabio Estevam >> >> The cable_plugin member never

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

On Tue, Mar 13, 2018 at 04:57:35PM -0700, Jeykumar Sankaran wrote: > On 2018-03-12 13:21, Sean Paul wrote: > > On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote: > > > On 2018-02-28 11:18, Sean Paul wrote: > > > > Instead, shuffle things around so we kickoff crtc after enabling > >

[maintainer-tools PATCH] doc: how to become a drm-intel committer

Until now, the drm-intel commit access have been handed out ad hoc, without transparency, consistency, or fairness. With pressure to add more committers, this is no longer tenable, if it ever was. Document the requirements and expectations around becoming a drm-intel committer. The Linux kernel

[DPU PATCH] drm/msm: Add pm_runtime_get/put calls to dpu

Ensure that pm_runtime is properly referenced/unreferenced when we need it. Signed-off-by: Sean Paul --- Didn't get a response to my suggestion, so wrote the patch anyways. Thoughts? drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +++

Re: [PATCH 3/3] drm: Store the calculated vrefresh in the user mode

On Tue, Mar 13, 2018 at 08:04:03PM +0100, Maarten Lankhorst wrote: > Op 13-03-18 om 16:07 schreef Ville Syrjala: > > From: Ville Syrjälä > > > > Ignore the vrefresh in the mode the user passed in and instead > > calculate the value based on the actual timings. This

Re: [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Do the refresh rate calculation with a single division. This gives > > us slightly more accurate results,

[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

A lot of Kconfig symbols have architecture specific dependencies. In those cases that depend on architectures we have already removed, they can be omitted. Signed-off-by: Arnd Bergmann --- block/bounce.c | 2 +- drivers/ide/Kconfig | 2 +-

[PATCH 00/16] remove eight obsolete architectures

Here is the collection of patches I have applied to my 'asm-generic' tree on top of the 'metag' removal. This does not include any of the device drivers, I'll send those separately to a someone different list of people. The removal came out of a discussion that is now documented at

[Bug 105505] Request for new account

https://bugs.freedesktop.org/show_bug.cgi?id=105505 Daniel Stone changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 105505] Request for new account

https://bugs.freedesktop.org/show_bug.cgi?id=105505 --- Comment #1 from tomi.valkei...@iki.fi --- Created attachment 138104 --> https://bugs.freedesktop.org/attachment.cgi?id=138104=edit GPG pub key -- You are receiving this mail because: You are the assignee for the

[Bug 105505] Request for new account

https://bugs.freedesktop.org/show_bug.cgi?id=105505 Bug ID: 105505 Summary: Request for new account Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority:

[PATCH v8 11/11] drm: Add and handle new aspect ratios in DRM layer

From: "Sharma, Shashank" HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise

[PATCH v8 10/11] drm: Add aspect ratio parsing in DRM layer

From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due

[PATCH v8 09/11] drm: Expose modes with aspect ratio, only if requested

From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless of whether user space requested this information or not. This patch prunes the modes with aspect-ratio

[PATCH v8 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes

[PATCH v8 07/11] drm: Handle aspect-ratio info in getblob

From: Ankit Nautiyal If the user-space does not support aspect-ratio, then getblob called with the blob id of a user-mode, should clear the aspect-ratio information in the blob data. Currently for a given blob id, there is no way to determine if the blob stores

[PATCH v8 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths

From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not

[PATCH v8 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes

From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the

[PATCH v8 06/11] drm: Add DRM client cap for aspect-ratio

From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm

[PATCH v8 05/11] video/hdmi: Reject illegal picture aspect ratios

From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma

[PATCH v8 03/11] drm/edid: Fix cea mode aspect ratio handling

From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's

[PATCH v8 01/11] drm/modes: Introduce drm_mode_match()

From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma ---

[PATCH v8 00/11] Aspect ratio support in DRM layer

From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series

Re: [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Do the refresh rate calculation with a single division. This gives > us slightly more accurate results, especially for interlaced since > we don't just double the final

[Bug 199115] New: [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081

https://bugzilla.kernel.org/show_bug.cgi?id=199115 Bug ID: 199115 Summary: [gma500] BUG: unable to handle kernel NULL pointer dereference at 0081 Product: Drivers Version: 2.5 Kernel Version: 4.15.7-300.fc27.x86_64

[Bug 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

https://bugs.freedesktop.org/show_bug.cgi?id=105502 --- Comment #1 from Harry Wentland --- Created attachment 138100 --> https://bugs.freedesktop.org/attachment.cgi?id=138100=edit [PATCH] drm/amd/display: Fix null pointer when setting backlight My bad for pushing a

Re: [PATCH 0/3] drm/rockchip: VOP interrupt fixes

Am Dienstag, 20. Februar 2018, 14:01:17 CET schrieb Marc Zyngier: > This small series fixes a number of issues that I found while trying > to get kexec working on the Chromebook Plus (aka rk3399-gru-kevin) in > order to use it as some sort of interactive bootloader. > > The main issue is that the

[Bug 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

https://bugs.freedesktop.org/show_bug.cgi?id=105502 Bug ID: 105502 Summary: HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level Product: DRI Version: DRI git Hardware: x86-64 (AMD64)

Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

Am Freitag, 9. März 2018, 23:22:57 CET schrieb Enric Balletbo i Serra: > From: zain wang > > We currently wait for the panel to mirror our intended PSR state > before continuing on both PSR enter and PSR exit. This is really > only important to do when we're entering PSR,

[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime

https://bugs.freedesktop.org/show_bug.cgi?id=105369 cd changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

Quoting Salvatore Mesoraca (2018-03-13 21:51:28) > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a false > positives with

Re: [PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > The Innolux P097PFG panel is 9.7" panel with 1536X2048 > resolution, it reuse P079ZCA panel driver, so improve > p079ZCA dt-binding to support P097PFG. > > Change-Id:

Re: [PATCH v4 2/3] drm/panel: support Innolux P097PFG panel

On 14 March 2018 at 09:12, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse > the Innolux P079ZCA panel driver. > > Change-Id: I97923aa3735f707332681691b0231c9421b427d0 > Signed-off-by: Lin Huang > --- > Changes in v2: >

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

On Tue, 13 Mar 2018, Salvatore Mesoraca wrote: > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi Lin, On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2 > Signed-off-by: Lin Huang >

Re: [Patch 4/4] drm/omap: Add virtual plane support to omap_plane

Hi Benoit, On 02/03/18 15:48, Benoit Parrot wrote: > Add virtual plane support by adding an array to contain > all of the actual plane_id a "omap_plane" correspond to. "plane_ids", "an", "corresponds" > When at least one 'plane' child node is present in DT then > omap_plane_init will only used

Re: [PATCH][next] drm/amd/pp: remove redundant pointer internal_buf

Apply it and thanks. Best Regards Rex From: Colin King Sent: Tuesday, March 13, 2018 9:22 PM To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); David Airlie; Zhu, Rex; amd-...@lists.freedesktop.org;

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

On 09/03/18 20:27, Benoit Parrot wrote: >> Is logical plane a h/w concept? > > It does represent a hardware resource. Logical plane is not a hw concept, it just describes a group of one or two HW planes. Then again, in the context of 2k+ displays, two HW planes must always be used together, so

Re: [Patch 3/4] drm/omap: Add virtual plane DT parsing support

Hi Benoit, On 02/03/18 15:48, Benoit Parrot wrote: > Virtual planes are used to extend display size capability for display > larger than 2048 pixels by splitting the frame buffer equally between > two physical planes. > > Here we are adding DT support to parse 'plane' child nodes which >

Re: [PATCH] drm/vc4: Add support for SAND modifier.

Hey Eric, On 3 March 2018 at 01:34, Eric Anholt wrote: > Ccing a couple of folks who are likely to have opinions about > drm_fourcc.h additions (Do we have enough docs? Are the macros OK?), > and Bootlin who are likely reviewers. > > The plan is to use these modifiers in VC4 GL

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA. In this particular > case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local > variable cmdline_size. Also, remove cmdline_size as it is not > actually useful anymore. >

Re: [PATCH] drm/i915/pmu: Work around compiler warnings on some kernel configs

Quoting Tvrtko Ursulin (2018-03-14 08:05:35) > From: Tvrtko Ursulin > > Arnd Bergman reports: > """ > The conditional spinlock confuses gcc into thinking the 'flags' value > might contain uninitialized data: > > drivers/gpu/drm/i915/i915_pmu.c: In function

Re: [PATCH] drm/panel: rm68200: add backlight dependency

On Wed, Mar 14, 2018 at 09:49:54AM +0100, Arnd Bergmann wrote: > On Wed, Mar 14, 2018 at 12:01 AM, Thierry Reding > wrote: > > On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote: > >> Like many other panel drivers, this one fails to build > >> when backlight

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 --- Comment #3 from Balázs Vinarz --- Created attachment 138097 --> https://bugs.freedesktop.org/attachment.cgi?id=138097=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 --- Comment #4 from Balázs Vinarz --- Created attachment 138098 --> https://bugs.freedesktop.org/attachment.cgi?id=138098=edit xrandr -- You are receiving this mail because: You are the assignee for the

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 --- Comment #2 from Balázs Vinarz --- Created attachment 138096 --> https://bugs.freedesktop.org/attachment.cgi?id=138096=edit glxinfo -- You are receiving this mail because: You are the assignee for the

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 --- Comment #1 from Balázs Vinarz --- Created attachment 138095 --> https://bugs.freedesktop.org/attachment.cgi?id=138095=edit dmidecode -- You are receiving this mail because: You are the assignee for the

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 Bug ID: 105500 Summary: AMD Richland (ARUBA) no screen at DP output when using three displays Product: DRI Version: unspecified Hardware: x86-64 (AMD64)

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

Am Freitag, 9. März 2018, 23:22:56 CET schrieb Enric Balletbo i Serra: > From: zain wang > > We would meet a short black screen when exit PSR with the full link > training, In this case, we should use fast link train instead of full > link training. > > Signed-off-by: zain

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

Am Freitag, 9. März 2018, 23:22:54 CET schrieb Enric Balletbo i Serra: > From: zain wang > > There is a race between AUX CH bring-up and enabling bridge which will > cause link training to fail. To avoid hitting it, don't change psr state > while enabling the bridge. > >

Re: [PATCH v5 04/36] drm/rockchip: add mutex vop lock

Am Freitag, 9. März 2018, 23:22:55 CET schrieb Enric Balletbo i Serra: > From: zain wang > > Add a lock to vop to avoid disabling the crtc while waiting for a line > flag while enabling psr. If we disable in the middle of waiting for the > line flag, we'll end up timing out

Re: [PATCH v5 02/36] drm/rockchip: Remove analogix psr worker

Am Freitag, 9. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra: > From: Sean Paul > > Now that the spinlocks and timers are gone, we can remove the psr > worker located in rockchip's analogix driver and do the enable/disable > directly. This should simplify the code

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Am Freitag, 9. März 2018, 23:22:52 CET schrieb Enric Balletbo i Serra: > From: Yakir Yang > > Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() > function, or print the sink PSR error state if we failed to apply the > requested PSR setting. > > Cc:

Re: [PATCH] ARM: dts: sun8i-h3: Add Mali node

Hi, Il 14/03/2018 09:05, Maxime Ripard ha scritto: On Tue, Mar 13, 2018 at 11:16:45AM +0100, Giulio Benetti wrote: The H3 has an ARM Mali 400 GPU, so add binding to our DT. Signed-off-by: Giulio Benetti How was this tested? I wanted you asked me about

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Hi Andrzej, thanks for review On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote: > On 13.03.2018 15:30, Jacopo Mondi wrote: > > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > > output decoder. > > IMO converter suits here better, but it is just suggestion.

Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

Hi Stefan, On Tue, Mar 13, 2018 at 07:20:33PM +0100, Stefan Schake wrote: > Hey Alexandru, > > On Tue, Mar 13, 2018 at 5:21 PM, Alexandru Gheorghe > wrote: > > This patchset tries to add support for using writeback connector to > > flatten a scene when it

Re: [PATCH v2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE

On Tue, Mar 13, 2018 at 06:54:37PM +0100, Giulio Benetti wrote: > Handle both positive and negative dclk polarity, > according to bus_flags, taking care of this: > > On A20 and similar SoCs, the only way to achieve Positive Edge > (Rising Edge), is setting dclk clock phase to 2/3(240°). > By

Re: [PATCH v2] drm/sun4i: move rgb mode_valid from connector to encoder

On Tue, Mar 13, 2018 at 12:36:57PM +0100, Giulio Benetti wrote: > mode_valid function must be connected to encoder. > Otherwise it could get not be called by drm in the case there's a > bridge connected to encoder instead of a panel. > > Move mode_valid function pointer to encoder helper

Re: [PATCH v2] drm/sun4i: add lvds mode_valid function

On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote: > mode_valid function is missing for lvds. > > Add it making it pointed by encoder helper functions. > > Signed-off-by: Giulio Benetti Applied, thanks! Maxime -- Maxime Ripard, Bootlin (formerly

[Bug 198123] Console is the wrong color at boot with radeon 6670

https://bugzilla.kernel.org/show_bug.cgi?id=198123 --- Comment #36 from Michel Dänzer (mic...@daenzer.net) --- (In reply to shibe from comment #35) > Has the cause of this issue been identified/confirmed? Not yet, unfortunately. > On boot I have grey console background instead of black. Can

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

Hi Andrzej, sorry for the mess :( On Wed, Mar 14, 2018 at 09:15:42AM +0100, Andrzej Hajda wrote: > On 13.03.2018 15:30, Jacopo Mondi wrote: > > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > > > Signed-off-by: Jacopo Mondi > > --- > >

[GIT PULL] omapdrm changes for v4.17, try 2

Hi Dave, Here's the omapdrm pull request with the compile errors fixed. I found another one while going through different kconfig combinations. Sorry about those. I think it's time to build a script to compile with all the possible combinations... Tomi The following changes since commit

Re: [PATCH] drm/panel: rm68200: add backlight dependency

On Wed, Mar 14, 2018 at 12:01 AM, Thierry Reding wrote: > On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote: >> Like many other panel drivers, this one fails to build >> when backlight support is disabled: >> >> drivers/gpu/drm/panel/panel-raydium-rm68200.o:

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 13.03.2018 15:30, Jacopo Mondi wrote: > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > output decoder. IMO converter suits here better, but it is just suggestion. > > Signed-off-by: Jacopo Mondi > --- > drivers/gpu/drm/bridge/Kconfig

Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures

On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham wrote: > The use of the packed attribute can cause a performance penalty for > all accesses to the struct members, as the compiler will assume that the > structure has the potential to have an unaligned base.

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

On 13.03.2018 15:30, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 > ++ > 1 file changed, 63 insertions(+) >

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #57 from Nicolai Hähnle (nhaeh...@gmail.com) --- (In reply to Ricardo Ribalda from comment #46) This was due to the constant address space change in LLVM. It has since been fixed in Mesa master. -- You are receiving this mail

Re: linux-next: merge conflict between drm-misc and sound trees

Hi Takashi, On Wed, 14 Mar 2018 08:37:12 +0100 Takashi Iwai wrote: > > FYI, there was yet another fix over the relevant code, but the > conflict resolution must be trivial as well. OK, thanks as well. -- Cheers, Stephen Rothwell pgpiIka6PJOwm.pgp Description: OpenPGP digital

  1   2   >