The actual name is R133NW4K-R0.
Fixes: 0f9fa5f58c784 ("drm/panel-edp: add IVO M133NW4J-R3 panel entry")
Signed-off-by: Abel Vesa
---
Assuming the information from here is correct:
https://raw.githubusercontent.com/linuxhw/EDID/master/DigitalDisplay.md
drivers/gpu/drm/panel/panel
Add an eDP panel entry for IVO M133NW4J.
Due to lack of documentation, use the delay_200_500_p2e100 timings like
some other IVO entries for now.
Signed-off-by: Abel Vesa
---
Assuming the information from here is correct:
https://raw.githubusercontent.com/linuxhw/EDID/master/DigitalDisplay.md
On 23-01-02 09:21:40, Johan Hovold wrote:
> On Sun, Jan 01, 2023 at 10:58:42PM -0600, Steev Klimaszewski wrote:
> > On Sat, Dec 31, 2022 at 8:27 AM Abel Vesa wrote:
> > >
> > > The actual name is R133NW4K-R0.
> > >
> > > Fixes: 0f9fa5f58c784 (&q
Add an eDP panel entry for BOE NE140WUM-N6G.
Due to lack of documentation, use the delay_200_500_e80 timings like
some other BOE entries for now.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
Signed-off-by: Abel Vesa
---
Changes in v2:
- Added raw EDID to commit message, as per Doug's reguest
- Picked up Doug's R-b tag
- Link to v1:
https://lore.kernel.org/r/20240823-drm-panel-edp-add-boe-ne140wum-n6g-v1-1-7bdd3c003...@linaro.org
---
drivers/gpu/drm/panel/panel-edp.c | 1
org/r/20240221-x1e80100-display-refactor-connector-v1-0-86c0e1ebd...@linaro.org
---
Abel Vesa (2):
drm/msm/dp: Add support for determining the eDP/DP mode from DT
drm/msm/dp: Add support for the X1E80100
drivers/gpu/drm/msm/dp/dp_display.c | 52 ++---
1 fil
Instead of relying on different compatibles for eDP and DP, lookup
the panel node in devicetree to figure out the connector type and
then pass on that information to the PHY. External DP is not described
in DT, therefore, assume it's eDP if panel node is present.
Signed-off-by: Abel
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set based on the presence of the panel node in DT.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9
On 24-03-22 15:30:54, Dmitry Baryshkov wrote:
> On Fri, 22 Mar 2024 at 15:22, Abel Vesa wrote:
> >
> > Instead of relying on different compatibles for eDP and DP, lookup
> > the panel node in devicetree to figure out the connector type and
> > then pass on that informat
On 24-03-22 15:38:03, Dmitry Baryshkov wrote:
> On Fri, 22 Mar 2024 at 15:36, Abel Vesa wrote:
> >
> > On 24-03-22 15:30:54, Dmitry Baryshkov wrote:
> > > On Fri, 22 Mar 2024 at 15:22, Abel Vesa wrote:
> > > >
> > > > Instead of relying on differen
On 24-03-22 09:30:21, Bjorn Andersson wrote:
> On Fri, Mar 22, 2024 at 03:22:22PM +0200, Abel Vesa wrote:
> > Instead of relying on different compatibles for eDP and DP, lookup
> > the panel node in devicetree to figure out the connector type and
> > then pass on that i
This patchset cannot be applied without the one mentioned above because
it relies on PHY_SUBMODE_EDP and PHY_SUBMODE_DP.
Signed-off-by: Abel Vesa
---
Changes in v4:
- Reworked the dp_display_get_connector_type to be more readable, like
Bjorn suggested.
- Dropped the unrelated change w.r.t. dp_au
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set based on the presence of the panel node in DT.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9
Instead of relying on different compatibles for eDP and DP, lookup
the panel node in devicetree to figure out the connector type and
then pass on that information to the PHY. External DP doesn't have
a panel described in DT, therefore, assume it's eDP if panel node
is present.
Signed-of
On 24-02-18 15:06:45, Dmitry Baryshkov wrote:
> On Sat, 17 Feb 2024 at 13:39, Abel Vesa wrote:
> >
> > On 24-02-16 12:32:02, Rob Herring wrote:
> > >
> > > On Fri, 16 Feb 2024 19:01:06 +0200, Abel Vesa wrote:
> > > > Document the MDSS har
r reg_bus_bw
- Switched to SDMA features mask
- Added Krzysztof's R-b tag to mdss schema patch
- Added Dmitry's R-b tag to the dpu patch
- Link to v1:
https://lore.kernel.org/r/20240129-x1e80100-display-v1-0-0d9eb8254...@linaro.org
---
Abel Vesa (4):
dt-bindings: display/msm: Docum
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 251 +
1 file changed, 251 insertions(+)
diff --git
a/Documentation/devicetree/bindings
Add support for MDSS on X1E80100.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 65657230bbff..fab6ad4e5107 100644
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu
set_mode to let the PHY know which mode it should configure itself.
The PHY counterpart patchset is here:
https://lore.kernel.org/all/20240220-x1e80100-phy-edp-compatible-refactor-v5-0-e8658adf5...@linaro.org/
Signed-off-by: Abel Vesa
---
Abel Vesa (3):
dt-bindings: display: msm: dp-contr
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 1
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set in devicetree via is-edp flag.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9 insertions(+)
diff
Add the X1E80100 to the list of compatibles and docoment the is-edp
flag. This new flag will be used from now on to dictate the mode from
devicetree, instead of having separate compatibles for eDP and DP.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/dp
set_mode to let the PHY know which mode it should configure itself.
The PHY counterpart patchset is here:
https://lore.kernel.org/all/20240220-x1e80100-phy-edp-compatible-refactor-v5-0-e8658adf5...@linaro.org/
Signed-off-by: Abel Vesa
---
Changes in v2:
- Added Dmitry's R-b tag to both driv
Add the X1E80100 to the list of compatibles and document the is-edp
flag. The controllers are expected to operate in DP mode by default,
and this flag can be used to select eDP mode.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++
1 file
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
drivers
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set in devicetree via is-edp flag.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file
On 24-02-27 16:45:25, Krzysztof Kozlowski wrote:
> On 22/02/2024 16:55, Abel Vesa wrote:
> > Add the X1E80100 to the list of compatibles and document the is-edp
> > flag. The controllers are expected to operate in DP mode by default,
> > and this flag can be us
f-by: Abel Vesa
---
Abel Vesa (4):
dt-bindings: display/msm: document MDSS on X1E80100
dt-bindings: display/msm: Document the DPU for X1E80100
drm/msm: mdss: Add X1E80100 support
drm/msm/dpu: Add X1E80100 support
Abhinav Kumar (1):
drm/msm/dp: Try looking for link-f
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 249 +
1 file changed, 249 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 455b2e3a0cdd..eddf7fdbb60a 100644
--- a/drivers/gpu/drm/msm
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu/drm/msm/disp/dpu1
From: Abhinav Kumar
On platforms where the endpoint used is on port@0, looking for port@1
instead results in just ignoring the max link-frequencies altogether.
Look at port@0 first, then, if not found, look for port@1.
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
drivers/gpu/drm
On 24-01-29 17:08:29, Dmitry Baryshkov wrote:
> On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
> >
> > From: Abhinav Kumar
> >
> > On platforms where the endpoint used is on port@0, looking for port@1
> > instead results in just ignoring the max link-frequenci
On 24-01-29 17:11:25, Dmitry Baryshkov wrote:
> On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
> >
> > Add support for MDSS on X1E80100.
> >
> > Signed-off-by: Abel Vesa
> > ---
> > drivers/gpu/drm/msm/msm_mdss.c | 10 ++
> > 1 file changed,
On 24-02-08 15:42:04, Dmitry Baryshkov wrote:
> On Thu, 8 Feb 2024 at 15:37, Abel Vesa wrote:
> >
> > On 24-01-29 17:11:25, Dmitry Baryshkov wrote:
> > > On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
> > > >
> > > > Add support for MDSS on X1
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 +
1 file changed, 252 insertions(+)
diff --git
a/Documentation/devicetree/bindings
DMA features mask
- Added Krzysztof's R-b tag to mdss schema patch
- Added Dmitry's R-b tag to the dpu patch
- Link to v1:
https://lore.kernel.org/r/20240129-x1e80100-display-v1-0-0d9eb8254...@linaro.org
---
Abel Vesa (4):
dt-bindings: display/msm: document MDSS on X1E80100
dt-
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
--- a/drivers/gpu/drm/msm
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 +
1 file changed, 253 insertions(+)
diff --git
a/Documentation/devicetree/bindings
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings
Add support for MDSS on X1E80100.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu
- Switched to SDMA features mask
- Added Krzysztof's R-b tag to mdss schema patch
- Added Dmitry's R-b tag to the dpu patch
- Link to v1:
https://lore.kernel.org/r/20240129-x1e80100-display-v1-0-0d9eb8254...@linaro.org
---
Abel Vesa (4):
dt-bindings: display/msm: Document the DPU for X1E8010
On 24-02-16 12:32:02, Rob Herring wrote:
>
> On Fri, 16 Feb 2024 19:01:06 +0200, Abel Vesa wrote:
> > Document the MDSS hardware found on the Qualcomm X1E80100 platform.
> >
> > Reviewed-by: Krzysztof Kozlowski
> > Signed-off-by: Abel Vesa
> > ---
> &g
Add support for the SDC ATNA45AF01 panel.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 825fa2a0d8a5..467a42eddbe9 100644
--- a/drivers/gpu/drm/panel
Add support for the SDC ATNA45AF01 panel.
Signed-off-by: Abel Vesa
---
Changes in v2:
- moved the panel entry in the proper place, as suggested by Doug
- Link to v1:
https://lore.kernel.org/r/20231201-x1e80100-drm-panel-edp-v1-1-ef9def711...@linaro.org
---
drivers/gpu/drm/panel/panel-edp.c | 2
onnect to DP controller #1.
> Also add interface #6, #7 and #8 connections to DP controller to
> complete x1e80100 interface table.
>
> Signed-off-by: Kuogee Hsieh
> ---
Nitpick: Probably mention the x1e80100 in the subject line somehow.
Reviewed-by: Abel Vesa
> .../drm/msm/disp/d
On 24-04-05 20:14:11, Bjorn Andersson wrote:
> Now that the connector_type is dynamically determined, the
> connector_type of the struct msm_dp_desc is unused. Clean it up.
>
> Remaining duplicate entries are squashed.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Abel V
w the LDB to reconfigure Video PLL as needed, as that
> results in accurate serializer clock.
>
> Signed-off-by: Marek Vasut
Any fixes tag needed ?
Otherwise, LGTM:
Reviewed-by: Abel Vesa
> ---
> Cc: Abel Vesa
> Cc: Andrzej Hajda
> Cc: David Airlie
> Cc: Fabio Estevam
>
() helper instead.
Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
drivers")
Cc: sta...@vger.kernel.org # 6.8
Cc: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
Changes in v2:
- Re-worded commit to be more explicit of what it fixes, as Johan sugges
patchset has been tested on.
Signed-off-by: Abel Vesa
---
Abel Vesa (4):
drm/dp: Add helper to set LTTPRs in transparent mode
drm/nouveau/dp: Use the generic helper to control LTTPR transparent mode
drm/i915/dp: Use the generic helper to control LTTPR transparent mode
drm/msm/dp
DPTX by issuing
an AUX write to the DPCD PHY_REPEATER_MODE register.
Add a generic helper that allows switching between these modes.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/display/drm_dp_helper.c | 17 +
include/drm/display/drm_dp_helper.h | 1 +
2 files changed, 18
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2
On 24-10-31 15:05:52, Johan Hovold wrote:
> On Mon, Oct 21, 2024 at 09:23:24AM +0200, Johan Hovold wrote:
> > On Fri, Oct 18, 2024 at 03:49:34PM +0300, Abel Vesa wrote:
> > > The assignment of the of_node to the aux bridge needs to mark the
> > > of_node as reused
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++--
1
ation mode to transparent mode
first and then to non-transparent, just like the mentioned section of
the specification mandates.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/m
On 24-10-31 17:33:35, Johan Hovold wrote:
> On Thu, Oct 31, 2024 at 06:13:45PM +0200, Abel Vesa wrote:
> > On 24-10-31 15:05:52, Johan Hovold wrote:
> > > On Mon, Oct 21, 2024 at 09:23:24AM +0200, Johan Hovold wrote:
> > > > On Fri, Oct 18, 2024 at 03:
There are some cases where sharing the of_node renders different resources
providers confused about the same resource being shared by two different
devices. Avoid that by marking the of_node as reused since the aux bridge
device is reusing the parent of_node.
Signed-off-by: Abel Vesa
On 25-01-03 20:09:42, Dmitry Baryshkov wrote:
> On Fri, Jan 03, 2025 at 02:58:17PM +0200, Abel Vesa wrote:
> > LTTPRs operating modes are defined by the DisplayPort standard and the
> > generic framework now provides a helper to switch between them, which
> > is handling the
ype-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
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c
On 24-12-11 21:22:00, Dmitry Baryshkov wrote:
> On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
> > According to the DisplayPort standard, LTTPRs have two operating
> > modes:
> > - non-transparent - it replies to DPCD LTTPR field specific AUX
> >request
On 24-12-11 15:42:27, Johan Hovold wrote:
> On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
>
> > +/**
> > + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
> > + * @aux: DisplayPort AUX channel
> > + * @enable: Enab
On 24-12-11 15:56:53, Johan Hovold wrote:
> On Wed, Dec 11, 2024 at 03:04:15PM +0200, Abel Vesa wrote:
>
> > +static void msm_dp_display_lttpr_init(struct msm_dp_display_private *dp)
> > +{
> > + int lttpr_count;
> > +
> > + if (drm_dp_read_lttpr_
patchset has been tested on.
Signed-off-by: Abel Vesa
---
Changes in v5:
- Added kernel-doc () suffix and semicolon after "Return" for
drm_dp_lttpr_set_transparent_mode, and dropped the extra blank
line from kernel-doc of drm_dp_lttpr_init, like Bjorn suggested
- Picked up Abhinav's R
ard v2.0 section 3.6.6.1. Do this in order
to move this handling out of the vendor specific driver implementation
into the generic framework.
Tested-by: Johan Hovold
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Johan Hovold
Reviewed-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
drivers/gpu/
the new drm generic helper instead as it makes the code a bit
cleaner.
Reviewed-by: Lyude Paul
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/
ype-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
eak
Signed-off-by: Abel Vesa
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 24 +-
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
in
patchset has been tested on.
Signed-off-by: Abel Vesa
---
Changes in v2:
- Added new wrapper over the set_transparent new helper in order to
move the non-transparent disable and the its enable->disable sequence
mentioned in the DP standard section 3.6.6.1 entirely in the generic
implemetat
the new drm generic helper instead as it makes the code a bit
cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_d
the new drm generic helper instead as it makes the code a bit
cleaner.
Signed-off-by: Abel Vesa
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 24 +-
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
ype-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.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 17 +
1 file change
ard v2.0 section 3.6.6.1. Do this in order
to move this handling out of the vendor specific driver implementation
into the generic framework.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/display/drm_dp_helper.c | 50 +
include/drm/display/drm_dp_helper.h | 2 ++
On 24-10-31 18:54:25, Dmitry Baryshkov wrote:
> On Thu, Oct 31, 2024 at 05:12:48PM +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 adjus
On 24-10-31 18:44:55, Dmitry Baryshkov wrote:
> On Thu, Oct 31, 2024 at 05:12:46PM +0200, Abel Vesa wrote:
> > LTTPRs operating modes are defined by the DisplayPort standard and the
> > generic framework now provides a helper to switch between them.
> > So use the drm generic
On 24-12-11 11:55:54, Dmitry Baryshkov wrote:
> On Wed, Dec 11, 2024 at 11:08:16AM +0200, Abel Vesa wrote:
> > On 24-10-31 18:54:25, Dmitry Baryshkov wrote:
> > > On Thu, Oct 31, 2024 at 05:12:48PM +0200, Abel Vesa wrote:
> > > > Link Training Tunable PHY Rep
patchset has been tested on.
Signed-off-by: Abel Vesa
---
Changes in v4:
- Picked up Dmitry's and Johan's R-b tags for the drm generic and drm
msm patches.
- Moved the comment about the roll-back to transparent mode inside the
if statement and fixed the typos, like Johan suggested.
-
On 25-01-07 10:30:29, Johan Hovold wrote:
> On Fri, Jan 03, 2025 at 02:58:15PM +0200, Abel Vesa wrote:
> > According to the DisplayPort standard, LTTPRs have two operating
> > modes:
> > - non-transparent - it replies to DPCD LTTPR field specific AUX
> >request
the new drm generic helper instead as it makes the code a bit
cleaner.
Reviewed-by: Lyude Paul
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/
ype-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
eak
Signed-off-by: Abel Vesa
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 24 +-
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
in
On 25-01-08 15:11:50, Dmitry Baryshkov wrote:
> On Mon, Jan 06, 2025 at 02:45:48PM +0200, Abel Vesa wrote:
> > On 25-01-03 20:09:42, Dmitry Baryshkov wrote:
> > > On Fri, Jan 03, 2025 at 02:58:17PM +0200, Abel Vesa wrote:
> > > > LTTPRs operating modes are defined b
ard v2.0 section 3.6.6.1. Do this in order
to move this handling out of the vendor specific driver implementation
into the generic framework.
Tested-by: Johan Hovold
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Johan Hovold
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/display/drm_dp_helper.c |
the new drm generic helper instead as it makes the code a bit
cleaner.
Reviewed-by: Lyude Paul
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/
patchset has been tested on.
Signed-off-by: Abel Vesa
---
Changes in v3:
- Picked-up T-b tag from Johan for the drm/dp transparent mode set helper
patch
- Re-worked the return value of the drm/dp transparet mode set helper
- Added some more details about what the values of the lttpr_count arg
is
the new drm generic helper instead as it makes the code a bit
cleaner.
Acked-by: Imre Deak
Signed-off-by: Abel Vesa
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 24 +-
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/disp
ard v2.0 section 3.6.6.1. Do this in order
to move this handling out of the vendor specific driver implementation
into the generic framework.
Tested-by: Johan Hovold
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/display/drm_dp_helper.c | 61 +
include/drm/disp
On 25-01-08 16:17:47, Bjorn Andersson wrote:
> On Wed, Jan 08, 2025 at 04:31:43PM +0200, Abel Vesa wrote:
> > According to the DisplayPort standard, LTTPRs have two operating
> > modes:
> > - non-transparent - it replies to DPCD LTTPR field specific AUX
> >request
On 25-01-08 14:57:41, Abhinav Kumar wrote:
>
>
> On 1/8/2025 6:31 AM, 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 the
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
On 25-03-25 19:21:27, Christopher Obbard wrote:
> The eDP panel has an HPD GPIO. Describe it in the devicetree.
>
> Unfortunately I cannot test this on the non-OLED model since I
> only have access to the model with OLED (which also uses the
> HPD GPIO).
>
> I believe this could be split into two
On 25-03-25 19:21:29, Christopher Obbard wrote:
> Some eDP devices report DP_EDP_PWMGEN_BIT_COUNT as 0, but still provide
> valid non-zero MIN and MAX values. This patch reworks the logic to
> fallback to the max value in such cases, ensuring correct backlight PWM
> configuration even when the bit
On 25-04-17 04:10:34, Aleksandrs Vinarskis wrote:
> Per-segment link training requires knowing the number of LTTPRs
> (if any) present. Store the count during LTTPRs' initialization.
>
> Signed-off-by: Aleksandrs Vinarskis
Reviewed-by: Abel Vesa
On 25-04-17 04:10:33, Aleksandrs Vinarskis wrote:
> Take into account LTTPR capabilities when selecting maximum allowed
> link rate, number of data lines.
>
> Signed-off-by: Aleksandrs Vinarskis
Reviewed-by: Abel Vesa
On 25-04-28 14:47:04, Johan Hovold wrote:
> On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote:
> > On Mon, 28 Apr 2025 at 09:45, Johan Hovold wrote:
> > > On Thu, Apr 17, 2025 at 04:10:31AM +0200, Aleksandrs Vinarskis wrote:
> > > > Recently added Initial LTTPR support in msm/dp
1 - 100 of 113 matches
Mail list logo
