From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 1B2BF1FF1BF for ; Thu, 9 Jan 2025 11:50:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736423417; cv=none; b=WoTPprnYDzn7qMIrOSR8Ot/9ZWimVH7TToopTlPKHjSNmXF4Ozakm4ihCfmHOjohBsiCA5MzP6x71XdR1P3LEppoovsvZSfg8oE+cZaVekklxeI24IpgOjk3xbbZzMAwxf3WmKOSo7AoALf87327N4yCHaL/CjdyYPgrkTpovO8= 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.45 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-f45.google.com with SMTP id 5b1f17b1804b1-4361f664af5so10219825e9.1 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=MfHQ6PpclvYJqG7a4YAQR1CesxowLIoaDX0tsJGtaciMM00ObSxs7Kw/LUZ+j7bmqi B4G3uMADmjBfjw++swUtdGPzhHPrg+q+KvFMvyD2fAI8nVn7Vvd5NpZh5as6l/150sTW 8KLJIr5TIXxSOfj2MMibKtf1JzaN+csSu0A37CN6TICvnUQWSnwaGXQmxNUaIE+kMbRI g5RUFP5g751/S2AWnZhsMTgZxSRBD3Y0yAmpWowxCUCkKhIZk1rgOkUbijaPkqAZA801 nbdCP0tCtXAAlEVyb62fF9WFu37rH7CwJ4tZeqQyz1jtuP4gWROlobhdSLQx6eYoKjPJ uHrw== X-Forwarded-Encrypted: i=1; AJvYcCUt5mvhciGHo1omi1osSOFMe9MuxyCenrIz93AsPoLE6VYkYlplIMxUHCM5nRbTocbzZR2hUt0C9r5H0Pk=@vger.kernel.org X-Gm-Message-State: AOJu0YwkarP24x1TtjsY4JEsy//uouvEs6bRZnDyh17qJST+h3XSx+WJ wgJiKq4Pt3fXOJQ42gU3UYQcW1MjLAxCYO6r128dXdVHeDULZEICA9lNCai7jyA= X-Gm-Gg: ASbGncsj+d+MW0IzwmpHRAQG4ic1FQIwzWWCtuCN/FS1/1rhxgBeuHMJrx/Yrgv+gFp voEv4L5N53sD/xsp1Jk0/nb6hgPnG08x+tSMVPzHfC6XkOkWmO3poITpH9SCAKV2SA7MbKG6F3E ut8wEwOi+K8WL6PyLDrFrdRnFhqB3UKBZ5CFiAPhpc9+2011SduUkngNjsxjcvum2XpZoSYl/w/ MWvogyNLVqkhp4a7gv92XIbSjPMY+064SRboM2pAjl2RQVZA9XLCgk= 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-kernel@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