Re: [PATCH] drm/mediatek: check for comp->funcs

Hi, Hsin-yi: On Thu, 2020-01-09 at 15:29 +0800, Hsin-Yi Wang wrote: > There might be some comp that doesn't have funcs, eg. hdmi-connector. > Check for comp->funcs otherwise there will be NULL pointer dereference > crash. > > Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to

[PATCH] drm/v3d: Fix a double free in the ioctl

This code used to leak "bin" but then we accidentally merged two fixes so now it's a double free. Fixes: 77e0723bd27f ("Merge v5.4-rc7 into drm-next") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/v3d/v3d_gem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/v3d/v3d_gem.c

Re: [PATCH -next] drm/mgag200: Fix typo in parameter description

On Fri, Jan 10, 2020 at 01:25:23AM +, Wei Yongjun wrote: > Fix typo in parameter description. > This commit message isn't totally clear. Maybe say something like: There was a typo in the MODULE_PARM_DESC(). It said that the module parameter was "modeset" but it's actually the description

[PATCH libdrm] meson.build: Don't detect header for linux

The header is not required for Linux and GNU libc 2.30 starts to warn about Linux specific header deprecation. Don't detect header for linux. Signed-off-by: Seung-Woo Kim --- Fix meson.build script instead of code itself as commented below: https://patchwork.kernel.org/patch/11325345/ ---

[git pull] drm fixes for 5.5-rc6

Hi Linus, Pre-LCA pull request I'm not sure how things will look next week, myself and Daniel are at LCA and I'm speaking quite late, so if I get my talk finished I'll probably process fixes. This week has a bunch of i915 fixes, some amdgpu fixes, one sun4i, one core MST, and one core fb_helper

Re: [PATCH] drm/panfrost: Remove core stack power management

On Thu, Jan 9, 2020 at 9:44 PM Alyssa Rosenzweig wrote: > > A-b > > On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote: > > Explict management of the GPU's core stacks is only necessary in the > > case of a broken integration with the PDC. Since there are no known > > platforms which

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

+Ulf to keep me honest on the power domains On Thu, Jan 9, 2020 at 10:08 PM Steven Price wrote: > > On 08/01/2020 05:23, Nicolas Boichat wrote: > > When there is a single power domain per device, the core will > > ensure the power domains are all switched on. > > > > However, when there are

Re: [PATCH] xf86drm: only include for FreeBSD build case

Hi On 2020년 01월 10일 00:28, Niclas Zeising wrote: > On 2020-01-09 16:18, Jani Nikula wrote: >> On Thu, 09 Jan 2020, Seung-Woo Kim wrote: >>> The header is only required FreeBSD and GNU libc >>> 2.30 starts to warn about Linux specific header >>> deprecation. Only include for FreeBSD. >>> >>>

Re: [PATCH] xf86drm: only include for FreeBSD build case

Hi, On 2020년 01월 10일 00:18, Jani Nikula wrote: > On Thu, 09 Jan 2020, Seung-Woo Kim wrote: >> The header is only required FreeBSD and GNU libc >> 2.30 starts to warn about Linux specific header >> deprecation. Only include for FreeBSD. >> >> Signed-off-by: Seung-Woo Kim >> --- >>

[radeon-alex:amd-19.50 1962/2687] include/kcl/kcl_drm.h:191:9: error: too few arguments to function 'drm_encoder_init'

Hi Yifan, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50 head: 02692309efa6ad48d47894e40fcb3832ace49c4c commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2687] drm/amdkcl: Test whether drm_encoder_init() wants name config:

[pull] drm DP MST DSC support

Hi Dave, Daniel, Ideally this would have gone through drm-misc, but it had dependencies on some changes in the DC code which were in my latest PR, so I sent this as a separate PR on top of my amdgpu PR. The following changes since commit 0f899fd466b693a129b16994c1b2b4db2fcde4a4: drm/amdkfd:

[pull] amdgpu, amdkfd, radeon, scheduler drm-next-5.6

Hi Dave, Daniel, More new stuff for 5.6. A few more things I forgot to put in the tag: amdgpu: - Use a task barrier to properly synchronize multi-GPU reset radeon: - Misc cleanups drm: - Add a task barrier helper for synchronizing threads scheduler: - Entity creation rework to separate

Re: [PATCH v2 2/2] drm/panel: add support for rm69299 visionox panel driver

Hi, On Tue, Jan 7, 2020 at 3:30 AM Harigovindan P wrote: > > + drm_panel_init(>panel); > + ctx->panel.dev = device; > + ctx->panel.funcs = _rm69299_drm_funcs; I haven't reviewed your whole panel driver, but I did just try to compile it and found that it won't compile against

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

On 1/7/20 2:45 PM, John Hubbard wrote: > Hi, > > The "track FOLL_PIN pages" would have been the very next patch, but it is > not included here because I'm still debugging a bug report from Leon. > Let's get all of the prerequisite work (it's been reviewed) into the tree > so that future reviews

Re: [PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel

On Thu, Jan 9, 2020 at 3:17 PM Sam Ravnborg wrote: > Applied to drm-misc-next. Thanks! Much appreciated. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

On 2020-01-09 4:13 p.m., Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland > wrote: > > On 2020-01-09 10:20 a.m., Mario Kleiner wrote: > > If the current eDP link settings, as read from hw, provide a higher > > bandwidth than the

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On 2020-01-09 4:04 p.m., Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher > wrote: > > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > mailto:mario.kleiner...@gmail.com>> > wrote: > > > > On Thu, Jan 9, 2020 at 4:40 PM Alex

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland wrote: > On 2020-01-09 10:20 a.m., Mario Kleiner wrote: > > If the current eDP link settings, as read from hw, provide a higher > > bandwidth than the verified_link_cap ones (= reported_link_cap), then > > override verified_link_cap with current

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote: > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > wrote: > > > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher > wrote: > >> > >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner > >> wrote: > >> > > As Harry mentioned in the other thread, won't

Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value

On Thu, Jan 9, 2020 at 5:49 AM Thomas Zimmermann wrote: > > Hi > > Am 09.01.20 um 11:15 schrieb Christian König: > > Am 08.01.20 um 18:51 schrieb Alex Deucher: > >> On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote: > >>> On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote: > Am

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä < > ville.syrj...@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > > > On

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote: >> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner >> wrote: >> > >> > If the current eDP link rate, as read from hw, provides a >> > higher bandwidth than the standard link rates, then

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

On Thu, Jan 09, 2020 at 04:53:02PM +, Steven Price wrote: > On 09/01/2020 16:28, Mark Brown wrote: > > On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote: > > > I'm not sure if it's better, but could we just encode the list of > > > regulators into device tree. I'm a bit worried

Re: [PATCH v5 1/2] dt-bindings: display: simple: Add Satoz panel

Hi Miquel. On Thu, Jan 09, 2020 at 07:40:36PM +0100, Miquel Raynal wrote: > Satoz is a Chinese TFT manufacturer. > Website: http://www.sat-sz.com/English/index.html > > Add the compatible for its SAT050AT40H12R2 5.0 inch LCD panel. > > Signed-off-by: Miquel Raynal Applied this and the

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

On 2020-01-09 10:20 a.m., Mario Kleiner wrote: > If the current eDP link settings, as read from hw, provide a higher > bandwidth than the verified_link_cap ones (= reported_link_cap), then > override verified_link_cap with current settings. > > These initial current eDP link settings have been

Re: [PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

On 2020-01-09 10:20 a.m., Mario Kleiner wrote: > read_current_link_settings_on_detect() on eDP 1.4+ may use the > edp_supported_link_rates table which is set up by > detect_edp_sink_caps(), so that function needs to be called first. > > Signed-off-by: Mario Kleiner > Cc: Martin Leung

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä > wrote: > > > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä < > > ville.syrj...@linux.intel.com> > > > wrote: > > > >

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä < > ville.syrj...@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > > > On

Re: [PATCH next] drm/i915/gtt: add missing include file asm/smp.h

On 2020/1/8 21:44, Jani Nikula wrote: > On Wed, 08 Jan 2020, Chen Zhou wrote: >> Fix build error: >> lib/crypto/chacha.c: In function chacha_permute: >> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger >> than 2048 bytes [-Wframe-larger-than=] >> } >> ^ > > IMO this

[PATCH RFC] ARM: dts: qcom: msm8974: add mdp5 iommu support

This adds preliminary IOMMU support for the MDP5 on msm8974. It appears that the qcom-iommu driver in upstream can be used on this SoC. I marked this patch as a RFC since the frame buffer becomes corrupted when I boot the Nexus 5 phone with this patch:

Re: [PATCH RFT v1 3/3] drm/panfrost: Use the mali-supply regulator for control again

On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote: > > On 07/01/2020 23:06, Martin Blumenstingl wrote: > > dev_pm_opp_set_rate() needs a reference to the regulator which should be > > updated when updating the GPU frequency. The name of the regulator has > > to be passed at initialization-time

[PATCH v2] drm/hisilicon: Add the mode_valid function

add mode_valid function, we can make sure the resolution is valid. Signed-off-by: Tian Tao Signed-off-by: Gong junjie Reviewed-by: Thomas Zimmermann --- v2: declare hibmc_crtc_mode_valid as static. Modify the return value of hibmc_crtc_mode_valid . ---

[PATCH 2/2] dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01D

Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD panel, and remove the old sharp,ls020b1dd01d.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil --- .../bindings/display/panel/panel-simple.yaml | 2 ++

Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

* Matthijs van Duin [200106 10:07]: > On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote: > > 4. The issue I'm seeing with stellarium on droid4 may be a stride > >issue as about one out of 3 or 4 frames is OK and aligning to > >512 also fixes the issue maybe because it happens

[PATCH next v2] drm/i915/gtt: add missing include file asm/smp.h

Fix build error: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings: drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus();

Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: Hi Krzysztof, On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote: The ioread8/16/32() and others have inconsistent

Re: [PATCH] drm/fb-cma-helpers: Fix include issue

On 12/3/19 5:49 PM, Benjamin Gaignard wrote: > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard > a écrit : >> Exported functions prototypes are missing in drm_fb_cma_helper.c >> Include drm_fb_cma_helper to fix that issue. >> > Gentle ping to reviewers. > Thanks, > Benjamin I know that removing

[PATCH 0/5] Use new logging macros in drm/i915

This patchset continues the conversion to using the new struct drm_device based logging macros in drm/i915. Wambui Karuga (5): drm/i915: conversion to new logging macros in i915/i915_vgpu.c drm/i915: conversion to new logging macros in i915/intel_csr.c drm/i915: conversion to new logging

[PATCH 2/5] drm/i915: conversion to new logging macros in i915/intel_csr.c

Replace the use of printk and struct device based logging macros with the new struct drm_device based logging macros in i915/intel_csr.c Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/intel_csr.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git

Re: [PATCH] drm/modes: tag unused variables to avoid warnings

On 1/7/20 2:24 PM, Thomas Zimmermann wrote: > Hi > > Am 10.12.19 um 11:24 schrieb Benjamin Gaignard: >> Some variables are set but never used. To avoid warning when compiling >> with W=1 and keep the algorithm like it is tag theses variables >> with _maybe_unused macro. >> >> Signed-off-by:

[PATCH 5/5] drm/i915: convert to new logging macros in i915/intel_memory_region.c

Replace the use of printk based logging macros with the new struct drm_device based logging macro in i915/intel_memory_region.c. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/intel_memory_region.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value

> On Jan 8, 2020, at 6:56 AM, Christian König wrote: > > Am 07.01.20 um 20:25 schrieb Tianlin Li: >> Right now several architectures allow their set_memory_*() family of >> functions to fail, but callers may not be checking the return values. >> If set_memory_*() returns with an error,

[PATCH next] drm/i915/gtt: add missing include file asm/smp.h

Fix build error: lib/crypto/chacha.c: In function chacha_permute: lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ Reported-by: Hulk Robot Signed-off-by: Chen Zhou --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 + 1 file

Re: [PATCH 1/3] drm/msm: support firmware-name for zap fw

On Wed 08 Jan 10:48 PST 2020, Jordan Crouse wrote: > On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote: > > From: Rob Clark > > > > Since zap firmware can be device specific, allow for a firmware-name > > property in the zap node to specify which firmware to load, similarly to > > the

Re: [PATCH] drm/panfrost: Remove core stack power management

A-b On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote: > Explict management of the GPU's core stacks is only necessary in the > case of a broken integration with the PDC. Since there are no known > platforms which have such a broken integration let's remove the explict > control from

[PATCH] drm/mediatek: check for comp->funcs

There might be some comp that doesn't have funcs, eg. hdmi-connector. Check for comp->funcs otherwise there will be NULL pointer dereference crash. Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to hardware capability") Fixes: 7395eab077f9 ("drm/mediatek: Add ctm property

[PATCH 1/5] drm/i915: conversion to new logging macros in i915/i915_vgpu.c

Replace the use of printk based logging macros with the struct drm_device based macros in i915/i915_vgpu.c Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/i915_vgpu.c | 41 +++- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git

[PATCH] drm/hisilicon: add the mode_valid function

add mode_valid function, and we can also use it to make suse the resolution is valid. Signed-off-by: Tian Tao Signed-off-by: Gong junjie --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 1 file changed, 20 insertions(+) diff --git

Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

Patches 1,2,3,6 are: Reviewed-by: Alyssa Rosenzweig The remaining patches in the series are Acked-by. Reportedly the kernel should work on certain Bifrost boards more or less as-is, but I'm not positive about the details. It's possible some of these are G72-specific or MT-specific

Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

Hi Geert, Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit : Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote: Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven

Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC

On 12/6/19 12:26 PM, Hans Verkuil wrote: > Add a missing 'depends on DRM' for the DRM_DP_CEC config > option. Without that enabling DRM_DP_CEC will force CEC_CORE > to =y instead of =m if DRM=m as well. > > Signed-off-by: Hans Verkuil Daniel, can you review this? It's annoying that the cec core

Re: [PATCH RFT v1 1/3] drm/panfrost: enable devfreq based the "operating-points-v2" property

Hi Robin, On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote: > > On 07/01/2020 11:06 pm, Martin Blumenstingl wrote: > > Decouple the check to see whether we want to enable devfreq for the GPU > > from dev_pm_opp_set_regulators(). This is preparation work for adding > > back support for

[PATCH v2] drm/msm: use BUG_ON macro for debugging.

As the if statement only checks for the value of the offset_name variable, it can be replaced by the more conscise BUG_ON macro for error reporting. v2: format expression to less than 80 characters for each line. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6

[PATCH 4/5] drm/i915: convert to new logging macros in i915/intel_gvt.c

This converts the use of printk based logging macros in i915/intel_gvt.c with the new struct drm_device based logging macros. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/intel_gvt.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git

Re: [PATCH v2 2/2] drm/sun4i: drc: Make sure we enforce the clock rate

On Wed, Jan 08, 2020 at 01:28:34AM +0800, Chen-Yu Tsai wrote: > On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard wrote: > > > > The DRC needs to run at 300MHz to be functional. This was done so far > > using assigned-clocks in the device tree, but that is easy to forget, and > > dosen't provide any

Re: [PATCH] xf86drm: only include for FreeBSD build case

On 2020-01-09 16:18, Jani Nikula wrote: On Thu, 09 Jan 2020, Seung-Woo Kim wrote: The header is only required FreeBSD and GNU libc 2.30 starts to warn about Linux specific header deprecation. Only include for FreeBSD. Signed-off-by: Seung-Woo Kim --- xf86drmMode.c |2 ++ 1 files

Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC

On 1/8/20 6:42 PM, Daniel Vetter wrote: > On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote: >> On 12/6/19 12:26 PM, Hans Verkuil wrote: >>> Add a missing 'depends on DRM' for the DRM_DP_CEC config >>> option. Without that enabling DRM_DP_CEC will force CEC_CORE >>> to =y instead of =m

[PATCH 3/5] drm/i915: conversion to new logging macros in i915/intel_device_info.c

This replaces the printk and struct device based logging macros with the new struct drm_device style based logging macros i915/intel_device_info.c. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/intel_device_info.c | 25 +--- 1 file changed, 14 insertions(+), 11

答复: [PATCH] drm/hisilicon: add the mode_valid function

Hi Thomas Zimmermann: I will modify this patch and send v2 as you suggested. Thank you very much. Best -邮件原件- 发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de] 发送时间: 2020年1月8日 16:49 收件人: tiantao (H) ; Chenfeng (puck) ; airl...@linux.ie; dan...@ffwll.ch;

[PATCH] drm/rockchip: use DIV_ROUND_UP macro for calculations.

Replace the open coded calculation with the more concise and readable DIV_ROUND_UP macro. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h

[PATCH 1/2] dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0

Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD panel, and remove the old giantplus,gpm740b0.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil --- .../bindings/display/panel/giantplus,gpm940b0.txt| 12

RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)

Hi Krzysztof, > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the > address so they can be converted to a "const" version for

RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument

From: Christophe Leroy > Sent: 08 January 2020 08:49 ... > And as pointed by Arnd, the volatile is really only necessary for the > dereference itself, should the arch use dereferencing. I've had trouble with some versions of gcc and reading of 'volatile unsigned char *'. It tended to follow the

[RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include

Now that the GVT interface to hypervisors does not depend on i915/GVT internals anymore, we can move the headers to the global include/. This makes out-of-tree modules for hypervisor integration possible. Cc: Zhenyu Wang Signed-off-by: Julian Stecklina --- drivers/gpu/drm/i915/gvt/gvt.h

[RFC PATCH 2/4] drm/i915/gvt: remove unused vblank_done completion

This variable is used nowhere, so remove it. Cc: Zhenyu Wang Signed-off-by: Julian Stecklina --- drivers/gpu/drm/i915/gvt/gvt.h | 2 -- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h

[RFC PATCH 0/4] Support for out-of-tree hypervisor modules in i915/gvt

These patch series removes the dependency of i915/gvt hypervisor backends on the driver internals of the i915 driver. Instead, we add a small public API that hypervisor backends can use. This enables out-of-tree hypervisor backends for the Intel graphics virtualization and simplifies development.

Re: [PATCH v3 1/4] dt-bindings: display: Convert Allwinner display pipeline to schemas

On Fri, Jan 3, 2020 at 9:28 AM Maxime Ripard wrote: > > The Allwinner SoCs have a display engine composed of several controllers > assembled differently depending on the SoC, the number and type of output > they have, and the additional features they provide. A number of those are > supported in

[RFC PATCH 3/4] drm/i915/gvt: define a public interface to gvt

So far, the KVMGT code just included the whole i915 driver and GVT internals to do its job. Change this to have a single public header that defines the interface via accessor functions. Some ugly things: a) The handle member of intel_vgpu should be in kvmgt_vdev and the generic code should just

[RFC PATCH 1/4] drm/i915/gvt: make gvt oblivious of kvmgt data structures

Instead of defining KVMGT per-device state in struct intel_vgpu directly, add an indirection. This makes the GVT code oblivious of what state KVMGT needs to keep. The intention here is to eventually make it possible to build hypervisor backends for the mediator, without having to touch the

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote: > > On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: > > > > On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: > > > > > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second > > > regulator for their SRAM, let's add

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

On 09/01/2020 16:28, Mark Brown wrote: On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote: On 08/01/2020 22:52, Nicolas Boichat wrote: That'd be a bit awkward to match, though... Currently all bifrost share the same compatible "arm,mali-bifrost", and it'd seem weird/wrong to match

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote: > On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner > wrote: > > > > If the current eDP link rate, as read from hw, provides a > > higher bandwidth than the standard link rates, then add the > > current link rate to the link_rates array for

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä > wrote: > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > The panel reports 10 bpc color

Re: [PATCH] drm/fb-cma-helpers: Fix include issue

Le jeu. 9 janv. 2020 à 17:29, Benjamin GAIGNARD a écrit : > > > On 12/3/19 5:49 PM, Benjamin Gaignard wrote: > > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard > > a écrit : > >> Exported functions prototypes are missing in drm_fb_cma_helper.c > >> Include drm_fb_cma_helper to fix that issue. >

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 05:38:15PM +0200, Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > If the current eDP link rate, as read from hw, provides a > > > higher bandwidth than the

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > firmware chooses link settings at

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote: > On 08/01/2020 22:52, Nicolas Boichat wrote: > > That'd be a bit awkward to match, though... Currently all bifrost > > share the same compatible "arm,mali-bifrost", and it'd seem > > weird/wrong to match "mediatek,mt8183-mali" in this

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > If the current eDP link rate, as read from hw, provides a > > higher bandwidth than the standard link rates, then add the > > current link rate to the link_rates array for

Re: [RESEND 1/1] drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple

Hi Tobias. On Thu, Jan 09, 2020 at 12:29:52PM +0100, Tobias Schramm wrote: > This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple > driver. The panel is used by the pine64 Pinebook Pro. > > Signed-off-by: Tobias Schramm Applied to drm-misc-next togher with the bindings

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner wrote: > > If the current eDP link rate, as read from hw, provides a > higher bandwidth than the standard link rates, then add the > current link rate to the link_rates array for consideration > in future mode-sets. > > These initial current eDP link

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > If the current eDP link rate, as read from hw, provides a > > higher bandwidth than the standard link rates, then add the > > current link rate to the link_rates

Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple

Hi Tobias. We need binding schema before we can apply this patch. Knew I forgot something See patch below. Please review/ack the patch, then we can process your panel-simple patch. LGTM, thanks! Sam On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote: This patch adds

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > If the current eDP link rate, as read from hw, provides a > higher bandwidth than the standard link rates, then add the > current link rate to the link_rates array for consideration > in future mode-sets. > > These initial current

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On Tue, 07 Jan 2020, Manasi Navare wrote: > Adaptive Sync is a VESA feature so add a DRM core helper to parse > the EDID's detailed descritors to obtain the adaptive sync monitor range. > Store this info as part fo drm_display_info so it can be used > across all drivers. > This part of the code

Some eDP fixes/improvements.

Hi and happy new year! Since i now have a MBP 2017 to play with, with a 10 bit Retina panel, and Polaris gpu, i'm trying to get it to get 10 bits, and found one small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for which i propose patch2 as solution. I sent a similar patch to i915

[PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

If the current eDP link settings, as read from hw, provide a higher bandwidth than the verified_link_cap ones (= reported_link_cap), then override verified_link_cap with current settings. These initial current eDP link settings have been set up by firmware during boot, so they should work on the

[PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

read_current_link_settings_on_detect() on eDP 1.4+ may use the edp_supported_link_rates table which is set up by detect_edp_sink_caps(), so that function needs to be called first. Signed-off-by: Mario Kleiner Cc: Martin Leung --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file

Re: [PATCH] xf86drm: only include for FreeBSD build case

On Thu, 09 Jan 2020, Seung-Woo Kim wrote: > The header is only required FreeBSD and GNU libc > 2.30 starts to warn about Linux specific header > deprecation. Only include for FreeBSD. > > Signed-off-by: Seung-Woo Kim > --- > xf86drmMode.c |2 ++ > 1 files changed, 2 insertions(+), 0

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: Hi Woody, sorry for the late reply, I've been off to a vacation over the holidays. On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit

[PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

If the current eDP link rate, as read from hw, provides a higher bandwidth than the standard link rates, then add the current link rate to the link_rates array for consideration in future mode-sets. These initial current eDP link settings have been set up by firmware during boot, so they should

Re: [PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel

Hi Linus. On Thu, Jan 09, 2020 at 08:28:15AM +0100, Linus Walleij wrote: > The Sony ACX424AKP is a command/videomode DSI panel for > mobile devices. It is used on the ST-Ericsson HREF520 > reference design. We support video mode by default, but > it is possible to switch the panel into command

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

On 08/01/2020 22:52, Nicolas Boichat wrote: On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: Some GPUs, namely, the bifrost/g72 part on MT8183, have a second regulator for their SRAM, let's add support for that. +

Re: [PATCH v2 6/7, RFC] drm/panfrost: Add bifrost compatible string

On 08/01/2020 05:23, Nicolas Boichat wrote: For testing only, the driver doesn't really work yet, AFAICT. Signed-off-by: Nicolas Boichat It does work (at least on the Hikey960), we just don't have any public user space driver for it... ;) Reviewed-by: Steven Price ---

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

On 08/01/2020 05:23, Nicolas Boichat wrote: When there is a single power domain per device, the core will ensure the power domains are all switched on. However, when there are multiple ones, as in MT8183 Bifrost GPU, we need to handle them in driver code. Signed-off-by: Nicolas Boichat ---

Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple

Hi Tobias. We need binding schema before we can apply this patch. See patch below. Please review/ack the patch, then we can process your panel-simple patch. Sam On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote: > This patch adds support for the 14 inch BOE NV140FHM-N49 eDP

Re: [PATCH] drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs

Thank you, Reviewed-by: Mikita Lipski On 1/8/20 10:24 PM, Alex Deucher wrote: the parameter is the mst manager, not the port. Signed-off-by: Alex Deucher --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PULL] drm-intel-fixes

Quoting Joonas Lahtinen (2020-01-09 15:34:58) > Hi Dave & Daniel, > > Happy New Year, now back from the holiday break. > > A bunch of important fixes. Further fixes for the power/perf > regressions caused by the past security fixes. Then fix for > user reported GPU hang regression. Revert to

[PULL] drm-intel-fixes

Hi Dave & Daniel, Happy New Year, now back from the holiday break. A bunch of important fixes. Further fixes for the power/perf regressions caused by the past security fixes. Then fix for user reported GPU hang regression. Revert to avoid screen flicker caused by HDA audio. Then missing two W/A

[PATCH] drm/panfrost: Remove core stack power management

Explict management of the GPU's core stacks is only necessary in the case of a broken integration with the PDC. Since there are no known platforms which have such a broken integration let's remove the explict control from the driver since this apparently causes problems on other platforms and will

Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

On Thu, Jan 09, 2020 at 01:10:33PM +, Robin Murphy wrote: > On 09/01/2020 12:01 pm, Steven Price wrote: > > On 08/01/2020 05:23, Nicolas Boichat wrote: > >> Hi! > >> > >> Sorry for the long delay since > >> https://patchwork.kernel.org/patch/11132381/, > >> finally got around to give this a

  1   2   >