On 2019-04-15 10:27 a.m., Nicholas Kazlauskas wrote:
> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the
> list of valid formats.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> -
e monitor.
>
> [How]
> There was previously a fix that prevented this from happening in the
> low range but it didn't cover the upper range. Expand the condition
> to include both.
>
> Cc: Sun peng Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Revie
On 2019-03-21 5:39 a.m., Mario Kleiner wrote:
> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
> wrote:
>>
>> On 3/20/19 3:51 AM, Mario Kleiner wrote:
>>> Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
>>>
>>> On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nichola
On 2019-03-18 5:58 p.m., Paul Menzel wrote:
>
> Dear Harry,
>
... snip ...
>>
>> Michel, do you know if this is supposed to work with
>> xf86-video-amdgpu? When I've tried it before I didn't have any luck but
>> didn't have time to look into it.
>
> Sorry, what is your question. With the com
On 2019-03-08 4:11 a.m., Michel Dänzer wrote:
> On 2019-03-06 5:35 p.m., Paul Menzel wrote:
>> On 03/06/19 15:55, Michel Dänzer wrote:
>>> On 2019-03-06 1:41 p.m., Paul Menzel wrote:
On 03/05/19 20:07, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:
>> Usin
; list this patch also fixes a double-free in the case where we fail to
> initialize only some of the planes.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
rmat instead since this is only correct for YUV420 formats.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +--
> 1 file changed, 10 in
On 2019-02-26 4:24 p.m., Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.12, v4.19.25, v4.1
On 2019-03-01 11:46 a.m., Wentland, Harry wrote:
> On 2019-03-01 11:43 a.m., Bhawanpreet Lakha wrote:
>> Fixes the warnings below
>>
>> warning: ‘ta_hdr’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> warning: ISO C90 fo
552e39816c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -142,7 +142,7 @@ static ssize_t amdgpu_ras_debugfs_read(struct file *f,
> char __user *buf,
> return 0;
>
> s -= *pos;
> - s = mi
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with t
le422 is renamed to simple_422 to avoid
> confusion
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dsc.c | 31 +++
> drivers/gpu/drm/i915/intel_vdsc.c | 4 ++--
> include/drm/drm_dsc.h
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it. The function is not changed; just moved and renamed.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentl
On 2019-02-07 2:21 p.m., Wentland, Harry wrote:
> On 2019-02-06 4:48 a.m., Przemek Socha wrote:
>> Good morning,
>>
>> on my Lenovo G50-45 a6310 APU with R4 Mullins commit
>> e261568f94d6c37ebb94d3c4b3f8a3085375dd9d is causing kernel Oops (unable to
>>
On 2019-02-06 4:48 a.m., Przemek Socha wrote:
> Good morning,
>
> on my Lenovo G50-45 a6310 APU with R4 Mullins commit
> e261568f94d6c37ebb94d3c4b3f8a3085375dd9d is causing kernel Oops (unable to
> handle NULL pointer).
Thanks. Obviously this change leads to a NULL pointer dereference as
dal_g
On 2019-02-04 3:16 a.m., Vishwakarma, Pratik wrote:
> Remove extraneous parentheses around the comparison
> to silence this warning
>
> Signed-off-by: Pratik Vishwakarma
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c | 2 +-
IG_DEBUG_FS - CRC capture isn't supported
> without this.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Fixes: 43a6a02eb355 ("drm/amd/display: Re-enable CRC capture following
> modeset")
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
/dce110/dce110_hw_sequencer.c
> @@ -2535,7 +2535,7 @@ static void dce110_apply_ctx_for_surface(
> }
>
> if (dc->fbc_compressor)
> - enable_fbc(dc, dc->current_state);
> + enable_fbc(dc, context);
Looks good, but I'd want Roma'
On 2019-02-01 5:55 p.m., sylvain.bertr...@gmail.com wrote:
> On Fri, Feb 01, 2019 at 09:20:56PM +0000, Wentland, Harry wrote:
>> DRM's AUX code uses usleep_range in drm_dp_dpcd_access.
>
> My bad, forgot about the usleep_range switch. That said AUX_RETRY_INTERVAL is
> 500
On 2019-02-01 3:47 p.m., sylvain.bertr...@gmail.com wrote:
> On Fri, Feb 01, 2019 at 08:08:30PM +, sylvain.bertr...@gmail.com wrote:
>> Do you mean non-DC displayport related code is already using udelay instead
>> of msleep on linux?
>
> I grep-ed amdgpu displayport atombios code, got udela
On 2019-02-01 12:31 p.m., sylvain.bertr...@gmail.com wrote:
> On Fri, Feb 01, 2019 at 10:28:13AM -0500, Bhawanpreet Lakha wrote:
>> From: John Barberiz
>> [How]
>> msleep is inaccurate for small values. Used udelay
>> instead for accuracy.
>
> Hi,
>
> Should it be the case for non-DC displayport
On 2019-01-29 1:56 p.m., Guenter Roeck wrote:
> On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote:
>> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry
>> wrote:
>>>
>>> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
>>>> arch/x86
finding and reverting.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +-
> drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/
Dänzer
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd
On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
> arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
> on SSE2 to support emitting double precision floating point instructions
> rather than calls to no
On 2019-01-25 3:25 a.m., Koenig, Christian wrote:
> Am 25.01.19 um 08:42 schrieb Sedat Dilek:
>> [ CC Nick D. ]
>>
>> Hi Christian,
>>
>> Nick has posted a fix in [2].
>> Is that OK for you?
>
> I've seen that and yeah I'm perfectly fine with it, but Harry is the one
> who needs to decide.
>
Lo
g
>
>
FYI, IGT test case making use of this:
https://patchwork.freedesktop.org/patch/275982/
Reviewed-by: Harry Wentland
Harry
>> ---
>> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 ++-
>> 1 file changed, 21 insertions(+), 1 deletion(-)
On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> This is the series I've been working on for a while now to get all of
> the atomic DRM drivers in the tree to use the atomic MST helpers, and to
> make the atomic MST helpers actually idempotent. Turns out it's a lot
> more difficult to do that without a
aconnector->port in
> dm_dp_destroy_mst_connector(). There's literally no point to that
> assignment that I can see anyway.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry We
ually release said
> payloads correctly.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 54 +
l Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topolo
aul
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 55 +--
> 1 file changed, 44 insertions(+), 11 deletions(-)
>
On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things could be simpli
one else's driver.
>
> Cc: Jerry Zuo
With the small change Daniel mentioned this series is
Reviewed-by: Harry Wentland
Harry
>
> Lyude Paul (3):
> drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
> drm/amdgpu: Don't fail resume process
On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expression by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 6d04ee9dc101 ("drm/amd/display: Restructuring and cleaning up DML")
> Cc: sta...@v
aximum vrr range to duplicate frames
> when appropriate by tracking flip timestamps.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 +++
ed offset on the
> framebuffer address. The DCC address is updated whenever the buffer
> address changes.
>
> Cc: Marek Olšák
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdg
chives/dri-devel/2018-December/201008.html
> Signed-off-by: Ken Chalmers
> Reviewed-by: Leo Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
ly pre-coffee that helps :-)
I concur. Something like "use local variables to improve readability".
With that fixed this is
Reviewed-by: Harry Wentland
Harry
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology
t;payloads[i].start_slot != req_payload.start_slot) {
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> -}
>> + mgr->payloads[i].start_slot = req_payload.start_slot;
>
> Entertaining!
>
> Reviewed-by: D
t-flip handlers from the FreeSync module.
> These adjust the minimum/maximum vrr range to duplicate frames
> when appropriate by tracking flip timestamps.
>
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
> Acked-by: Leo Li
Reviewed-by: Harry Wentland
On 2018-12-15 4:42 a.m., Mikhail Gavrilov wrote:
> On Sat, 15 Dec 2018 at 00:36, Wentland, Harry wrote:
>>
>> Looks like there's an error before this happens that might get us into this
>> mess:
>>
>> [ 229.741741] [drm:amdgpu_job_timedout [amdgpu]] *ERR
On 2018-12-11 5:07 p.m., Nick Desaulniers wrote:
> On Tue, Dec 11, 2018 at 1:42 PM Nathan Chancellor
> wrote:
>>
>> On Tue, Dec 11, 2018 at 01:25:00PM -0800, Nick Desaulniers wrote:
>>> On Mon, Dec 10, 2018 at 3:42 PM Nathan Chancellor
>>> wrote:
Clang warns when an expression that equa
ursor-vs-flip-varying-size
>
> Cc: Leo Li
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
> 1 file changed, 10 insertio
On 2018-12-04 5:18 p.m., Mikhail Gavrilov wrote:
> Hi guys.
> I having troubles when Vega GPU is hang I unable reboot system.
>
> Can somebody help me please.
>
> I tried enter follow commands:
> # init 6
> # reboot
> But no one of them having success.
>
> SysRq-W showing to us this:
>
Looks l
On 2018-12-07 3:32 p.m., Kuehling, Felix wrote:
> On 2018-12-07 9:46 a.m., Wentland, Harry wrote:
>> On 2018-12-07 9:41 a.m., Wentland, Harry wrote:
>>> On 2018-12-07 12:40 a.m., Kuehling, Felix wrote:
>>>> This change seems to be breaking the build for me. I&#x
On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
>
> Signed-off-by: Chunming Zhou
+igt-dev
I think intel-gfx still works for IGT development but most of the IGT work
happens on igt-...@lists.freedesktop.org now.
Harry
> ---
> include/drm-uapi/drm.h | 33 ++
On 2018-12-07 9:41 a.m., Wentland, Harry wrote:
> On 2018-12-07 12:40 a.m., Kuehling, Felix wrote:
>> This change seems to be breaking the build for me. I'm getting errors like
>> this:
>>
>> CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdg
On 2018-12-07 12:40 a.m., Kuehling, Felix wrote:
> This change seems to be breaking the build for me. I'm getting errors like
> this:
>
>CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o
> In file included from ../include/trace/events/tlb.h:9:0,
> from ../a
ry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/
Does this patch help you?
https://patchwork.freedesktop.org/patch/264781/
The easiest way to test it would be to build and try the amd-staging-drm-next
branch from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next
Which monitors are you using and how are they connected (DP, HDMI
---
> *From:* Deucher, Alexander
> *Sent:* Wednesday, November 28, 2018 12:06:26 AM
> *To:* S, Shirish; Li, Sun peng (Leo); Wentland, Harry
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ
&
lla: https://bugs.freedesktop.org/108825
> Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector
> property")
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm
On 2018-11-27 3:52 a.m., S, Shirish wrote:
> This patch extends the below patch to apply DP signal type, for exactly
> the same reasons it was disabled for HDMI.
>
> "1a0e348 drm/amd/display: Disable 4k 60 HDMI on DCE11"
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/amd/display/dc/dce/dc
On 2018-11-27 11:18 a.m., David Francis wrote:
> The fallback code for getting default backlight caps was using
> the wrong variable name. Fix it.
>
> Fixes:
> https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.html
> Signed-off-by: David Francis
Reviewed-
On 2018-11-27 4:22 a.m., Daniel Vetter wrote:
> On Mon, Nov 12, 2018 at 04:12:10PM +0000, Wentland, Harry wrote:
>> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
>>> These include the drm_connector 'vrr_capable' and the drm_crtc
>>> 'vrr_enabled&#x
On 2018-11-12 12:05 p.m., Kazlauskas, Nicholas wrote:
> On 11/12/18 11:12 AM, Wentland, Harry wrote:
>> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
>>> These include the drm_connector 'vrr_capable' and the drm_crtc
>>> 'vrr_enabled' propert
When DM
> backlight device is updated, copy over the
> backlight caps into DM, but only once. Use
> the backlight caps in the backlight-to-dc
> calculation.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amd
t message, only attach property if DMCU loaded
> v3:
> Store ABM level in crtc state to accommodate dc
> v4:
> Fix ABM saving on dpms cycle
>
> Signed-off-by: David Francis
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display
On 2018-11-12 10:32 p.m., Rex Zhu wrote:
> the clk value should be tranferred to MHz first and
> then transfer to uint16. otherwise, the clock value
> will be truncated.
>
> Reported-by: Hersen Wu
> Signed-off-by: Rex Zhu
Reviewed-by: Harry Wentland
Harry
> ---
&
On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Manasi Navare
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
Looks
_bug.cgi?id=200645
> Fixes: e03fd3f300f6 ("drm/amd/display: Do not limit color depth to 8bpc")
>
> Signed-off-by: Nicholas Kazlauskas
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16
> .../gpu/dr
esktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> C
ACPI Control Methods V0.44
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 31 ++---
> drivers/gpu/drm/amd/include/amd_acpi.h | 151 +++
> 2 files changed, 56 insertions(+)
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the ma
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the maxi
nly caller affected by this change is the DRM helper for
> calculating vblank timestamps. This change corrects behavior for
> calculating the page flip timestap from being the previous timestamp
> to the calculation to the next timestamp when position >= vtotal.
>
> Signed-off-by: Nich
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Manasi Navare
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
> --
On 2018-11-06 3:29 p.m., Alex Deucher wrote:
> Causes a black screen on a Stoney laptop.
>
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577
> Signed-off-by: Alex Deucher
Thanks.
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd
On 2018-11-06 11:24 a.m., Alex Deucher wrote:
> In case we need to access CLK registers.
>
> Signed-off-by: Alex Deucher
Acked-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/dr
user passes in a backlight value of 0,
> tell them everything is fine, then write a value of
> 1 to hardware.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> Bugzilla: https://bugs.freedesktop.org/108668
> Fixes: 416615ea9578 ("drm/amd/display: s
On 2018-11-02 9:26 a.m., David Francis wrote:
> This will clean up powerplay code, as we are no longer
> multiplying the clocks by 1000 in DM and then dividing them
> by 1000 in powerplay
>
> Signed-off-by: David Francis
Series is
Reviewed-by: Harry Wentland
Harry
> ---
On 2018-11-05 2:27 p.m., Alex Deucher wrote:
> Causes a black screen on Stoney laptop.
>
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion
On 2018-11-05 2:27 p.m., Alex Deucher wrote:
> The value is dependent on whether fbc is available.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/
g for MST connectors managed to
> paper over this issue entirely; hence why this was never caught until
> now.
>
> [how]
> Since this code isn't used anywhere and seems useless anyway, we can
> just drop it entirely. This appears to fix the issue on my HP ZBook with
> an A
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 6 +++---
> drivers/gpu/drm/amd/include/dm_pp_interface.h| 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
ck on:
> 1. Detect new topology, and create new connectors.
> 2. Notify userspace with sysfs hotplug event.
> 3. Reprobe new connectors, and reassign CRTC from old (e.g., DP2)
> to new (e.g., DP3) connector.
>
> Signed-off-by: Jerry (Fangzhi) Zuo
Series is
Reviewed-by: Harry Wentland
On 2018-10-30 3:34 p.m., David Francis wrote:
> We were multiplying clock requests by 1000 in amdgpu_dm
> and then dividing them by 1000 in powerplay.
>
> Also, the vega12 code was dividing by 10 when it should have been
> multiplying (to convert units of 10kHz to units of kHz).
>
> Signed-off-by
On 2018-10-26 2:44 a.m., Guttula, Suresh wrote:
>
>
> On 10/26/2018 12:04 AM, Wentland, Harry wrote:
>> On 2018-10-25 2:58 a.m., Guttula, Suresh wrote:
>>> This patch will work as workaround for silicon limitation
>>> related to PWM dutycycle when the backlight
On 2018-10-25 2:58 a.m., Guttula, Suresh wrote:
> This patch will work as workaround for silicon limitation
> related to PWM dutycycle when the backlight level goes to 0.
>
> Actually PWM value is 16 bit value and valid range from 1-65535.
> when ever user requested to set this PWM value to 0 whic
fore the CRTC
> disable pass.
>
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
>
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
>
> Signed-off-by: Nicholas Kaz
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22
intended for atomic use
> it isn't filtered from legacy userspace queries. This allows for Xorg
> userspace drivers to implement support.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_connector.c | 49 +
> include/drm/drm_connector.h | 15 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/g
On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't w
On 2018-10-18 1:38 p.m., Wentland, Harry wrote:
> On 2018-10-16 11:48 a.m., Alex Deucher wrote:
>> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo)
>> wrote:
>>>
>>>
>>>
>>> On 2018-10-16 08:33 AM, Daniel Vetter wrote:
>>>> On
On 2018-10-16 11:48 a.m., Alex Deucher wrote:
> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo)
> wrote:
>>
>>
>>
>> On 2018-10-16 08:33 AM, Daniel Vetter wrote:
>>> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote:
From: Leo Li
This fixes a general protectio
On 2018-10-18 11:30 a.m., David Francis wrote:
> In a refactor, the watermark clock inputs to
> powerplay from DC were changed from units of 10kHz to
> kHz clocks.
>
> One division by 100 was not converted into a division
> by 1000.
>
> Signed-off-by: David Francis
Rev
On 2018-10-17 4:42 p.m., Alex Deucher wrote:
> On Wed, Oct 17, 2018 at 4:16 PM Wentland, Harry
> wrote:
>>
>> On 2018-10-17 4:10 p.m., Alex Deucher wrote:
>>> On Wed, Oct 17, 2018 at 3:54 PM Wentland, Harry
>>> wrote:
>>>>
>>>> On 201
On 2018-10-17 4:10 p.m., Alex Deucher wrote:
> On Wed, Oct 17, 2018 at 3:54 PM Wentland, Harry
> wrote:
>>
>> On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
>>> DCE6 targets are added replicating existing DCE8 implementation.
>>> ---
>>> driver
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
>
> NOTE: due to missing CRTC_VERTICAL_INTERRUPT0_CONTROL registers/masks,
> dce/dce_8_0_{d,sh_mask}.h headers were used instead of
> dce/dce_6_0_{d,sh_mask}.h
> but only as exception
On 2018-10-17 3:50 p.m., Wentland, Harry wrote:
> On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
>> DCE6 targets are added as branching of existing DCE8 implementation.
>
> All your parents require a Signed-off-by. See
> https://www.kernel.org/doc/html/v4.17/process/submi
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
> ---
> drivers/gpu/drm/amd/display/dc/bios/Makefile | 9 +
> .../display/dc/bios/command_table_helper.c| 8 +
> .../display/dc/bios/command_table_helper.h| 3 +
> .../disp
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added as branching of existing DCE8 implementation.
All your parents require a Signed-off-by. See
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Harry
> ---
> .../gpu/drm
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
>
> NOTE: dce_8_0_{d,sh_mask}.h headers used instead of dce_6_0_{d,sh_mask}.h
> only to build dce60_resource.c due to missing *_DCE60 macros/registers/masks
>
> IMPORTANT: Coding of dce6
95 matches
Mail list logo
