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 keep
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&action=edit
amdgpu_vbios
This is the amdgpu_vbios copied from /sys/kernel/debug/dri/0/amdgpu_vbios on
this ACER
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(+)
>
> diff --git a/drivers/gpu/drm/drm_br
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.
>
> Signed-off-b
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
---
drivers/gpu/drm/msm/msm_drv.c | 1
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 mana
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 an
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
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 44 ++--
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 runtime_p
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 (msm_m
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
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68
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 +---
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 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_i
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_power_handle
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.
s
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 +0300, Jani Nikula wrote:
> >> >> On Wed, 09 M
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.
-
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&action=edit
dmesg of loading amdgpu module with patch 218586
I tried git://people.freedesktop.org/~agd5f/linux
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 a/Documentation/devic
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
---
.../display/panel/dlc,dlc0700yzg-1.txt| 7
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 cfg.auto_dete
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:
- update patch following Enric suggest
drivers/
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
---
.../display/panel/dlc,dlc0700yzg-1.txt| 7
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 bus-format-override = "rgb565";
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(+)
create mode 100644
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 patch following Enric suggest
drivers/gpu/drm/rockchip/cdn-dp-c
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
---
.../bindings/panel/dlc,dlc0700yzg-1.txt | 7
.../devicetree/bindings/vendor-prefixes.txt
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 | 29 +
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
---
drivers/dma-buf/
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
Acked-by: James Mo
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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetr
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. Fix some of
> > > them vi
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 V
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 a
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
.../displ
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
> fals
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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetr
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 mode 100644
Docum
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 escreveu:
> >
> > > > > tools/memory-
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
.../displ
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:
> > > horizo
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 hardware design,
so we use n
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 n
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 pro
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
--
(english) http://www.livejournal.com/~pavelma
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 this is
not what you nee
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&action=edit
Full dmesg output after reboot
--
You are receiving this mail because:
You are the assignee for the bug._
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 amdgpu without crashing on
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 mds
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
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:
git://people.fr
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 dr
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
>> > ---
>> > .../bindings/display/panel/koe,tx14d24vm1bpa.txt |
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 mailing list
dri-devel@lists.freede
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 s
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 current
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 msm_drv
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:
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
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: Ra
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
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 sam
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
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 runtime_pm
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
> ---
> drivers/gpu/drm/msm/Mak
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 unprefix
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(+), 25 deletions(-)
dif
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 dr
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 current
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 testsuite mostly passes w
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: Matthew Wilcox
> > ---
> > drivers/gpu/drm
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
>
> Thanks, LGTM:
>
> Acked-by: Hans d
https://bugs.freedesktop.org/show_bug.cgi?id=102233
Jan Vesely changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEEDINFO
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 |Add
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
Pr
https://bugs.freedesktop.org/show_bug.cgi?id=84740
Germano Massullo changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
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 no
https://bugzilla.kernel.org/show_bug.cgi?id=199115
Dominik Mierzejewski (domi...@greysector.net) changed:
What|Removed |Added
See Also||https://bu
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
https://bugs.freedesktop.org/show_bug.cgi?id=106470
Dominik 'Rathann' Mierzejewski changed:
What|Removed |Added
See Also||https://bugzilla.kernel
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
--- a/amdgpu/amdgpu_device.c
+++ b/a
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 LRU
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
Se
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 u
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, bu
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
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 an
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&action=edit
dmesg of loading amdgpu module - tested in 4.17-rc4
I also tried Linux kernel 4.17-rc4 again. Howe
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: x86
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 fix
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 b/drivers/gpu/drm/ttm/ttm_bo.c
index
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
--- a/drivers/gpu/drm/amd/amdg
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: amd-...@lists.freedesktop.org; dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=106474
Bug ID: 106474
Summary: "CPU1 stuck for XXs: Xorg" since update to
linux-4.16.x
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=106474
--- Comment #1 from Clemens Eisserer ---
Created attachment 139490
--> https://bugs.freedesktop.org/attachment.cgi?id=139490&action=edit
dmesg of the affected machine running 4.15.17
--
You are receiving this mail because:
You are the assign
Looks like a good idea to me as well. Reviewed-by: Christian König
for the series.
Regards,
Christian.
Am 11.05.2018 um 07:27 schrieb Zhou, David(ChunMing):
The series is OK to me, Reviewed-by: Chunming Zhou
It is better to wait Christian to have a look before pushing patch.
Regards,
Dav
98 matches
Mail list logo
