e reset. Save the registers, then, before entering suspend
> and restore them in resume.
>
> Also, fix the suspend/resume routines and make sure we disable/enable
> the clock correctly.
>
> Signed-off-by: Laurentiu Palcu
Reviewed-by: Abel Vesa
On 25-07-16 11:15:05, Laurentiu Palcu wrote:
> Currently, besides probe(), the platform data is read in both suspend()
> and resume(). Let's avoid this by making pdata a member of imx95_blk_ctl
> structure.
>
> Signed-off-by: Laurentiu Palcu
Reviewed-by: Abel Vesa
elaxed'; ISO C99 and later do not support implicit function
> declarations [-Wimplicit-function-declaration]
>33 | return readl_relaxed(panel->link_base + offset);
>
> Fixes: 9d47325ee063 ("drm/msm/dp: drop the msm_dp_catalog module")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Abel Vesa
On 25-05-23 09:55:00, Abel Vesa wrote:
> On 25-04-30 15:00:51, Krzysztof Kozlowski wrote:
> > v12.0 DPU on SM8750 comes with 10-bit color alpha. Add register
> > differences and new implementations of setup_alpha_out(),
> > setup_border_color() and setup_blend_config().
On 25-04-30 15:00:51, Krzysztof Kozlowski wrote:
> v12.0 DPU on SM8750 comes with 10-bit color alpha. Add register
> differences and new implementations of setup_alpha_out(),
> setup_border_color() and setup_blend_config().
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Krzysztof Kozlowski
On 25-04-29 09:23:46, Johan Hovold wrote:
> On Mon, Apr 28, 2025 at 05:17:21PM +0300, Abel Vesa wrote:
> > 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, Joh
On 25-04-28 20:23:45, Aleksandrs Vinarskis wrote:
> On Mon, 28 Apr 2025 at 16:17, Abel Vesa wrote:
> >
> > The change itself makes sense though and I think makes sense to be marked
> > as a fix.
>
> Just to confirm, you mean to mark as fix only the 1st patch, correc
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
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-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-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-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
>
> This ensures successful link training both when connected directly to
> the monitor (single LTTPR onboard most X1E laptops) and via the docking
> station (at least two LTTPRs). This does not address/resolve underlying
> mainlink initialization issues.
>
> Signed
if (rc)
> - DRM_ERROR("failed to set LTTPRs transparency mode, rc=%d\n",
> rc);
> + lttpr_count = drm_dp_lttpr_count(dp->lttpr_common_caps);
> + rc = drm_dp_lttpr_init(dp->aux, lttpr_count);
> + if (rc) {
> + DRM_ERROR("fialed
On 25-02-27 16:51:15, Uwe Kleine-König wrote:
> Hello Abel,
>
> On Thu, Feb 27, 2025 at 03:07:21PM +0200, Abel Vesa wrote:
> > On 25-02-26 17:34:50, Uwe Kleine-König wrote:
> > > On Wed, Feb 26, 2025 at 05:31:08PM +0200, Abel Vesa wrote:
> > > > The current
On 25-02-26 17:34:50, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Feb 26, 2025 at 05:31:08PM +0200, Abel Vesa wrote:
> > The current implementation assumes that the PWM provider will be able to
> > meet the requested period, but that is not always the case. Some PWM
> >
the best match
period based on available configuration knobs. From there on, the
backlight will use the best matched period, since the driver's internal
PWM state is now synced up with the one from provider.
Signed-off-by: Abel Vesa
---
drivers/video/backlight/pwm_bl.c | 11 +++
1 f
On 24-12-19 23:36:56, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Log the version for informational purposes, such as for keeping track
> of possible GMU fw-related failures in crash / CI logs.
>
> Intentionally not implemented on the if (gmu->legacy) codepath, as
> these registers seem not t
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
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
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/
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/
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
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
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.
-
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 |
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
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
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
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/
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
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
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
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c
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
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
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
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_
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
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 ++
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
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
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
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
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
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-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 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:
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/i915/display/intel_dp_link_training.c | 2
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
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
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
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
() 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
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
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
>
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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 | 253 +
1 file changed, 253 insertions(+)
diff --git
a/Documentation/devicetree/bindings
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
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
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
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
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
1 - 100 of 113 matches
Mail list logo
