From: Kieran Bingham <kieran.bingham@ideasonboard.com> To: Doug Anderson <dianders@chromium.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jernej Skrabec <jernej.skrabec@siol.net>, Jonas Karlman <jonas@kwiboo.se>, Neil Armstrong <narmstrong@baylibre.com>, dri-devel <dri-devel@lists.freedesktop.org>, Stephen Boyd <swboyd@chromium.org>, linux-renesas-soc@vger.kernel.org, Andrzej Hajda <a.hajda@samsung.com> Subject: Re: [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode Date: Wed, 23 Feb 2022 18:04:59 +0000 [thread overview] Message-ID: <164563949999.4066078.2399611738908533224@Monstersaurus> (raw) In-Reply-To: <YNM+JO4AAkPOLg7Y@pendragon.ideasonboard.com> Hi Doug, Laurent, Quoting Laurent Pinchart (2021-06-23 14:59:00) > Hi Doug, > > On Wed, Mar 24, 2021 at 03:47:07PM -0700, Doug Anderson wrote: > > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > > > > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > > > routed to a DisplayPort connector. Enable DisplayPort mode when the next > > > component in the display pipeline is not a panel, and disable eDP > > > features in that case. > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > --- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 ++++++++++++++++++++------- > > > 1 file changed, 24 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > index e2527d597ccb..f792227142a7 100644 > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > @@ -55,6 +55,7 @@ > > > #define SN_LN_ASSIGN_REG 0x59 > > > #define LN_ASSIGN_WIDTH 2 > > > #define SN_ENH_FRAME_REG 0x5A > > > +#define ASSR_CONTROL BIT(0) > > > #define VSTREAM_ENABLE BIT(3) > > > #define LN_POLRS_OFFSET 4 > > > #define LN_POLRS_MASK 0xf0 > > > @@ -86,6 +87,8 @@ > > > #define SN_DATARATE_CONFIG_REG 0x94 > > > #define DP_DATARATE_MASK GENMASK(7, 5) > > > #define DP_DATARATE(x) ((x) << 5) > > > +#define SN_TRAINING_SETTING_REG 0x95 > > > +#define SCRAMBLE_DISABLE BIT(4) > > > #define SN_ML_TX_MODE_REG 0x96 > > > #define ML_TX_MAIN_LINK_OFF 0 > > > #define ML_TX_NORMAL_MODE BIT(0) > > > @@ -723,6 +726,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, > > > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, > > > DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > > > > > + /* For DisplayPort, use the standard DP scrambler seed. */ > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > > > + ASSR_CONTROL, 0); > > > > I don't actually know anything about DP scrambler seeds. However: > > > > 1. From reading the docs, this field seems to be documented to be > > "read only" unless: > > > > 1a) The "TEST2" pin is pulled high when you power on the bridge. > > 1b) You set "ASSR_OVERRIDE" (page select to page 7, write to register > > 0x16, page select back to page 0). > > > > I don't know if TEST2 is being pulled high in your hardware, but at > > least I can see that 1b) isn't done. So I'm guessing that this line is > > a no-op? If I had to guess from all the hoops they're making you jump > > through there's some sort of errata around standard scrambling on this > > bridge chip. Are you sure it works OK? > > Good question :-) We managed to get the SN65DSI86 to work with an > external DP monitor yesterday, so it's possible (some modes don't > operate correctly yet, but I assume that to be an issue with the DSI > encoder). > > The TEST2 pin is strapped to ground on the board. > > According to the DisplayPort specification, eDP and DP use different > scrambler seeds to prevent interoperability between an eDP source and a > DP sink. I'll check what happens without this change. Without this change, the display still works... > > > 2. The docs I see claim that this field is 2 bits big. It seems like > > it would be nice to honor. Yeah, it's silly because 0x11 and 0x10 are > > "reserved" so it's really more like a 1-bit field, but still seems > > like it would be better to set both bits, or at least add a comment > > explaining why you're not matching the datasheet. > > Sure. > > > 3. Your patch doesn't seem to touch the bit of code in > > ti_sn_bridge_enable() that says this: > > > > /** > > * The SN65DSI86 only supports ASSR Display Authentication method and > > * this method is enabled by default. An eDP panel must support this > > * authentication method. We need to enable this method in the eDP panel > > * at DisplayPort address 0x0010A prior to link training. > > */ > > drm_dp_dpcd_writeb(&pdata->aux, DP_EDP_CONFIGURATION_SET, > > DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); > > > > Won't that be a problem? > > I'll have a look. I'm not sure I yet fully understand the requirements here, but could it be that only supporting ASSR is why the scrambling is disabled below? Commenting out that write does not affect the bring up of my DP monitor. > > > > + > > > /* enable DP PLL */ > > > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > > > > > @@ -734,6 +742,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, > > > goto exit; > > > } > > > > > > + /* For DisplayPort, disable scrambling mode. */ > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > > + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, > > > + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); > > > > I'm assuming that this is the important part of your patch? Would be > > sorta nice to include the "why" in your comment. Why do you want to > > disable scrambling mode for DP but not for eDP? Maybe you care about > > compatibility but not EMI if you're hooking up to random DP things? > > I'll investigate and include proper documentation in v2 (or drop the > change altogether if it's not required). And indeed, this part is important. If I drop this hunk - then I get no display output. I'm afraid I don't (yet) know the reasons 'why' to extend the comment, beyond "Scrambling is not supported for DP". If anyone already does, please feel free to provide the text, and I'll include it in the next revision, or I'll try to do some more digging into this part. -- Kieran > > -- > Regards, > > Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Kieran Bingham <kieran.bingham@ideasonboard.com> To: Doug Anderson <dianders@chromium.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jernej Skrabec <jernej.skrabec@siol.net>, Neil Armstrong <narmstrong@baylibre.com>, Jonas Karlman <jonas@kwiboo.se>, dri-devel <dri-devel@lists.freedesktop.org>, Stephen Boyd <swboyd@chromium.org>, linux-renesas-soc@vger.kernel.org, Andrzej Hajda <a.hajda@samsung.com> Subject: Re: [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode Date: Wed, 23 Feb 2022 18:04:59 +0000 [thread overview] Message-ID: <164563949999.4066078.2399611738908533224@Monstersaurus> (raw) In-Reply-To: <YNM+JO4AAkPOLg7Y@pendragon.ideasonboard.com> Hi Doug, Laurent, Quoting Laurent Pinchart (2021-06-23 14:59:00) > Hi Doug, > > On Wed, Mar 24, 2021 at 03:47:07PM -0700, Doug Anderson wrote: > > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > > > > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > > > routed to a DisplayPort connector. Enable DisplayPort mode when the next > > > component in the display pipeline is not a panel, and disable eDP > > > features in that case. > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > --- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 ++++++++++++++++++++------- > > > 1 file changed, 24 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > index e2527d597ccb..f792227142a7 100644 > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > @@ -55,6 +55,7 @@ > > > #define SN_LN_ASSIGN_REG 0x59 > > > #define LN_ASSIGN_WIDTH 2 > > > #define SN_ENH_FRAME_REG 0x5A > > > +#define ASSR_CONTROL BIT(0) > > > #define VSTREAM_ENABLE BIT(3) > > > #define LN_POLRS_OFFSET 4 > > > #define LN_POLRS_MASK 0xf0 > > > @@ -86,6 +87,8 @@ > > > #define SN_DATARATE_CONFIG_REG 0x94 > > > #define DP_DATARATE_MASK GENMASK(7, 5) > > > #define DP_DATARATE(x) ((x) << 5) > > > +#define SN_TRAINING_SETTING_REG 0x95 > > > +#define SCRAMBLE_DISABLE BIT(4) > > > #define SN_ML_TX_MODE_REG 0x96 > > > #define ML_TX_MAIN_LINK_OFF 0 > > > #define ML_TX_NORMAL_MODE BIT(0) > > > @@ -723,6 +726,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, > > > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, > > > DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > > > > > + /* For DisplayPort, use the standard DP scrambler seed. */ > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > > > + ASSR_CONTROL, 0); > > > > I don't actually know anything about DP scrambler seeds. However: > > > > 1. From reading the docs, this field seems to be documented to be > > "read only" unless: > > > > 1a) The "TEST2" pin is pulled high when you power on the bridge. > > 1b) You set "ASSR_OVERRIDE" (page select to page 7, write to register > > 0x16, page select back to page 0). > > > > I don't know if TEST2 is being pulled high in your hardware, but at > > least I can see that 1b) isn't done. So I'm guessing that this line is > > a no-op? If I had to guess from all the hoops they're making you jump > > through there's some sort of errata around standard scrambling on this > > bridge chip. Are you sure it works OK? > > Good question :-) We managed to get the SN65DSI86 to work with an > external DP monitor yesterday, so it's possible (some modes don't > operate correctly yet, but I assume that to be an issue with the DSI > encoder). > > The TEST2 pin is strapped to ground on the board. > > According to the DisplayPort specification, eDP and DP use different > scrambler seeds to prevent interoperability between an eDP source and a > DP sink. I'll check what happens without this change. Without this change, the display still works... > > > 2. The docs I see claim that this field is 2 bits big. It seems like > > it would be nice to honor. Yeah, it's silly because 0x11 and 0x10 are > > "reserved" so it's really more like a 1-bit field, but still seems > > like it would be better to set both bits, or at least add a comment > > explaining why you're not matching the datasheet. > > Sure. > > > 3. Your patch doesn't seem to touch the bit of code in > > ti_sn_bridge_enable() that says this: > > > > /** > > * The SN65DSI86 only supports ASSR Display Authentication method and > > * this method is enabled by default. An eDP panel must support this > > * authentication method. We need to enable this method in the eDP panel > > * at DisplayPort address 0x0010A prior to link training. > > */ > > drm_dp_dpcd_writeb(&pdata->aux, DP_EDP_CONFIGURATION_SET, > > DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); > > > > Won't that be a problem? > > I'll have a look. I'm not sure I yet fully understand the requirements here, but could it be that only supporting ASSR is why the scrambling is disabled below? Commenting out that write does not affect the bring up of my DP monitor. > > > > + > > > /* enable DP PLL */ > > > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > > > > > @@ -734,6 +742,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, > > > goto exit; > > > } > > > > > > + /* For DisplayPort, disable scrambling mode. */ > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > > + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, > > > + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); > > > > I'm assuming that this is the important part of your patch? Would be > > sorta nice to include the "why" in your comment. Why do you want to > > disable scrambling mode for DP but not for eDP? Maybe you care about > > compatibility but not EMI if you're hooking up to random DP things? > > I'll investigate and include proper documentation in v2 (or drop the > change altogether if it's not required). And indeed, this part is important. If I drop this hunk - then I get no display output. I'm afraid I don't (yet) know the reasons 'why' to extend the comment, beyond "Scrambling is not supported for DP". If anyone already does, please feel free to provide the text, and I'll include it in the next revision, or I'll try to do some more digging into this part. -- Kieran > > -- > Regards, > > Laurent Pinchart
next prev parent reply other threads:[~2022-02-23 18:05 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 3:01 [RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 01/11] dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:29 ` Jagan Teki 2021-03-22 10:29 ` Jagan Teki 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-27 16:42 ` Rob Herring 2021-03-27 16:42 ` Rob Herring 2021-03-22 3:01 ` [RFC PATCH 02/11] drm/bridge: ti-sn65dsi86: " Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:29 ` Jagan Teki 2021-03-22 10:29 ` Jagan Teki 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:41 ` Laurent Pinchart 2021-03-23 21:41 ` Laurent Pinchart 2021-03-23 22:55 ` Doug Anderson 2021-03-23 22:55 ` Doug Anderson 2021-03-23 23:02 ` Laurent Pinchart 2021-03-23 23:02 ` Laurent Pinchart 2021-03-26 0:43 ` Doug Anderson 2021-03-26 0:43 ` Doug Anderson 2021-03-26 1:01 ` Laurent Pinchart 2021-03-26 1:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:11 ` Stephen Boyd 2021-03-23 7:11 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:45 ` Laurent Pinchart 2021-03-23 21:45 ` Laurent Pinchart 2021-03-23 22:45 ` Doug Anderson 2021-03-23 22:45 ` Doug Anderson 2021-03-24 8:47 ` Geert Uytterhoeven 2021-03-24 8:47 ` Geert Uytterhoeven 2021-03-22 3:01 ` [RFC PATCH 05/11] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:19 ` Jagan Teki 2021-03-22 10:19 ` Jagan Teki 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 21:50 ` Laurent Pinchart 2021-03-23 21:50 ` Laurent Pinchart 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-26 1:06 ` Laurent Pinchart 2021-03-26 1:06 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 06/11] drm/bridge: ti-sn65dsi86: Group code in sections Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 7:14 ` Stephen Boyd 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 07/11] drm/bridge: ti-sn65dsi86: Split connector creation to a function Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:15 ` Stephen Boyd 2021-03-23 7:15 ` Stephen Boyd 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 08/11] drm/bridge: ti-sn65dsi86: Implement bridge connector operations Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:15 ` Stephen Boyd 2021-03-23 7:15 ` Stephen Boyd 2021-03-24 22:46 ` Doug Anderson 2021-03-24 22:46 ` Doug Anderson 2021-03-26 1:40 ` Laurent Pinchart 2021-03-26 1:40 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 09/11] drm/bridge: ti-sn65dsi86: Make connector creation optional Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-24 22:47 ` Doug Anderson 2021-03-24 22:47 ` Doug Anderson 2021-06-23 13:59 ` Laurent Pinchart 2021-06-23 13:59 ` Laurent Pinchart 2022-02-23 18:04 ` Kieran Bingham [this message] 2022-02-23 18:04 ` Kieran Bingham 2022-02-23 18:20 ` Doug Anderson 2022-02-23 18:20 ` Doug Anderson 2022-03-04 15:49 ` Laurent Pinchart 2022-03-04 15:49 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:21 ` Stephen Boyd 2021-03-23 7:21 ` Stephen Boyd 2021-03-24 22:47 ` Doug Anderson 2021-03-24 22:47 ` Doug Anderson 2021-06-23 23:25 ` Laurent Pinchart 2021-06-23 23:25 ` Laurent Pinchart 2021-06-23 23:51 ` Doug Anderson 2021-06-23 23:51 ` Doug Anderson 2022-02-23 17:43 ` Kieran Bingham 2022-02-23 17:43 ` Kieran Bingham 2022-02-23 18:25 ` Doug Anderson 2022-02-23 18:25 ` Doug Anderson 2022-03-04 15:45 ` Kieran Bingham 2022-03-04 15:45 ` Kieran Bingham 2022-03-04 16:30 ` Doug Anderson 2022-03-04 16:30 ` Doug Anderson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=164563949999.4066078.2399611738908533224@Monstersaurus \ --to=kieran.bingham@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=jernej.skrabec@siol.net \ --cc=jonas@kwiboo.se \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=narmstrong@baylibre.com \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.