From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12895216616 for ; Thu, 9 Jan 2025 11:50:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736423417; cv=none; b=uBl4EKcylo310SjWi3UU3A6GYyMoIMnkWw5FGn1DLdt8VFmzc0ApIi9+XxeJn+VMjOxzGZ04h98bmhSpMyUSaB3PAwBNfSqj7SuhDAohDoUae01vCQ2sVBnFADfxoxlszuUGH+XmVoPcRuxiNKc1WAnFoau5AGu4mmfHnS1VBQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736423417; c=relaxed/simple; bh=SqJHQuRVYeDld3eBmmM5ReizrF5rLjMQIfKUayCgqA8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HYLrW8uWmRr0+9ahtkkDME8IY/VPKKH/tIQAlDF+cPIBLTZ2EbX86/OQfIsApHVuFq1MrYfMnfMifNJ3MBGFxQccRxYcE3oIi59p9w9aJladdaHZBvWM7h4hj+PIDEkbZ+WBSx3+qFqkufMXu5bmsrj4V08yIlUauqg0mHTBBjs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=gxlvJ8lC; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="gxlvJ8lC" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-436202dd7f6so10366285e9.0 for ; Thu, 09 Jan 2025 03:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736423413; x=1737028213; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SBUIkyq8HThi2u/QbO+9Ek4VXanc8mg0IJge15zLjYc=; b=gxlvJ8lCYVMVmz5BKe68D8M9ffYhu+AbyEbCLwxB/WHf3ZoyO4tavVq4B5lT9RjSKD A1rKm+hWn8TZAqtIyM6Ho5NGoiBKma/+kabgfFufnbARloitWhGq/dMgknpEY/qc869P THyCW9RC7dVA0m/Lazx1jpdbgnt88Jp4Pu5YqbVGw+TtIts5eDFQXPeYA7XbAHZ1+lXi TGThP3TXAJW8oE70ojK+N0gZ3wvyohMasx8uJTDf1rCeZYcwYYUMgsNpbpuiuJsbxoIa v4gBeCfZ/yvFfhxjYz5tSkD9XsTQX8YanLyrmo/KpnjT4F0Lq6AnGZvqIasEAE9cxWUs 3eng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736423413; x=1737028213; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SBUIkyq8HThi2u/QbO+9Ek4VXanc8mg0IJge15zLjYc=; b=ijLdB4M69/g8gsJ0JWTTlfP7QApU/B/Lx5vBhIMZeaOyX5OQvIMsu2BGx7l8wNMlPT DAY8peA9wmD+JVo/+HD0irziwPksnfoNBDgNv7iSrHHjLdggMZMoE4rHw4soRgd3ctDJ OLeOvWegxCf6eWyMN30PyLGbQd7Kg1m+6Szx2tmDCwJGIEDBrlxt5K/YSPnDCqEiq8dY uFzDFQ5/VwC5sjM2Bfj54hKCz2I/nSOQiLcEMEyCQxlCIniQYVEaKNm0fvicvwkImaa2 zTrJBcEXBwMA9R3TNrRj1Zy6FOPGqcFqRF5ALbIWdoe8EN/v3+d69RU7ZSH/1SGCyi0o 9Lsg== X-Forwarded-Encrypted: i=1; AJvYcCUy1+fO5hzeM+hroJC1geGkF2nAiDpRjGIj7hgnauti0L8bc+tL2uPSss/kzGM+eW+NdHEbObVZzFVuqDqg@vger.kernel.org X-Gm-Message-State: AOJu0YymegnYNPdkOFCmb3bNaVbiGYT4x5AF8C6u+SCO5jtXEv1OkMcE xUluCJfN6fKrKF0Bi+ccSnkooycnh/FrLUiPCFZVtiv0B7r95YC33UDGX4hpujY= X-Gm-Gg: ASbGncsagjjUBsqLXeBDEQPpXx5pZI5Dp9zguUTPUWR8+YAil7BeeiGtkMUpUUNAOcD Pn6HzduXw0Q6iP+OQxXOmSKaeO00krhfw0eWtKrz0yz8ZLXnMPnmZsb9TIEOUkjOnS49Qhyf0AJ DgDfj5HuuQQKkCFeUwRS86m2xSwuU229LUo/wWWWxQfnGfqxnlO/Yw3lRKo0/OpnO7D4uwwgeri /UeB+5ALxfnT/HP6B7xcmSXKoqXl0aUHvUNQEHUNa5x/a1/QOIJcNU= X-Google-Smtp-Source: AGHT+IE6bPuwfgpmvhR0wnVywkO+uV/zmxqYUYfEIWBePuS9J7kF881P4MIK7Z1l4XbIG4X4Nze9zA== X-Received: by 2002:a05:600c:3152:b0:434:f9e1:5cf8 with SMTP id 5b1f17b1804b1-436e271d3a2mr66267645e9.31.1736423413467; Thu, 09 Jan 2025 03:50:13 -0800 (PST) Received: from linaro.org ([86.121.162.10]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e3838a3sm1628874f8f.33.2025.01.09.03.50.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jan 2025 03:50:12 -0800 (PST) Date: Thu, 9 Jan 2025 13:50:10 +0200 From: Abel Vesa To: Bjorn Andersson Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Karol Herbst , Lyude Paul , Danilo Krummrich , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , Rob Clark , Abhinav Kumar , Dmitry Baryshkov , Sean Paul , Marijn Suijten , Konrad Dybcio , Johan Hovold , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, Johan Hovold Subject: Re: [PATCH v4 4/4] drm/msm/dp: Add support for LTTPR handling Message-ID: References: <20250108-drm-dp-msm-add-lttpr-transparent-mode-set-v4-0-918949bc2e3a@linaro.org> <20250108-drm-dp-msm-add-lttpr-transparent-mode-set-v4-4-918949bc2e3a@linaro.org> Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On 25-01-08 16:25:31, Bjorn Andersson wrote: > On Wed, Jan 08, 2025 at 04:31:46PM +0200, Abel Vesa wrote: > > Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort > > 1.4a specification. As the name suggests, these PHY repeaters are > > capable of adjusting their output for link training purposes. > > > > According to the DisplayPort standard, LTTPRs have two operating > > modes: > > - non-transparent - it replies to DPCD LTTPR field specific AUX > > requests, while passes through all other AUX requests > > - transparent - it passes through all AUX requests. > > > > Switching between this two modes is done by the DPTX by issuing > > an AUX write to the DPCD PHY_REPEATER_MODE register. > > > > The msm DP driver is currently lacking any handling of LTTPRs. > > This means that if at least one LTTPR is found between DPTX and DPRX, > > the link training would fail if that LTTPR was not already configured > > in transparent mode. > > > > The section 3.6.6.1 from the DisplayPort v2.0 specification mandates > > that before link training with the LTTPR is started, the DPTX may place > > the LTTPR in non-transparent mode by first switching to transparent mode > > and then to non-transparent mode. This operation seems to be needed only > > on first link training and doesn't need to be done again until device is > > unplugged. > > > > It has been observed on a few X Elite-based platforms which have > > such LTTPRs in their board design that the DPTX needs to follow the > > procedure described above in order for the link training to be successful. > > > > So add support for reading the LTTPR DPCD caps to figure out the number > > of such LTTPRs first. Then, for platforms (or Type-C dongles) that have > > at least one such an LTTPR, set its operation mode to transparent mode > > first and then to non-transparent, just like the mentioned section of > > the specification mandates. > > > > Tested-by: Johan Hovold > > Reviewed-by: Dmitry Baryshkov > > Reviewed-by: Johan Hovold > > Signed-off-by: Abel Vesa > > --- > > drivers/gpu/drm/msm/dp/dp_display.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c > > index 24dd37f1682bf5016bb0efbeb44489061deff060..ad09daa4c8ab5c0eb67890509b94e72820bab870 100644 > > --- a/drivers/gpu/drm/msm/dp/dp_display.c > > +++ b/drivers/gpu/drm/msm/dp/dp_display.c > > @@ -107,6 +107,8 @@ struct msm_dp_display_private { > > struct msm_dp_event event_list[DP_EVENT_Q_MAX]; > > spinlock_t event_lock; > > > > + u8 lttpr_caps[DP_LTTPR_COMMON_CAP_SIZE]; > > As far as I can see these 8 bytes are read and acted upon only within > msm_dp_display_lttpr_init() below. Any particular reason why you don't > just put them on the stack? Sure, I can do that. My rationale here was that this caps hold more than just LTTPRs count. Thinks like max lane count or max link rate are part of the LTTPR common caps. There are drm generic helpers for each one where you need to pass on these caps. Yes, at this point they are not used in the drm/msm, but looking at the i915 and nouveau, they seem to be useful at some point. This is why I followed the i915 to safekeep them in this container struct. Anyway, I'll drop them from here and put them on stack. > > Regards, > Bjorn Thanks for reviewing! Abel