Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

Ville Syrjälä writes: > On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote: >> On Fri, 11 May 2018 20:29:48 +0300 >> Ville Syrjälä wrote: >> >> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: >> > >

Re: [PATCH 1/4] drm/panel: otm8009a: fix backlight updates

Hi Philippe, Reviewed-by: Vincent Abriou BR Vincent On 04/23/2018 04:10 PM, Philippe Cornu wrote: > Backlight updates was not working anymore since the good > implementation of the dsi lpm mode in the dsi host driver. > After a longer analysis, the backlight updates in

Re: [PATCH 3/4] drm/panel: otm8009a: no message if probe success

Hi Philippe, Reviewed-by: Vincent Abriou BR Vincent On 04/23/2018 04:10 PM, Philippe Cornu wrote: > Remove the message in case of probe success. This comes from > a suggestion followed in the recent integration of the > raydium rm68200 panel. > > Signed-off-by: Philippe

Re: [PATCH 2/4] drm/panel: otm8009a: fix glitches by moving backlight enable to otm8009a_enable()

Hi Philippe, Reviewed-by: Vincent Abriou BR Vincent On 04/23/2018 04:10 PM, Philippe Cornu wrote: > The backlight 1st update was in the otm8009a_prepare() function > for a bad reason: backlight was not working in video mode and the > otm8009a_prepare() is in command mode

Re: [PATCH 1/2] drm/tegra: Fix order of teardown in IOMMU case

On Mon, Apr 23, 2018 at 11:35:14AM +0300, Dmitry Osipenko wrote: > On 23.04.2018 09:57, Thierry Reding wrote: > > From: Thierry Reding > > > > The original code works fine, this is merely a cosmetic change to make > > the teardown order the reverse of the setup order. > > >

RE: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

[Bug 97025] flip queue failed: Device or resource busy

https://bugs.freedesktop.org/show_bug.cgi?id=97025 --- Comment #28 from Michel Dänzer --- (In reply to Bernd Steinhauser from comment #27) > > Although I'm not sure if it works as expected, since the display does still > seem to disconnect when I turn the screen off. AFAIK

Re: [PATCH 4/4] drm/panel: otm8009a: use new backlight api

Hi Philippe, Reviewed-by: Vincent Abriou BR Vincent On 04/23/2018 04:10 PM, Philippe Cornu wrote: > Use the new backlight api. > > Signed-off-by: Philippe Cornu > --- > drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 26 >

Re: [PATCH v1] gpu: host1x: Fix dma_free_wc() argument in the error path

On Mon, Apr 23, 2018 at 12:54:56PM +0300, Dmitry Osipenko wrote: > If IOVA allocation or IOMMU mapping fails, dma_free_wc() is invoked with > size=0 because of a typo, that triggers "kernel BUG at mm/vmalloc.c:124!". > > Signed-off-by: Dmitry Osipenko > --- >

Re: [PATCH 2/2] drm/tegra: Acquire a reference to the IOVA cache

On Mon, Apr 23, 2018 at 11:43:16AM +0300, Dmitry Osipenko wrote: > On 23.04.2018 11:41, Dmitry Osipenko wrote: > > On 23.04.2018 11:34, Dmitry Osipenko wrote: > >> On 23.04.2018 09:57, Thierry Reding wrote: > >>> From: Thierry Reding > >>> > >>> The IOVA API uses a memory

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

Hi, > > So my expectation that a backmerge happens anyway after -rc1/2 is in > > line with reality, it is just to be delayed this time. I'll stay > > tuned ;) > > Is this patch already merged in drm-misc-next tree ? Pushed now. cheers, Gerd ___

RE: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote: > Status register contains a lot of bits for reporting internal errors > inside Mali DP. Currently, we just silently ignore all of the erorrs, > that doesn't help when we are investigating different bugs, especially > on the FPGA

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

Hi Alex, On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote: Status register contains a lot of bits for reporting internal errors inside Mali DP. Currently, we just silently ignore all of the erorrs, Being picky: s/erorrs/errors/ that doesn't help when we are investigating

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Rob & Laurent :) On 04/26/2018 12:05 AM, Laurent Pinchart wrote: > Hi Rob, > > On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote: >> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: >>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: On

Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies

Hi Laurent, Archit, Andrzej & Yannick, Do you have any comments on this v2 driver part? (more details regarding v1/v2 differences in the cover letter https://www.spinics.net/lists/dri-devel/msg174137.html) Thank you, Philippe :-) On 04/25/2018 09:53 AM, Philippe Cornu wrote: > Add the

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote: Hi Daniel, > On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau wrote: > > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote: > >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote: > >> >

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

On Mon, May 14, 2018 at 10:19:27AM +0100, Brian Starkey wrote: > Hi Alex, > > On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote: > >Status register contains a lot of bits for reporting internal errors > >inside Mali DP. Currently, we just silently ignore all of the erorrs, > >

[PATCH] gpu: host1x: Acquire a reference to the IOVA cache

From: Thierry Reding The IOVA API uses a memory cache to allocate IOVA nodes from. To make sure that this cache is available, obtain a reference to it and release the reference when the cache is no longer needed. On 64-bit ARM this is hidden by the fact that the DMA mapping

[PATCH] drm/omap: dss: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). drivers/gpu/drm/omapdrm/dss/dss.c:959:9-16: WARNING: ERR_CAST can be used with d Generated by: scripts/coccinelle/api/err_cast.cocci Signed-off-by: Hernán Gonzalez --- drivers/gpu/drm/omapdrm/dss/dss.c

Re: drm SPDX updates

Dirk, On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote: > License clarifications and SPDX headers for a bunch of files which were > authored by VMware. > > This should address the comments made on the previous series. > I added Thomas as Cc (sorry, forgot on the first version) and added a >

[git pull] amdkfd next 4.18

Hi Dave, This is amdkfd pull for 4.18. The major new features are: - Add support for GFXv9 dGPUs (VEGA) - Add support for userptr memory mapping In addition, there are a couple of small fixes and improvements, such as: - Fix lock handling - Fix rollback packet in kernel kfd_queue - Optimize kfd

[PATCH v1 0/7] drm/mediatek: support hdmi output for mt2701 and mt7623

In order to support HDMI on mt2701, we have to make some modifications. 1) Add the HDMI driver. 2) Add the DPI driver. 3) Add a mechanism that config output component by dts. Changes since v0: - Correct some typos in commit message. - Fixup the build warning (tmp variable didn't be initialized)

[PATCH v1 2/7] drm/mediatek: fix to get right bridge for dpi encoder

From: chunhui dai 1, dpi is an encoder, there is an bridge in the struct of decoder, we could use it. 2, using of_graph_get_remote_port_parent to get right bridge in device tree. Signed-off-by: chunhui dai ---

[PATCH v1 6/7] drm/mediatek: add a error return value when clock driver has been prepared

DRM driver get the comp->clk by of_clk_get(), we only assign NULL to comp->clk when error happened, but do not return the error number. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Bug 104598] vkmark with kwin compositing: Page flip failed: Cannot allocate memory

https://bugs.freedesktop.org/show_bug.cgi?id=104598 --- Comment #6 from Christoph Haag --- Yes, it's still happening. It's just running vkmark in default mode. It looks like this: https://youtu.be/MngLl6BgOfg I'm not sure if previously it happened continuously but now it's

Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support

On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote: > On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard > wrote: > > Hi, > > > > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote: > >> + hdmi_phy: hdmi-phy@1ef { > >> +

RE: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

[PATCH v1 1/7] drm/mediatek: move dpi private data to device

From: chunhui dai move clock factor and edge enable setting to private data. Signed-off-by: chunhui dai --- drivers/gpu/drm/mediatek/mtk_dpi.c | 82 ++--- drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 2 +- 2

[PATCH v1 7/7] drm/mediatek: config component output by device node port

We can select output component by device node port. Main path default output component is DSI. External path default output component is DPI. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 37 ++

[PATCH v1 4/7] drm/mediatek: add hdmi driver for different hardware

From: chunhui dai This patch adds hdmi driver suppot for both MT2701 and MT7623. And also support other (existing or future) chips that use the same binding and driver. Signed-off-by: Chunhui Dai --- drivers/gpu/drm/mediatek/Makefile

[PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623

From: chunhui dai This patch adds dpi driver suppot for both mt2701 and mt7623. And also support other (existing or future) chips that use the same binding and driver. Signed-off-by: chunhui dai --- drivers/gpu/drm/mediatek/mtk_dpi.c |

[PATCH v1 5/7] drm/mediatek: implement connection from BLS to DPI0

Modify display driver to support connection from BLS to DPI. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c

Re: [PATCH] gpu: host1x: Fix compiler errors

On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote: > The compiler is complaining with the following errors: > > drivers/gpu/host1x/cdma.c:94:48: error: > passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > >

RE: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=106490 --- Comment #1 from Leonid Maksymchuk --- It looks like it's Chromium or VA-API bug, but not Mesa. Chromium VA-API decoding works with Mesa 18.0 if RGB10 visual configs is disabled. -- You are receiving this mail because:

[Bug 106496] Hung screen at modprobe amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=106496 Michel Dänzer changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug 106245] Raven ridge (2400g) fails to start (swiotlb buffer is full) with IOMMU disabled

https://bugs.freedesktop.org/show_bug.cgi?id=106245 Michel Dänzer changed: What|Removed |Added CC||c...@atamisk.net

Re: [PATCH] gpu: host1x: Acquire a reference to the IOVA cache

On Mon, May 14, 2018 at 01:34:27PM +0300, Dmitry Osipenko wrote: > On 14.05.2018 13:13, Thierry Reding wrote: > > From: Thierry Reding > > > > The IOVA API uses a memory cache to allocate IOVA nodes from. To make > > sure that this cache is available, obtain a reference to it

[Bug 106496] Hung screen at modprobe amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=106496 Michel Dänzer changed: What|Removed |Added Attachment #139536|text/x-log |text/plain

Re: [PATCH] gpu: drm: tegra: Adding new typedef vm_fault_t

On Tue, Apr 17, 2018 at 07:17:55PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

Hi Eric, On Tue, Apr 24, 2018 at 09:53:28AM -0700, Eric Anholt wrote: > Maxime Ripard writes: > > > The vc4 HVS uses an internal RGB888 representation of the frames, and will > > by default expand formats using a lower depth using zeros. > > > > This causes an issue

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

On Tue, Apr 24, 2018 at 9:48 AM, Maxime Ripard wrote: > The vc4 HVS uses an internal RGB888 representation of the frames, and will > by default expand formats using a lower depth using zeros. > > This causes an issue when we try to use other compositing software such as

Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support

On Friday, April 27, 2018 02:09:31 PM Daniel Vetter wrote: > On Fri, Apr 27, 2018 at 1:36 PM, Laurent Pinchart > wrote: > > Hi Bartlomiej, > > > > On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote: > >> Hi, > >> > >> This patchset removes

Re: [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

On 2018-05-11 20:58, Sean Paul wrote: On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote: SoCs containing dpu have a MDSS top level wrapper which includes sub-blocks as dpu, dsi, phy, dp etc. MDSS top level wrapper manages common resources like common clocks, power and irq for its

Re: [PATCH] video: fbdev: remove unused auo_k190xfb drivers

On Friday, April 27, 2018 05:07:41 PM Heiko Stuebner wrote: > Am Freitag, 27. April 2018, 13:04:24 CEST schrieb Bartlomiej Zolnierkiewicz: > > auo_k1900fb and auo_k1901fb drivers have been introduced six > > years ago by following commits: > > > > commit 2c8304d3125b ("video: auo_k190x: add code

Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies

On 14.05.2018 11:38, Philippe CORNU wrote: > Hi Laurent, Archit, Andrzej & Yannick, > > Do you have any comments on this v2 driver part? > (more details regarding v1/v2 differences in the cover letter > https://www.spinics.net/lists/dri-devel/msg174137.html) > > Thank you, > Philippe :-) > > > On

Re: [PATCH v2 09/11] docs: Fix some broken references

On Wed, 9 May 2018 10:18:52 -0300 Mauro Carvalho Chehab wrote: > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix-rst > > Manually checked if the produced result is

[Bug 106513] AMDGPU not working on ubuntu 18.04

https://bugs.freedesktop.org/show_bug.cgi?id=106513 Alex Deucher changed: What|Removed |Added Resolution|--- |DUPLICATE

Re: [PATCH v3 3/4] phy: rockchip-typec: support variable phy config value

On Mon, May 14, 2018 at 05:53:54PM +0800, Lin Huang wrote: > the phy config values used to fix in dp firmware, but some boards > need change these values to do training and get the better eye diagram > result. So support that in phy driver. > > Signed-off-by: Chris Zhong >

Re: [PATCH] Add SPDX idenitifier and clarify license

On Wed, May 2, 2018 at 10:00 AM, Christian König wrote: > Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom: >> >> From: Dirk Hohndel >> >> This is dual licensed under GPL-2.0 or MIT. >> >> Cc: "Christian König" >>

Re: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

Re: drm SPDX updates

On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote: > On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote: > > > I haven't seen any comments in the week since I wrote this. I'm not > > > familiar with the process for the drm changes - so what are the usual next > > > steps?

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote: > Quoting Ezequiel Garcia (2018-05-09 21:14:49) > > Change how dma_fence_add_callback() behaves, when the fence > > has error-signaled by the time it is being add. After this commit, > > dma_fence_add_callback() returns the fence error,

Re: [PATCH v3 4/4] drm/rockchip: support dp training outside dp firmware

On Mon, May 14, 2018 at 05:53:55PM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So if the phy is using custom config values, do software > link training instead of relying

[DPU PATCH v3 03/12] drm/msm/dpu: add MDSS top level driver for dpu

SoCs containing dpu have a MDSS top level wrapper which includes sub-blocks as dpu, dsi, phy, dp etc. MDSS top level wrapper manages common resources like common clocks, power and irq for its sub-blocks. Currently, in dpu driver, all the power resource management is part of power_handle which

[DPU PATCH v3 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

MDSS and dpu drivers manage their respective clocks via runtime_pm. Remove custom clock management code from dpu_power_handle. Also dpu core clock management code is restricted to dpu_core_perf module. Changes in v3: - none Changes in v2: - remove local variable to hold and

[DPU PATCH v3 04/12] drm/msm/dpu: create new platform driver for dpu device

Current MSM display controller HW matches a tree like hierarchy where MDSS top level wrapper is parent device and mdp5/dpu, dsi, dp are child devices. Each child device like mdp5, dsi etc. have a separate driver, but currently dpu handling is tied to a single driver which was managing both mdss

[DPU PATCH v3 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

dpu_core_perf_crtc_update() is responsible for aggregating the data bus bandwidth and dpu core clock rate requirements and request the same for all active crtcs. Currently, there is no error handling support in this function so there is no way caller can know if the perf request fails. This change

[DPU PATCH v3 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

Currently, msm_drv was creating dpu_power_handle client which was used by dpu_dbg module to enable power resources before register debug dumping. Now since, the mdss core power resource handling is implemented via runtime_pm and same has been removed from dpu_power_handle. Remove dpu_power_handle

Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t

On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote: > On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote: > > Hi Sean, > > > > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder > > wrote: > > > Use new return type vm_fault_t for fault handler. > > > >

Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions

Thank you for the review comments Uma Shankar! On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To:

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote: > On 2018-05-10 10:10, Andrzej Hajda wrote: > > On 04.05.2018 15:52, Peter Rosin wrote: > >> If the bridge supplier is unbound, this will bring the bridge consumer > >> down along with the bridge. Thus, there will no longer linger any >

[DPU PATCH v3 02/12] drm/msm/mdp5: subclass msm_mdss for mdp5

SoCs having mdp5 or dpu have identical tree like device hierarchy where MDSS top level wrapper manages common power resources for all child devices. Subclass msm_mdss so that msm_mdss includes common defines and mdp5/dpu mdss derivations to include any extensions. Add mdss helper interface

[DPU PATCH v3 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

Now, since dpu_power_handle manages only bus scaling and power enable/disable notifications which are restricted to dpu driver, move dpu_power_handle to dpu folder. Changes in v3: - none Changes in v2: - resolved conflict in dpu_unbind - dropped (Reviewed-by: Sean Paul)

[DPU PATCH v3 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

Mdss main power supply (mdss_gdsc) is implemented as a generic power domain and mdss top level wrapper device manage it via runtime_pm. Remove custom power management code from dpu_power_handle. Changes in v3: - remove redundant param check from dpu_power_resource_init() (Sean

[DPU PATCH v3 09/12] drm/msm/dp: remove dpu_power_handle calls from dp driver

DP driver was dependent on dpu_power_handle for MDSS common clocks and gdsc (main power supply). The common clocks and power is managed by MDSS top wrapper device now which is parent of all sub-devices like DP device. For same reason, clock and power management code is removed from

[DPU PATCH v3 06/12] drm/msm/dpu: use runtime_pm calls on dpu device

The dpu driver implements runtime_pm support for managing dpu specific resources like - clocks, bus bandwidth etc. Use pm_runtime_get/put_sync calls on dpu device. The common clocks and power management for all child nodes (mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver via

[DPU PATCH v3 05/12] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address

The dpu sub-block offsets were defined wrt mdss base address instead of dpu base address. Since, dpu is now defined as a separate device, update hw catalog offsets for all dpu sub blocks wrt dpu base address. Changes in v3: - none Changes in v2: - none Signed-off-by: Rajesh

[DPU PATCH v3 00/12] Refactor DPU device/driver hierarchy and add runtime_pm support

SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper manages common resources like common clocks, main power supply and interrupts for its sub-blocks. But current dpu driver implementation is based on a flat

[DPU PATCH v3 01/12] drm/msm: remove redundant pm_runtime_enable call from msm_drv

MDSS top level device includes the common power resources and it's corresponding driver (i.e. mdp5_mdss) handles call to enable/disable runtime_pm for enabling these resources. Remove redundant pm_runtime_enable call from msm_drv. Changes in v3: - none Changes in v2: - none

Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs

On Mon, May 14, 2018 at 1:20 AM, Jagan Teki wrote: > On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai wrote: >> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki >> wrote: >>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable

Re: [PATCH 3/3] drm/vc4: Attach underscan props to the HDMI connector

On Wed, May 09, 2018 at 04:52:38PM +0200, Boris Brezillon wrote: > On Mon, 7 May 2018 17:24:08 +0200 > Daniel Vetter wrote: > > > On Mon, May 07, 2018 at 04:44:34PM +0200, Boris Brezillon wrote: > > > Now that the plane code takes the underscan setup into account, we can > > >

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

https://bugs.freedesktop.org/show_bug.cgi?id=105760 Alex Deucher changed: What|Removed |Added CC|

Re: [PATCH] Add SPDX idenitifier and clarify license

Am 14.05.2018 um 18:00 schrieb Alex Deucher: On Wed, May 2, 2018 at 10:00 AM, Christian König wrote: Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom: From: Dirk Hohndel This is dual licensed under GPL-2.0 or MIT. Cc: "Christian König"

Re: [PATCH 0/4] DRM helpers for Display Stream Compression PPS infoframes

On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote: > VESA Display Stream Compression is a specification for visually losless > video compression over display links. The DSC standard also defines > a picture parameter set (PPS) which encoder must communicate to decoders. > This is done

[Bug 106513] AMDGPU not working on ubuntu 18.04

https://bugs.freedesktop.org/show_bug.cgi?id=106513 Bug ID: 106513 Summary: AMDGPU not working on ubuntu 18.04 Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal

Re: drm SPDX updates

On 05/14/2018 04:54 PM, Dirk Hohndel wrote: On Mon, May 14, 2018 at 07:59:56AM +0200, Thomas Gleixner wrote: Dirk, On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote: License clarifications and SPDX headers for a bunch of files which were authored by VMware. This should address the comments

[Bug 106499] [regression, bisected] Several games crash on start

https://bugs.freedesktop.org/show_bug.cgi?id=106499 --- Comment #2 from Gregor Münch --- There is another bug Report, bisecting to another commit (which might make more sense): https://bugs.freedesktop.org/show_bug.cgi?id=106511 Was in a hurry while bisecting it, cant test

Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

Hi and thanks for the review! Le vendredi 11 mai 2018 à 16:36 +0200, Maxime Ripard a écrit : > On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote: > > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts > > @@ -0,0 +1,297 @@ > > +/* > > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) >

Re: [PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp

Hi Lin, 2018-05-14 11:53 GMT+02:00 Lin Huang : > From: Chris Zhong > > We may support training outside firmware, so we need support > dpcd read/write to get the message or do some setting with > display. > > Signed-off-by: Chris Zhong

Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90

Hi, Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit : > On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote: > > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote: > > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote: > > > > This adds timings

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

https://bugs.freedesktop.org/show_bug.cgi?id=106519 Bug ID: 106519 Summary: Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with

[Bug 106517] IGT commit rights

https://bugs.freedesktop.org/show_bug.cgi?id=106517 --- Comment #1 from Dhinakaran Pandiyan --- Created attachment 139563 --> https://bugs.freedesktop.org/attachment.cgi?id=139563=edit SSH public key -- You are receiving this mail because: You are the assignee

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #2 from mikhail.v.gavri...@gmail.com --- $ inxi -bM System:Host: localhost.localdomain Kernel: 4.17.0-0.rc3.git4.1.fc29.x86_64 x86_64 bits: 64 Desktop: Gnome 3.29.1 Distro: Fedora release 29 (Rawhide) Machine:

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 139567 --> https://bugs.freedesktop.org/attachment.cgi?id=139567=edit Video in Totem player -- You are receiving this mail because: You are the assignee for the

[Bug 106517] IGT commit rights

https://bugs.freedesktop.org/show_bug.cgi?id=106517 Bug ID: 106517 Summary: IGT commit rights Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies

Hi Andrzej, On 05/14/2018 12:33 PM, Andrzej Hajda wrote: > On 14.05.2018 11:38, Philippe CORNU wrote: >> Hi Laurent, Archit, Andrzej & Yannick, >> >> Do you have any comments on this v2 driver part? >> (more details regarding v1/v2 differences in the cover letter >>

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

Hi! > WLED4 peripheral is present on some PMICs like pmi8998 > and pm660l. It has a different register map and also > configurations are different. Add support for it. > > Signed-off-by: Kiran Gunda > --- > .../bindings/leds/backlight/qcom-wled.txt | 172 - >

[Bug 106500] GPU Recovery + DC deadlock

https://bugs.freedesktop.org/show_bug.cgi?id=106500 --- Comment #1 from Andrey Grodzovsky --- Created attachment 139562 --> https://bugs.freedesktop.org/attachment.cgi?id=139562=edit Quick try to avoid deadlock Can u give this a quick try and seed if it helps ? --

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #202 from Ioannis Panagiotopoulos --- Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland and the right boot arguments. However this worked when I had the R9 390 installed alone.

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Philippe, On Monday, 14 May 2018 12:22:16 EEST Philippe CORNU wrote: > On 04/26/2018 12:05 AM, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote: > >> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: > >>> On Wednesday, 25 April 2018

Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski wrote: > Dear All, It is only Thierry that you need to ping. It goes thru his tree as I mentioned on another panel you sent. >> This commit adds support for AUO's 7.0" display. > > If I may gentle remind about this patch > >>

Re: [PATCH 0/4] DRM helpers for Display Stream Compression PPS infoframes

On Mon, May 14, 2018 at 06:50:28PM +0200, Daniel Vetter wrote: > On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote: > > VESA Display Stream Compression is a specification for visually losless > > video compression over display links. The DSC standard also defines > > a picture

Re: [PATCH v10 1/2] drm: content-type property for HDMI connector

On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content_type property to drm_connector_state > in order to properly handle external HDMI TV content-type setting. > > v2: > * Moved helper function which attaches

[RFC PATCH 4/5] mfd: cros-ec: Introduce CEC commands and events definitions.

From: Stefan Adolfsson The EC can expose a CEC bus, this patch adds the CEC related definitions needed by the cros-ec-cec driver. Having a 16 byte mkbp event size makes it possible to send CEC messages from the EC to the AP directly inside the mkbp event instead of first

[RFC PATCH 1/5] mfd: cros_ec_dev: Add CEC sub-device registration

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device when the CEC feature bit is present. Signed-off-by: Neil Armstrong --- drivers/mfd/cros_ec_dev.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/mfd/cros_ec_dev.c

[RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

In non device-tree world, we can need to get the notifier by the driver name directly and eventually defer probe if not yet created. This patch adds a variant of the get function by using the device name instead and will not create a notifier if not yet created. But the i915 driver exposes at

[RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

This patchs adds the cec_notifier feature to the intel_hdmi part of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate between each HDMI ports. The changes will allow the i915 HDMI code to notify EDID and HPD changes to an eventual CEC adapter. Signed-off-by: Neil Armstrong

[RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the driver for such feature of the Embedded Controller. This driver is part of the cros-ec MFD and will be add as a sub-device when the feature bit is exposed by the EC. The controller will only handle a single logical

  1   2   >