is report is about the radeon driver, let's not confuse things here by mixing
in amdgpu-pro issues.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/
[ Adding Dan Williams and dri-devel ]
On 14/10/16 03:28 AM, Shawn Starr wrote:
> Hello AMD folks,
>
> I have discovered a problem in Linus master that affects AMDGPU, nobody would
> notice this in drm-next-4.9-wip since its not in this repo.
[...]
> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is
g didn't happen.
So I don't think our word is less valid just because *one* user claimed he/she
disabled DPM and the hang still happened.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
U
[snip]
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> @@ -0,0 +1,15 @@
> +config DRM_HISI_HIBMC
> + tristate "DRM Support for Hisilicon Hibmc"
> + depends on DRM && PCI
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select DRM_GEM_CMA_HE
On Thu, Oct 13, 2016 at 04:14:04PM -0400, Rob Clark wrote:
> On Thu, Oct 13, 2016 at 2:24 PM, Ville Syrjälä
> wrote:
> > On Thu, Oct 13, 2016 at 01:16:29PM -0400, Rob Clark wrote:
> >> Sometimes we just want to see the atomic state, without getting so many
> >> other debug traces. So add a new
n HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/a05b382d/attachment-0001.html>
On Thu, 13 Oct 2016, Daniel Vetter wrote:
> I was a bit over-eager in my cleanup in
>
> commit 95c081c17f284de50eaca60d4d55643a64d39019
> Author: Daniel Vetter
> Date: Tue Jun 21 10:54:12 2016 +0200
>
> drm: Move master pointer from drm_minor to drm_device
>
> Noticed by Chris Wilson.
>
> F
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/6f916818/attachment.html>
On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> intermediate edid reads. This causes transient failures in CI which
> flags up the sporadic EDID read failures, which are recovered by
> rereading the EDID automat
Hi Brian,
On 10/11/2016 08:23 PM, Brian Starkey wrote:
> Hi,
>
> This RFC series introduces a new connector type:
> DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
>
> Writeback connectors are used to expose the memory writeback engines
> found in some display con
On Fri, Oct 14, 2016 at 01:46:37PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> > Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> > intermediate edid reads. This causes transient failures in CI which
> > flags up the sporadi
hares initrd.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/3e61ed33/attachment-0001.html>
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
On 10/13/2016 10:18 PM, Rob Clark wrote:
> If the bottom-most layer is not fullscreen, we need to use the BASE
> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The
> blend_setup() code pretty much handled this already, we just had to
> figure this out in _atomic_check() and
Hi Archit,
On Fri, Oct 14, 2016 at 04:20:14PM +0530, Archit Taneja wrote:
>Hi Brian,
>
>On 10/11/2016 08:23 PM, Brian Starkey wrote:
>>Hi,
>>
>>This RFC series introduces a new connector type:
>> DRM_MODE_CONNECTOR_WRITEBACK
>>It is a follow-on from a previous discussion: [1]
>>
>>Writeback connec
On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> > Multiple incompatible data
On Thu, Oct 13, 2016 at 12:48:46PM -0400, Rob Clark wrote:
> If the bottom-most layer is not fullscreen, we need to use the BASE
> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The
> blend_setup() code pretty much handled this already, we just had to
> figure this out in _ato
Hi Alex,
Your new attached patch is Tested-by and Reviewed-by: Rex Zhu
Just one question,
Do we need to set clock_gate for smu?
Best Regards
Rex
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, October 13, 2016 11:29 PM
To: Zhu, Rex
Cc: Grazvyda
On Fri, Oct 14, 2016 at 01:39:15PM +0100, Brian Starkey wrote:
> Hi Archit,
>
> On Fri, Oct 14, 2016 at 04:20:14PM +0530, Archit Taneja wrote:
> >Hi Brian,
> >
> >On 10/11/2016 08:23 PM, Brian Starkey wrote:
> >>Hi,
> >>
> >>This RFC series introduces a new connector type:
> >> DRM_MODE_CONNECTOR_
On Fri, Oct 14, 2016 at 02:54:59PM +0200, Dmitry Vyukov wrote:
> Size of kmalloc() in vga_arb_write() is controlled by user.
> Too large kmalloc() size triggers WARNING message on console.
> Allocate the buffer on stack to avoid the WARNING.
> The string must be small (e.g "target PCI:domain:bus:de
ARC PGU driver starts crashing on initialization after
'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
of "drm_i2c_encoder_driver" structure, which doesn't exist after
adv7511 hdmi encoder interface changed fr
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Zhu, Rex
> Sent: Friday, October 14, 2016 8:12 AM
> To: Alex Deucher
> Cc: Maling list - DRI developers; amd-gfx list
> Subject: RE: [PATCH] drm/amd/powerplay: don't give up if DPM is alrea
On Fri, Oct 14, 2016 at 8:45 AM, Ville Syrjälä
wrote:
> On Thu, Oct 13, 2016 at 12:48:46PM -0400, Rob Clark wrote:
>> If the bottom-most layer is not fullscreen, we need to use the BASE
>> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The
>> blend_setup() code pretty much
Just by curiosity, why using "old" TTM instead of GEM ? any particular reasons ?
2016-10-14 16:44 GMT+02:00 Rongrong Zou :
> Hi Benjamin,
>
> Thanks for reviewing!
>
> Benjamin Gaignard æ¼ 2016/10/14 16:29 寫é:
>>
>> [snip]
>>
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
Hello Rex Zhu,
The patch 599a7e9fe1b6: "drm/amd/powerplay: implement smu7 hwmgr to
manager asics with smu ip version 7." from Sep 9, 2016, leads to the
following static checker warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:2125
smu7_patch_limits_vddc()
warn:
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/f43ab8f8/attachment.html>
ktop.org/archives/dri-devel/attachments/20161014/65669c70/attachment.html>
On Fri, Oct 14, 2016 at 2:39 PM, Brian Starkey wrote:
>> - Besides the above property, writeback hardware can have provisions
>> for scaling, color space conversion and rotation. This would mean that
>> we'd eventually add more writeback specific props/params in
>> drm_connector/drm_connector_stat
l at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-powerplay-smu7-fix-static-checker-warning.patch
Type: text/x-patch
Size: 1557 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/c36f0df1/attachment.bin>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161014/a4c6fc63/attachment.html>
Hi Dave,
Fixes for radeon and amdgpu for 4.9:
- allow an additional reg in the SI reg checker
- fix thermal sensor readback on CZ/ST
- misc bug fixes
The following changes since commit 69405d3da98b48633b78a49403e4f9cdb7c6a0f5:
Merge tag 'topic/drm-misc-2016-10-11' of
git://anongit.freedesktop
eceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/64c5df1d/attachment.html>
On 2016-09-15 11:04 -0400, Jerome Glisse wrote:
>> On Mon, Sep 5, 2016 at 10:25 PM, Jerome Glisse wrote:
>> >> Recently I got myself a new laptop with the following integrated GPU:
>> >>
>> >> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
>> >> Mullins [Radeon R3 Graph
.org/archives/dri-devel/attachments/20161014/f94f87d9/attachment-0001.html>
While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of featu
First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.
Changes since v1:
- Don't replace allo
Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.
Changes since v1:
- Style nit
Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw regis
Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Reviewed-by: Paulo Zanoni
Cc: Ville Syrjälä
Cc: Matt Roper
---
drivers/gpu/drm/i915/int
Thanks to Paulo Zanoni for indirectly pointing this out.
Looks like we never actually added any code for checking whether or not
we actually wrote watermark levels properly. Let's fix that.
Changes since v1:
- Use %u instead of %d when printing WM state mismatches
Signed-off-by: Lyude
Reviewed-
Helper we're going to be using for implementing verification of the wm
levels in skl_verify_wm_level().
Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 14
Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.
Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Matt Roper
--
This function is a wreck, let's help it get its life back together and
cleanup all of the copy pasta here.
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Reviewed-by: Paulo Zanoni
Cc: Ville Syrjälä
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 52 +++
There's not much of a reason this should have the locations to read out
the hardware state hardcoded, so allow the caller to specify the
location and add this function to intel_drv.h. As well, we're going to
need this function to be reusable for the next patch.
Changes since v1:
- Fix accidental b
Wrapping strings is against the guidelines in Documentation/CodingStyle,
chapter 2.
Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
di
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/a9b8cd19/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161014/771ca970/attachment.html>
We had this wired up already internally but initially did not expose the
property pending bikeshed about alpha and color management properties.
I noted that drm-hwc2 was looking for this property, and a couple other
drivers already support it in the same way. So time to expose it!
Signed-off-by:
Bit more spiffed out version of the RFC. Now with Sean's suggestion to
add vfuncs in plane/crtc/connector funcs for drivers that subclass the
various state structs. Plus Ville's suggestion about helper macros
for printing mode/rect structs (and alignment with how drm_rect printed
the integer and
Sometimes it is nice not to duplicate equivalent printk() and
seq_printf() code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/Makefile| 3 ++-
drivers/gpu/drm/drm_print.c | 54 +++
include/drm/drm_print.h | 62 +
We subclass drm_plane_state, so add mdp5_plane_atomic_print_state() to
dump out our own driver specific plane state.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 12
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 18 +-
2 files changed, 29 in
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c | 93
include/drm/drmP.h | 1 +
include/drm/drm_crtc.h | 37 ++
3 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/d
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c | 40
drivers/gpu/drm/drm_debugfs.c | 9 +
include/drm/drm_atomic.h | 4
3 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomi
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_simple_kms_helper.c | 14 ++
drivers/gpu/drm/i915/intel_atomic_plane.c | 10 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 15 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++
include/drm/drm
I'll want to print things in a similar way in a later patch. This will
make it easier.
TODO drm_rect_debug_print() doesn't have many call sites, and is kind of
unnecessary now. Should we just drop it?
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_modes.c | 8 +---
drivers/gpu/drm/drm_
On Fri, Oct 14, 2016 at 7:55 PM, Rob Clark wrote:
> Bit more spiffed out version of the RFC. Now with Sean's suggestion to
> add vfuncs in plane/crtc/connector funcs for drivers that subclass the
> various state structs. Plus Ville's suggestion about helper macros
> for printing mode/rect struct
Size of kmalloc() in vga_arb_write() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Allocate the buffer on stack to avoid the WARNING.
The string must be small (e.g "target PCI:domain:bus:dev.fn").
Signed-off-by: Dmitry Vyukov
Reviewed-by: Ville Syrjälä
Cc
On Fri, Oct 14, 2016 at 3:06 PM, Ville Syrjälä
wrote:
> On Fri, Oct 14, 2016 at 02:54:59PM +0200, Dmitry Vyukov wrote:
>> Size of kmalloc() in vga_arb_write() is controlled by user.
>> Too large kmalloc() size triggers WARNING message on console.
>> Allocate the buffer on stack to avoid the WARN
Size of kmalloc() in vga_arb_write() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Allocate the buffer on stack to avoid the WARNING.
The string must be small (e.g "target PCI:domain:bus:dev.fn").
Signed-off-by: Dmitry Vyukov
Cc: Dave Airlie
Cc: Ville SyrjÃ
Hi Benjamin,
Thanks for reviewing!
Benjamin Gaignard æ¼ 2016/10/14 16:29 寫é:
> [snip]
>
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> @@ -0,0 +1,15 @@
>> +config DRM_HISI_HIBMC
>> + tristate "DRM Support for Hisilicon Hibmc"
>> + depends on DRM && PCI
>> +
Benjamin Gaignard æ¼ 2016/10/14 22:33 寫é:
> Just by curiosity, why using "old" TTM instead of GEM ? any particular
> reasons ?
Do you mean i can manage the video memory visiable to pci without TTM,
i found all the other simple gpu chips(eg: AST, mgag200) use TTM, so i
chose TTM.
>
> 2016-1
61 matches
Mail list logo
