RE: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization

The series is OK to me, Reviewed-by: Chunming Zhou It is better to wait Christian to have a look before pushing patch. Regards, David Zhou -Original Message- From: Junwei Zhang [mailto:jerry.zh...@amd.com] Sent: Friday, May 11, 2018 12:58 PM To:

[PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization

Signed-off-by: Junwei Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index e62153a..6a9e46a 100644 ---

[PATCH 1/2] drm/ttm: remove priority hard code when initializing ttm bo

Then priority could be set before initialization. By default, it requires to kzalloc ttm bo. In fact, we always do so. Signed-off-by: Junwei Zhang --- drivers/gpu/drm/ttm/ttm_bo.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[git pull] drm fixes for v4.17-rc5

Hi Linus, As last week seemed a bit slow, we got a few more fixes this week. The main stuff is 2 weeks of fixes for amdgpu, some missing bits of vega12 atom firmware support were added, and some power management fixes. Nouveau got two regression fixes for an DP MST deadlock and a random oops

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

https://bugs.freedesktop.org/show_bug.cgi?id=106473 Bug ID: 106473 Summary: Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker Product: Mesa Version: unspecified Hardware:

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #24 from jian-h...@endlessm.com --- Created attachment 139485 --> https://bugs.freedesktop.org/attachment.cgi?id=139485=edit dmesg of loading amdgpu module - tested in 4.17-rc4 I also tried Linux kernel 4.17-rc4 again. However,

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

On 05/11/2018 10:26 AM, zhoucm1 wrote: On 2018年05月11日 10:19, Zhang, Jerry (Junwei) wrote: On 05/11/2018 10:11 AM, zhoucm1 wrote: On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote: On 05/10/2018 10:40 PM, Christian König wrote: Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

On 2018年05月11日 10:19, Zhang, Jerry (Junwei) wrote: On 05/11/2018 10:11 AM, zhoucm1 wrote: On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote: On 05/10/2018 10:40 PM, Christian König wrote: Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add an evitable bo who has reservation object

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

On 05/11/2018 10:11 AM, zhoucm1 wrote: On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote: On 05/10/2018 10:40 PM, Christian König wrote: Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add an evitable bo who has reservation object to the correct lru[bo->priority] list Nice catch,

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote: On 05/10/2018 10:40 PM, Christian König wrote: Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add an evitable bo who has reservation object to the correct lru[bo->priority] list Nice catch, but since this affects only a very small

[Bug 106471] Radeon HD 3450 acceleration not working

https://bugs.freedesktop.org/show_bug.cgi?id=106471 Bug ID: 106471 Summary: Radeon HD 3450 acceleration not working Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

On 05/10/2018 10:40 PM, Christian König wrote: Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add an evitable bo who has reservation object to the correct lru[bo->priority] list Nice catch, but since this affects only a very small use case can we just remove and readd the BO to the

[PATCH libdrm 1/1] amdgpu: Take lock before removing devices from fd_tab hash table.

Close the file descriptors under lock as well. Signed-off-by: Jan Vesely --- amdgpu/amdgpu_device.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c index 983b19ab..f71fc050 100644 ---

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

https://bugs.freedesktop.org/show_bug.cgi?id=106470 Bug ID: 106470 Summary: [gma500] BUG: unable to handle kernel NULL pointer dereference at 0081 Product: DRI Version: unspecified Hardware: Other

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

https://bugs.freedesktop.org/show_bug.cgi?id=106470 Dominik 'Rathann' Mierzejewski changed: What|Removed |Added See Also|

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

https://bugzilla.kernel.org/show_bug.cgi?id=199115 Dominik Mierzejewski (domi...@greysector.net) changed: What|Removed |Added See Also|

[Bug 106306] amdgpu CIK power management issues (overdrive and wattman)

https://bugs.freedesktop.org/show_bug.cgi?id=106306 --- Comment #3 from gr...@sub.red --- Thanks, I wasn't aware of that. The old overdrive functionality indeed works with amdgpu.dpm=1 on 4.16. However, it doesn't on 4.17. And wattman functionality doesn't work at all; pp_od_clk_voltage prints

[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)

https://bugs.freedesktop.org/show_bug.cgi?id=84740 Germano Massullo changed: What|Removed |Added Resolution|--- |WONTFIX

[Bug 106466] GPU recovery fails on Vega 64

https://bugs.freedesktop.org/show_bug.cgi?id=106466 Bug ID: 106466 Summary: GPU recovery fails on Vega 64 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 102233, which changed state. Bug 102233 Summary: OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL https://bugs.freedesktop.org/show_bug.cgi?id=102233 What|Removed

[Bug 102233] OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL

https://bugs.freedesktop.org/show_bug.cgi?id=102233 Jan Vesely changed: What|Removed |Added Resolution|--- |NOTOURBUG

Re: [PATCH v1] drm: panel-orientation-quirks: Convert to use match_string() helper

On Mon, May 07, 2018 at 10:12:47AM +0200, Hans de Goede wrote: > Hi, > > On 03-05-18 20:41, Andy Shevchenko wrote: > > The new helper returns index of the matching string in an array. > > We are going to use it here. > > > > Signed-off-by: Andy Shevchenko > >

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

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. > > > > Signed-off-by: Souptick Joarder > > Reviewed-by:

[Bug 74973] [radeonsi] Gimp OpenCL does not work

https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #8 from Jan Vesely --- (In reply to darkbasic from comment #7) > I will be able to test within a couple of months, at the moment I don't have > access to a pc with such hardware. Is this still an issue? gegl

Re: [Freedreno] [DPU PATCH 04/11] drm/msm/dpu: create new platform driver for dpu device

On Thu, May 10, 2018 at 01:59:38PM +0530, Rajesh Yadav wrote: > 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

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

On Thu, May 10, 2018 at 01:59:37PM +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 sub-blocks. > > Currently, in dpu

[PATCH 10/18] efifb: Remove pr_fmt duplicate logging prefixes

Converting pr_fmt from a simple define to use KBUILD_MODNAME added some duplicate logging prefixes to existing uses. Remove them. Signed-off-by: Joe Perches --- drivers/video/fbdev/efifb.c | 48 ++--- 1 file changed, 23 insertions(+),

[PATCH 00/18] Convert default pr_fmt from empty to KBUILD_MODNAME

pr_ logging uses allow a prefix to be specified with a specific #define pr_fmt The default of pr_fmt in printk.h is #define pr_fmt(fmt) fmt so no prefixing of logging output is generically done. There are several output logging uses like dump_stack() that are unprefixed and should remain

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

On Thu, May 10, 2018 at 01:59:45PM +0530, Rajesh Yadav wrote: > 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. > > Signed-off-by: Rajesh Yadav > --- >

Re: [DPU PATCH 10/11] drm/msm/dpu: use runtime_pm calls in dpu_dbg

On Thu, May 10, 2018 at 01:59:44PM +0530, Rajesh Yadav wrote: > 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

[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).

https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #9 from i...@yahoo.com --- The fix for r600/Evergreen has been committed: https://cgit.freedesktop.org/mesa/mesa/commit/?id=ce027ac5c798b39582288e5d7d9973b3cdda591e The Tahiti issue remains under investigation. -- You are receiving

Re: [DPU PATCH 09/11] drm/msm/dp: remove dpu_power_handle calls from dp driver

On Thu, May 10, 2018 at 01:59:43PM +0530, Rajesh Yadav wrote: > 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

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

On Thu, May 10, 2018 at 01:59:42PM +0530, Rajesh Yadav wrote: > 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. > > Signed-off-by: Rajesh Yadav

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

On Thu, May 10, 2018 at 01:59:41PM +0530, Rajesh Yadav wrote: > 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. > > Signed-off-by:

Re: [DPU PATCH 06/11] drm/msm/dpu: use runtime_pm calls on dpu device

On Thu, May 10, 2018 at 01:59:40PM +0530, Rajesh Yadav wrote: > 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

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

On Thu, May 10, 2018 at 01:59:39PM +0530, Rajesh Yadav wrote: > 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. > > Signed-off-by:

Re: [DPU PATCH 01/11] drm/msm: remove redundant pm_runtime_enable call from msm_drv

On Thu, May 10, 2018 at 01:59:35PM +0530, Rajesh Yadav wrote: > 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

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

On Thu, May 10, 2018 at 01:59:38PM +0530, Rajesh Yadav wrote: > 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

Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo

Am 10.05.2018 um 07:01 schrieb Junwei Zhang: Expect to add an evitable bo who has reservation object to the correct lru[bo->priority] list Nice catch, but since this affects only a very small use case can we just remove and readd the BO to the LRU? A call to ttm_bo_move_to_lru_tail() after

Re: [PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)

On Wed, May 9, 2018 at 10:43 AM, Lukasz Majewski wrote: > This commit adds support for KOE's 5.7" display. > > Signed-off-by: Lukasz Majewski Please add ack/reviewed-by's when posting new versions. Rob ___ dri-devel

Re: [PATCH] display: panel: Add KOE tx14d24vm1bpa display support (320x240)

On Fri, May 4, 2018 at 5:28 AM, Lukasz Majewski wrote: > Hi Rob, > >> On Thu, Apr 12, 2018 at 04:37:15PM +0200, Lukasz Majewski wrote: >> > This commit adds support for KOE's 5.7" display. >> > >> > Signed-off-by: Lukasz Majewski >> > --- >> >

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

On Thu, May 10, 2018 at 01:59:37PM +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 sub-blocks. > > Currently, in dpu

[pull] amdgpu drm-fixes-4.17

Hi Dave, Regression fix for Fiji cards with high TDP. The following changes since commit 7c2b134110a6af3bfe574efdb23ee04c047dc311: Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes (2018-05-10 13:48:52 +1000) are available in the git repository at:

[Bug 106428] reported VDDGFX GPU voltage jumps above set limits in pp_od_clk_voltage when UVD is used for VAAPI/VDPAU

https://bugs.freedesktop.org/show_bug.cgi?id=106428 --- Comment #1 from tempel.jul...@gmail.com --- I did some more tests and now I'm very sure that the voltage is just reported wrong when using UVD, and not being actually that high. I also jumps to reported 1.1V without any pstate adjustments or

Re: [DPU PATCH 02/11] drm/msm/mdp5: subclass msm_mdss for mdp5

On Thu, May 10, 2018 at 01:59:36PM +0530, Rajesh Yadav wrote: > 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

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #23 from Daniel Drake --- > Is this a regression? If so, when was the last time it worked correctly? Thanks for looking at this. It is not a regression, we have yet to find a kernel which is able to load

[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #3 from Tim Cuthbertson --- Created attachment 139464 --> https://bugs.freedesktop.org/attachment.cgi?id=139464=edit Full dmesg output after reboot -- You are receiving this mail because: You are the assignee

[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #2 from Tim Cuthbertson --- I am running Wayland, so no Xorg log. I do not know how to get dmesg from a previous crashed session, so I am attaching dmesg from a session that was started with amdgpu.dpm=0. If

Re: [PATCH V1 1/5] qcom: wled: Rename pm8941-wled.c to qcom-wled.c

On Thu 2018-05-03 15:27:08, Kiran Gunda wrote: > pm8941-wled.c driver is supporting the WLED peripheral > on pm8941. Rename it to qcom-wled.c so that it can support > WLED on multiple PMICs. > > Signed-off-by: Kiran Gunda Acked-by: Pavel Machek --

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 2018-05-09 17:08, Andrzej Hajda wrote: > On 04.05.2018 15:51, Peter Rosin wrote: >> Bridge drivers can now (temporarily, in a transition phase) select if >> they want to provide a full owner device or keep just providing an >> of_node. >> >> By providing a full owner device, the bridge drivers

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 2018-05-09 17:53, Peter Rosin wrote: > On 2018-05-09 17:08, Andrzej Hajda wrote: >> On 04.05.2018 15:51, Peter Rosin wrote: >>> Bridge drivers can now (temporarily, in a transition phase) select if >>> they want to provide a full owner device or keep just providing an >>> of_node. >>> >>> By

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

On Monday, May 07, 2018 07:29 PM, Enric Balletbo Serra wrote: Hi Lin, Thanks for the patch. 2018-05-04 10:08 GMT+02:00 Lin Huang : DP firware use fix phy config value to do training, but some s/fiware/firmware/ board need to adjust these value to fit for their

Re: [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters

On Thu, May 08, 2018 at 16:28:30 +0530, Satendra Singh Thakur wrote: > On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote: > > On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote: > > > 1.There is a function in drm-core to calculate display timing parameters: > > >

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

On Wed, May 09, 2018 at 04:41:53PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 9 May 2018 15:11:07 -0400 (EDT) > Alan Stern escreveu: > > > On Wed, 9 May 2018, Mauro Carvalho Chehab wrote: > > > > > Em Wed, 9 May 2018 19:15:01 +0200 > > > Andrea Parri

[PATCH v2 1/2] dt-bindings: Add vendor prefix for DLC Display Co., Ltd.

From: Philipp Zabel DLC provides a wide range of display solutions. Website: http://www.dlcdisplay.com/ Signed-off-by: Philipp Zabel Signed-off-by: Marco Felsch --- Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH v2 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support

This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel. The customer isn't listed as vendor so we have to add the vendor prefix too. Philipp Zabel (2): dt-bindings: Add vendor prefix for DLC Display Co., Ltd. gpu: drm/panel: Add DLC DLC0700YZG-1 panel

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

On Wed, May 09, 2018 at 10:18:52AM -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 valid, removing a few >

[PATCH v2 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support

This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel. The customer isn't listed as vendor so we have to add the vendor prefix too. Philipp Zabel (2): dt-bindings: Add vendor prefix for DLC Display Co., Ltd. gpu: drm/panel: Add DLC DLC0700YZG-1 panel

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

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 on firmware, if software training fail, keep firmware training as

[PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)

This commit adds support for KOE's 5.7" display. Signed-off-by: Lukasz Majewski --- .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 ++ drivers/gpu/drm/panel/panel-simple.c | 26 ++ 2 files changed, 68 insertions(+) create

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

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, if it has error-signaled before dma_fence_add_callback() is called. Signed-off-by: Ezequiel Garcia

Re: [PATCH v2 11/11] docs: fix broken references with multiple hints

On Wed, 9 May 2018, Mauro Carvalho Chehab wrote: > The script: > ./scripts/documentation-file-ref-check --fix-rst > > Gives multiple hints for broken references on some files. > Manually use the one that applies for some files. > > Signed-off-by: Mauro Carvalho Chehab

[PATCH v2 1/2] dt-bindings: Add vendor prefix for DLC Display Co., Ltd.

From: Philipp Zabel DLC provides a wide range of display solutions. Website: http://www.dlcdisplay.com/ Signed-off-by: Philipp Zabel Signed-off-by: Marco Felsch --- Documentation/devicetree/bindings/vendor-prefixes.txt

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

On Wed, May 09, 2018 at 03:20:45PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 9 May 2018 19:15:01 +0200 > Andrea Parri escreveu: > > > On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote: > > > As we move stuff around, some doc references are broken.

Re: [PATCH 1/2] ARM: dts: Restructure Vexpress motherboard includes

On 27/04/18 19:54, Linus Walleij wrote: > It is a bit unorthodox to just include a file in the middle > of a another DTS file, it breaks the pattern from other device > trees and also makes it really hard to reference things > across the files with phandles. > > Restructure the include for the

[PATCH v2 RESEND] display: panel: Add AUO g070vvn01 display support (800x480)

This commit adds support for AUO's 7.0" display. Signed-off-by: Lukasz Majewski --- .../bindings/display/panel/auo,g070vvn01 | 30 + drivers/gpu/drm/panel/panel-simple.c | 31 ++ 2 files changed, 61 insertions(+)

[PATCH] gpu: drm/panel: Add DLC DLC0700YZG-1 panel

From: Philipp Zabel From: Philipp Zabel This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels to the simple-panel driver. Signed-off-by: Philipp Zabel Tested-by: Marco Felsch ---

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

This commit adds support for AUO's 7.0" display. Signed-off-by: Lukasz Majewski --- Changes for v3: - Remove not used 'bus-format-override = "rgb565";' property Changes for v2: - Add *.txt suffix to the auo,g070wn01 file --- .../bindings/display/panel/auo,g070vvn01.txt |

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

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 Signed-off-by: Lin Huang --- Changes in v2: - update

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

Hi Rob, > On Tue, Apr 10, 2018 at 5:29 AM, Lukasz Majewski > wrote: > > This commit adds support for AUO's 7.0" display. > > > > Signed-off-by: Lukasz Majewski > > > > --- > > Changes for v2: > > - Add *.txt suffix to the auo,g070wn01 file > > - Remove not needed

[PATCH v2 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel

From: Philipp Zabel This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels to the simple-panel driver. Signed-off-by: Philipp Zabel [m.fel...@pengutronix.de: fix typo in compatible dt-binding] Signed-off-by: Marco Felsch

[PATCH v2 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel

From: Philipp Zabel This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels to the simple-panel driver. Signed-off-by: Philipp Zabel [m.fel...@pengutronix.de: fix typo in compatible dt-binding] Signed-off-by: Marco Felsch

Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

On 2018-05-07 23:40, Bjorn Andersson wrote: On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: [..] + +#define WLED_AUTO_DETECT_OVP_COUNT 5 +#define WLED_AUTO_DETECT_CNT_DLY_USHZ /* 1 second */ +static bool wled_auto_detection_required(struct wled *wled) So

[PATCH v2 2/4] phy: rockchip-typec: support variable phy config value

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 Signed-off-by: Lin Huang --- Changes in v2: -

[PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

If want to do training outside DP Firmware, need phy voltage swing and pre_emphasis value. Signed-off-by: Lin Huang --- Changes in v2: - rebase Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #22 from jian-h...@endlessm.com --- Created attachment 139462 --> https://bugs.freedesktop.org/attachment.cgi?id=139462=edit dmesg of loading amdgpu module with patch 218586 I tried git://people.freedesktop.org/~agd5f/linux on

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #21 from jian-h...@endlessm.com --- For the question "What physical display connectors are on the board?" There are one HDMI and one VGA connectors on this mother board. I have tried both connectors and both of them hit this bug.

Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang wrote: > > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang wrote: > >> > On Tue, May 08, 2018 at 10:30:19PM

Re: [PATCH 00/13] *** per vm lru ***

On 2018年05月10日 13:07, Zhang, Jerry (Junwei) wrote: On 05/09/2018 02:45 PM, Chunming Zhou wrote: move implemenation from ttm to amdgpu driver. (suggested by Christian) per-vm-lru is because of per-vm-bo, which has no chance to refresh lru, the nagtive effect is game performance isn't stable.

[DPU PATCH 09/11] 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 11/11] 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. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/Makefile | 2 +-

[DPU PATCH 08/11] 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. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/dpu_power_handle.c | 190

[DPU PATCH 02/11] 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 10/11] 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

[DPU PATCH 05/11] 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. Signed-off-by: Rajesh Yadav ---

[DPU PATCH 06/11] 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 07/11] 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. Signed-off-by: Rajesh Yadav ---

[DPU PATCH 04/11] 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 00/11] 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 03/11] 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 01/11] 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. Signed-off-by: Rajesh Yadav ---

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

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 > dangling pointers from the bridge consumer (the drm_device) to some > non-existent bridge supplier. > >

Re: [PATCH v2 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach

On 04.05.2018 15:52, Peter Rosin wrote: > The .odev owner device will be handy to have around. > > Signed-off-by: Peter Rosin Reviewed-by: Andrzej Hajda  -- Regards Andrzej > --- > drivers/gpu/drm/drm_bridge.c | 6 ++ > 1 file changed, 6 insertions(+)

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #20 from jian-h...@endlessm.com --- Created attachment 139456 --> https://bugs.freedesktop.org/attachment.cgi?id=139456=edit amdgpu_vbios This is the amdgpu_vbios copied from /sys/kernel/debug/dri/0/amdgpu_vbios on this ACER

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 10.05.2018 00:21, Peter Rosin wrote: > On 2018-05-09 17:53, Peter Rosin wrote: >> On 2018-05-09 17:08, Andrzej Hajda wrote: >>> On 04.05.2018 15:51, Peter Rosin wrote: Bridge drivers can now (temporarily, in a transition phase) select if they want to provide a full owner device or