On 6/27/2022 8:38 AM, Dmitry Baryshkov wrote:
On Mon, 27 Jun 2022 at 18:33, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:
On 6/24/2022 6:15 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-24 18:02:50)
On 6/24/2022 5:46 PM, Dmitry Baryshkov wrote:
On Sat, 25 Jun 2022 at 03:28, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
On Sat, 25 Jun 2022 at 03:23, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:
On 6/24/2022 5:21 PM, Dmitry Baryshkov wrote:
On Sat, 25 Jun 2022 at 03:19, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:
How can I have eDP call dpu_encoder_init() before DP calls with
_dpu_kms_initialize_displayport()?
Why do you want to do it? They are two different encoders.
eDP is primary display which in normal case should be bring up first if
DP is also presented.
I do not like the concept of primary display. It is the user, who must
decide which display is primary to him. I have seen people using just
external monitors and ignoring built-in eDP completely.from
Also, why does the bring up order matters here? What do you gain by
bringing up eDP before the DP?
I should probably rephrase my question to be more clear. How does
changing the order of DP vs eDP bringup help you 'to fix screen
corruption'.
it did fix the primary display correction issue if edp go first and i do
not know the root cause yet.
We are still investigating it.
However I do think currently msm_dp_config sc7280_dp_cfg has issues need
be addressed.
What issues exist with sc7280_dp_cfg? It looks correct to me.
If we are going to bring up a new chipset with edp as primary only, i am
not sure the below configuration will work?
static const struct msm_dp_config sc7280_dp_cfg = {
.descs = (const struct msm_dp_desc[]) {
[MSM_DP_CONTROLLER_1] = { .io_start = 0x0aea0000, .connector_type = DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
},
.num_descs = 1,
};
As I wrote in one of the comments, there is an issue with num_descs
being not obvious (in your example it should be 2, not 1). I thought
about dropping it and looping until the MSM_DP_CONTROLLER_COUNT, but
this would result in other kinds of hard-to-catch issues. Let me muse
about it.
Thanks for consideration.
