Re comments about infinite retry: gotcha, makes sense to me.
On Tue, 2022-09-27 at 09:45 +1000, Alistair Popple wrote:
> John Hubbard writes:
>
> > On 9/26/22 14:35, Lyude Paul wrote:
> > > > + for (i = 0; i < npages; i++) {
> > > > +
Since this isn't actually a failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2cd0932b
be
blocked.
So, let's only use pm_runtime_put_autosuspend().
Changes since v1:
* Use pm_runtime_put_autosuspend(), not pm_runtime_put()
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
2 files changed, 2 i
Noticed these minor issues while trying to investigate
https://bugzilla.redhat.com/show_bug.cgi?id=2086470
While unfortunately I've been unable to confirm whether these patches
fix the specific problem in question, they're likely fixes we want to
pull in regardless.
Lyude Paul
Reviewed-by: Lyude Paul
You also have permission to push this to drm-misc-whatever
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and a
; drivers/platform/x86/asus-nb-wmi.c | 21 -
> drivers/platform/x86/asus-wmi.c | 13 -
> drivers/platform/x86/asus-wmi.h | 2 -
> drivers/platform/x86/eeepc-wmi.c | 25 +-
> drivers/platform/x86/samsung-laptop.c | 87
> drivers/platform/x86/toshiba_acpi.c | 16 -
> include/acpi/video.h | 9 +-
> 26 files changed, 468 insertions(+), 415 deletions(-)
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Mon, 2022-07-04 at 17:32 -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> Currently on flakey internet in the back of a car, so I probably won't be
> able
> to push this until I get back tonight or early tomorrow
Whoops! Slipped my mind when I got back, but I just
s.
Anyway, this patch looks good to me:
Reviewed-by: Lyude Paul
I will push it to the appropriate branch in a little bit
On Wed, 2022-07-20 at 16:27 +1000, Alistair Popple wrote:
> Users may request that pages from an OpenCL SVM allocation be migrated
> to the GPU with clEnqueueSVMMigrateM
nd/or that function
> should switch to use dma_alloc_noncoherent.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
e need all
noncoherent allocations without getting is_swiotlb_active() involved - which
should be easy. Does this seem like a workable solution, or is there something
I'm missing here?
On Thu, 2022-07-28 at 17:17 -0400, Lyude Paul wrote:
> Hi! Sorry about the slow reply to this, been busy wit
le of
coherent allocations using is_swiotlb_active().
So, let's do this by replacing is_swiotlb_active() with our own
nouveau_drm_use_coherent_gpu_mapping() helper.
Signed-off-by: Lyude Paul
Cc: Christoph Hellwig
---
Hey! This is the patch that I came up with, but as the folks involved
with this
ed at this point though,
so I should have a chance to respin this in the next few business days.
On Tue, 2022-06-07 at 15:29 -0400, Lyude Paul wrote:
> Ugh, thanks ./scripts/get_maintainers.pl for confusing and breaking
> git-send email <<. Sorry for the resend everyone.
>
>
l to
apply, you can just ignore and skip them.
----
Lyude Paul (14):
drm/dp_mst: Destroy MSTBs asynchronously
drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor
drm/dp_mst: Refactor pdt setup/teardown, add
On Wed, 2019-10-30 at 10:21 +0100, Daniel Vetter wrote:
> On Tue, Oct 29, 2019 at 11:06 PM Lyude Paul wrote:
> > topic/mst-suspend-resume-reprobe-2019-10-29-2:
> > UAPI Changes:
> >
> > Cross-subsystem Changes:
> >
> > Core Changes:
> > * Handle UP
Reviewed-by: Lyude Paul
On Tue, 2019-10-29 at 12:10 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The current link status contains bytes 0x202 through 0x207, but we also
> want to make sure to include the DP_ADJUST_REQUEST_POST_CURSOR2 (0x20c)
> so that the post-cursor
Whoops, replied to the wrong one
Reviewed-by: Lyude Paul
On Tue, 2019-10-29 at 15:03 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The current link status contains bytes 0x202 through 0x207, but we also
> want to make sure to include the DP_ADJUST_REQUEST_POST_CURSOR2
.
The current plan is to extend VESA membership to X.Org members who
specifically request it. If you think you'd be at all interested in this, or
know any projects or contributors who would be, please feel free to respond to
this message and let me know!
arate function for this
>
> Reviewed-by: Manasi Navare
> Reviewed-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Signed-off-by: David Francis
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c| 16 +
text
> *res_ctx,
>
>
> #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> -static enum dc_status add_dsc_to_stream_resource(struct dc *dc,
> +enum dc_status dcn20_add_dsc_to_stream_resource(struct dc *dc,
> struct dc_state *dc_ctx,
> struct dc_stream_state *dc_stream)
> {
> @@ -1510,6 +1510,9 @@ static enum dc_status
> add_dsc_to_stream_resource(struct dc *dc,
> if (pipe_ctx->stream != dc_stream)
> continue;
>
> + if (pipe_ctx->stream_res.dsc)
> + continue;
> +
> acquire_dsc(&dc_ctx->res_ctx, pool, &pipe_ctx-
> >stream_res.dsc);
>
> /* The number of DSCs can be less than the number of pipes */
> @@ -1561,7 +1564,7 @@ enum dc_status dcn20_add_stream_to_ctx(struct dc *dc,
> struct dc_state *new_ctx,
> #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> /* Get a DSC if required and available */
> if (result == DC_OK && dc_stream->timing.flags.DSC)
> - result = add_dsc_to_stream_resource(dc, new_ctx, dc_stream);
> + result = dcn20_add_dsc_to_stream_resource(dc, new_ctx,
> dc_stream);
> #endif
>
> if (result == DC_OK)
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.h
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.h
> index fef473d68a4a..865f684a500a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.h
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.h
> @@ -159,6 +159,7 @@ void dcn20_calculate_dlg_params(
>
> enum dc_status dcn20_build_mapped_resource(const struct dc *dc, struct
> dc_state *context, struct dc_stream_state *stream);
> enum dc_status dcn20_add_stream_to_ctx(struct dc *dc, struct dc_state
> *new_ctx, struct dc_stream_state *dc_stream);
> +enum dc_status dcn20_add_dsc_to_stream_resource(struct dc *dc, struct
> dc_state *dc_ctx, struct dc_stream_state *dc_stream);
> enum dc_status dcn20_remove_stream_from_ctx(struct dc *dc, struct dc_state
> *new_ctx, struct dc_stream_state *dc_stream);
> enum dc_status dcn20_get_default_swizzle_mode(struct dc_plane_state
> *plane_state);
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
to iterate through all the ports in the topology and set
> mode_changed flag on crtc if DSC has been enabled.
>
> Cc: Harry Wentland
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 103 +-
> incl
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
> drivers/gpu/drm/nouveau/dispnv04/arb.c:59:21: warning: variable pclks set
&g
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
> drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable
for dynamically selecting the bpc based on the topology's
available bandwidth, since userspace isn't really using HDR yet anyway.
This matches the behavior that i915 has, along with the behavior of
amdgpu and should fix some people's displays not turning on.
Lyude Paul (3):
drm/nouve
Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
probably should be calling it before handling any PBN changes. Just a
precaution.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vett
omic check. But for now,
follow the behavior that both i915 and amdgpu are sticking to.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
check phase and commit phase. This will let us (eventually)
implement the max bpc connector property, and will also be needed for
limiting the bpc we use on MST displays to 8 in the next commit.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST"
} else {
> + drm_dp_mst_topology_put_port(port_va
> lidated);
> + }
> + }
> + }
> + }
> +
> if (port->connector)
> drm_modeset_unlock(&mgr->base.lock);
> else if (create_connector)
> --
> 2.17.1
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Reviewed-by: Manasi Navare
> Reviewed-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Signed-off-by: David Francis
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c
te connector's VCPI slots.
>
> v2: - use drm_dp_mst_atomic_enable_dsc per port to
> enable/disable DSC
>
> v3: - Iterate through connector states from the state passed
> - On each connector state get stream from dc_state,
> instead CRTC state
>
> Reviewed-by: Lyude Paul
> Signed-o
Acked-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> From: David Francis
>
> If there is limited link bandwidth on a MST network,
> it must be divided fairly between the streams on that network
>
> Implement an algorithm to determine the
Acked-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Need to calculate VCPI slots differently for DSC
> to take in account current link rate, link count
> and FEC.
> [how]
> Add helper to get pbn_div fro
Reviewed-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> For DSC case we cannot use topology manager's PBN divider
> variable. The default divider does not take FEC into account.
> Therefore the driver h
+ mutex_lock(&mgr->payload_lock);
> + vcpi->num_slots = 0;
> + mutex_unlock(&mgr->payload_lock);
> + } else {
> +
Back from the holidays!
Reviewed-by: Lyude Paul
Do you need me to push this to drm-misc?
On Thu, 2019-12-26 at 10:31 +0800, Wayne Lin wrote:
> [Why]
> Found kernel NULL pointer dereference under the below situation:
>
> src — HDMI_Monitor src — HDMI_M
Reviewed-by: Lyude Paul
Thanks for all of the contributions you've made as of late! I will go ahead
and push this into drm-misc-fixes
On Fri, 2020-01-03 at 13:50 +0800, Wayne Lin wrote:
> [Why]
> According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> in REMOTE_I2
buf[idx] = (req-
> >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> buf[idx] |= (req-
> >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> idx++;
> }
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Got shown this patch at work and realized it still needed review, so I went
ahead and did that :)
Reviewed-by: Lyude Paul
On Mon, 2019-07-22 at 16:38 +0200, Takashi Iwai wrote:
> This patch adds the support for the notification of HD-audio hotplug
> via the already existing drm_audio_com
On Wed, 2019-12-25 at 06:45 +, Lin, Wayne wrote:
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, December 21, 2019 8:12 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > amd-...@lists.freedesktop.org
> > Cc: Kazlauskas,
Reviewed-by: Lyude Paul
On Mon, 2019-10-07 at 19:12 +0200, Sam Ravnborg wrote:
> drmP.h is deprecated and will be deleted.
> Replace use with proper header.
>
> Divide header includes in blocks while touching these.
>
> Build tested with various archtectures and configs.
Reviewed-by: Lyude Paul
On Mon, 2019-10-07 at 19:12 +0200, Sam Ravnborg wrote:
> There is finally no more users left in the kernel of drmP.h
> and drm_os_linux.h (drmP.h was the only user left).
> Delete the header files and delete the corresponding todo entry.
>
> When we sta
Zuo
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 ++
> .../amd/display/am
gic as in
> dm_encoder_helper_atomic_chek, but since we do not know which
> connectors will have DSC enabled we have to recalculate PBN only
> after that's determined, which is done in
> compute_mst_dsc_configs_for_state.
>
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Lyud
understand why this is a future enhancement? Everything
we need to implement these helpers should already be here, it's just a matter
of keeping track who has dsc enabled where in the mst atomic state
On Mon, 2019-10-07 at 17:52 -0400, Lyude Paul wrote:
> Ok, let's stop and slow down
On Tue, 2019-10-08 at 12:24 -0400, Lyude Paul wrote:
> ...
> yikes
> I need to apologize because I was going through my email and I realized you
> _did_ respond to me earlier regarding some of these questions, it just
> appears
> the reply fell through the cracks and somehow
| 8 +-
> > drivers/gpu/drm/tegra/sor.c| 32 +--
> > include/drm/drm_dp_helper.h | 124 +-
> > 8 files changed, 459 insertions(+), 87 deletions(-)
> >
> > --
> > 2.22.0
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 2019-09-27 at 09:52 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote:
> > Finally! For a very long time, our MST helpers have had one very
> > annoying issue: They don't know how to reprobe the topology state when
> > coming
Hey! Re: our discussion about this at XDC, I think I'm going to drop this
patch and just fix KASAN so it prints the hashed pointer as well, I'll cc you
on the patches for that as well
On Fri, 2019-09-27 at 10:25 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyu
oh, completely forgot about this one
Reviewed-by: Lyude Paul
On Thu, 2019-10-10 at 00:41 +0200, Daniel Vetter wrote:
> Private atomic objects have grown their own locking with
>
> commit b962a12050a387e4bbf3a48745afe1d29d396b0d
> Author: Rob Clark
> Date: Mon Oct 22 14:3
On Tue, 2019-10-08 at 21:26 +, Mikita Lipski wrote:
>
> On 08.10.2019 12:24, Lyude Paul wrote:
> > ...
> > yikes
> > I need to apologize because I was going through my email and I realized
> > you
> > _did_ respond to me earlier regarding some of these qu
2019 at 11:27:41AM -0400, Sean Paul wrote:
> > On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> > > This commit is seperate from the previous one to make it easier to
> > > revert in the future. Basically, there's multiple userspace applications
> >
a few
different projects to figure out who all would be interested in such training.
If there's any takers, or anyone has any questions, feel free to respond and
let us know!
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freed
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Keeping the list sorted alphabetically makes it much easier to determine
> where to add new includes.
>
> Signed-off-by: Thierry Reding
> ---
> include
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> It's idiomatic to check the return value of a function call immediately
> after the function call, without any blank lines in between, to make it
> more obvious that
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper that checks for the fast training capability given the DPCD
> receiver capabilities blob.
>
> Signed-off-by: Thierry Reding
> ---
> include
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper to check whether the sink supports ANSI 8B/10B channel
> coding capability as specified in ANSI X3.230-1994, clause 11.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper to check if the sink supports the eDP alternate scrambler
> reset value of 0xfffe.
>
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_h
orth clamping the value to 4 here?
> +
> + if (rd_interval > 0 && dpcd[DP_DPCD_REV] < DP_DPCD_REV_14)
Also small nit pick: you can just use rd_interval instead of rd_interval > 0
> + rd_interval *= 4 * USEC_PER_MSEC;
> + else
> + rd_interval = 100;
&
max 4)\n",
> rd_interval);
>
> if (rd_interval == 0)
> - udelay(400);
> + rd_interval = 400;
> else
> - mdelay(rd_interval * 4);
> + rd_interval *= 4 * USEC_PER_MSEC;
> +
> + us
unsigned int min = drm_dp_aux_rd_interval(dpcd);
>
> - if (rd_interval == 0)
> - rd_interval = 400;
> - else
> - rd_interval *= 4 * USEC_PER_MSEC;
> -
> - usleep_range(rd_interval, rd_interval * 2);
> + usleep_range(min, min *
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:35 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> If the transmitter supports pre-emphasis post cursor2 the sink will
> request adjustments in a similar way to how it requests adjustments to
> the voltage swing and pre-em
elayed_destroy_work() - danvet
* Better explain why we need to do this - danvet
* Use cancel_work_sync() instead of flush_work() - flush_work() doesn't
account for work requeing
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
hile the
device housing said connector is in runtime suspend.
As well, the debugging tools that are added in this include:
* A limited debugging utility for dumping the list of topology
references on an MST port or branch connector whose topology reference
count has reached 0
Lyude Paul (14
send sideband messages from
most contexts without having to deal with getting blocked if we hold
connection_mutex. This also fixes MST branch device hotplugging on i915,
finally!
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewe
_dp_mst_link_probe_work() and drm_dp_mst_up_req_work(). Additionally,
add some more detailed explanations for how this locking is intended to
work to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports.
Signed-off-by: Lyude Paul
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry We
eviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 40 +++
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 66ff226d8c86..204d0c832c65 100
rdown_pdt() into a single function:
drm_dp_port_set_pdt(). This function also handles actually ensuring that
we grab the correct locks when we need to modify port->mstb.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Sea
detailed explanation of what problems this is
trying to fix, since there's a _lot_ of context here and I honestly
forgot some of it myself a couple times.
* Don't grab mgr->lock when reading port->mstb in
drm_dp_mst_handle_link_address_port(). It's not needed.
ke sure we read the input_port field in connection status
notifications in drm_dp_mst_handle_conn_stat() to prevent this from
happening once we've implemented suspend/resume reprobing.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by:
ng with runtime suspend/resume.
Now that those requests are handled asynchronously, this change should
be completely safe.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouv
Does what it says on the tin.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions
lizing the display.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/d
Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Alex Deucher
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 ++-
drivers/gpu/drm/amd/a
Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm
he memory might have been
freed by that point
* Don't print message on allocation error failures, the kernel already
does this for us
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/d
to change port->connector at all on ports, just throw out
ports that need their connectors removed to make things easier.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/displ
that we know need this. As you might have already
guessed, OUI quirks didn't seem to be a very safe bet for these panels
due to them not having their device IDs filled out.
Lyude Paul (3):
drm/dp: Introduce EDID-based quirks
drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen
UI-based quirks, so
that callers can simply check all possible quirks using
drm_dp_has_quirk().
Signed-off-by: Lyude Paul
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 61 +++
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
.../drm/i915/display/intel_
ure we can remove these quirks once we have a better way of
probing for this.
Changes since v1:
* Add one more EDID per Dell's request
* Remove model number (which is possibly wrong) and replace with Dell
CML 2020 systems
Signed-off-by: Lyude Paul
Cc: Jani Nikula
---
drivers/gpu/drm/drm_d
ppear to fill in the device ID).
Hopefully in the future we'll figure out a better way of probing this.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 4 +++
.../drm/i915/display/intel_dp_aux_backlight.c | 25 +
alid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-of
ne
to hang.
So, let's teach nouveau to reject interlaced modes on hardware that
can't actually handle it. Additionally for MST, since we accomplish this
by simply reusing more of the SST mode validation we also get (some)
basic bw validation for modes we detect on MST connectors completely
display HW.
This fixes some hangs with Turing, which would be caused by attempting
to set an interlaced mode on hardware that doesn't support it. This
patch likely fixes other hardware hanging in the same way as well.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/n
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off
meh). But, we'll need this in a moment so
that we can share mode validation between SST and MST which will fix
some real world issues.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 ++---
1 file changed, 14 insertions(+
sible, and has a XLUT handle programmed.
Signed-off-by: Lyude Paul
Fixes: facaed62b4cb ("drm/nouveau/kms/gv100: initial support")
Cc: # v4.18+
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/
annel from within
nouveau_display_create(). Everywhere else, we initialize the core
channel during resume.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drive
ne
to hang.
So, let's teach nouveau to reject interlaced modes on hardware that
can't actually handle it. Additionally for MST, since we accomplish this
by simply reusing more of the SST mode validation we also get (some)
basic bw validation for modes we detect on MST connectors completely
alid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude P
isplay.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/core.h | 3 +++
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15
drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/
meh). But, we'll need this in a moment so
that we can share mode validation between SST and MST which will fix
some real world issues.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off
chunks and reassembling them
into a full sideband message. I know at least I constantly find myself
forgetting those functions are for rx and not tx.
So, I will give my r-b for the whole series, but...
Reviewed-by: Lyude Paul
...I think we should definitely look more into what Wayne's talk
> https://fedorapeople.org/~jwrdegoede/drm-debug.log
>
> This message stands out as pointing to the likely cause of this problem:
>
> [ 3.309061] [drm:intel_dump_pipe_config [i915]] MST master transcoder:
>
>
> Regards,
>
> Hans
>
--
Cheers,
Lyude Pau
ttps%3A%2F%2Fsupport.lenovo.com%2Fnl%2Fen%2Fsolutions%2Fpd029622&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=64uP50QojK2HkemDq3EGNKCVEgVl1ZxucyI%2F%2Bkk2Ng0%3D&reserved=0
> > >
&
er an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Signed-off-by: Sean Paul
>
> Changes in v4:
> -Added to the set
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
> include/drm/drm_dp_helper.h | 3 +
> include/dr
used variable
> > ‘drm’ [-Wunused-variable]
> > struct nouveau_drm *drm = nouveau_drm(connector->dev);
> > ^~~
>
> As commented on 7/9, you should squash this with the patch that
> introduces the warnings.
Agreed, with the patches squashed you c
_URL out of i915_utils.c and
into i915_utils.h so that other places which print things that aren't
traditional errors but are worth filing bugs about, can actually use
it.
Signed-off-by: Lyude Paul
Reviewed-by: Adam Jackson
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c
eprobe the connector when
we're ready.
Signed-off-by: Lyude Paul
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic
check")
Cc: Mikita Lipski
Cc: Alex Deucher
Cc: Sean Paul
Cc: Hans de Goede
---
drivers/gpu/drm/drm_dp_mst_topology.c | 13
populated - as this is always a bug in the
MST helpers.
This should fix regressions seen on nouveau, i915 and amdgpu where we
erroneously reject atomic states that should fit within bandwidth
limitations.
Signed-off-by: Lyude Paul
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth valida
ned-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 61e7beada832..207eef08d12c 100644
--- a/drivers/gpu/drm/drm_dp_mst_
901 - 1000 of 2396 matches
Mail list logo
