On 07/01/2022 06:42, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:27)
Currently DP driver will allocate panel bridge for eDP panels.
Simplify this code to just check if there is any next bridge in the
chain (be it a panel bridge or regular bridge). Rename panel_bridge
field to
On 07/01/2022 06:37, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:26)
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it
Quoting Dmitry Baryshkov (2022-01-06 18:01:27)
> Currently DP driver will allocate panel bridge for eDP panels.
> Simplify this code to just check if there is any next bridge in the
> chain (be it a panel bridge or regular bridge). Rename panel_bridge
> field to next_bridge accordingly.
>
> Signed-
Quoting Dmitry Baryshkov (2022-01-06 18:01:26)
> In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
> enable and disable") the DP driver received a drm_bridge instance, which
> is always attached to the encoder as a root bridge. However it conflicts
> with the panel_bridge sup
On 07/01/2022 05:16, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:25)
I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
display
enable and disable") conflicts with the panel-edp (panel bridge)
support. Both bridges will try to attach directly to the
Quoting Dmitry Baryshkov (2022-01-06 18:01:25)
> I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
> display
> enable and disable") conflicts with the panel-edp (panel bridge)
> support. Both bridges will try to attach directly to the drm encoder
> itself. I started writ
After changing dp_parser code to always check for the next bridge, it
does not check connector type anymore. Remove connector type from the
dp_paser_parse() arguments list and from the struct msm_dp_desc fields
list.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +++
Remove unused dp_display_en/disable prototypes. While we are at it,
remove extra 'data' argument that is unused.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_dis
Refactoring DP code transformed several functions into empty stubs.
Remove them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 35 -
1 file changed, 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp
dp_bridge's functions are thin wrappers around the msm_dp_display_*
family. Squash dp_bridge callbacks into respective msm_dp_display
functions, removing the latter functions from public space.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/d
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 +++---
drivers/gpu/drm/msm/dp/
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it conflicts
with the panel_bridge support for eDP panels. Change panel_bridge
attachment to
Currently DP driver will allocate panel bridge for eDP panels.
Simplify this code to just check if there is any next bridge in the
chain (be it a panel bridge or regular bridge). Rename panel_bridge
field to next_bridge accordingly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_d
I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
display
enable and disable") conflicts with the panel-edp (panel bridge)
support. Both bridges will try to attach directly to the drm encoder
itself. I started writing lengthy letter describing what is broken and
how it s
Quoting Dmitry Baryshkov (2022-01-05 15:10:31)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index bf4d72356a12..2301ac114920 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -78,6 +78,10
Quoting Dmitry Baryshkov (2022-01-05 15:10:30)
> Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
s/hanled/handled/
> is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
> (and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
> use dpu_h
Quoting Dmitry Baryshkov (2022-01-05 15:10:30)
> Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
> is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
> (and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
> use dpu_hw_intf directly.
>
>
Quoting Dmitry Baryshkov (2022-01-05 15:10:29)
> INTF blocks are not really handled by resource manager, they are
> assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
> Then this allocation is passed to RM and then returned to then
> dpu_encoder.
> So allocate them outside of RM an
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
Quoting Dmitry Baryshkov (2022-01-05 15:10:28)
> Add missing calls to dpu_hw_dspp_destroy() to free resources allocated
> for DSPP hardware blocks.
>
> Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
> dpu driver")
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by
Quoting Dmitry Baryshkov (2022-01-05 15:10:27)
> No code uses lm_max_width from resource manager, so drop it. Instead of
> calculating the lm_max_width, code can use max_mixer_width field from
> the hw catalog.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2022-01-05 23:06:56)
> The round_pixclk() callback returns different rate only on MDP4 in HDMI
> (DTV) case. Stop using this callback in other cases to simplify
> mode_valid callbacks.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Kuogee Hsieh (2022-01-06 12:44:54)
> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
> and expect DP source return correct checksum. During drm edid read,
> correct edid checksum is calculated and stored at
> connector::real_edid_checksum.
>
> The problem is struct dp_p
Quoting Kuogee Hsieh (2022-01-06 09:14:56)
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_2(struct
> dp_ctrl_private *ctrl,
>
> *training_step = DP_TRAINING_2;
>
> - if (drm_dp_tps3_supported(ctrl->panel->dpcd))
> + if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
> +
Quoting Kuogee Hsieh (2022-01-06 09:14:56)
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 39558a2..ba70387 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_
On Thu 06 Jan 10:14 PST 2022, Rob Clark wrote:
> From: Rob Clark
>
> System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
> the runpm reference counts. This doesn't actually work so well when the
> GPU is active. So add a reasonable delay waiting for the GPU to become
> idle
On Thu 06 Jan 12:44 PST 2022, Kuogee Hsieh wrote:
> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
> and expect DP source return correct checksum. During drm edid read,
> correct edid checksum is calculated and stored at
> connector::real_edid_checksum.
>
Interesting, thank
The struct is unused now so drop it along with the functions that use
it.
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 148 +---
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Acked-by: Mark Brown
Cc: Jaroslav Kysela
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
There aren't any users anymore so drop it.
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/drm_of.c | 85 +---
inclu
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Kai Vehmanen
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc:
Cc:
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Acked-by: Sebastian Reichel
Tested-by: Linus Walleij
Cc:
Cc: Daniel Vetter
Cc: "Rafael J. Wysock
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Tomas Winkler
Cc: Vitaly Lubart
Cc: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Cc: Arnd Bergman
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Emma Anholt
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: R
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Yong Wu
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Tested-by: Jyri Sarha
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Si
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Neil Armstrong
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Te
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
TODO: Move the helpers to PM in aggregate driver hooks.
Acked-by: Paul Cercueil
Cc: Daniel Vetter
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
Cc: Daniel Vetter
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Philipp Zabel
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc:
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Daniel Vetter
Cc: "Rafa
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
The device lists are poorly ordered when the component device code is
used. This is because component_master_add_with_match() returns 0
regardless of component devices calling component_add() first. It can
really only fail if an allocation fails, in which case everything is
going bad and we're out
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Russell King
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Saravana Kannan
Si
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
TODO: This can be updated to move the drm helper logic into the
aggregate driver shutdown op.
Cc: L
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Liviu Dudau
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Sa
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: James Qian Wang (Arm Technology China)
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clar
Similar to drm_of_component_probe() but using the new API that registers
a driver instead of an ops struct. This allows us to migrate the users
of drm_of_component_probe() to the new way of doing things.
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell K
This allows aggregate driver writers to use the device passed to their
probe/remove/shutdown functions properly instead of treating it as an
opaque pointer.
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Laurent Pinchart
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kanna
We'd like to get more device model features in the component framework
so let's pass the struct aggregate_device pointer instead of the parent
device pointer to the component binding functions. This will allow
drivers to inspect and control things related to the aggregate device in
case they need i
The component framework only provides 'bind' and 'unbind' callbacks to
tell the host driver that it is time to assemble the aggregate driver
now that all the components have probed. The component framework doesn't
attempt to resolve runtime PM or suspend/resume ordering, and explicitly
mentions thi
Remove most references to 'master' in the code and replace them with
some form of 'aggregate device'. This better reflects the reality of
what this code does, i.e. an aggregate device that represents a
device like a GPU card once some set of devices that make up the
aggregate device probe and regis
This series is from discussion we had on reordering the device lists for
drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
the aggregate device onto and then we probe the aggregate device once
all the components are probed and call component_add(). The probe/remove
hooks are whe
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connect
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connect
From: Rob Clark
With system suspend using pm_runtime_force_suspend() we can't rely on
the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks
after (or racing with) suspend. So flush any pending idle or boost
work in the suspend path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/m
From: Rob Clark
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
the runpm reference counts. This doesn't actually work so well when the
GPU is active. So add a reasonable delay waiting for the GPU to become
idle.
Alternatively we could just return -EBUSY in this case, b
From: Rob Clark
Because system suspend uses pm_runtime_force_suspend() we can't rely
runpm refcnt's to protect us if the GPU is active, etc. Fortunately
*usually* the GPU is idle when system suspend is triggered. But that
isn't quite good enough.
The first patch attempts to block for a modest
On Thu 06 Jan 09:15 PST 2022, Kuogee Hsieh wrote:
> We never assign struct dp_panel::connector, instead the connector is
> stored in struct msm_dp::connector. When we run compliance testing test
> case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set
I unfortunately have no idea
We never assign struct dp_panel::connector, instead the connector is
stored in struct msm_dp::connector. When we run compliance testing test
case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set
in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
On 1/5/2022 1:34 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-12-29 11:17:02)
There is kernel crashed due to unable to handle kernel NULL
pointer dereference of dp_panel->connector while running DP link
layer compliance test case 4.2.2.6 (EDID Corruption Detection).
Can you explain how
69 matches
Mail list logo
