* [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-07 14:29 ` Linus Walleij
2020-03-09 13:36 ` [PATCH v2 " Ville Syrjala
2020-03-02 20:34 ` [PATCH 02/33] drm/panel-arm-versatile: " Ville Syrjala
` (32 subsequent siblings)
33 siblings, 2 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index b4c014126781..94e294b66a6a 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -1019,7 +1019,7 @@ static const struct nt35510_config nt35510_hydis_hva40wv1 = {
*/
.mode = {
/* The internal pixel clock of the NT35510 is 20 MHz */
- .clock = 20000000,
+ .clock = 23581,
.hdisplay = 480,
.hsync_start = 480 + 2, /* HFP = 2 */
.hsync_end = 480 + 2 + 0, /* HSync = 0 */
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock
2020-03-02 20:34 ` [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock Ville Syrjala
@ 2020-03-07 14:29 ` Linus Walleij
2020-03-09 13:36 ` [PATCH v2 " Ville Syrjala
1 sibling, 0 replies; 98+ messages in thread
From: Linus Walleij @ 2020-03-07 14:29 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Sam Ravnborg, open list:DRM PANEL DRIVERS
Hi Ville,
On Mon, Mar 2, 2020 at 9:34 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> .mode = {
> /* The internal pixel clock of the NT35510 is 20 MHz */
> - .clock = 20000000,
> + .clock = 23581,
I double checked this with the datasheet NT35510 Application Note V0.07 HYDIS
and all documentation is in line with the comment: the internal clock
frequency of
the dotclock is 20 MHz so this should be set to 20000 (kHz) sorry for putting
the three orders of magnitude too big number there :P
This clock isn't used by any drivers because this is a command mode DSI
panel with a DSI link clocked from the host. (hs_rate or lp_rate).
The internal formula shows how the actual vrefresh can be calculated for
the display in respone to setting of the internal registers, see page 34:
https://dflund.se/~triad/NT35510-appnote.pdf
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* [PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock
2020-03-02 20:34 ` [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock Ville Syrjala
2020-03-07 14:29 ` Linus Walleij
@ 2020-03-09 13:36 ` Ville Syrjala
2020-03-09 15:33 ` Linus Walleij
1 sibling, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-09 13:36 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The dotclock is three orders of magnitude out. Fix it.
v2: Just set it to 20MHz (Linus)
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index b4c014126781..4a8fa908a2cf 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -1019,7 +1019,7 @@ static const struct nt35510_config nt35510_hydis_hva40wv1 = {
*/
.mode = {
/* The internal pixel clock of the NT35510 is 20 MHz */
- .clock = 20000000,
+ .clock = 20000,
.hdisplay = 480,
.hsync_start = 480 + 2, /* HFP = 2 */
.hsync_end = 480 + 2 + 0, /* HSync = 0 */
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock
2020-03-09 13:36 ` [PATCH v2 " Ville Syrjala
@ 2020-03-09 15:33 ` Linus Walleij
2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Linus Walleij @ 2020-03-09 15:33 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Sam Ravnborg, open list:DRM PANEL DRIVERS
On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The dotclock is three orders of magnitude out. Fix it.
>
> v2: Just set it to 20MHz (Linus)
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock
2020-03-09 15:33 ` Linus Walleij
@ 2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-11 14:46 UTC (permalink / raw)
To: Linus Walleij; +Cc: Sam Ravnborg, open list:DRM PANEL DRIVERS
On Mon, Mar 09, 2020 at 04:33:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The dotclock is three orders of magnitude out. Fix it.
> >
> > v2: Just set it to 20MHz (Linus)
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
2020-03-02 20:34 ` [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 12:10 ` Linus Walleij
2020-03-02 20:34 ` [PATCH 03/33] drm/panel-feixin-k101-im2ba02: " Ville Syrjala
` (31 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-arm-versatile.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 41444a73c980..ef49ba206eea 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -158,7 +158,7 @@ static const struct versatile_panel_type versatile_panels[] = {
.width_mm = 171,
.height_mm = 130,
.mode = {
- .clock = 25000,
+ .clock = 24696,
.hdisplay = 640,
.hsync_start = 640 + 24,
.hsync_end = 640 + 24 + 96,
@@ -181,7 +181,7 @@ static const struct versatile_panel_type versatile_panels[] = {
.width_mm = 34,
.height_mm = 45,
.mode = {
- .clock = 62500,
+ .clock = 16002,
.hdisplay = 176,
.hsync_start = 176 + 2,
.hsync_end = 176 + 2 + 3,
@@ -205,7 +205,7 @@ static const struct versatile_panel_type versatile_panels[] = {
.width_mm = 37,
.height_mm = 50,
.mode = {
- .clock = 5400,
+ .clock = 10588,
.hdisplay = 240,
.hsync_start = 240 + 10,
.hsync_end = 240 + 10 + 10,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock
2020-03-02 20:34 ` [PATCH 02/33] drm/panel-arm-versatile: " Ville Syrjala
@ 2020-03-03 12:10 ` Linus Walleij
2020-03-03 14:54 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Linus Walleij @ 2020-03-03 12:10 UTC (permalink / raw)
To: Ville Syrjala; +Cc: open list:DRM PANEL DRIVERS
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
I actually answered this in the mail thread where refresh was
deleted:
These dotclocks are correct. Delete the incorrect vrefresh instead.
So please drop this patch.
Thanks,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock
2020-03-03 12:10 ` Linus Walleij
@ 2020-03-03 14:54 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 14:54 UTC (permalink / raw)
To: Linus Walleij; +Cc: open list:DRM PANEL DRIVERS
On Tue, Mar 03, 2020 at 01:10:26PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> I actually answered this in the mail thread where refresh was
> deleted:
Sorry for the dupe. The thread turned into a mess so I just
decided to start from a clean slate.
>
> These dotclocks are correct. Delete the incorrect vrefresh instead.
>
> So please drop this patch.
Will do. Thanks.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
2020-03-02 20:34 ` [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock Ville Syrjala
2020-03-02 20:34 ` [PATCH 02/33] drm/panel-arm-versatile: " Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 23:36 ` Icenowy Zheng
2020-03-02 20:34 ` [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks Ville Syrjala
` (30 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg, Icenowy Zheng
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
index fddbfddf6566..8debee85f4ec 100644
--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel *panel)
}
static const struct drm_display_mode k101_im2ba02_default_mode = {
- .clock = 70000,
+ .clock = 67286,
.vrefresh = 60,
.hdisplay = 800,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
2020-03-02 20:34 ` [PATCH 03/33] drm/panel-feixin-k101-im2ba02: " Ville Syrjala
@ 2020-03-02 23:36 ` Icenowy Zheng
2020-03-03 14:51 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Icenowy Zheng @ 2020-03-02 23:36 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: Sam Ravnborg
于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala <ville.syrjala@linux.intel.com> 写到:
>From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
>The currently listed dotclock disagrees with the currently
>listed vrefresh rate. Change the dotclock to match the vrefresh.
>
>Someone tell me which (if either) of the dotclock or vreresh is
>correct?
dotclock is correct and vrefresh is only a placeholder value.
>
>Cc: Icenowy Zheng <icenowy@aosc.io>
>Cc: Sam Ravnborg <sam@ravnborg.org>
>Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
>
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>- .clock = 70000,
>+ .clock = 67286,
> .vrefresh = 60,
>
> .hdisplay = 800,
--
使用 K-9 Mail 发送自我的Android设备。
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
2020-03-02 23:36 ` Icenowy Zheng
@ 2020-03-03 14:51 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 14:51 UTC (permalink / raw)
To: Icenowy Zheng; +Cc: Sam Ravnborg, dri-devel
On Tue, Mar 03, 2020 at 07:36:35AM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala <ville.syrjala@linux.intel.com> 写到:
> >From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >The currently listed dotclock disagrees with the currently
> >listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> >Someone tell me which (if either) of the dotclock or vreresh is
> >correct?
>
> dotclock is correct and vrefresh is only a placeholder value.
Thanks. I'll drop this one.
>
> >
> >Cc: Icenowy Zheng <icenowy@aosc.io>
> >Cc: Sam Ravnborg <sam@ravnborg.org>
> >Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >---
> > drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >index fddbfddf6566..8debee85f4ec 100644
> >--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
> >*panel)
> > }
> >
> > static const struct drm_display_mode k101_im2ba02_default_mode = {
> >- .clock = 70000,
> >+ .clock = 67286,
> > .vrefresh = 60,
> >
> > .hdisplay = 800,
>
> --
> 使用 K-9 Mail 发送自我的Android设备。
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (2 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 03/33] drm/panel-feixin-k101-im2ba02: " Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-07 14:38 ` Linus Walleij
2020-03-09 13:38 ` [PATCH v2 " Ville Syrjala
2020-03-02 20:34 ` [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock Ville Syrjala
` (29 subsequent siblings)
33 siblings, 2 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index f394d53a7da4..5e06e73c2517 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -540,7 +540,7 @@ static int ili9322_enable(struct drm_panel *panel)
/* Serial RGB modes */
static const struct drm_display_mode srgb_320x240_mode = {
- .clock = 2453500,
+ .clock = 14478,
.hdisplay = 320,
.hsync_start = 320 + 359,
.hsync_end = 320 + 359 + 1,
@@ -554,7 +554,7 @@ static const struct drm_display_mode srgb_320x240_mode = {
};
static const struct drm_display_mode srgb_360x240_mode = {
- .clock = 2700000,
+ .clock = 10014,
.hdisplay = 360,
.hsync_start = 360 + 35,
.hsync_end = 360 + 35 + 1,
@@ -569,7 +569,7 @@ static const struct drm_display_mode srgb_360x240_mode = {
/* This is the only mode listed for parallel RGB in the datasheet */
static const struct drm_display_mode prgb_320x240_mode = {
- .clock = 6400000,
+ .clock = 6429,
.hdisplay = 320,
.hsync_start = 320 + 38,
.hsync_end = 320 + 38 + 1,
@@ -584,7 +584,7 @@ static const struct drm_display_mode prgb_320x240_mode = {
/* YUV modes */
static const struct drm_display_mode yuv_640x320_mode = {
- .clock = 2454000,
+ .clock = 18954,
.hdisplay = 640,
.hsync_start = 640 + 252,
.hsync_end = 640 + 252 + 1,
@@ -598,7 +598,7 @@ static const struct drm_display_mode yuv_640x320_mode = {
};
static const struct drm_display_mode yuv_720x360_mode = {
- .clock = 2700000,
+ .clock = 22911,
.hdisplay = 720,
.hsync_start = 720 + 252,
.hsync_end = 720 + 252 + 1,
@@ -613,7 +613,7 @@ static const struct drm_display_mode yuv_720x360_mode = {
/* BT.656 VGA mode, 640x480 */
static const struct drm_display_mode itu_r_bt_656_640_mode = {
- .clock = 2454000,
+ .clock = 27480,
.hdisplay = 640,
.hsync_start = 640 + 3,
.hsync_end = 640 + 3 + 1,
@@ -628,7 +628,7 @@ static const struct drm_display_mode itu_r_bt_656_640_mode = {
/* BT.656 D1 mode 720x480 */
static const struct drm_display_mode itu_r_bt_656_720_mode = {
- .clock = 2700000,
+ .clock = 29880,
.hdisplay = 720,
.hsync_start = 720 + 3,
.hsync_end = 720 + 3 + 1,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
2020-03-02 20:34 ` [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks Ville Syrjala
@ 2020-03-07 14:38 ` Linus Walleij
2020-03-09 13:38 ` [PATCH v2 " Ville Syrjala
1 sibling, 0 replies; 98+ messages in thread
From: Linus Walleij @ 2020-03-07 14:38 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Thierry Reding, open list:DRM PANEL DRIVERS
Hi Ville!
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This display is particularly peculiar since it uses
the ITU-T packed streams and like DSI those have
a different clocking than whatever is clocked out to the
actual display by the pixel clock.
Datasheet is here:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf
I see I have consistently set the clocks two orders of
magnitude wrong in this driver, mea culpa :P
But I checked them all and what I think you should
do is just divide them all by 100 and leave as-is.
> /* Serial RGB modes */
> static const struct drm_display_mode srgb_320x240_mode = {
> - .clock = 2453500,
> + .clock = 14478,
Please set to 24535.
> static const struct drm_display_mode srgb_360x240_mode = {
> - .clock = 2700000,
> + .clock = 10014,
Please set to 27000.
> /* This is the only mode listed for parallel RGB in the datasheet */
> static const struct drm_display_mode prgb_320x240_mode = {
> - .clock = 6400000,
> + .clock = 6429,
Please set to 64000.
> static const struct drm_display_mode yuv_640x320_mode = {
> - .clock = 2454000,
> + .clock = 18954,
Please set to 24540.
> static const struct drm_display_mode yuv_720x360_mode = {
> - .clock = 2700000,
> + .clock = 22911,
Please set to 27000.
> /* BT.656 VGA mode, 640x480 */
> static const struct drm_display_mode itu_r_bt_656_640_mode = {
> - .clock = 2454000,
> + .clock = 27480,
Please set to 24540.
> /* BT.656 D1 mode 720x480 */
> static const struct drm_display_mode itu_r_bt_656_720_mode = {
> - .clock = 2700000,
> + .clock = 29880,
Please set to 27000.
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* [PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
2020-03-02 20:34 ` [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks Ville Syrjala
2020-03-07 14:38 ` Linus Walleij
@ 2020-03-09 13:38 ` Ville Syrjala
2020-03-09 15:33 ` Linus Walleij
1 sibling, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-09 13:38 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The listed dotclocks are two orders of mangnitude out.
Fix them.
v2: Just divide everything by 100 (Linus)
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index f394d53a7da4..09935520e606 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -540,7 +540,7 @@ static int ili9322_enable(struct drm_panel *panel)
/* Serial RGB modes */
static const struct drm_display_mode srgb_320x240_mode = {
- .clock = 2453500,
+ .clock = 24535,
.hdisplay = 320,
.hsync_start = 320 + 359,
.hsync_end = 320 + 359 + 1,
@@ -554,7 +554,7 @@ static const struct drm_display_mode srgb_320x240_mode = {
};
static const struct drm_display_mode srgb_360x240_mode = {
- .clock = 2700000,
+ .clock = 27000,
.hdisplay = 360,
.hsync_start = 360 + 35,
.hsync_end = 360 + 35 + 1,
@@ -569,7 +569,7 @@ static const struct drm_display_mode srgb_360x240_mode = {
/* This is the only mode listed for parallel RGB in the datasheet */
static const struct drm_display_mode prgb_320x240_mode = {
- .clock = 6400000,
+ .clock = 64000,
.hdisplay = 320,
.hsync_start = 320 + 38,
.hsync_end = 320 + 38 + 1,
@@ -584,7 +584,7 @@ static const struct drm_display_mode prgb_320x240_mode = {
/* YUV modes */
static const struct drm_display_mode yuv_640x320_mode = {
- .clock = 2454000,
+ .clock = 24540,
.hdisplay = 640,
.hsync_start = 640 + 252,
.hsync_end = 640 + 252 + 1,
@@ -598,7 +598,7 @@ static const struct drm_display_mode yuv_640x320_mode = {
};
static const struct drm_display_mode yuv_720x360_mode = {
- .clock = 2700000,
+ .clock = 27000,
.hdisplay = 720,
.hsync_start = 720 + 252,
.hsync_end = 720 + 252 + 1,
@@ -613,7 +613,7 @@ static const struct drm_display_mode yuv_720x360_mode = {
/* BT.656 VGA mode, 640x480 */
static const struct drm_display_mode itu_r_bt_656_640_mode = {
- .clock = 2454000,
+ .clock = 24540,
.hdisplay = 640,
.hsync_start = 640 + 3,
.hsync_end = 640 + 3 + 1,
@@ -628,7 +628,7 @@ static const struct drm_display_mode itu_r_bt_656_640_mode = {
/* BT.656 D1 mode 720x480 */
static const struct drm_display_mode itu_r_bt_656_720_mode = {
- .clock = 2700000,
+ .clock = 27000,
.hdisplay = 720,
.hsync_start = 720 + 3,
.hsync_end = 720 + 3 + 1,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
2020-03-09 13:38 ` [PATCH v2 " Ville Syrjala
@ 2020-03-09 15:33 ` Linus Walleij
2020-03-11 14:47 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Linus Walleij @ 2020-03-09 15:33 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Thierry Reding, open list:DRM PANEL DRIVERS
On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The listed dotclocks are two orders of mangnitude out.
> Fix them.
>
> v2: Just divide everything by 100 (Linus)
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
2020-03-09 15:33 ` Linus Walleij
@ 2020-03-11 14:47 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-11 14:47 UTC (permalink / raw)
To: Linus Walleij; +Cc: Thierry Reding, open list:DRM PANEL DRIVERS
On Mon, Mar 09, 2020 at 04:33:56PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The listed dotclocks are two orders of mangnitude out.
> > Fix them.
> >
> > v2: Just divide everything by 100 (Linus)
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (3 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 12:52 ` Heiko Stuebner
2020-03-02 20:34 ` [PATCH 06/33] drm/panel-lg-lg4573: " Ville Syrjala
` (28 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Heiko Stuebner, Sam Ravnborg
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 76ecf2de9c44..113ab9c0396b 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
.vsync_end = 1280 + 30 + 4,
.vtotal = 1280 + 30 + 4 + 12,
.vrefresh = 60,
- .clock = 41600,
+ .clock = 69217,
.width_mm = 62,
.height_mm = 110,
};
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
2020-03-02 20:34 ` [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock Ville Syrjala
@ 2020-03-03 12:52 ` Heiko Stuebner
2020-04-02 13:13 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Heiko Stuebner @ 2020-03-03 12:52 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Sam Ravnborg, dri-devel
Hi,
Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
The values came that way from the vendor .
And lookin at other Leadtek display datasheets, 60Hz should be the
correct refresh rate.
The display is also running happily at the 69MHz of
your patch, so
Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Heiko
>
> Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> index 76ecf2de9c44..113ab9c0396b 100644
> --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> .vsync_end = 1280 + 30 + 4,
> .vtotal = 1280 + 30 + 4 + 12,
> .vrefresh = 60,
> - .clock = 41600,
> + .clock = 69217,
> .width_mm = 62,
> .height_mm = 110,
> };
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
2020-03-03 12:52 ` Heiko Stuebner
@ 2020-04-02 13:13 ` Ville Syrjälä
2020-04-02 13:20 ` Heiko Stuebner
2020-04-02 15:49 ` Sam Ravnborg
0 siblings, 2 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-04-02 13:13 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: Thierry Reding, Sam Ravnborg, dri-devel
On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> Hi,
>
> Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> The values came that way from the vendor .
> And lookin at other Leadtek display datasheets, 60Hz should be the
> correct refresh rate.
>
> The display is also running happily at the 69MHz of
> your patch, so
>
> Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Thanks for confirming.
I think this patch the last one with a huge difference between
vrefresh and clock. So once this goes in I'm thinking of declaring
the remaining patches as not important and pushing ahead with the
mode dieting. Can someone ack this so I can get it in?
> Heiko
>
> >
> > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > index 76ecf2de9c44..113ab9c0396b 100644
> > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > .vsync_end = 1280 + 30 + 4,
> > .vtotal = 1280 + 30 + 4 + 12,
> > .vrefresh = 60,
> > - .clock = 41600,
> > + .clock = 69217,
> > .width_mm = 62,
> > .height_mm = 110,
> > };
> >
>
>
>
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
2020-04-02 13:13 ` Ville Syrjälä
@ 2020-04-02 13:20 ` Heiko Stuebner
2020-04-02 15:49 ` Sam Ravnborg
1 sibling, 0 replies; 98+ messages in thread
From: Heiko Stuebner @ 2020-04-02 13:20 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Thierry Reding, Sam Ravnborg, dri-devel
Am Donnerstag, 2. April 2020, 15:13:10 CEST schrieb Ville Syrjälä:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> >
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > >
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> >
> > The values came that way from the vendor .
> > And lookin at other Leadtek display datasheets, 60Hz should be the
> > correct refresh rate.
> >
> > The display is also running happily at the 69MHz of
> > your patch, so
> >
> > Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
>
> Thanks for confirming.
>
> I think this patch the last one with a huge difference between
> vrefresh and clock. So once this goes in I'm thinking of declaring
> the remaining patches as not important and pushing ahead with the
> mode dieting. Can someone ack this so I can get it in?
hmm, not sure which one you want, so please pick one
Acked-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
or for the address I use whan applying drm-misc commits:
Acked-by: Heiko Stuebner <heiko@sntech.de>
Heiko
> > >
> > > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > index 76ecf2de9c44..113ab9c0396b 100644
> > > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > > .vsync_end = 1280 + 30 + 4,
> > > .vtotal = 1280 + 30 + 4 + 12,
> > > .vrefresh = 60,
> > > - .clock = 41600,
> > > + .clock = 69217,
> > > .width_mm = 62,
> > > .height_mm = 110,
> > > };
> > >
> >
> >
> >
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
2020-04-02 13:13 ` Ville Syrjälä
2020-04-02 13:20 ` Heiko Stuebner
@ 2020-04-02 15:49 ` Sam Ravnborg
1 sibling, 0 replies; 98+ messages in thread
From: Sam Ravnborg @ 2020-04-02 15:49 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Heiko Stuebner, Thierry Reding, dri-devel
Hi Ville.
On Thu, Apr 02, 2020 at 04:13:10PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> >
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > >
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> >
> > The values came that way from the vendor .
> > And lookin at other Leadtek display datasheets, 60Hz should be the
> > correct refresh rate.
> >
> > The display is also running happily at the 69MHz of
> > your patch, so
> >
> > Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
>
> Thanks for confirming.
>
> I think this patch the last one with a huge difference between
> vrefresh and clock. So once this goes in I'm thinking of declaring
> the remaining patches as not important and pushing ahead with the
> mode dieting. Can someone ack this so I can get it in?
You have done a very good job following up on the individual panels and
the above seems like a good plan moving forward.
So for the remaining patches:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
>
> > Heiko
> >
> > >
> > > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > index 76ecf2de9c44..113ab9c0396b 100644
> > > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > > .vsync_end = 1280 + 30 + 4,
> > > .vtotal = 1280 + 30 + 4 + 12,
> > > .vrefresh = 60,
> > > - .clock = 41600,
> > > + .clock = 69217,
> > > .width_mm = 62,
> > > .height_mm = 110,
> > > };
> > >
> >
> >
> >
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (4 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 5:24 ` Heiko Schocher
2020-03-02 20:34 ` [PATCH 07/33] drm/panel-sitronix-st7789v: " Ville Syrjala
` (27 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Heiko Schocher
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Heiko Schocher <hs@denx.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index b262b53dbd85..5907f2503755 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -197,7 +197,7 @@ static int lg4573_enable(struct drm_panel *panel)
}
static const struct drm_display_mode default_mode = {
- .clock = 27000,
+ .clock = 28341,
.hdisplay = 480,
.hsync_start = 480 + 10,
.hsync_end = 480 + 10 + 59,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock
2020-03-02 20:34 ` [PATCH 06/33] drm/panel-lg-lg4573: " Ville Syrjala
@ 2020-03-03 5:24 ` Heiko Schocher
2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Heiko Schocher @ 2020-03-03 5:24 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Thierry Reding, dri-devel
Hello Ville Syrjala,
Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
Your clock fix is correct, thanks!
>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Heiko Schocher <hs@denx.de>
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs@denx.de
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock
2020-03-03 5:24 ` Heiko Schocher
@ 2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-11 14:46 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Thierry Reding, dri-devel
On Tue, Mar 03, 2020 at 06:24:25AM +0100, Heiko Schocher wrote:
> Hello Ville Syrjala,
>
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> Your clock fix is correct, thanks!
>
> >
> > Cc: Heiko Schocher <hs@denx.de>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Heiko Schocher <hs@denx.de>
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 07/33] drm/panel-sitronix-st7789v: Fix dotclock
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (5 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 06/33] drm/panel-lg-lg4573: " Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks Ville Syrjala
` (26 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index cc02c54c1b2e..5e9d706d06a6 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -156,7 +156,7 @@ static int st7789v_write_data(struct st7789v *ctx, u8 cmd)
}
static const struct drm_display_mode default_mode = {
- .clock = 7000,
+ .clock = 6008,
.hdisplay = 240,
.hsync_start = 240 + 38,
.hsync_end = 240 + 38 + 10,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (6 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 07/33] drm/panel-sitronix-st7789v: " Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-07 14:40 ` Linus Walleij
2020-03-02 20:34 ` [PATCH 09/33] drm/panel-simple: Fix dotclock for AUO G101EVN010 Ville Syrjala
` (25 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-sony-acx424akp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
index de0abf76ae6f..c91e55b2d7a3 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
@@ -48,7 +48,7 @@ struct acx424akp {
};
static const struct drm_display_mode sony_acx424akp_vid_mode = {
- .clock = 330000,
+ .clock = 27234,
.hdisplay = 480,
.hsync_start = 480 + 15,
.hsync_end = 480 + 15 + 0,
@@ -68,7 +68,7 @@ static const struct drm_display_mode sony_acx424akp_vid_mode = {
* command mode using the maximum HS frequency.
*/
static const struct drm_display_mode sony_acx424akp_cmd_mode = {
- .clock = 420160,
+ .clock = 35478,
.hdisplay = 480,
.hsync_start = 480 + 154,
.hsync_end = 480 + 154 + 16,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks
2020-03-02 20:34 ` [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks Ville Syrjala
@ 2020-03-07 14:40 ` Linus Walleij
2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Linus Walleij @ 2020-03-07 14:40 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Sam Ravnborg, open list:DRM PANEL DRIVERS
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
These are better than what is currently in the driver
at least, we don't know the real dotclocks. (No datasheet.)
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks
2020-03-07 14:40 ` Linus Walleij
@ 2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-11 14:46 UTC (permalink / raw)
To: Linus Walleij; +Cc: Sam Ravnborg, open list:DRM PANEL DRIVERS
On Sat, Mar 07, 2020 at 03:40:11PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> These are better than what is currently in the driver
> at least, we don't know the real dotclocks. (No datasheet.)
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 09/33] drm/panel-simple: Fix dotclock for AUO G101EVN010
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (7 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2 Ville Syrjala
` (24 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Alex Gonzalez
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Alex Gonzalez <alex.gonzalez@digi.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 342d075e80c5..9782a016a157 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -827,7 +827,7 @@ static const struct panel_desc auo_g070vvn01 = {
};
static const struct drm_display_mode auo_g101evn010_mode = {
- .clock = 68930,
+ .clock = 70894,
.hdisplay = 1280,
.hsync_start = 1280 + 82,
.hsync_end = 1280 + 82 + 2,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (8 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 09/33] drm/panel-simple: Fix dotclock for AUO G101EVN010 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 13:13 ` Christoph Fritz
2020-03-02 20:34 ` [PATCH 11/33] drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7 Ville Syrjala
` (23 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Christoph Fritz, Thierry Reding, Stefan Riedmueller
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Stefan Riedmueller <s.riedmueller@phytec.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9782a016a157..8643ba7e76a6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -851,7 +851,7 @@ static const struct panel_desc auo_g101evn010 = {
};
static const struct drm_display_mode auo_g104sn02_mode = {
- .clock = 40000,
+ .clock = 45963,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 216,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2
2020-03-02 20:34 ` [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2 Ville Syrjala
@ 2020-03-03 13:13 ` Christoph Fritz
2020-03-04 12:19 ` Stefan Riedmüller
0 siblings, 1 reply; 98+ messages in thread
From: Christoph Fritz @ 2020-03-03 13:13 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: Thierry Reding, Stefan Riedmueller
On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
This display (a controller is included) has a wide tolerance range.
Adapting clock should be fine while keeping vrefresh rate at 60 Hz.
I guess an even better alternative would be to change this config to a
pixelclock describing one like the other auo panels.
But at the moment I'm not having a display here.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2
2020-03-03 13:13 ` Christoph Fritz
@ 2020-03-04 12:19 ` Stefan Riedmüller
0 siblings, 0 replies; 98+ messages in thread
From: Stefan Riedmüller @ 2020-03-04 12:19 UTC (permalink / raw)
To: chf.fritz, Ville Syrjala, dri-devel; +Cc: Thierry Reding
Hi Ville, hi Christoph,
On 03.03.20 14:13, Christoph Fritz wrote:
> On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>
>> The currently listed dotclock disagrees with the currently
>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>
>> Someone tell me which (if either) of the dotclock or vreresh is
>> correct?
The 40 MHz clock comes from the datasheet which states this as the typical
clock frequency. But the valid range reaches from 30 MHz to 50 MHz. The
datasheet also states a 60 Hz frame rate so setting the clock to the
corresponding frequency makes sense to me.
I gave it a little test here and both values work for me.
Regards,
Stefan
>
> This display (a controller is included) has a wide tolerance range.
>
> Adapting clock should be fine while keeping vrefresh rate at 60 Hz.
>
> I guess an even better alternative would be to change this config to a
> pixelclock describing one like the other auo panels.
>
> But at the moment I'm not having a display here.
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 11/33] drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (9 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 12/33] drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16 Ville Syrjala
` (22 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Giulio Benetti
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8643ba7e76a6..d2980485d0c5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1136,7 +1136,7 @@ static const struct panel_desc boe_nv140fhmn49 = {
};
static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
- .clock = 9000,
+ .clock = 9413,
.hdisplay = 480,
.hsync_start = 480 + 5,
.hsync_end = 480 + 5 + 5,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 12/33] drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (10 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 11/33] drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 13/33] drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG Ville Syrjala
` (21 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Giulio Benetti
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d2980485d0c5..9b19ffb23755 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1161,7 +1161,7 @@ static const struct panel_desc cdtech_s043wq26h_ct7 = {
};
static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
- .clock = 35000,
+ .clock = 29232,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 40,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 13/33] drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (11 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 12/33] drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 14/33] drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA Ville Syrjala
` (20 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Randy Li
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Randy Li <ayaka@soulik.info>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9b19ffb23755..6ad38b6a3950 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1185,7 +1185,7 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
};
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
- .clock = 66770,
+ .clock = 70284,
.hdisplay = 800,
.hsync_start = 800 + 49,
.hsync_end = 800 + 49 + 33,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 14/33] drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (12 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 13/33] drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6 Ville Syrjala
` (19 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 6ad38b6a3950..93e5bc32fb59 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1232,7 +1232,7 @@ static const struct panel_desc chunghwa_claa101wa01a = {
};
static const struct drm_display_mode chunghwa_claa101wb01_mode = {
- .clock = 69300,
+ .clock = 71072,
.hdisplay = 1366,
.hsync_start = 1366 + 48,
.hsync_end = 1366 + 48 + 32,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (13 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 14/33] drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 7:33 ` Marco Felsch
2020-03-02 20:34 ` [PATCH 16/33] drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP Ville Syrjala
` (18 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Andreas Pretzsch, Marco Felsch
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Andreas Pretzsch <apr@cn-eng.de>
Cc: Marco Felsch <m.felsch@pengutronix.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 93e5bc32fb59..35750229189f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
};
static const struct drm_display_mode edt_et035012dm6_mode = {
- .clock = 6500,
+ .clock = 6414,
.hdisplay = 320,
.hsync_start = 320 + 20,
.hsync_end = 320 + 20 + 30,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-02 20:34 ` [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6 Ville Syrjala
@ 2020-03-03 7:33 ` Marco Felsch
2020-03-03 14:52 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Marco Felsch @ 2020-03-03 7:33 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
Hi Ville,
On 20-03-02 22:34, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
Pls, check the datasheet which is linked within the comment. We hit the
vrefresh exactly if we are in SYNC MODE.
Regards,
Marco
> Cc: Andreas Pretzsch <apr@cn-eng.de>
> Cc: Marco Felsch <m.felsch@pengutronix.de>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 93e5bc32fb59..35750229189f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
> };
>
> static const struct drm_display_mode edt_et035012dm6_mode = {
> - .clock = 6500,
> + .clock = 6414,
> .hdisplay = 320,
> .hsync_start = 320 + 20,
> .hsync_end = 320 + 20 + 30,
> --
> 2.24.1
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-03 7:33 ` Marco Felsch
@ 2020-03-03 14:52 ` Ville Syrjälä
2020-03-06 8:02 ` Marco Felsch
0 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 14:52 UTC (permalink / raw)
To: Marco Felsch; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> Hi Ville,
>
> On 20-03-02 22:34, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> Pls, check the datasheet which is linked within the comment. We hit the
> vrefresh exactly if we are in SYNC MODE.
It's too much work to start hunting datasheets for all these
and figuring out what's going on in each case. Pls just
inform me which way is correct if you know the details.
>
> Regards,
> Marco
>
> > Cc: Andreas Pretzsch <apr@cn-eng.de>
> > Cc: Marco Felsch <m.felsch@pengutronix.de>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 93e5bc32fb59..35750229189f 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
> > };
> >
> > static const struct drm_display_mode edt_et035012dm6_mode = {
> > - .clock = 6500,
> > + .clock = 6414,
> > .hdisplay = 320,
> > .hsync_start = 320 + 20,
> > .hsync_end = 320 + 20 + 30,
> > --
> > 2.24.1
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-03 14:52 ` Ville Syrjälä
@ 2020-03-06 8:02 ` Marco Felsch
2020-03-09 13:18 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Marco Felsch @ 2020-03-06 8:02 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
On 20-03-03 16:52, Ville Syrjälä wrote:
> On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > Hi Ville,
> >
> > On 20-03-02 22:34, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > >
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> >
> > Pls, check the datasheet which is linked within the comment. We hit the
> > vrefresh exactly if we are in SYNC MODE.
>
> It's too much work to start hunting datasheets for all these
> and figuring out what's going on in each case. Pls just
> inform me which way is correct if you know the details.
How do you know that the clock is wrong if it is to much work? As I said
the clock is completely fine.
Regards,
Marco
> >
> > Regards,
> > Marco
> >
> > > Cc: Andreas Pretzsch <apr@cn-eng.de>
> > > Cc: Marco Felsch <m.felsch@pengutronix.de>
> > > Cc: Thierry Reding <treding@nvidia.com>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > index 93e5bc32fb59..35750229189f 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
> > > };
> > >
> > > static const struct drm_display_mode edt_et035012dm6_mode = {
> > > - .clock = 6500,
> > > + .clock = 6414,
> > > .hdisplay = 320,
> > > .hsync_start = 320 + 20,
> > > .hsync_end = 320 + 20 + 30,
> > > --
> > > 2.24.1
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
> --
> Ville Syrjälä
> Intel
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-06 8:02 ` Marco Felsch
@ 2020-03-09 13:18 ` Ville Syrjälä
2020-03-10 7:05 ` Marco Felsch
0 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-09 13:18 UTC (permalink / raw)
To: Marco Felsch; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> On 20-03-03 16:52, Ville Syrjälä wrote:
> > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > Hi Ville,
> > >
> > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > The currently listed dotclock disagrees with the currently
> > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > >
> > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > correct?
> > >
> > > Pls, check the datasheet which is linked within the comment. We hit the
> > > vrefresh exactly if we are in SYNC MODE.
> >
> > It's too much work to start hunting datasheets for all these
> > and figuring out what's going on in each case. Pls just
> > inform me which way is correct if you know the details.
>
> How do you know that the clock is wrong if it is to much work? As I said
> the clock is completely fine.
htotal*vtotal*vrefresh != clock, so one or both are incorrect.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-09 13:18 ` Ville Syrjälä
@ 2020-03-10 7:05 ` Marco Felsch
2020-03-10 12:04 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Marco Felsch @ 2020-03-10 7:05 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
On 20-03-09 15:18, Ville Syrjälä wrote:
> On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> > On 20-03-03 16:52, Ville Syrjälä wrote:
> > > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > > Hi Ville,
> > > >
> > > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > >
> > > > > The currently listed dotclock disagrees with the currently
> > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > >
> > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > correct?
> > > >
> > > > Pls, check the datasheet which is linked within the comment. We hit the
> > > > vrefresh exactly if we are in SYNC MODE.
> > >
> > > It's too much work to start hunting datasheets for all these
> > > and figuring out what's going on in each case. Pls just
> > > inform me which way is correct if you know the details.
> >
> > How do you know that the clock is wrong if it is to much work? As I said
> > the clock is completely fine.
>
> htotal*vtotal*vrefresh != clock, so one or both are incorrect.
I checked the values using this equation:
clock / (htotal * vtotal) = vrefresh.
Regards,
Marco
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6
2020-03-10 7:05 ` Marco Felsch
@ 2020-03-10 12:04 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-10 12:04 UTC (permalink / raw)
To: Marco Felsch; +Cc: Thierry Reding, Andreas Pretzsch, dri-devel
On Tue, Mar 10, 2020 at 08:05:32AM +0100, Marco Felsch wrote:
> On 20-03-09 15:18, Ville Syrjälä wrote:
> > On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> > > On 20-03-03 16:52, Ville Syrjälä wrote:
> > > > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > > > Hi Ville,
> > > > >
> > > > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > >
> > > > > > The currently listed dotclock disagrees with the currently
> > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > >
> > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > correct?
> > > > >
> > > > > Pls, check the datasheet which is linked within the comment. We hit the
> > > > > vrefresh exactly if we are in SYNC MODE.
> > > >
> > > > It's too much work to start hunting datasheets for all these
> > > > and figuring out what's going on in each case. Pls just
> > > > inform me which way is correct if you know the details.
> > >
> > > How do you know that the clock is wrong if it is to much work? As I said
> > > the clock is completely fine.
> >
> > htotal*vtotal*vrefresh != clock, so one or both are incorrect.
>
> I checked the values using this equation:
> clock / (htotal * vtotal) = vrefresh.
I guess you truncated instead of rounding to nearest. With round to
nearest we get vrefresh=61. The actual number being 60.8...
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 16/33] drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (14 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 17/33] drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T Ville Syrjala
` (17 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg, Marian-Cristian Rotariu, Lad Prabhakar
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 35750229189f..357b8578a62f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1368,7 +1368,7 @@ static const struct panel_desc edt_et035012dm6 = {
};
static const struct drm_display_mode edt_etm043080dh6gp_mode = {
- .clock = 10870,
+ .clock = 9722,
.hdisplay = 480,
.hsync_start = 480 + 8,
.hsync_end = 480 + 8 + 4,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 17/33] drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (15 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 16/33] drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 18/33] drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5 Ville Syrjala
` (16 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Boris Brezillon
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 357b8578a62f..baccf407222c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1514,7 +1514,7 @@ static const struct panel_desc evervision_vgg804821 = {
};
static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
- .clock = 32260,
+ .clock = 35414,
.hdisplay = 800,
.hsync_start = 800 + 168,
.hsync_end = 800 + 168 + 64,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 18/33] drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (16 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 17/33] drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 19/33] drm/panel-simple: Fix dotclock for Innolux AT070TN92 Ville Syrjala
` (15 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index baccf407222c..3e98dbfc31c4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1588,7 +1588,7 @@ static const struct panel_desc friendlyarm_hd702e = {
};
static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
- .clock = 9000,
+ .clock = 9121,
.hdisplay = 480,
.hsync_start = 480 + 5,
.hsync_end = 480 + 5 + 1,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 19/33] drm/panel-simple: Fix dotclock for Innolux AT070TN92
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (17 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 18/33] drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 20/33] drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD Ville Syrjala
` (14 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Boris Brezillon, Thierry Reding, Riccardo Bortolato
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Riccardo Bortolato <bortolato@navaltechitalia.it>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3e98dbfc31c4..8daec89eed5c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1745,7 +1745,7 @@ static const struct panel_desc innolux_at043tn24 = {
};
static const struct drm_display_mode innolux_at070tn92_mode = {
- .clock = 33333,
+ .clock = 34540,
.hdisplay = 800,
.hsync_start = 800 + 210,
.hsync_end = 800 + 210 + 20,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 20/33] drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (18 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 19/33] drm/panel-simple: Fix dotclock for Innolux AT070TN92 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28 Ville Syrjala
` (13 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Paul Kocialkowski
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Paul Kocialkowski <contact@paulk.fr>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8daec89eed5c..225be4757a85 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2065,7 +2065,7 @@ static const struct panel_desc kyo_tcg121xglp = {
};
static const struct drm_display_mode lemaker_bl035_rgb_002_mode = {
- .clock = 7000,
+ .clock = 6414,
.hdisplay = 320,
.hsync_start = 320 + 20,
.hsync_end = 320 + 20 + 30,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (19 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 20/33] drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-03 13:00 ` Adam Ford
2020-03-02 20:34 ` [PATCH 22/33] drm/panel-simple: Fix dotclock for Netron DY E231732 Ville Syrjala
` (12 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg, Adam Ford
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Adam Ford <aford173@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 225be4757a85..3a46b82722f5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
};
static const struct drm_display_mode logicpd_type_28_mode = {
- .clock = 9000,
+ .clock = 9107,
.hdisplay = 480,
.hsync_start = 480 + 3,
.hsync_end = 480 + 3 + 42,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28
2020-03-02 20:34 ` [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28 Ville Syrjala
@ 2020-03-03 13:00 ` Adam Ford
2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Adam Ford @ 2020-03-03 13:00 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Sam Ravnborg, dri-devel
On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 225be4757a85..3a46b82722f5 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
> };
>
> static const struct drm_display_mode logicpd_type_28_mode = {
> - .clock = 9000,
> + .clock = 9107,
This should be OK. The max dotclk frequency of this panel is 12MHz,
so 9.107MHz should be just fine.
Reviewed-by: Adam Ford <aford173@gmail.com>
adam
> .hdisplay = 480,
> .hsync_start = 480 + 3,
> .hsync_end = 480 + 3 + 42,
> --
> 2.24.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28
2020-03-03 13:00 ` Adam Ford
@ 2020-03-11 14:46 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-11 14:46 UTC (permalink / raw)
To: Adam Ford; +Cc: Sam Ravnborg, dri-devel
On Tue, Mar 03, 2020 at 07:00:12AM -0600, Adam Ford wrote:
> On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Adam Ford <aford173@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 225be4757a85..3a46b82722f5 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
> > };
> >
> > static const struct drm_display_mode logicpd_type_28_mode = {
> > - .clock = 9000,
> > + .clock = 9107,
>
> This should be OK. The max dotclk frequency of this panel is 12MHz,
> so 9.107MHz should be just fine.
>
> Reviewed-by: Adam Ford <aford173@gmail.com>
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 22/33] drm/panel-simple: Fix dotclock for Netron DY E231732
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (20 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 23/33] drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI TFT Ville Syrjala
` (11 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3a46b82722f5..0ac74c625f8e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2384,7 +2384,7 @@ static const struct panel_desc nec_nl4827hc19_05b = {
};
static const struct drm_display_mode netron_dy_e231732_mode = {
- .clock = 66000,
+ .clock = 60480,
.hdisplay = 1024,
.hsync_start = 1024 + 160,
.hsync_end = 1024 + 160 + 70,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 23/33] drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI TFT
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (21 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 22/33] drm/panel-simple: Fix dotclock for Netron DY E231732 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M Ville Syrjala
` (10 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 0ac74c625f8e..ca72b73408e9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2588,7 +2588,7 @@ static const struct panel_desc olimex_lcd_olinuxino_43ts = {
* installation instructions.
*/
static const struct drm_display_mode ontat_yx700wv03_mode = {
- .clock = 29500,
+ .clock = 29760,
.hdisplay = 800,
.hsync_start = 824,
.hsync_end = 896,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (22 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 23/33] drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI TFT Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 21:24 ` H. Nikolaus Schaller
2020-03-02 20:34 ` [PATCH 25/33] drm/panel-simple: Fix dotclock for PDA 91-00156-A0 Ville Syrjala
` (9 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: H . Nikolaus Schaller, Sam Ravnborg
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index ca72b73408e9..f9b4f84bffb3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
};
static const struct drm_display_mode ortustech_com37h3m_mode = {
- .clock = 22153,
+ .clock = 19842,
.hdisplay = 480,
.hsync_start = 480 + 8,
.hsync_end = 480 + 8 + 10,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-02 20:34 ` [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M Ville Syrjala
@ 2020-03-02 21:24 ` H. Nikolaus Schaller
2020-03-03 15:03 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: H. Nikolaus Schaller @ 2020-03-02 21:24 UTC (permalink / raw)
To: Ville Syrjala
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
Hi Ville,
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala <ville.syrjala@linux.intel.com>:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
Data sheet of COM37H3M99DTC says:
MIN TYP MAX
CLK frequency fCLK 18 19.8 27 MHz
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv 646 650 700 H
HSYNC frequency fHSYNC -- 39.0 50.0 Khz
HSYNC cycle time th 504 508 630 CLK
But data sheet of COM37H3M05DTC says
MIN TYP MAX
CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode - there is also an QVGA mode)
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv -- 650 -- H
HSYNC frequency fHSYNC -- 39.3 -- Khz
HSYNC cycle time th -- 570 -- CLK
So there are two different subvariants of the same panel.
If I remember correctly, the 05 is older (April 2010)
and the 99DTC newer (Dec 2011).
So 22 MHz isn't outside of either spec but may be higher
than needed for the 99DTC. I.e. the panel is probably
running at higher frame rate than 60 fps.
Hm. I think we should define some compromise. I.e.
.clock = 22230
.vrefresh = 60
.vtotal = 650
.htotal = 570
Probably we originally tried to do this with the parameter
set but got something wrong.
If you agree with this approach, I can try to figure out
the other parameters so that they should fit both panel
variants. I can only test with COM37H3M99DTC since I
do no longer have a device with COM37H3M05DTC.
In general it seems that the structure drm_display_mode
is overdetermined.
Either .clock could be calculated from .vrefresh (and
the other .vtotal and .htotal) or vice versa like I
did for the proposal above.
I haven't looked into the driver code, but would it be
possible to specify .clock = 0 (or leave it out) to
calculate it bottom up? This would avoid such inconsistencies.
On the other hand it is not easily visible any more
from the code if the clock is in range of the data
sheet limits.
BR and thanks,
Nikolaus
>
> Cc: H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index ca72b73408e9..f9b4f84bffb3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
> };
>
> static const struct drm_display_mode ortustech_com37h3m_mode = {
> - .clock = 22153,
> + .clock = 19842,
> .hdisplay = 480,
> .hsync_start = 480 + 8,
> .hsync_end = 480 + 8 + 10,
> --
> 2.24.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-02 21:24 ` H. Nikolaus Schaller
@ 2020-03-03 15:03 ` Ville Syrjälä
2020-03-03 15:49 ` H. Nikolaus Schaller
0 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 15:03 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
On Mon, Mar 02, 2020 at 10:24:14PM +0100, H. Nikolaus Schaller wrote:
> Hi Ville,
>
> > Am 02.03.2020 um 21:34 schrieb Ville Syrjala <ville.syrjala@linux.intel.com>:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> Data sheet of COM37H3M99DTC says:
>
> MIN TYP MAX
> CLK frequency fCLK 18 19.8 27 MHz
> VSYNC Frequency fVSYNC 54 60 66 Hz
> VSYNC cycle time tv 646 650 700 H
> HSYNC frequency fHSYNC -- 39.0 50.0 Khz
> HSYNC cycle time th 504 508 630 CLK
>
> But data sheet of COM37H3M05DTC says
>
> MIN TYP MAX
> CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode - there is also an QVGA mode)
> VSYNC Frequency fVSYNC 54 60 66 Hz
> VSYNC cycle time tv -- 650 -- H
> HSYNC frequency fHSYNC -- 39.3 -- Khz
> HSYNC cycle time th -- 570 -- CLK
>
> So there are two different subvariants of the same panel.
>
> If I remember correctly, the 05 is older (April 2010)
> and the 99DTC newer (Dec 2011).
>
> So 22 MHz isn't outside of either spec but may be higher
> than needed for the 99DTC. I.e. the panel is probably
> running at higher frame rate than 60 fps.
>
> Hm. I think we should define some compromise. I.e.
>
> .clock = 22230
> .vrefresh = 60
> .vtotal = 650
> .htotal = 570
>
> Probably we originally tried to do this with the parameter
> set but got something wrong.
>
> If you agree with this approach, I can try to figure out
> the other parameters so that they should fit both panel
> variants. I can only test with COM37H3M99DTC since I
> do no longer have a device with COM37H3M05DTC.
>
> In general it seems that the structure drm_display_mode
> is overdetermined.
>
> Either .clock could be calculated from .vrefresh (and
> the other .vtotal and .htotal) or vice versa like I
> did for the proposal above.
>
> I haven't looked into the driver code, but would it be
> possible to specify .clock = 0 (or leave it out) to
> calculate it bottom up? This would avoid such inconsistencies.
I'm going to remove .vrefresh entirely from the struct.
It'll just be calculated from the other timings as needed.
>
> On the other hand it is not easily visible any more
> from the code if the clock is in range of the data
> sheet limits.
>
> BR and thanks,
> Nikolaus
>
> >
> > Cc: H. Nikolaus Schaller <hns@goldelico.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index ca72b73408e9..f9b4f84bffb3 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
> > };
> >
> > static const struct drm_display_mode ortustech_com37h3m_mode = {
> > - .clock = 22153,
> > + .clock = 19842,
> > .hdisplay = 480,
> > .hsync_start = 480 + 8,
> > .hsync_end = 480 + 8 + 10,
> > --
> > 2.24.1
> >
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-03 15:03 ` Ville Syrjälä
@ 2020-03-03 15:49 ` H. Nikolaus Schaller
2020-03-05 19:41 ` H. Nikolaus Schaller
0 siblings, 1 reply; 98+ messages in thread
From: H. Nikolaus Schaller @ 2020-03-03 15:49 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
Hi,
> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>
>> I haven't looked into the driver code, but would it be
>> possible to specify .clock = 0 (or leave it out) to
>> calculate it bottom up? This would avoid such inconsistencies.
>
> I'm going to remove .vrefresh entirely from the struct.
> It'll just be calculated from the other timings as needed.
Ok!
Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
I'll give it a try and let you know.
BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-03 15:49 ` H. Nikolaus Schaller
@ 2020-03-05 19:41 ` H. Nikolaus Schaller
2020-03-09 13:00 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: H. Nikolaus Schaller @ 2020-03-05 19:41 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
> Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi,
>
>> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>>
>>> I haven't looked into the driver code, but would it be
>>> possible to specify .clock = 0 (or leave it out) to
>>> calculate it bottom up? This would avoid such inconsistencies.
>>
>> I'm going to remove .vrefresh entirely from the struct.
>> It'll just be calculated from the other timings as needed.
>
> Ok!
>
> Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
>
> I'll give it a try and let you know.
Ok, here is a new parameter set within data sheet limits for both
panel variants:
static const struct drm_display_mode ortustech_com37h3m_mode = {
.clock = 22153,
.hdisplay = 480,
.hsync_start = 480 + 40,
.hsync_end = 480 + 40 + 10,
.htotal = 480 + 40 + 10 + 40,
.vdisplay = 640,
.vsync_start = 640 + 4,
.vsync_end = 640 + 4 + 2,
.vtotal = 640 + 4 + 2 + 4,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
};
I have tested on our omap3 based board and didn't find an issue
so you can insert into your patch.
BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-05 19:41 ` H. Nikolaus Schaller
@ 2020-03-09 13:00 ` Ville Syrjälä
2020-03-09 13:03 ` H. Nikolaus Schaller
0 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-09 13:00 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
>
> > Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > Hi,
> >
> >> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
> >>
> >>> I haven't looked into the driver code, but would it be
> >>> possible to specify .clock = 0 (or leave it out) to
> >>> calculate it bottom up? This would avoid such inconsistencies.
> >>
> >> I'm going to remove .vrefresh entirely from the struct.
> >> It'll just be calculated from the other timings as needed.
> >
> > Ok!
> >
> > Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
> >
> > I'll give it a try and let you know.
>
> Ok, here is a new parameter set within data sheet limits for both
> panel variants:
>
> static const struct drm_display_mode ortustech_com37h3m_mode = {
> .clock = 22153,
> .hdisplay = 480,
> .hsync_start = 480 + 40,
> .hsync_end = 480 + 40 + 10,
> .htotal = 480 + 40 + 10 + 40,
> .vdisplay = 640,
> .vsync_start = 640 + 4,
> .vsync_end = 640 + 4 + 2,
> .vtotal = 640 + 4 + 2 + 4,
> .vrefresh = 60,
> .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> };
>
> I have tested on our omap3 based board and didn't find an issue
> so you can insert into your patch.
Migth be better if you send that so we get proper attribution and
you can explain the change properly in the commit message.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
2020-03-09 13:00 ` Ville Syrjälä
@ 2020-03-09 13:03 ` H. Nikolaus Schaller
0 siblings, 0 replies; 98+ messages in thread
From: H. Nikolaus Schaller @ 2020-03-09 13:03 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Discussions about the Letux Kernel, Sam Ravnborg,
open list:DRM PANEL DRIVERS
> Am 09.03.2020 um 14:00 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>
> On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
>>
>>> Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>
>>> Hi,
>>>
>>>> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>>>>
>>>>> I haven't looked into the driver code, but would it be
>>>>> possible to specify .clock = 0 (or leave it out) to
>>>>> calculate it bottom up? This would avoid such inconsistencies.
>>>>
>>>> I'm going to remove .vrefresh entirely from the struct.
>>>> It'll just be calculated from the other timings as needed.
>>>
>>> Ok!
>>>
>>> Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
>>>
>>> I'll give it a try and let you know.
>>
>> Ok, here is a new parameter set within data sheet limits for both
>> panel variants:
>>
>> static const struct drm_display_mode ortustech_com37h3m_mode = {
>> .clock = 22153,
>> .hdisplay = 480,
>> .hsync_start = 480 + 40,
>> .hsync_end = 480 + 40 + 10,
>> .htotal = 480 + 40 + 10 + 40,
>> .vdisplay = 640,
>> .vsync_start = 640 + 4,
>> .vsync_end = 640 + 4 + 2,
>> .vtotal = 640 + 4 + 2 + 4,
>> .vrefresh = 60,
>> .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
>> };
>>
>> I have tested on our omap3 based board and didn't find an issue
>> so you can insert into your patch.
>
> Migth be better if you send that so we get proper attribution and
> you can explain the change properly in the commit message.
Ok, will do asap.
BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 25/33] drm/panel-simple: Fix dotclock for PDA 91-00156-A0
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (23 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 26/33] drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40 Ville Syrjala
` (8 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Eugen Hristev, Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f9b4f84bffb3..f02b510dabf7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2697,7 +2697,7 @@ static const struct panel_desc osddisplays_osd070t1718_19ts = {
};
static const struct drm_display_mode pda_91_00156_a0_mode = {
- .clock = 33300,
+ .clock = 29319,
.hdisplay = 800,
.hsync_start = 800 + 1,
.hsync_end = 800 + 1 + 64,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 26/33] drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (24 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 25/33] drm/panel-simple: Fix dotclock for PDA 91-00156-A0 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03 Ville Syrjala
` (7 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Josh Wu, Thierry Reding, Alexandre Belloni
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Josh Wu <josh.wu@atmel.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f02b510dabf7..3012b47c1e4e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2721,7 +2721,7 @@ static const struct panel_desc pda_91_00156_a0 = {
static const struct drm_display_mode qd43003c0_40_mode = {
- .clock = 9000,
+ .clock = 9176,
.hdisplay = 480,
.hsync_start = 480 + 8,
.hsync_end = 480 + 8 + 4,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (25 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 26/33] drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 21:40 ` Vladimir Zapolskiy
2020-03-02 20:34 ` [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11 Ville Syrjala
` (6 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Vladimir Zapolskiy
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3012b47c1e4e..7526af2d6d95 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
};
static const struct drm_display_mode sharp_lq035q7db03_mode = {
- .clock = 5500,
+ .clock = 5419,
.hdisplay = 240,
.hsync_start = 240 + 16,
.hsync_end = 240 + 16 + 7,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03
2020-03-02 20:34 ` [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03 Ville Syrjala
@ 2020-03-02 21:40 ` Vladimir Zapolskiy
2020-03-03 14:49 ` Ville Syrjälä
0 siblings, 1 reply; 98+ messages in thread
From: Vladimir Zapolskiy @ 2020-03-02 21:40 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: Thierry Reding
Hi Ville,
On 3/2/20 10:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
yes, I will tell you, see my answer below.
Adding Linus as a person who may be interested in PL111 specifics.
> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 3012b47c1e4e..7526af2d6d95 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
> };
>
> static const struct drm_display_mode sharp_lq035q7db03_mode = {
> - .clock = 5500,
> + .clock = 5419,
> .hdisplay = 240,
> .hsync_start = 240 + 16,
> .hsync_end = 240 + 16 + 7,
>
Here .clock is correct, you may find the usage of the panel in
lpc3250-phy3250.dts example, and the PL111 controller on the SoC
won't be able to provide the exactly computed `.clock = 5419'.
So, I have to NAK this change, in this example the difference
between the declared and the computed .vreresh is one Hz, which
I hope can be accepted as negligible and ignorable, otherwise,
if you insist, please correct the .vrefresh from 60 to 61.
--
Best wishes,
Vladimir
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03
2020-03-02 21:40 ` Vladimir Zapolskiy
@ 2020-03-03 14:49 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 14:49 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Thierry Reding, dri-devel
On Mon, Mar 02, 2020 at 11:40:07PM +0200, Vladimir Zapolskiy wrote:
> Hi Ville,
>
> On 3/2/20 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> yes, I will tell you, see my answer below.
>
> Adding Linus as a person who may be interested in PL111 specifics.
>
> > Cc: Vladimir Zapolskiy <vz@mleia.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 3012b47c1e4e..7526af2d6d95 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
> > };
> >
> > static const struct drm_display_mode sharp_lq035q7db03_mode = {
> > - .clock = 5500,
> > + .clock = 5419,
> > .hdisplay = 240,
> > .hsync_start = 240 + 16,
> > .hsync_end = 240 + 16 + 7,
> >
>
> Here .clock is correct, you may find the usage of the panel in
> lpc3250-phy3250.dts example, and the PL111 controller on the SoC
> won't be able to provide the exactly computed `.clock = 5419'.
OK, I'll drop this one.
>
> So, I have to NAK this change, in this example the difference
> between the declared and the computed .vreresh is one Hz, which
> I hope can be accepted as negligible and ignorable, otherwise,
> if you insist, please correct the .vrefresh from 60 to 61.
I'm going to nuke .vrefresh entirely.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (26 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 22:53 ` Peter Rosin
2020-03-02 20:34 ` [PATCH 29/33] drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN Ville Syrjala
` (5 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Gustaf Lindström, Thierry Reding, Peter Rosin
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Gustaf Lindström <gl@axentia.se>
Cc: Peter Rosin <peda@axentia.se>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 7526af2d6d95..cb587de8c49e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3026,7 +3026,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
};
static const struct drm_display_mode sharp_lq150x1lg11_mode = {
- .clock = 71100,
+ .clock = 65722,
.hdisplay = 1024,
.hsync_start = 1024 + 168,
.hsync_end = 1024 + 168 + 64,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-02 20:34 ` [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11 Ville Syrjala
@ 2020-03-02 22:53 ` Peter Rosin
2020-03-03 14:20 ` Thierry Reding
0 siblings, 1 reply; 98+ messages in thread
From: Peter Rosin @ 2020-03-02 22:53 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: Gustaf Lindström, Thierry Reding
On 2020-03-02 21:34, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
TL/DR; I do not care if you change the refresh rate or the dotclock.
The whole entry for that panel in simple-panel is dubious. The panel
is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
data channel and use the panel with RGB666. In either case, you need
an LVDS signal and nothing else...
The panel can also rotate the picture 180 degrees using the RL/UD pin.
These options are of course not expressed in the simple panel driver
(and we have always used fixed signals for those pins in our designs,
IIRC). As far as I'm concerned, the panel can be removed from
simple-panel. Our device trees are nowadays correctly expressing the
hardware with an LVDS encoder between the RGB output and the panel
and points to the panel-lvds driver for the panel.
The reason that it is as it is, is that we obviously didn't understand
what we were doing when we added the entry, and this garbage was what
we came up with that produced a picture.
If you want to keep the panel in simple-panel despite all this, the
timing constraints are as follows:
Pixel clock 50-80 MHz, 65 MHz typical
Horizontal period 1094-1720 clocks, 1344 typical
16.0-23.4 us 20.7 us
Horizontal enable 1024 clocks, always
Vertical period 776-990 lines, 806 typical
13.3-18.0 ms 16.7 ms
Vertical enable 768 lines, always
Using a "long" (the datasheet is not very specific on this issue) vertical
period may introduce deterioration of display quality, flicker etc.
I don't think the division between front-porch/back-porch matters much.
That said, I have no idea whatsoever if others have started using this
panel entry. My guess is that it has zero users, but who can tell?
Cheers,
Peter
> Cc: Gustaf Lindström <gl@axentia.se>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 7526af2d6d95..cb587de8c49e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3026,7 +3026,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
> };
>
> static const struct drm_display_mode sharp_lq150x1lg11_mode = {
> - .clock = 71100,
> + .clock = 65722,
> .hdisplay = 1024,
> .hsync_start = 1024 + 168,
> .hsync_end = 1024 + 168 + 64,
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-02 22:53 ` Peter Rosin
@ 2020-03-03 14:20 ` Thierry Reding
2020-03-03 14:57 ` Peter Rosin
0 siblings, 1 reply; 98+ messages in thread
From: Thierry Reding @ 2020-03-03 14:20 UTC (permalink / raw)
To: Peter Rosin; +Cc: Gustaf Lindström, Thierry Reding, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 2727 bytes --]
On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
> On 2020-03-02 21:34, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
>
> TL/DR; I do not care if you change the refresh rate or the dotclock.
>
> The whole entry for that panel in simple-panel is dubious. The panel
> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
> with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
> data channel and use the panel with RGB666. In either case, you need
> an LVDS signal and nothing else...
>
> The panel can also rotate the picture 180 degrees using the RL/UD pin.
>
> These options are of course not expressed in the simple panel driver
> (and we have always used fixed signals for those pins in our designs,
> IIRC). As far as I'm concerned, the panel can be removed from
> simple-panel. Our device trees are nowadays correctly expressing the
> hardware with an LVDS encoder between the RGB output and the panel
> and points to the panel-lvds driver for the panel.
How do you make sure that you always bind against the correct driver? If
it matches simple-panel and panel-lvds, it's not deterministically going
to pick the right one. Well, it may actually be deterministic on Linux,
but perhaps only by accident.
> The reason that it is as it is, is that we obviously didn't understand
> what we were doing when we added the entry, and this garbage was what
> we came up with that produced a picture.
>
> If you want to keep the panel in simple-panel despite all this, the
> timing constraints are as follows:
>
> Pixel clock 50-80 MHz, 65 MHz typical
> Horizontal period 1094-1720 clocks, 1344 typical
> 16.0-23.4 us 20.7 us
> Horizontal enable 1024 clocks, always
> Vertical period 776-990 lines, 806 typical
> 13.3-18.0 ms 16.7 ms
> Vertical enable 768 lines, always
>
> Using a "long" (the datasheet is not very specific on this issue) vertical
> period may introduce deterioration of display quality, flicker etc.
>
> I don't think the division between front-porch/back-porch matters much.
>
> That said, I have no idea whatsoever if others have started using this
> panel entry. My guess is that it has zero users, but who can tell?
A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
the only device tree that uses this panel in the upstream kernel.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-03 14:20 ` Thierry Reding
@ 2020-03-03 14:57 ` Peter Rosin
2020-03-03 15:05 ` Thierry Reding
2020-03-04 17:25 ` Sam Ravnborg
0 siblings, 2 replies; 98+ messages in thread
From: Peter Rosin @ 2020-03-03 14:57 UTC (permalink / raw)
To: Thierry Reding; +Cc: Thierry Reding, dri-devel
On 2020-03-03 15:20, Thierry Reding wrote:
> On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The currently listed dotclock disagrees with the currently
>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>
>>> Someone tell me which (if either) of the dotclock or vreresh is
>>> correct?
>>
>> TL/DR; I do not care if you change the refresh rate or the dotclock.
>>
>> The whole entry for that panel in simple-panel is dubious. The panel
>> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
>> with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
>> data channel and use the panel with RGB666. In either case, you need
>> an LVDS signal and nothing else...
>>
>> The panel can also rotate the picture 180 degrees using the RL/UD pin.
>>
>> These options are of course not expressed in the simple panel driver
>> (and we have always used fixed signals for those pins in our designs,
>> IIRC). As far as I'm concerned, the panel can be removed from
>> simple-panel. Our device trees are nowadays correctly expressing the
>> hardware with an LVDS encoder between the RGB output and the panel
>> and points to the panel-lvds driver for the panel.
>
> How do you make sure that you always bind against the correct driver? If
> it matches simple-panel and panel-lvds, it's not deterministically going
> to pick the right one. Well, it may actually be deterministic on Linux,
> but perhaps only by accident.
You are probably right that it's fragile, but no problems so far. That
said, I did wonder why the panel-lvds driver "wins" over simple-panel for
compatible = "sharp,lq150x1lg11", "panel-lvds";
I figured it was by design and didn't spend too much time thinking about
it. Maybe I should have?
>> The reason that it is as it is, is that we obviously didn't understand
>> what we were doing when we added the entry, and this garbage was what
>> we came up with that produced a picture.
>>
>> If you want to keep the panel in simple-panel despite all this, the
>> timing constraints are as follows:
>>
>> Pixel clock 50-80 MHz, 65 MHz typical
>> Horizontal period 1094-1720 clocks, 1344 typical
>> 16.0-23.4 us 20.7 us
>> Horizontal enable 1024 clocks, always
>> Vertical period 776-990 lines, 806 typical
>> 13.3-18.0 ms 16.7 ms
>> Vertical enable 768 lines, always
>>
>> Using a "long" (the datasheet is not very specific on this issue) vertical
>> period may introduce deterioration of display quality, flicker etc.
>>
>> I don't think the division between front-porch/back-porch matters much.
>>
>> That said, I have no idea whatsoever if others have started using this
>> panel entry. My guess is that it has zero users, but who can tell?
>
> A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
> the only device tree that uses this panel in the upstream kernel.
This is our design, and what made us originally add the entry to simple
panel, but as I said, we no longer need simple-panel support for it...
Cheers,
Peter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-03 14:57 ` Peter Rosin
@ 2020-03-03 15:05 ` Thierry Reding
2020-03-03 15:16 ` Peter Rosin
2020-03-04 17:25 ` Sam Ravnborg
1 sibling, 1 reply; 98+ messages in thread
From: Thierry Reding @ 2020-03-03 15:05 UTC (permalink / raw)
To: Peter Rosin; +Cc: Thierry Reding, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 2268 bytes --]
On Tue, Mar 03, 2020 at 02:57:45PM +0000, Peter Rosin wrote:
>
> On 2020-03-03 15:20, Thierry Reding wrote:
> > On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
> >> On 2020-03-02 21:34, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> The currently listed dotclock disagrees with the currently
> >>> listed vrefresh rate. Change the dotclock to match the vrefresh.
> >>>
> >>> Someone tell me which (if either) of the dotclock or vreresh is
> >>> correct?
> >>
> >> TL/DR; I do not care if you change the refresh rate or the dotclock.
> >>
> >> The whole entry for that panel in simple-panel is dubious. The panel
> >> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
> >> with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
> >> data channel and use the panel with RGB666. In either case, you need
> >> an LVDS signal and nothing else...
> >>
> >> The panel can also rotate the picture 180 degrees using the RL/UD pin.
> >>
> >> These options are of course not expressed in the simple panel driver
> >> (and we have always used fixed signals for those pins in our designs,
> >> IIRC). As far as I'm concerned, the panel can be removed from
> >> simple-panel. Our device trees are nowadays correctly expressing the
> >> hardware with an LVDS encoder between the RGB output and the panel
> >> and points to the panel-lvds driver for the panel.
> >
> > How do you make sure that you always bind against the correct driver? If
> > it matches simple-panel and panel-lvds, it's not deterministically going
> > to pick the right one. Well, it may actually be deterministic on Linux,
> > but perhaps only by accident.
>
> You are probably right that it's fragile, but no problems so far. That
> said, I did wonder why the panel-lvds driver "wins" over simple-panel for
>
> compatible = "sharp,lq150x1lg11", "panel-lvds";
>
> I figured it was by design and didn't spend too much time thinking about
> it. Maybe I should have?
It's most likely because panel-lvds.o is linked into the kernel before
panel-simple.o and the first match wins. You may want to move the entry
to panel-lvds to make this a little more robust.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-03 15:05 ` Thierry Reding
@ 2020-03-03 15:16 ` Peter Rosin
0 siblings, 0 replies; 98+ messages in thread
From: Peter Rosin @ 2020-03-03 15:16 UTC (permalink / raw)
To: Thierry Reding; +Cc: Thierry Reding, dri-devel
On 2020-03-03 16:05, Thierry Reding wrote:
> On Tue, Mar 03, 2020 at 02:57:45PM +0000, Peter Rosin wrote:
>>
>> On 2020-03-03 15:20, Thierry Reding wrote:
>>> On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
>>>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> The currently listed dotclock disagrees with the currently
>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>
>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>> correct?
>>>>
>>>> TL/DR; I do not care if you change the refresh rate or the dotclock.
>>>>
>>>> The whole entry for that panel in simple-panel is dubious. The panel
>>>> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
>>>> with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
>>>> data channel and use the panel with RGB666. In either case, you need
>>>> an LVDS signal and nothing else...
>>>>
>>>> The panel can also rotate the picture 180 degrees using the RL/UD pin.
>>>>
>>>> These options are of course not expressed in the simple panel driver
>>>> (and we have always used fixed signals for those pins in our designs,
>>>> IIRC). As far as I'm concerned, the panel can be removed from
>>>> simple-panel. Our device trees are nowadays correctly expressing the
>>>> hardware with an LVDS encoder between the RGB output and the panel
>>>> and points to the panel-lvds driver for the panel.
>>>
>>> How do you make sure that you always bind against the correct driver? If
>>> it matches simple-panel and panel-lvds, it's not deterministically going
>>> to pick the right one. Well, it may actually be deterministic on Linux,
>>> but perhaps only by accident.
>>
>> You are probably right that it's fragile, but no problems so far. That
>> said, I did wonder why the panel-lvds driver "wins" over simple-panel for
>>
>> compatible = "sharp,lq150x1lg11", "panel-lvds";
>>
>> I figured it was by design and didn't spend too much time thinking about
>> it. Maybe I should have?
>
> It's most likely because panel-lvds.o is linked into the kernel before
> panel-simple.o and the first match wins. You may want to move the entry
> to panel-lvds to make this a little more robust.
Ok, or because I dropped the simple-panel driver when we no longer
depended on it. Either way, what do you mean "move to [..] panel-lvds"?
It has no list of panels, you have to end with "panel-lvds" in the
compatible for the driver to bind.
Cheers,
Peter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
2020-03-03 14:57 ` Peter Rosin
2020-03-03 15:05 ` Thierry Reding
@ 2020-03-04 17:25 ` Sam Ravnborg
2020-03-05 13:07 ` [PATCH] Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels" Peter Rosin
1 sibling, 1 reply; 98+ messages in thread
From: Sam Ravnborg @ 2020-03-04 17:25 UTC (permalink / raw)
To: Peter Rosin; +Cc: Thierry Reding, Thierry Reding, dri-devel
Hi Peter.
> >>
> >> That said, I have no idea whatsoever if others have started using this
> >> panel entry. My guess is that it has zero users, but who can tell?
> >
> > A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
> > the only device tree that uses this panel in the upstream kernel.
>
> This is our design, and what made us originally add the entry to simple
> panel, but as I said, we no longer need simple-panel support for it...
With the only upstream user using panel-lvds we should delete
it from panel-simple.
With all the features it does not belong in panel-simple anyway.
Peter - care to send a patch for that?
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH] Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"
2020-03-04 17:25 ` Sam Ravnborg
@ 2020-03-05 13:07 ` Peter Rosin
2020-03-07 18:31 ` Sam Ravnborg
0 siblings, 1 reply; 98+ messages in thread
From: Peter Rosin @ 2020-03-05 13:07 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Sam Ravnborg, Peter Rosin
This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b.
The interface of the panel is LVDS, not parallel.
The color depth is RGB888, not RGB565.
The panel has additional features, making it not so simple.
The only user (upstream) of this panel is appropriately using panel-lvds.
Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/panel/panel-simple.c | 27 ---------------------------
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac62b5..fb8d61f5ae5d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2768,30 +2768,6 @@ static const struct panel_desc sharp_lq123p1jx31 = {
},
};
-static const struct drm_display_mode sharp_lq150x1lg11_mode = {
- .clock = 71100,
- .hdisplay = 1024,
- .hsync_start = 1024 + 168,
- .hsync_end = 1024 + 168 + 64,
- .htotal = 1024 + 168 + 64 + 88,
- .vdisplay = 768,
- .vsync_start = 768 + 37,
- .vsync_end = 768 + 37 + 2,
- .vtotal = 768 + 37 + 2 + 8,
- .vrefresh = 60,
-};
-
-static const struct panel_desc sharp_lq150x1lg11 = {
- .modes = &sharp_lq150x1lg11_mode,
- .num_modes = 1,
- .bpc = 6,
- .size = {
- .width = 304,
- .height = 228,
- },
- .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
-};
-
static const struct display_timing sharp_ls020b1dd01d_timing = {
.pixelclock = { 2000000, 4200000, 5000000 },
.hactive = { 240, 240, 240 },
@@ -3465,9 +3441,6 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "sharp,lq123p1jx31",
.data = &sharp_lq123p1jx31,
- }, {
- .compatible = "sharp,lq150x1lg11",
- .data = &sharp_lq150x1lg11,
}, {
.compatible = "sharp,ls020b1dd01d",
.data = &sharp_ls020b1dd01d,
--
2.20.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread
* [PATCH 29/33] drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (27 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 30/33] drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion Ville Syrjala
` (4 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Nicolas Ferre, Boris Brezillon
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cb587de8c49e..46a82ca5c2ca 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3077,7 +3077,7 @@ static const struct panel_desc sharp_ls020b1dd01d = {
};
static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
- .clock = 33300,
+ .clock = 29319,
.hdisplay = 800,
.hsync_start = 800 + 1,
.hsync_end = 800 + 1 + 64,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 30/33] drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (28 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 29/33] drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01 Ville Syrjala
` (3 subsequent siblings)
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Bhuvanchandra DV
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 46a82ca5c2ca..5ce1328fd7dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3309,7 +3309,7 @@ static const struct panel_desc tpk_f07a_0102 = {
};
static const struct drm_display_mode tpk_f10a_0102_mode = {
- .clock = 45000,
+ .clock = 50427,
.hdisplay = 1024,
.hsync_start = 1024 + 176,
.hsync_end = 1024 + 176 + 5,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (29 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 30/33] drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-11 14:56 ` Fabio Estevam
2020-03-02 20:34 ` [PATCH 32/33] drm/panel-simple: Fix dotclock for LG LH500WX1-SD03 Ville Syrjala
` (2 subsequent siblings)
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Sam Ravnborg, Thierry Reding
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 5ce1328fd7dc..6b48c02af112 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3368,7 +3368,7 @@ static const struct panel_desc urt_umsh_8596md_parallel = {
};
static const struct drm_display_mode vl050_8048nt_c01_mode = {
- .clock = 33333,
+ .clock = 34540,
.hdisplay = 800,
.hsync_start = 800 + 210,
.hsync_end = 800 + 210 + 20,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01
2020-03-02 20:34 ` [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01 Ville Syrjala
@ 2020-03-11 14:56 ` Fabio Estevam
0 siblings, 0 replies; 98+ messages in thread
From: Fabio Estevam @ 2020-03-11 14:56 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Thierry Reding, Sam Ravnborg, DRI mailing list
Hi Ville,
On Mon, Mar 2, 2020 at 5:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 5ce1328fd7dc..6b48c02af112 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3368,7 +3368,7 @@ static const struct panel_desc urt_umsh_8596md_parallel = {
> };
>
> static const struct drm_display_mode vl050_8048nt_c01_mode = {
> - .clock = 33333,
> + .clock = 34540,
I don't have access to hardware to test this change at the moment, but
looking at the panel datasheet I see that 34.54MHz is still inside the
valid range:
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH 32/33] drm/panel-simple: Fix dotclock for LG LH500WX1-SD03
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (30 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:34 ` [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7 Ville Syrjala
2020-03-02 21:47 ` [PATCH 00/33] drm/panel: Fix dotclocks Sam Ravnborg
33 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Thierry Reding, Alexandre Courbot
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 6b48c02af112..b24fdf239440 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3939,7 +3939,7 @@ static const struct panel_desc_dsi lg_ld070wx3_sl01 = {
};
static const struct drm_display_mode lg_lh500wx1_sd03_mode = {
- .clock = 67000,
+ .clock = 66348,
.hdisplay = 720,
.hsync_start = 720 + 12,
.hsync_end = 720 + 12 + 4,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (31 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 32/33] drm/panel-simple: Fix dotclock for LG LH500WX1-SD03 Ville Syrjala
@ 2020-03-02 20:34 ` Ville Syrjala
2020-03-02 20:48 ` Jonathan Marek
2020-03-02 21:47 ` [PATCH 00/33] drm/panel: Fix dotclocks Sam Ravnborg
33 siblings, 1 reply; 98+ messages in thread
From: Ville Syrjala @ 2020-03-02 20:34 UTC (permalink / raw)
To: dri-devel; +Cc: Jonathan Marek, Brian Masney
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Jonathan Marek <jonathan@marek.ca>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b24fdf239440..f958d8dfd760 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
};
static const struct drm_display_mode lg_acx467akm_7_mode = {
- .clock = 150000,
+ .clock = 125498,
.hdisplay = 1080,
.hsync_start = 1080 + 2,
.hsync_end = 1080 + 2 + 2,
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-02 20:34 ` [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7 Ville Syrjala
@ 2020-03-02 20:48 ` Jonathan Marek
2020-03-03 3:13 ` Brian Masney
2020-03-04 9:10 ` Linus Walleij
0 siblings, 2 replies; 98+ messages in thread
From: Jonathan Marek @ 2020-03-02 20:48 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: Brian Masney
Hi,
This is a command mode panel and the the msm/mdp5 driver uses the
vrefresh field for the actual refresh rate, while the dotclock field is
used for the DSI clocks. The dotclock needed to be a bit higher than
necessary otherwise the panel would not work.
If you want to get rid of the separate clock/vrefresh fields there would
need to be some changes to msm driver.
(note I hadn't made the patch with upstreaming in mind, the 150000 value
is likely not optimal, just something that worked, this is something
that should have been checked with the downstream driver)
-Jonathan
On 3/2/20 3:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Jonathan Marek <jonathan@marek.ca>
> Cc: Brian Masney <masneyb@onstation.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index b24fdf239440..f958d8dfd760 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
> };
>
> static const struct drm_display_mode lg_acx467akm_7_mode = {
> - .clock = 150000,
> + .clock = 125498,
> .hdisplay = 1080,
> .hsync_start = 1080 + 2,
> .hsync_end = 1080 + 2 + 2,
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-02 20:48 ` Jonathan Marek
@ 2020-03-03 3:13 ` Brian Masney
2020-03-03 3:28 ` Jonathan Marek
2020-03-04 9:10 ` Linus Walleij
1 sibling, 1 reply; 98+ messages in thread
From: Brian Masney @ 2020-03-03 3:13 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> Hi,
>
> This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
> field for the actual refresh rate, while the dotclock field is used for the
> DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
> the panel would not work.
>
> If you want to get rid of the separate clock/vrefresh fields there would
> need to be some changes to msm driver.
>
> (note I hadn't made the patch with upstreaming in mind, the 150000 value is
> likely not optimal, just something that worked, this is something that
> should have been checked with the downstream driver)
Is this the right clock frequency in the downstream MSM 3.4 kernel that
you're talking about?
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
I don't see any obvious clock values in the downstream command mode
panel configuration:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
and everything appears to be working fine. You can add my Tested-by if
you end up applying this.
Tested-by: Brian Masney <masneyb@onstation.org>
Brian
> On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Jonathan Marek <jonathan@marek.ca>
> > Cc: Brian Masney <masneyb@onstation.org>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index b24fdf239440..f958d8dfd760 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
> > };
> > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > - .clock = 150000,
> > + .clock = 125498,
> > .hdisplay = 1080,
> > .hsync_start = 1080 + 2,
> > .hsync_end = 1080 + 2 + 2,
> >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-03 3:13 ` Brian Masney
@ 2020-03-03 3:28 ` Jonathan Marek
2020-03-03 3:36 ` Jonathan Marek
0 siblings, 1 reply; 98+ messages in thread
From: Jonathan Marek @ 2020-03-03 3:28 UTC (permalink / raw)
To: Brian Masney; +Cc: dri-devel
On 3/2/20 10:13 PM, Brian Masney wrote:
> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>> Hi,
>>
>> This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
>> field for the actual refresh rate, while the dotclock field is used for the
>> DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
>> the panel would not work.
>>
>> If you want to get rid of the separate clock/vrefresh fields there would
>> need to be some changes to msm driver.
>>
>> (note I hadn't made the patch with upstreaming in mind, the 150000 value is
>> likely not optimal, just something that worked, this is something that
>> should have been checked with the downstream driver)
>
> Is this the right clock frequency in the downstream MSM 3.4 kernel that
> you're talking about?
>
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>
No, I'm talking about the DSI clock (the driver for it is in
drm/msm/dsi/). For a command mode panel the front/back porches aren't
relevant, but the dsi pixel/byte clock need to be a bit higher than
1920x1080x60. Since 125498 is a little higher than 124416 that might be
enough (there is also rounding of the clock values to consider).
> I don't see any obvious clock values in the downstream command mode
> panel configuration:
>
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>
> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> and everything appears to be working fine. You can add my Tested-by if
> you end up applying this.
>
> Tested-by: Brian Masney <masneyb@onstation.org>
>
> Brian
>
>
>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The currently listed dotclock disagrees with the currently
>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>
>>> Someone tell me which (if either) of the dotclock or vreresh is
>>> correct?
>>>
>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>> Cc: Brian Masney <masneyb@onstation.org>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
>>> index b24fdf239440..f958d8dfd760 100644
>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
>>> };
>>> static const struct drm_display_mode lg_acx467akm_7_mode = {
>>> - .clock = 150000,
>>> + .clock = 125498,
>>> .hdisplay = 1080,
>>> .hsync_start = 1080 + 2,
>>> .hsync_end = 1080 + 2 + 2,
>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-03 3:28 ` Jonathan Marek
@ 2020-03-03 3:36 ` Jonathan Marek
2020-03-03 12:26 ` Brian Masney
0 siblings, 1 reply; 98+ messages in thread
From: Jonathan Marek @ 2020-03-03 3:36 UTC (permalink / raw)
To: Brian Masney; +Cc: dri-devel
Another thing: did you verify that the panel still runs at 60hz (and not
dropping frames to 30hz)? IIRC that was the behavior with lower clock.
On 3/2/20 10:28 PM, Jonathan Marek wrote:
>
> On 3/2/20 10:13 PM, Brian Masney wrote:
>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>> Hi,
>>>
>>> This is a command mode panel and the the msm/mdp5 driver uses the
>>> vrefresh
>>> field for the actual refresh rate, while the dotclock field is used
>>> for the
>>> DSI clocks. The dotclock needed to be a bit higher than necessary
>>> otherwise
>>> the panel would not work.
>>>
>>> If you want to get rid of the separate clock/vrefresh fields there would
>>> need to be some changes to msm driver.
>>>
>>> (note I hadn't made the patch with upstreaming in mind, the 150000
>>> value is
>>> likely not optimal, just something that worked, this is something that
>>> should have been checked with the downstream driver)
>>
>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>> you're talking about?
>>
>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>
>>
>
> No, I'm talking about the DSI clock (the driver for it is in
> drm/msm/dsi/). For a command mode panel the front/back porches aren't
> relevant, but the dsi pixel/byte clock need to be a bit higher than
> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> enough (there is also rounding of the clock values to consider).
>
>> I don't see any obvious clock values in the downstream command mode
>> panel configuration:
>>
>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>
>>
>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>> and everything appears to be working fine. You can add my Tested-by if
>> you end up applying this.
>>
>> Tested-by: Brian Masney <masneyb@onstation.org>
>>
>> Brian
>>
>>
>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>
>>>> The currently listed dotclock disagrees with the currently
>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>
>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>> correct?
>>>>
>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>> ---
>>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>> index b24fdf239440..f958d8dfd760 100644
>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>> panasonic_vvx10f004b00 = {
>>>> };
>>>> static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>> - .clock = 150000,
>>>> + .clock = 125498,
>>>> .hdisplay = 1080,
>>>> .hsync_start = 1080 + 2,
>>>> .hsync_end = 1080 + 2 + 2,
>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-03 3:36 ` Jonathan Marek
@ 2020-03-03 12:26 ` Brian Masney
2020-03-03 13:04 ` Jonathan Marek
0 siblings, 1 reply; 98+ messages in thread
From: Brian Masney @ 2020-03-03 12:26 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> Another thing: did you verify that the panel still runs at 60hz (and not
> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
Yes, the panel is running at 60 HZ according to the Xorg log with
Ville's patch applied:
modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
1920 1922 1924 1926 (115.6 kHz eP)
I verified there's no underflow errors in dmesg.
If I recall correctly, the clock speeds that was in your tree was set
too low for the gpu_opp_table (that wouldn't cause this issue), but I
seem to recall there were some other clock speed mismatches. The
bandwidth requests weren't set on the RPM as well, so maybe that
contributed to the problem. That's done upstream with the msm8974
interconnect driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
There's a separate known issue with 'pp done time out' errors that
occur on the framebuffer that started upstream several months ago with
the introduction of async commit support in the MSM driver. I tried
working around this by enabling the autorefresh feature but it's not
fully working yet and I hit a dead end since there's no docs available
publicly for this. The grim details are at:
https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
So I'm still OK with Ville's patch going in.
Brian
>
> On 3/2/20 10:28 PM, Jonathan Marek wrote:
> >
> > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > Hi,
> > > >
> > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > the vrefresh
> > > > field for the actual refresh rate, while the dotclock field is
> > > > used for the
> > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > necessary otherwise
> > > > the panel would not work.
> > > >
> > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > need to be some changes to msm driver.
> > > >
> > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > 150000 value is
> > > > likely not optimal, just something that worked, this is something that
> > > > should have been checked with the downstream driver)
> > >
> > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > you're talking about?
> > >
> > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > >
> > >
> >
> > No, I'm talking about the DSI clock (the driver for it is in
> > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > enough (there is also rounding of the clock values to consider).
> >
> > > I don't see any obvious clock values in the downstream command mode
> > > panel configuration:
> > >
> > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > >
> > >
> > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > and everything appears to be working fine. You can add my Tested-by if
> > > you end up applying this.
> > >
> > > Tested-by: Brian Masney <masneyb@onstation.org>
> > >
> > > Brian
> > >
> > >
> > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > >
> > > > > The currently listed dotclock disagrees with the currently
> > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > >
> > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > correct?
> > > > >
> > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > ---
> > > > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > panasonic_vvx10f004b00 = {
> > > > > };
> > > > > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > - .clock = 150000,
> > > > > + .clock = 125498,
> > > > > .hdisplay = 1080,
> > > > > .hsync_start = 1080 + 2,
> > > > > .hsync_end = 1080 + 2 + 2,
> > > > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-03 12:26 ` Brian Masney
@ 2020-03-03 13:04 ` Jonathan Marek
2020-03-04 2:16 ` Brian Masney
0 siblings, 1 reply; 98+ messages in thread
From: Jonathan Marek @ 2020-03-03 13:04 UTC (permalink / raw)
To: Brian Masney; +Cc: dri-devel
What Xorg prints doesn't mean anything. I don't think there will be
errors in dmesg, you need to run something that does pageflips as fast
as possible and see that the refresh rate is still 60. (modetest with
-v, glmark-drm are examples)
On 3/3/20 7:26 AM, Brian Masney wrote:
> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>> Another thing: did you verify that the panel still runs at 60hz (and not
>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
>
> Yes, the panel is running at 60 HZ according to the Xorg log with
> Ville's patch applied:
>
> modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
> 1920 1922 1924 1926 (115.6 kHz eP)
>
> I verified there's no underflow errors in dmesg.
>
> If I recall correctly, the clock speeds that was in your tree was set
> too low for the gpu_opp_table (that wouldn't cause this issue), but I
> seem to recall there were some other clock speed mismatches. The
> bandwidth requests weren't set on the RPM as well, so maybe that
> contributed to the problem. That's done upstream with the msm8974
> interconnect driver:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
>
> There's a separate known issue with 'pp done time out' errors that
> occur on the framebuffer that started upstream several months ago with
> the introduction of async commit support in the MSM driver. I tried
> working around this by enabling the autorefresh feature but it's not
> fully working yet and I hit a dead end since there's no docs available
> publicly for this. The grim details are at:
>
> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
>
> So I'm still OK with Ville's patch going in.
>
> Brian
>
>
>>
>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>
>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>> Hi,
>>>>>
>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>> the vrefresh
>>>>> field for the actual refresh rate, while the dotclock field is
>>>>> used for the
>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>> necessary otherwise
>>>>> the panel would not work.
>>>>>
>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>> need to be some changes to msm driver.
>>>>>
>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>> 150000 value is
>>>>> likely not optimal, just something that worked, this is something that
>>>>> should have been checked with the downstream driver)
>>>>
>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>> you're talking about?
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>
>>>>
>>>
>>> No, I'm talking about the DSI clock (the driver for it is in
>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>> enough (there is also rounding of the clock values to consider).
>>>
>>>> I don't see any obvious clock values in the downstream command mode
>>>> panel configuration:
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>
>>>>
>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>> and everything appears to be working fine. You can add my Tested-by if
>>>> you end up applying this.
>>>>
>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>
>>>> Brian
>>>>
>>>>
>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>
>>>>>> The currently listed dotclock disagrees with the currently
>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>
>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>> correct?
>>>>>>
>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>> panasonic_vvx10f004b00 = {
>>>>>> };
>>>>>> static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>> - .clock = 150000,
>>>>>> + .clock = 125498,
>>>>>> .hdisplay = 1080,
>>>>>> .hsync_start = 1080 + 2,
>>>>>> .hsync_end = 1080 + 2 + 2,
>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-03 13:04 ` Jonathan Marek
@ 2020-03-04 2:16 ` Brian Masney
2020-03-04 2:27 ` Jonathan Marek
0 siblings, 1 reply; 98+ messages in thread
From: Brian Masney @ 2020-03-04 2:16 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> What Xorg prints doesn't mean anything. I don't think there will be errors
> in dmesg, you need to run something that does pageflips as fast as possible
> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> examples)
I assume that you mean modetest from
https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
Here's the modeset connector information:
id encoder status name size (mm) modes encoders
32 31 connected DSI-1 62x110 1 31
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
flags: ; type: preferred, driver
And the page flip results...
$ modetest -v -s 32:1080x1920
trying to open device 'msm'...done
setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
failed to set gamma: Function not implemented
freq: 13.50Hz
freq: 13.51Hz
freq: 13.51Hz
It's the same results with and without Ville's patch.
Here's the beginning of the glmark2 results with the x11-gl flavor:
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: freedreno
GL_RENDERER: FD330
GL_VERSION: 3.1 Mesa 20.0.0-devel
=======================================================
[build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
[build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
[shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
[shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
[shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
[shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
[bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
[bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
[bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
38.462 ms
[pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 26 FrameTime: 38.462 ms
[desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
...
Brian
>
> On 3/3/20 7:26 AM, Brian Masney wrote:
> > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> >
> > Yes, the panel is running at 60 HZ according to the Xorg log with
> > Ville's patch applied:
> >
> > modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
> > 1920 1922 1924 1926 (115.6 kHz eP)
> >
> > I verified there's no underflow errors in dmesg.
> >
> > If I recall correctly, the clock speeds that was in your tree was set
> > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > seem to recall there were some other clock speed mismatches. The
> > bandwidth requests weren't set on the RPM as well, so maybe that
> > contributed to the problem. That's done upstream with the msm8974
> > interconnect driver:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> >
> > There's a separate known issue with 'pp done time out' errors that
> > occur on the framebuffer that started upstream several months ago with
> > the introduction of async commit support in the MSM driver. I tried
> > working around this by enabling the autorefresh feature but it's not
> > fully working yet and I hit a dead end since there's no docs available
> > publicly for this. The grim details are at:
> >
> > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> >
> > So I'm still OK with Ville's patch going in.
> >
> > Brian
> >
> >
> > >
> > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > >
> > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > Hi,
> > > > > >
> > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > the vrefresh
> > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > used for the
> > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > necessary otherwise
> > > > > > the panel would not work.
> > > > > >
> > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > need to be some changes to msm driver.
> > > > > >
> > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > 150000 value is
> > > > > > likely not optimal, just something that worked, this is something that
> > > > > > should have been checked with the downstream driver)
> > > > >
> > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > you're talking about?
> > > > >
> > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > >
> > > > >
> > > >
> > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > enough (there is also rounding of the clock values to consider).
> > > >
> > > > > I don't see any obvious clock values in the downstream command mode
> > > > > panel configuration:
> > > > >
> > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > >
> > > > >
> > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > you end up applying this.
> > > > >
> > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > >
> > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > >
> > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > correct?
> > > > > > >
> > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > ---
> > > > > > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > };
> > > > > > > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > - .clock = 150000,
> > > > > > > + .clock = 125498,
> > > > > > > .hdisplay = 1080,
> > > > > > > .hsync_start = 1080 + 2,
> > > > > > > .hsync_end = 1080 + 2 + 2,
> > > > > > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 2:16 ` Brian Masney
@ 2020-03-04 2:27 ` Jonathan Marek
2020-03-04 2:53 ` Brian Masney
2020-03-04 10:37 ` Brian Masney
0 siblings, 2 replies; 98+ messages in thread
From: Jonathan Marek @ 2020-03-04 2:27 UTC (permalink / raw)
To: Brian Masney; +Cc: dri-devel
modetest should be printing "freq: 60.0Hz", so definitely something
wrong there. Though I guess you have another problem since I would
expect the patch to drop it to 30 and not 13.5.
(FYI glmark-x11 isn't vsynced which is why I specifically mentioned
glmark-drm)
On 3/3/20 9:16 PM, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
>> What Xorg prints doesn't mean anything. I don't think there will be errors
>> in dmesg, you need to run something that does pageflips as fast as possible
>> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
>> examples)
>
> I assume that you mean modetest from
> https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> Here's the modeset connector information:
>
> id encoder status name size (mm) modes encoders
> 32 31 connected DSI-1 62x110 1 31
> modes:
> index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> flags: ; type: preferred, driver
>
> And the page flip results...
>
> $ modetest -v -s 32:1080x1920
> trying to open device 'msm'...done
> setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> failed to set gamma: Function not implemented
> freq: 13.50Hz
> freq: 13.51Hz
> freq: 13.51Hz
>
> It's the same results with and without Ville's patch.
>
> Here's the beginning of the glmark2 results with the x11-gl flavor:
>
> =======================================================
> glmark2 2017.07
> =======================================================
> OpenGL Information
> GL_VENDOR: freedreno
> GL_RENDERER: FD330
> GL_VERSION: 3.1 Mesa 20.0.0-devel
> =======================================================
> [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> 38.462 ms
> [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> FPS: 26 FrameTime: 38.462 ms
> [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> ...
>
> Brian
>
>
>>
>> On 3/3/20 7:26 AM, Brian Masney wrote:
>>> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>>>> Another thing: did you verify that the panel still runs at 60hz (and not
>>>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
>>>
>>> Yes, the panel is running at 60 HZ according to the Xorg log with
>>> Ville's patch applied:
>>>
>>> modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
>>> 1920 1922 1924 1926 (115.6 kHz eP)
>>>
>>> I verified there's no underflow errors in dmesg.
>>>
>>> If I recall correctly, the clock speeds that was in your tree was set
>>> too low for the gpu_opp_table (that wouldn't cause this issue), but I
>>> seem to recall there were some other clock speed mismatches. The
>>> bandwidth requests weren't set on the RPM as well, so maybe that
>>> contributed to the problem. That's done upstream with the msm8974
>>> interconnect driver:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
>>>
>>> There's a separate known issue with 'pp done time out' errors that
>>> occur on the framebuffer that started upstream several months ago with
>>> the introduction of async commit support in the MSM driver. I tried
>>> working around this by enabling the autorefresh feature but it's not
>>> fully working yet and I hit a dead end since there's no docs available
>>> publicly for this. The grim details are at:
>>>
>>> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
>>>
>>> So I'm still OK with Ville's patch going in.
>>>
>>> Brian
>>>
>>>
>>>>
>>>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>>>
>>>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>>>> the vrefresh
>>>>>>> field for the actual refresh rate, while the dotclock field is
>>>>>>> used for the
>>>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>>>> necessary otherwise
>>>>>>> the panel would not work.
>>>>>>>
>>>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>>>> need to be some changes to msm driver.
>>>>>>>
>>>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>>>> 150000 value is
>>>>>>> likely not optimal, just something that worked, this is something that
>>>>>>> should have been checked with the downstream driver)
>>>>>>
>>>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>>>> you're talking about?
>>>>>>
>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>>>
>>>>>>
>>>>>
>>>>> No, I'm talking about the DSI clock (the driver for it is in
>>>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>>>> enough (there is also rounding of the clock values to consider).
>>>>>
>>>>>> I don't see any obvious clock values in the downstream command mode
>>>>>> panel configuration:
>>>>>>
>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>>>
>>>>>>
>>>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>>>> and everything appears to be working fine. You can add my Tested-by if
>>>>>> you end up applying this.
>>>>>>
>>>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>
>>>>>>>> The currently listed dotclock disagrees with the currently
>>>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>>>
>>>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>>>> correct?
>>>>>>>>
>>>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>> ---
>>>>>>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>>>> panasonic_vvx10f004b00 = {
>>>>>>>> };
>>>>>>>> static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>>>> - .clock = 150000,
>>>>>>>> + .clock = 125498,
>>>>>>>> .hdisplay = 1080,
>>>>>>>> .hsync_start = 1080 + 2,
>>>>>>>> .hsync_end = 1080 + 2 + 2,
>>>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 2:27 ` Jonathan Marek
@ 2020-03-04 2:53 ` Brian Masney
2020-03-04 3:04 ` Jonathan Marek
2020-03-04 10:37 ` Brian Masney
1 sibling, 1 reply; 98+ messages in thread
From: Brian Masney @ 2020-03-04 2:53 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> modetest should be printing "freq: 60.0Hz", so definitely something wrong
> there. Though I guess you have another problem since I would expect the
> patch to drop it to 30 and not 13.5.
>
> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> glmark-drm)
I tried compiling the drm variant and it was complaining about some
missing dependencies that I didn't see in Alpine Linux. I didn't try too
hard since I'm a bit short on time at this point since I'm starting a
new job on Monday and I have another side project that I want to finish
before then.
I suspect that the issue is caused by the introduction of the async
commit support in the MSM driver that introduced the ping/pong timeouts.
I'll try in a few weeks or so reverting those patches and see if that
affects the speed.
I'm still ok with Ville's patch going in given the existing slow state.
There's no clear path forward right now for the autocommit patch that I
linked to earlier in this thread. :(
Brian
>
> On 3/3/20 9:16 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > in dmesg, you need to run something that does pageflips as fast as possible
> > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > examples)
> >
> > I assume that you mean modetest from
> > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > Here's the modeset connector information:
> >
> > id encoder status name size (mm) modes encoders
> > 32 31 connected DSI-1 62x110 1 31
> > modes:
> > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> > #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> > flags: ; type: preferred, driver
> >
> > And the page flip results...
> >
> > $ modetest -v -s 32:1080x1920
> > trying to open device 'msm'...done
> > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > failed to set gamma: Function not implemented
> > freq: 13.50Hz
> > freq: 13.51Hz
> > freq: 13.51Hz
> >
> > It's the same results with and without Ville's patch.
> >
> > Here's the beginning of the glmark2 results with the x11-gl flavor:
> >
> > =======================================================
> > glmark2 2017.07
> > =======================================================
> > OpenGL Information
> > GL_VENDOR: freedreno
> > GL_RENDERER: FD330
> > GL_VERSION: 3.1 Mesa 20.0.0-devel
> > =======================================================
> > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> > 38.462 ms
> > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> > FPS: 26 FrameTime: 38.462 ms
> > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > ...
> >
> > Brian
> >
> >
> > >
> > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > >
> > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > Ville's patch applied:
> > > >
> > > > modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
> > > > 1920 1922 1924 1926 (115.6 kHz eP)
> > > >
> > > > I verified there's no underflow errors in dmesg.
> > > >
> > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > seem to recall there were some other clock speed mismatches. The
> > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > contributed to the problem. That's done upstream with the msm8974
> > > > interconnect driver:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > >
> > > > There's a separate known issue with 'pp done time out' errors that
> > > > occur on the framebuffer that started upstream several months ago with
> > > > the introduction of async commit support in the MSM driver. I tried
> > > > working around this by enabling the autorefresh feature but it's not
> > > > fully working yet and I hit a dead end since there's no docs available
> > > > publicly for this. The grim details are at:
> > > >
> > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > >
> > > > So I'm still OK with Ville's patch going in.
> > > >
> > > > Brian
> > > >
> > > >
> > > > >
> > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > >
> > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > the vrefresh
> > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > used for the
> > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > necessary otherwise
> > > > > > > > the panel would not work.
> > > > > > > >
> > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > need to be some changes to msm driver.
> > > > > > > >
> > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > 150000 value is
> > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > should have been checked with the downstream driver)
> > > > > > >
> > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > you're talking about?
> > > > > > >
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > enough (there is also rounding of the clock values to consider).
> > > > > >
> > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > panel configuration:
> > > > > > >
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > >
> > > > > > >
> > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > you end up applying this.
> > > > > > >
> > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > >
> > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > >
> > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > >
> > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > correct?
> > > > > > > > >
> > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > > };
> > > > > > > > > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > - .clock = 150000,
> > > > > > > > > + .clock = 125498,
> > > > > > > > > .hdisplay = 1080,
> > > > > > > > > .hsync_start = 1080 + 2,
> > > > > > > > > .hsync_end = 1080 + 2 + 2,
> > > > > > > > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 2:53 ` Brian Masney
@ 2020-03-04 3:04 ` Jonathan Marek
2020-03-04 10:00 ` Brian Masney
0 siblings, 1 reply; 98+ messages in thread
From: Jonathan Marek @ 2020-03-04 3:04 UTC (permalink / raw)
To: Brian Masney; +Cc: dri-devel
If I have time to kill over the weekend I'll do a new rebase of my Nexus
5 patches (my last rebase was back in August on 5.2, and the panel was
working correctly at 60Hz back then).
Looked at it again and it does look like your glmark was vsynced (glmark
explicitly disables vsync so I guess you have it force-enabled) since
the results are all 26-27 (X works a bit differently and gets double the
framerate somehow?)
On 3/3/20 9:53 PM, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
>> modetest should be printing "freq: 60.0Hz", so definitely something wrong
>> there. Though I guess you have another problem since I would expect the
>> patch to drop it to 30 and not 13.5.
>>
>> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
>> glmark-drm)
>
> I tried compiling the drm variant and it was complaining about some
> missing dependencies that I didn't see in Alpine Linux. I didn't try too
> hard since I'm a bit short on time at this point since I'm starting a
> new job on Monday and I have another side project that I want to finish
> before then.
>
> I suspect that the issue is caused by the introduction of the async
> commit support in the MSM driver that introduced the ping/pong timeouts.
> I'll try in a few weeks or so reverting those patches and see if that
> affects the speed.
>
> I'm still ok with Ville's patch going in given the existing slow state.
> There's no clear path forward right now for the autocommit patch that I
> linked to earlier in this thread. :(
>
> Brian
>
>>
>> On 3/3/20 9:16 PM, Brian Masney wrote:
>>> On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
>>>> What Xorg prints doesn't mean anything. I don't think there will be errors
>>>> in dmesg, you need to run something that does pageflips as fast as possible
>>>> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
>>>> examples)
>>>
>>> I assume that you mean modetest from
>>> https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
>>> Here's the modeset connector information:
>>>
>>> id encoder status name size (mm) modes encoders
>>> 32 31 connected DSI-1 62x110 1 31
>>> modes:
>>> index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
>>> #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
>>> flags: ; type: preferred, driver
>>>
>>> And the page flip results...
>>>
>>> $ modetest -v -s 32:1080x1920
>>> trying to open device 'msm'...done
>>> setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
>>> failed to set gamma: Function not implemented
>>> freq: 13.50Hz
>>> freq: 13.51Hz
>>> freq: 13.51Hz
>>>
>>> It's the same results with and without Ville's patch.
>>>
>>> Here's the beginning of the glmark2 results with the x11-gl flavor:
>>>
>>> =======================================================
>>> glmark2 2017.07
>>> =======================================================
>>> OpenGL Information
>>> GL_VENDOR: freedreno
>>> GL_RENDERER: FD330
>>> GL_VERSION: 3.1 Mesa 20.0.0-devel
>>> =======================================================
>>> [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
>>> [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
>>> [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
>>> [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
>>> [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
>>> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
>>> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
>>> 38.462 ms
>>> [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
>>> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
>>> FPS: 26 FrameTime: 38.462 ms
>>> [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
>>> ...
>>>
>>> Brian
>>>
>>>
>>>>
>>>> On 3/3/20 7:26 AM, Brian Masney wrote:
>>>>> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>>>>>> Another thing: did you verify that the panel still runs at 60hz (and not
>>>>>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
>>>>>
>>>>> Yes, the panel is running at 60 HZ according to the Xorg log with
>>>>> Ville's patch applied:
>>>>>
>>>>> modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
>>>>> 1920 1922 1924 1926 (115.6 kHz eP)
>>>>>
>>>>> I verified there's no underflow errors in dmesg.
>>>>>
>>>>> If I recall correctly, the clock speeds that was in your tree was set
>>>>> too low for the gpu_opp_table (that wouldn't cause this issue), but I
>>>>> seem to recall there were some other clock speed mismatches. The
>>>>> bandwidth requests weren't set on the RPM as well, so maybe that
>>>>> contributed to the problem. That's done upstream with the msm8974
>>>>> interconnect driver:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
>>>>>
>>>>> There's a separate known issue with 'pp done time out' errors that
>>>>> occur on the framebuffer that started upstream several months ago with
>>>>> the introduction of async commit support in the MSM driver. I tried
>>>>> working around this by enabling the autorefresh feature but it's not
>>>>> fully working yet and I hit a dead end since there's no docs available
>>>>> publicly for this. The grim details are at:
>>>>>
>>>>> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
>>>>>
>>>>> So I'm still OK with Ville's patch going in.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>>
>>>>>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>>>>>
>>>>>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>>>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>>>>>> the vrefresh
>>>>>>>>> field for the actual refresh rate, while the dotclock field is
>>>>>>>>> used for the
>>>>>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>>>>>> necessary otherwise
>>>>>>>>> the panel would not work.
>>>>>>>>>
>>>>>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>>>>>> need to be some changes to msm driver.
>>>>>>>>>
>>>>>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>>>>>> 150000 value is
>>>>>>>>> likely not optimal, just something that worked, this is something that
>>>>>>>>> should have been checked with the downstream driver)
>>>>>>>>
>>>>>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>>>>>> you're talking about?
>>>>>>>>
>>>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No, I'm talking about the DSI clock (the driver for it is in
>>>>>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>>>>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>>>>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>>>>>> enough (there is also rounding of the clock values to consider).
>>>>>>>
>>>>>>>> I don't see any obvious clock values in the downstream command mode
>>>>>>>> panel configuration:
>>>>>>>>
>>>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>>>>>
>>>>>>>>
>>>>>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>>>>>> and everything appears to be working fine. You can add my Tested-by if
>>>>>>>> you end up applying this.
>>>>>>>>
>>>>>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>>>
>>>>>>>>>> The currently listed dotclock disagrees with the currently
>>>>>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>>>>>
>>>>>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>>>>>> correct?
>>>>>>>>>>
>>>>>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>>> ---
>>>>>>>>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>>>>>> panasonic_vvx10f004b00 = {
>>>>>>>>>> };
>>>>>>>>>> static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>>>>>> - .clock = 150000,
>>>>>>>>>> + .clock = 125498,
>>>>>>>>>> .hdisplay = 1080,
>>>>>>>>>> .hsync_start = 1080 + 2,
>>>>>>>>>> .hsync_end = 1080 + 2 + 2,
>>>>>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 3:04 ` Jonathan Marek
@ 2020-03-04 10:00 ` Brian Masney
0 siblings, 0 replies; 98+ messages in thread
From: Brian Masney @ 2020-03-04 10:00 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Tue, Mar 03, 2020 at 10:04:56PM -0500, Jonathan Marek wrote:
> If I have time to kill over the weekend I'll do a new rebase of my Nexus 5
> patches (my last rebase was back in August on 5.2, and the panel was working
> correctly at 60Hz back then).
That would be great if you have time to look at the panel. My
out-of-tree patches for this phone are at
https://github.com/masneyb/linux/commits/v5.5-nexus5.
A high-level description of those patches are on the cover letter:
https://github.com/masneyb/nexus-5-upstream/blob/master/out-of-tree-patches/upstream-patches/v5.5/0000-cover-letter.patch
A description of what works and what I've done upstream for this device
is described at:
https://masneyb.github.io/nexus-5-upstream/
Brian
>
> Looked at it again and it does look like your glmark was vsynced (glmark
> explicitly disables vsync so I guess you have it force-enabled) since the
> results are all 26-27 (X works a bit differently and gets double the
> framerate somehow?)
>
> On 3/3/20 9:53 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> > > modetest should be printing "freq: 60.0Hz", so definitely something wrong
> > > there. Though I guess you have another problem since I would expect the
> > > patch to drop it to 30 and not 13.5.
> > >
> > > (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> > > glmark-drm)
> >
> > I tried compiling the drm variant and it was complaining about some
> > missing dependencies that I didn't see in Alpine Linux. I didn't try too
> > hard since I'm a bit short on time at this point since I'm starting a
> > new job on Monday and I have another side project that I want to finish
> > before then.
> >
> > I suspect that the issue is caused by the introduction of the async
> > commit support in the MSM driver that introduced the ping/pong timeouts.
> > I'll try in a few weeks or so reverting those patches and see if that
> > affects the speed.
> >
> > I'm still ok with Ville's patch going in given the existing slow state.
> > There's no clear path forward right now for the autocommit patch that I
> > linked to earlier in this thread. :(
> >
> > Brian
> >
> > >
> > > On 3/3/20 9:16 PM, Brian Masney wrote:
> > > > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > > > in dmesg, you need to run something that does pageflips as fast as possible
> > > > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > > > examples)
> > > >
> > > > I assume that you mean modetest from
> > > > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > > > Here's the modeset connector information:
> > > >
> > > > id encoder status name size (mm) modes encoders
> > > > 32 31 connected DSI-1 62x110 1 31
> > > > modes:
> > > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> > > > #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> > > > flags: ; type: preferred, driver
> > > >
> > > > And the page flip results...
> > > >
> > > > $ modetest -v -s 32:1080x1920
> > > > trying to open device 'msm'...done
> > > > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > > > failed to set gamma: Function not implemented
> > > > freq: 13.50Hz
> > > > freq: 13.51Hz
> > > > freq: 13.51Hz
> > > >
> > > > It's the same results with and without Ville's patch.
> > > >
> > > > Here's the beginning of the glmark2 results with the x11-gl flavor:
> > > >
> > > > =======================================================
> > > > glmark2 2017.07
> > > > =======================================================
> > > > OpenGL Information
> > > > GL_VENDOR: freedreno
> > > > GL_RENDERER: FD330
> > > > GL_VERSION: 3.1 Mesa 20.0.0-devel
> > > > =======================================================
> > > > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > > > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > > > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > > > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > > > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > > > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > > > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> > > > 38.462 ms
> > > > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > > > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> > > > FPS: 26 FrameTime: 38.462 ms
> > > > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > > > ...
> > > >
> > > > Brian
> > > >
> > > >
> > > > >
> > > > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > > > >
> > > > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > > > Ville's patch applied:
> > > > > >
> > > > > > modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
> > > > > > 1920 1922 1924 1926 (115.6 kHz eP)
> > > > > >
> > > > > > I verified there's no underflow errors in dmesg.
> > > > > >
> > > > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > > > seem to recall there were some other clock speed mismatches. The
> > > > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > > > contributed to the problem. That's done upstream with the msm8974
> > > > > > interconnect driver:
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > > > >
> > > > > > There's a separate known issue with 'pp done time out' errors that
> > > > > > occur on the framebuffer that started upstream several months ago with
> > > > > > the introduction of async commit support in the MSM driver. I tried
> > > > > > working around this by enabling the autorefresh feature but it's not
> > > > > > fully working yet and I hit a dead end since there's no docs available
> > > > > > publicly for this. The grim details are at:
> > > > > >
> > > > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > > > >
> > > > > > So I'm still OK with Ville's patch going in.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > > > >
> > > > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > > > the vrefresh
> > > > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > > > used for the
> > > > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > > > necessary otherwise
> > > > > > > > > > the panel would not work.
> > > > > > > > > >
> > > > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > > > need to be some changes to msm driver.
> > > > > > > > > >
> > > > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > > > 150000 value is
> > > > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > > > should have been checked with the downstream driver)
> > > > > > > > >
> > > > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > > > you're talking about?
> > > > > > > > >
> > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > > > enough (there is also rounding of the clock values to consider).
> > > > > > > >
> > > > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > > > panel configuration:
> > > > > > > > >
> > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > > > you end up applying this.
> > > > > > > > >
> > > > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > >
> > > > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > > > >
> > > > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > > > correct?
> > > > > > > > > > >
> > > > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > > > > };
> > > > > > > > > > > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > > > - .clock = 150000,
> > > > > > > > > > > + .clock = 125498,
> > > > > > > > > > > .hdisplay = 1080,
> > > > > > > > > > > .hsync_start = 1080 + 2,
> > > > > > > > > > > .hsync_end = 1080 + 2 + 2,
> > > > > > > > > > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 2:27 ` Jonathan Marek
2020-03-04 2:53 ` Brian Masney
@ 2020-03-04 10:37 ` Brian Masney
1 sibling, 0 replies; 98+ messages in thread
From: Brian Masney @ 2020-03-04 10:37 UTC (permalink / raw)
To: Jonathan Marek; +Cc: dri-devel
On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> modetest should be printing "freq: 60.0Hz", so definitely something wrong
> there. Though I guess you have another problem since I would expect the
> patch to drop it to 30 and not 13.5.
So I reverted the following three commits related to the async commit
support in the MSM driver:
d934a712c5e6 ("drm/msm: add atomic traces")
2d99ced787e3 ("drm/msm: async commit support")
194fc68d7a49 ("drm/msm/dpu: async commit support")
The modetest results now look much better:
# With existing 150000 clock rate on the panel
$ modetest -v -s 32:1080x19
setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
failed to set gamma: Function not implemented
freq: 59.40Hz
freq: 59.69Hz
freq: 59.69Hz
...
With Ville's patch the frequency drops slightly.
# With 125498 clock rate on the panel
$ modetest -v -s 32:1080x19
freq: 55.44Hz
freq: 55.09Hz
freq: 55.88Hz
...
Brian
>
> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> glmark-drm)
>
> On 3/3/20 9:16 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > in dmesg, you need to run something that does pageflips as fast as possible
> > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > examples)
> >
> > I assume that you mean modetest from
> > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > Here's the modeset connector information:
> >
> > id encoder status name size (mm) modes encoders
> > 32 31 connected DSI-1 62x110 1 31
> > modes:
> > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> > #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> > flags: ; type: preferred, driver
> >
> > And the page flip results...
> >
> > $ modetest -v -s 32:1080x1920
> > trying to open device 'msm'...done
> > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > failed to set gamma: Function not implemented
> > freq: 13.50Hz
> > freq: 13.51Hz
> > freq: 13.51Hz
> >
> > It's the same results with and without Ville's patch.
> >
> > Here's the beginning of the glmark2 results with the x11-gl flavor:
> >
> > =======================================================
> > glmark2 2017.07
> > =======================================================
> > OpenGL Information
> > GL_VENDOR: freedreno
> > GL_RENDERER: FD330
> > GL_VERSION: 3.1 Mesa 20.0.0-devel
> > =======================================================
> > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> > 38.462 ms
> > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> > FPS: 26 FrameTime: 38.462 ms
> > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > ...
> >
> > Brian
> >
> >
> > >
> > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > >
> > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > Ville's patch applied:
> > > >
> > > > modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082 1084 1086
> > > > 1920 1922 1924 1926 (115.6 kHz eP)
> > > >
> > > > I verified there's no underflow errors in dmesg.
> > > >
> > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > seem to recall there were some other clock speed mismatches. The
> > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > contributed to the problem. That's done upstream with the msm8974
> > > > interconnect driver:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > >
> > > > There's a separate known issue with 'pp done time out' errors that
> > > > occur on the framebuffer that started upstream several months ago with
> > > > the introduction of async commit support in the MSM driver. I tried
> > > > working around this by enabling the autorefresh feature but it's not
> > > > fully working yet and I hit a dead end since there's no docs available
> > > > publicly for this. The grim details are at:
> > > >
> > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > >
> > > > So I'm still OK with Ville's patch going in.
> > > >
> > > > Brian
> > > >
> > > >
> > > > >
> > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > >
> > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > the vrefresh
> > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > used for the
> > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > necessary otherwise
> > > > > > > > the panel would not work.
> > > > > > > >
> > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > need to be some changes to msm driver.
> > > > > > > >
> > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > 150000 value is
> > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > should have been checked with the downstream driver)
> > > > > > >
> > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > you're talking about?
> > > > > > >
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > enough (there is also rounding of the clock values to consider).
> > > > > >
> > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > panel configuration:
> > > > > > >
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > >
> > > > > > >
> > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > you end up applying this.
> > > > > > >
> > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > >
> > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > >
> > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > >
> > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > correct?
> > > > > > > > >
> > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > > };
> > > > > > > > > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > - .clock = 150000,
> > > > > > > > > + .clock = 125498,
> > > > > > > > > .hdisplay = 1080,
> > > > > > > > > .hsync_start = 1080 + 2,
> > > > > > > > > .hsync_end = 1080 + 2 + 2,
> > > > > > > > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-02 20:48 ` Jonathan Marek
2020-03-03 3:13 ` Brian Masney
@ 2020-03-04 9:10 ` Linus Walleij
2020-03-04 13:16 ` Jonathan Marek
1 sibling, 1 reply; 98+ messages in thread
From: Linus Walleij @ 2020-03-04 9:10 UTC (permalink / raw)
To: Jonathan Marek; +Cc: open list:DRM PANEL DRIVERS, Brian Masney
On Mon, Mar 2, 2020 at 9:49 PM Jonathan Marek <jonathan@marek.ca> wrote:
> This is a command mode panel and the the msm/mdp5 driver uses the
> vrefresh field for the actual refresh rate, while the dotclock field is
> used for the DSI clocks. The dotclock needed to be a bit higher than
> necessary otherwise the panel would not work.
I don't know if this predates the support for defining DSI clocks
but for what we have in the kernel right now this is wrong.
struct mipi_dsi_device contains:
* @hs_rate: maximum lane frequency for high speed mode in hertz, this should
* be set to the real limits of the hardware, zero is only accepted for
* legacy drivers
* @lp_rate: maximum lane frequency for low power mode in hertz, this should
* be set to the real limits of the hardware, zero is only accepted for
* legacy drivers
The MDP driver should use these frequencies for a DSI command
mode panel, and the panel driver should define them.
These two clocks are/can be/should be completely orthogonal to
the dotclock/pixelclock inside the panel, which is likely driven from
its own crystal directly from the panel-internal framebuffer.
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 9:10 ` Linus Walleij
@ 2020-03-04 13:16 ` Jonathan Marek
2020-03-04 14:00 ` Linus Walleij
0 siblings, 1 reply; 98+ messages in thread
From: Jonathan Marek @ 2020-03-04 13:16 UTC (permalink / raw)
To: Linus Walleij; +Cc: open list:DRM PANEL DRIVERS, Brian Masney
The msm DSI driver does predate the addition of those fields and doesn't
use them at all.
Seems like it would be a bit of a hack too, since the frequency we want
to use is not the "real limits of the hardware"..
On 3/4/20 4:10 AM, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:49 PM Jonathan Marek <jonathan@marek.ca> wrote:
>
>> This is a command mode panel and the the msm/mdp5 driver uses the
>> vrefresh field for the actual refresh rate, while the dotclock field is
>> used for the DSI clocks. The dotclock needed to be a bit higher than
>> necessary otherwise the panel would not work.
>
> I don't know if this predates the support for defining DSI clocks
> but for what we have in the kernel right now this is wrong.
>
> struct mipi_dsi_device contains:
>
> * @hs_rate: maximum lane frequency for high speed mode in hertz, this should
> * be set to the real limits of the hardware, zero is only accepted for
> * legacy drivers
> * @lp_rate: maximum lane frequency for low power mode in hertz, this should
> * be set to the real limits of the hardware, zero is only accepted for
> * legacy drivers
>
> The MDP driver should use these frequencies for a DSI command
> mode panel, and the panel driver should define them.
>
> These two clocks are/can be/should be completely orthogonal to
> the dotclock/pixelclock inside the panel, which is likely driven from
> its own crystal directly from the panel-internal framebuffer.
>
> Yours,
> Linus Walleij
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
2020-03-04 13:16 ` Jonathan Marek
@ 2020-03-04 14:00 ` Linus Walleij
0 siblings, 0 replies; 98+ messages in thread
From: Linus Walleij @ 2020-03-04 14:00 UTC (permalink / raw)
To: Jonathan Marek; +Cc: open list:DRM PANEL DRIVERS, Brian Masney
On Wed, Mar 4, 2020 at 2:17 PM Jonathan Marek <jonathan@marek.ca> wrote:
[hs_rate / lp_rate]
> The msm DSI driver does predate the addition of those fields and doesn't
> use them at all.
I think it would be benficient to switch to these fields, because then
the .clock field (dot/pixelclock) is not abused to contain what I guess
is the desires hs_rate.
> Seems like it would be a bit of a hack too, since the frequency we want
> to use is not the "real limits of the hardware"..
That just means "clock it as high as the panel can take".
Normally that would come from the vendor datasheet of
the panel.
If you don't have the datasheet, whatever you use in the vendor
tree is fine, I suppose what is currently in .clock is fine.
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH 00/33] drm/panel: Fix dotclocks
2020-03-02 20:34 [PATCH 00/33] drm/panel: Fix dotclocks Ville Syrjala
` (32 preceding siblings ...)
2020-03-02 20:34 ` [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7 Ville Syrjala
@ 2020-03-02 21:47 ` Sam Ravnborg
2020-03-03 14:50 ` Ville Syrjälä
33 siblings, 1 reply; 98+ messages in thread
From: Sam Ravnborg @ 2020-03-02 21:47 UTC (permalink / raw)
To: Ville Syrjala; +Cc: dri-devel
Hi Ville.
On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> A lot of the panel drivers put bogus looking values into
> mode.clock. This series replaces the bogus values with
> mode.vrefresh*mode.htotal*mode.vtotal.
I think you got it wrong....
The few I sampled I would rather say that the clock
specified was the one that was possible with the present
HW and the refresh rate was then set to what was attempted.
Example:
chunghwa_claa101wb01_mode
clock is 69300 - which looks like a value you could configure
in HW. It not not a nive round value.
refresh is 60, which looks like the refresh value that was attempted.
So unless there is a big difference between the
calcualted refresh (based on the specifed clock),
and the specified clock it should be assumed that clock is OK.
And it is OK to drop refresh.
This is my take on it - but you based your patches on refresh.
So maybe you have a better rationale to do so?
Also, let's await feedback from the people cc'ed on the pathces.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread* Re: [PATCH 00/33] drm/panel: Fix dotclocks
2020-03-02 21:47 ` [PATCH 00/33] drm/panel: Fix dotclocks Sam Ravnborg
@ 2020-03-03 14:50 ` Ville Syrjälä
0 siblings, 0 replies; 98+ messages in thread
From: Ville Syrjälä @ 2020-03-03 14:50 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: dri-devel
On Mon, Mar 02, 2020 at 10:47:13PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > A lot of the panel drivers put bogus looking values into
> > mode.clock. This series replaces the bogus values with
> > mode.vrefresh*mode.htotal*mode.vtotal.
>
> I think you got it wrong....
> The few I sampled I would rather say that the clock
> specified was the one that was possible with the present
> HW and the refresh rate was then set to what was attempted.
>
> Example:
> chunghwa_claa101wb01_mode
>
> clock is 69300 - which looks like a value you could configure
> in HW. It not not a nive round value.
> refresh is 60, which looks like the refresh value that was attempted.
>
> So unless there is a big difference between the
> calcualted refresh (based on the specifed clock),
> and the specified clock it should be assumed that clock is OK.
> And it is OK to drop refresh.
>
> This is my take on it - but you based your patches on refresh.
> So maybe you have a better rationale to do so?
No. I just blindly converted everything and posted the patches
so people can tell me which way to go.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 98+ messages in thread