Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.
Let's add a property in the device tree for this concept.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
Changes in v2: None
.../devicetree/bindings/display/panel/simple-panel.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 45a457ad38f0..b2b872c710f2 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -11,6 +11,9 @@ Optional properties:
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
+- no-hpd: This panel is supposed to communicate that it's ready via HPD
+ (hot plug detect) signal, but the signal isn't hooked up so we should
+ hardcode the max delay from the panel spec when powering up the panel.
Example:
--
2.19.1.568.g152ad8e336-goog
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
In any case, let's update the name and also the physical size to match
the correct panel.
Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Cc: Sandeep Panda <[email protected]>
---
Changes in v2: None
drivers/gpu/drm/panel/panel-simple.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 88592f9a0018..a04ffb3b2174 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1373,7 +1373,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
},
};
-static const struct drm_display_mode innolux_tv123wam_mode = {
+static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
.clock = 206016,
.hdisplay = 2160,
.hsync_start = 2160 + 48,
@@ -1387,13 +1387,13 @@ static const struct drm_display_mode innolux_tv123wam_mode = {
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
};
-static const struct panel_desc innolux_tv123wam = {
- .modes = &innolux_tv123wam_mode,
+static const struct panel_desc innolux_p120zdg_bf1 = {
+ .modes = &innolux_p120zdg_bf1_mode,
.num_modes = 1,
.bpc = 8,
.size = {
- .width = 259,
- .height = 173,
+ .width = 254,
+ .height = 169,
},
.delay = {
.hpd_absent_delay = 200,
@@ -2456,8 +2456,8 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,n156bge-l21",
.data = &innolux_n156bge_l21,
}, {
- .compatible = "innolux,tv123wam",
- .data = &innolux_tv123wam,
+ .compatible = "innolux,p120zdg-bf1",
+ .data = &innolux_p120zdg_bf1,
}, {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
--
2.19.1.568.g152ad8e336-goog
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
While we doing the rename, also mention that no-hpd can be used with
this panel. See the previous patch in this series ("drm/panel:
simple: Add "no-hpd" delay for Innolux TV123WAM").
Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Cc: Sandeep Panda <[email protected]>
---
Changes in v2: None
.../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} (70%)
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
similarity index 70%
rename from Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
rename to Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
index a9b35265fa13..513f03466aba 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
@@ -1,20 +1,22 @@
-Innolux TV123WAM 12.3 inch eDP 2K display panel
+Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
Required properties:
-- compatible: should be "innolux,tv123wam"
+- compatible: should be "innolux,p120zdg-bf1"
- power-supply: regulator to provide the supply voltage
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
+- no-hpd: If HPD isn't hooked up; add this property.
Example:
panel_edp: panel-edp {
- compatible = "innolux,tv123wam";
+ compatible = "innolux,p120zdg-bf1";
enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
power-supply = <&pm8916_l2>;
backlight = <&backlight>;
+ no-hpd;
};
--
2.19.1.568.g152ad8e336-goog
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see there's a timing "t3" that times from power on
to the aux channel being operational. This time is specced as 0 - 200
ms. The datasheet says that the aux channel is operational at exactly
the same time that HPD is asserted.
Scoping the signals on this board showed that HPD was asserted 84 ms
after power was asserted. That very closely matches the magic 70 ms
delay that we had. ...and actually, in my testing the 70 ms wasn't
quite enough of a delay and some percentage of the time the display
didn't come up until I bumped it to 100 ms (presumably 84 ms would
have worked too).
To solve this, we tried to hook up the HPD signal in the bridge.
...but in doing so we found that that the bridge didn't report that
HPD was asserted until ~280 ms after we powered it (!). This is
explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
(Hot Plug/Unplug Detection)". Reading there we see that the bridge
isn't even intended to report HPD until 100 ms after it's asserted.
...but that would have left us at 184 ms. The extra 100 ms
(presumably) comes from this part in the datasheet:
> The HPD state machine operates off an internal ring oscillator. The
> ring oscillator frequency will vary [ ... ]. The min/max range in
> the HPD State Diagram refers to the possible times based off
> variation in the ring oscillator frequency.
Given that the 280 ms we'll end up delaying if we hook up HPD is
_slower_ than the 200 ms we could just hardcode, for now we'll solve
the problem by just hardcoding a 200 ms delay in the panel driver
using the patch in this series ("drm/panel: simple: Support panels
with HPD where HPD isn't connected").
If we later find a panel that needs to use this bridge where we need
HPD then we'll have to come up with some new code to handle it. Given
the silly debouncing in the bridge chip, though, it seems unlikely.
One last note is that I tried to solve this through another way: In
ti_sn_bridge_enable() I tried to use various combinations of
dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
was up. In theory that would let me detect _exactly_ when I could
continue and do link training. Unfortunately even if I did an aux
transfer w/out waiting I couldn't see any errors. Possibly I could
keep looping over link training until it came back with success, but
that seemed a little overly hacky to me.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++++++++++++++------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f8a931cf3665..680566d97adc 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
unsigned int val;
int ret;
- /*
- * FIXME:
- * This 70ms was found necessary by experimentation. If it's not
- * present, link training fails. It seems like it can go anywhere from
- * pre_enable() up to semi-auto link training initiation below.
- *
- * Neither the datasheet for the bridge nor the panel tested mention a
- * delay of this magnitude in the timing requirements. So for now, add
- * the mystery delay until someone figures out a better fix.
- */
- msleep(70);
-
/* DSI_A lane config */
val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
@@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
/* configure bridge ref_clk */
ti_sn_bridge_set_refclk_freq(pdata);
- /* in case drm_panel is connected then HPD is not supported */
+ /*
+ * HPD on this bridge chip is a bit useless. This is an eDP bridge
+ * so the HPD is an internal signal that's only there to signal that
+ * the panel is done powering up. ...but the bridge chip debounces
+ * this signal by between 100 ms and 400 ms (depending on process,
+ * voltage, and temperate--I measured it at about 200 ms). One
+ * particular panel asserted HPD 84 ms after it was powered on meaning
+ * that we saw HPD 284 ms after power on. ...but the same panel said
+ * that instead of looking at HPD you could just hardcode a delay of
+ * 200 ms. We'll assume that the panel driver will have the hardcoded
+ * delay in its prepare and always disable HPD.
+ *
+ * If HPD somehow makes sense on some future panel we'll have to
+ * change this to be conditional on someone specifying that HPD should
+ * be used.
+ */
regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
HPD_DISABLE);
--
2.19.1.568.g152ad8e336-goog
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson <[email protected]>
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 687fd087b9fc..88592f9a0018 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1396,6 +1396,7 @@ static const struct panel_desc innolux_tv123wam = {
.height = 173,
},
.delay = {
+ .hpd_absent_delay = 200,
.unprepare = 500,
},
};
--
2.19.1.568.g152ad8e336-goog
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.
Let's add support in simple-panel for this concept.
At the moment we will co-opt the existing "prepare" delay to keep
track of the delay and we'll use a boolean to specify that a given
panel should only apply the delay if the "no-hpd" property was
specified.
Signed-off-by: Douglas Anderson <[email protected]>
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..687fd087b9fc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -56,6 +56,8 @@ struct panel_desc {
/**
* @prepare: the time (in milliseconds) that it takes for the panel to
* become ready and start receiving video data
+ * @hpd_absent_delay: Add this to the prepare delay if we know Hot
+ * Plug Detect isn't used.
* @enable: the time (in milliseconds) that it takes for the panel to
* display the first valid frame after starting to receive
* video data
@@ -66,6 +68,7 @@ struct panel_desc {
*/
struct {
unsigned int prepare;
+ unsigned int hpd_absent_delay;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
@@ -79,6 +82,7 @@ struct panel_simple {
struct drm_panel base;
bool prepared;
bool enabled;
+ bool no_hpd;
const struct panel_desc *desc;
@@ -202,6 +206,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
static int panel_simple_prepare(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
+ unsigned int delay;
int err;
if (p->prepared)
@@ -215,8 +220,11 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- if (p->desc->delay.prepare)
- msleep(p->desc->delay.prepare);
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
p->prepared = true;
@@ -305,6 +313,8 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
panel->prepared = false;
panel->desc = desc;
+ panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
+
panel->supply = devm_regulator_get(dev, "power");
if (IS_ERR(panel->supply))
return PTR_ERR(panel->supply);
--
2.19.1.568.g152ad8e336-goog
On Thu, Oct 25, 2018 at 03:21:30PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the HPD signal from
> the panel isn't actually hooked up. In the case where the HPD isn't
> hooked up you can look at the timing diagram on the panel datasheet
> and insert a delay for the maximum amount of time that the HPD might
> take to come up.
>
> Let's add support in simple-panel for this concept.
>
> At the moment we will co-opt the existing "prepare" delay to keep
> track of the delay and we'll use a boolean to specify that a given
> panel should only apply the delay if the "no-hpd" property was
> specified.
>
> Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
> ---
>
> Changes in v2:
> - Use "hpd_absent_delay" property instead of a bool + prepare delay
>
> drivers/gpu/drm/panel/panel-simple.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 97964f7f2ace..687fd087b9fc 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -56,6 +56,8 @@ struct panel_desc {
> /**
> * @prepare: the time (in milliseconds) that it takes for the panel to
> * become ready and start receiving video data
> + * @hpd_absent_delay: Add this to the prepare delay if we know Hot
> + * Plug Detect isn't used.
> * @enable: the time (in milliseconds) that it takes for the panel to
> * display the first valid frame after starting to receive
> * video data
> @@ -66,6 +68,7 @@ struct panel_desc {
> */
> struct {
> unsigned int prepare;
> + unsigned int hpd_absent_delay;
> unsigned int enable;
> unsigned int disable;
> unsigned int unprepare;
> @@ -79,6 +82,7 @@ struct panel_simple {
> struct drm_panel base;
> bool prepared;
> bool enabled;
> + bool no_hpd;
>
> const struct panel_desc *desc;
>
> @@ -202,6 +206,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
> static int panel_simple_prepare(struct drm_panel *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
> + unsigned int delay;
> int err;
>
> if (p->prepared)
> @@ -215,8 +220,11 @@ static int panel_simple_prepare(struct drm_panel *panel)
>
> gpiod_set_value_cansleep(p->enable_gpio, 1);
>
> - if (p->desc->delay.prepare)
> - msleep(p->desc->delay.prepare);
> + delay = p->desc->delay.prepare;
> + if (p->no_hpd)
> + delay += p->desc->delay.hpd_absent_delay;
> + if (delay)
> + msleep(delay);
>
> p->prepared = true;
>
> @@ -305,6 +313,8 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> panel->prepared = false;
> panel->desc = desc;
>
> + panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
> +
> panel->supply = devm_regulator_get(dev, "power");
> if (IS_ERR(panel->supply))
> return PTR_ERR(panel->supply);
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
On Thu, Oct 25, 2018 at 03:21:31PM -0700, Douglas Anderson wrote:
> If the HPD signal isn't hooked up to this panel we need a 200 ms
> delay. In the datasheet this is shown as the maximum time that HPD
> will take to be asserted after power is given to the panel.
>
> Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
> ---
>
> Changes in v2:
> - Use "hpd_absent_delay" property instead of a bool + prepare delay
>
> drivers/gpu/drm/panel/panel-simple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 687fd087b9fc..88592f9a0018 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1396,6 +1396,7 @@ static const struct panel_desc innolux_tv123wam = {
> .height = 173,
> },
> .delay = {
> + .hpd_absent_delay = 200,
> .unprepare = 500,
> },
> };
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
On Thu, Oct 25, 2018 at 03:21:33PM -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> While we doing the rename, also mention that no-hpd can be used with
> this panel. See the previous patch in this series ("drm/panel:
> simple: Add "no-hpd" delay for Innolux TV123WAM").
>
> Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
> Signed-off-by: Douglas Anderson <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
I didn't see your v2 when I replied to the v1 patch, so for the record,
Reviewed-by: Sean Paul <[email protected]>
Also note to whoever applies this to -misc, v1 also had
Reviewed-by: Abhinav Kumar <[email protected]>
Sean
> Cc: Sandeep Panda <[email protected]>
> ---
>
> Changes in v2: None
>
> .../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
> rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} (70%)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> similarity index 70%
> rename from Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> rename to Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> index a9b35265fa13..513f03466aba 100644
> --- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> +++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> @@ -1,20 +1,22 @@
> -Innolux TV123WAM 12.3 inch eDP 2K display panel
> +Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
>
> This binding is compatible with the simple-panel binding, which is specified
> in simple-panel.txt in this directory.
>
> Required properties:
> -- compatible: should be "innolux,tv123wam"
> +- compatible: should be "innolux,p120zdg-bf1"
> - power-supply: regulator to provide the supply voltage
>
> Optional properties:
> - enable-gpios: GPIO pin to enable or disable the panel
> - backlight: phandle of the backlight device attached to the panel
> +- no-hpd: If HPD isn't hooked up; add this property.
>
> Example:
> panel_edp: panel-edp {
> - compatible = "innolux,tv123wam";
> + compatible = "innolux,p120zdg-bf1";
> enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
> power-supply = <&pm8916_l2>;
> backlight = <&backlight>;
> + no-hpd;
> };
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
On Thu, Oct 25, 2018 at 03:21:34PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> In any case, let's update the name and also the physical size to match
> the correct panel.
>
> Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> Signed-off-by: Douglas Anderson <[email protected]>
> Reviewed-by: Abhinav Kumar <[email protected]>
> Cc: Sandeep Panda <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/panel/panel-simple.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 88592f9a0018..a04ffb3b2174 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1373,7 +1373,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> },
> };
>
> -static const struct drm_display_mode innolux_tv123wam_mode = {
> +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> .clock = 206016,
> .hdisplay = 2160,
> .hsync_start = 2160 + 48,
> @@ -1387,13 +1387,13 @@ static const struct drm_display_mode innolux_tv123wam_mode = {
> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> };
>
> -static const struct panel_desc innolux_tv123wam = {
> - .modes = &innolux_tv123wam_mode,
> +static const struct panel_desc innolux_p120zdg_bf1 = {
> + .modes = &innolux_p120zdg_bf1_mode,
> .num_modes = 1,
> .bpc = 8,
> .size = {
> - .width = 259,
> - .height = 173,
> + .width = 254,
> + .height = 169,
> },
> .delay = {
> .hpd_absent_delay = 200,
> @@ -2456,8 +2456,8 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "innolux,n156bge-l21",
> .data = &innolux_n156bge_l21,
> }, {
> - .compatible = "innolux,tv123wam",
> - .data = &innolux_tv123wam,
> + .compatible = "innolux,p120zdg-bf1",
> + .data = &innolux_p120zdg_bf1,
> }, {
> .compatible = "innolux,zj070na-01p",
> .data = &innolux_zj070na_01p,
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
On Fri, Oct 26, 2018 at 10:43:56AM -0400, Sean Paul wrote:
> On Thu, Oct 25, 2018 at 03:21:33PM -0700, Douglas Anderson wrote:
> > As far as I can tell the bindings that were added in commit
> > 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> > bindings") weren't actually for Innolux TV123WAM but were actually for
> > Innolux P120ZDG-BF1.
> >
> > As far as I can tell the Innolux TV123WAM isn't a real panel and but
> > it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> > Let's unmosh.
> >
> > Here's my evidence:
> >
> > * Searching for TV123WAM on the Internet turns up a TI panel. While
> > it's possible that an Innolux panel has the same model number as the
> > TI Panel, it seems a little doubtful. Looking up the datasheet from
> > the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
> >
> > * As far as I know, the patch adding the Innolux Panel was supposed to
> > be for the board that's sitting in front of me as I type this
> > (support for that board is not yet upstream). On the back of that
> > panel I see Innolux P120ZDZ-EZ1 rev B1.
> >
> > * Someone pointed me at a datasheet that's supposed to be for the
> > panel in front of me (sorry, I can't share the datasheet). That
> > datasheet has the string "p120zdg-bf1"
> >
> > * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> > that are 2160x1440. They don't have datasheets, but the fact that
> > the resolution matches is a good sign.
> >
> > While we doing the rename, also mention that no-hpd can be used with
> > this panel. See the previous patch in this series ("drm/panel:
> > simple: Add "no-hpd" delay for Innolux TV123WAM").
> >
> > Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
> > Signed-off-by: Douglas Anderson <[email protected]>
> > Reviewed-by: Rob Herring <[email protected]>
>
> I didn't see your v2 when I replied to the v1 patch, so for the record,
>
> Reviewed-by: Sean Paul <[email protected]>
>
> Also note to whoever applies this to -misc, v1 also had
>
> Reviewed-by: Abhinav Kumar <[email protected]>
And I just realized that patches 5 & 6 were swapped in v2. So nevermind this,
Doug's v2 tags are correct.
Dear coffee, please kick in soon.
Sean
>
>
> Sean
>
> > Cc: Sandeep Panda <[email protected]>
> > ---
> >
> > Changes in v2: None
> >
> > .../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> > rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} (70%)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> > similarity index 70%
> > rename from Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> > rename to Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> > index a9b35265fa13..513f03466aba 100644
> > --- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> > @@ -1,20 +1,22 @@
> > -Innolux TV123WAM 12.3 inch eDP 2K display panel
> > +Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
> >
> > This binding is compatible with the simple-panel binding, which is specified
> > in simple-panel.txt in this directory.
> >
> > Required properties:
> > -- compatible: should be "innolux,tv123wam"
> > +- compatible: should be "innolux,p120zdg-bf1"
> > - power-supply: regulator to provide the supply voltage
> >
> > Optional properties:
> > - enable-gpios: GPIO pin to enable or disable the panel
> > - backlight: phandle of the backlight device attached to the panel
> > +- no-hpd: If HPD isn't hooked up; add this property.
> >
> > Example:
> > panel_edp: panel-edp {
> > - compatible = "innolux,tv123wam";
> > + compatible = "innolux,p120zdg-bf1";
> > enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
> > power-supply = <&pm8916_l2>;
> > backlight = <&backlight>;
> > + no-hpd;
> > };
> > --
> > 2.19.1.568.g152ad8e336-goog
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Sean Paul, Software Engineer, Google / Chromium OS
Sean,
On Fri, Oct 26, 2018 at 7:47 AM Sean Paul <[email protected]> wrote:
> > I didn't see your v2 when I replied to the v1 patch, so for the record,
> >
> > Reviewed-by: Sean Paul <[email protected]>
> >
> > Also note to whoever applies this to -misc, v1 also had
> >
> > Reviewed-by: Abhinav Kumar <[email protected]>
>
> And I just realized that patches 5 & 6 were swapped in v2. So nevermind this,
> Doug's v2 tags are correct.
>
> Dear coffee, please kick in soon.
Sorry about that--I should have mentioned it in the notes. I realized
that the bindings were supposed to land before the code so I swapped
them. Thanks for your review!
-Doug
On 26.10.2018 00:21, Douglas Anderson wrote:
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at the datasheet for the same panel that was tested for the
> original commit, I see there's a timing "t3" that times from power on
> to the aux channel being operational. This time is specced as 0 - 200
> ms. The datasheet says that the aux channel is operational at exactly
> the same time that HPD is asserted.
>
> Scoping the signals on this board showed that HPD was asserted 84 ms
> after power was asserted. That very closely matches the magic 70 ms
> delay that we had. ...and actually, in my testing the 70 ms wasn't
> quite enough of a delay and some percentage of the time the display
> didn't come up until I bumped it to 100 ms (presumably 84 ms would
> have worked too).
>
> To solve this, we tried to hook up the HPD signal in the bridge.
> ...but in doing so we found that that the bridge didn't report that
> HPD was asserted until ~280 ms after we powered it (!). This is
> explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
> (Hot Plug/Unplug Detection)". Reading there we see that the bridge
> isn't even intended to report HPD until 100 ms after it's asserted.
> ...but that would have left us at 184 ms. The extra 100 ms
> (presumably) comes from this part in the datasheet:
>
>> The HPD state machine operates off an internal ring oscillator. The
>> ring oscillator frequency will vary [ ... ]. The min/max range in
>> the HPD State Diagram refers to the possible times based off
>> variation in the ring oscillator frequency.
> Given that the 280 ms we'll end up delaying if we hook up HPD is
> _slower_ than the 200 ms we could just hardcode, for now we'll solve
> the problem by just hardcoding a 200 ms delay in the panel driver
> using the patch in this series ("drm/panel: simple: Support panels
> with HPD where HPD isn't connected").
>
> If we later find a panel that needs to use this bridge where we need
> HPD then we'll have to come up with some new code to handle it. Given
> the silly debouncing in the bridge chip, though, it seems unlikely.
>
> One last note is that I tried to solve this through another way: In
> ti_sn_bridge_enable() I tried to use various combinations of
> dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
> was up. In theory that would let me detect _exactly_ when I could
> continue and do link training. Unfortunately even if I did an aux
> transfer w/out waiting I couldn't see any errors. Possibly I could
> keep looping over link training until it came back with success, but
> that seemed a little overly hacky to me.
>
> Signed-off-by: Douglas Anderson <[email protected]>
> Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
--
Regards
Andrzej
On 26.10.2018 00:21, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> While we doing the rename, also mention that no-hpd can be used with
> this panel. See the previous patch in this series ("drm/panel:
> simple: Add "no-hpd" delay for Innolux TV123WAM").
>
> Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
> Signed-off-by: Douglas Anderson <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> Cc: Sandeep Panda <[email protected]>
Grats for good deduction.
Reviewed-by: Andrzej Hajda <[email protected]>
--
Regards
Andrzej
On Thu, Oct 25, 2018 at 03:21:29PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the HPD signal from
> the panel isn't actually hooked up. In the case where the HPD isn't
> hooked up you can look at the timing diagram on the panel datasheet
> and insert a delay for the maximum amount of time that the HPD might
> take to come up.
>
> Let's add a property in the device tree for this concept.
>
> Signed-off-by: Douglas Anderson <[email protected]>
Thanks for the series, Doug, I've applied it all to drm-misc-next-fixes for
4.20.
Sean
> Reviewed-by: Sean Paul <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> ---
>
> Changes in v2: None
>
> .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index 45a457ad38f0..b2b872c710f2 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -11,6 +11,9 @@ Optional properties:
> - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> - enable-gpios: GPIO pin to enable or disable the panel
> - backlight: phandle of the backlight device attached to the panel
> +- no-hpd: This panel is supposed to communicate that it's ready via HPD
> + (hot plug detect) signal, but the signal isn't hooked up so we should
> + hardcode the max delay from the panel spec when powering up the panel.
>
> Example:
>
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS