This is v10 for the previous series[1] and few pathes are dropped
as part of this series since it would require separate rework same
will send in separately or another series.
Changes for v10:
- rebased on linux-next
- dropped few patches
- add 150 multiplication on hsync_porch
Changes for v9:
- rebase on drm-misc
- update commit messages
- add hsync_porch overflow patch
Changes for v8:
- rebase on master
- rework on commit messages
- rework video start delay
- include drq changes from previous version
Changes for v7:
- rebase on master
- collect Merlijn Wajer Tested-by credits.
Changes for v6:
- fixed all burst mode patches as per previous version comments
- rebase on master
- update proper commit message
- dropped unneeded comments
- order the patches that make review easy
Changes for v5, v4, v3, v2:
- use existing driver code construct for hblk computation
- create separate function for vblk computation
- cleanup commit messages
- update proper commit messages
- fixed checkpatch warnings/errors
- use proper return value for tcon0 probe
- add logic to get tcon0 divider values
- simplify timings code to support burst mode
- fix drq computation return values
- rebase on master
[1] https://patchwork.kernel.org/cover/10837163/
Any inputs?
Jagan.
Jagan Teki (2):
drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow
drm/sun4i: sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfer
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.18.0.321.gffc6fa0e3
Loop N1 instruction delay for burst mode devices are computed
based on horizontal sync and porch timing values.
The current driver is using u16 type for computing this hsync_porch
value, which would failed to fit within the u16 type for large sync
and porch timings devices. This would result in hsync_porch overflow
and eventually computed wrong instruction delay value.
Example, timings, where it produces the overflow
{
.hdisplay = 1080,
.hsync_start = 1080 + 408,
.hsync_end = 1080 + 408 + 4,
.htotal = 1080 + 408 + 4 + 38,
}
It reproduces the desired delay value 65487 but the correct working
value should be 7.
So, Fix it by computing hsync_porch value separately with u32 type.
Fixes: 1c1a7aa3663c ("drm/sun4i: dsi: Add burst support")
Signed-off-by: Jagan Teki <[email protected]>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 6ff585055a07..bfa7e2b146df 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -457,8 +457,9 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
u16 delay = 50 - 1;
if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
- delay = (mode->htotal - mode->hdisplay) * 150;
- delay /= (mode->clock / 1000) * 8;
+ u32 hsync_porch = (mode->htotal - mode->hdisplay) * 150;
+
+ delay = (hsync_porch / ((mode->clock / 1000) * 8));
delay -= 50;
}
--
2.18.0.321.gffc6fa0e3
Some DSI panels do use GENERIC_SHORT_WRITE_2 transfer protocol to host
DSI driver and which is similar to GENERIC_SHORT_WRITE.
Add support for the same transfer, so-that so-that the panels which are
requesting similar transfer type will process properly.
Signed-off-by: Jagan Teki <[email protected]>
Tested-by: Merlijn Wajer <[email protected]>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index bfa7e2b146df..a1fc8b520985 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -980,6 +980,7 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host *host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
ret = sun6i_dsi_dcs_write_short(dsi, msg);
break;
--
2.18.0.321.gffc6fa0e3
On Mon, May 13, 2019 at 12:11:25AM +0530, Jagan Teki wrote:
> This is v10 for the previous series[1] and few pathes are dropped
> as part of this series since it would require separate rework same
> will send in separately or another series.
APplied both, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com