Hi Laurent,
On 10 January 2013 05:05, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Vikas,
Thank you for the patch.
On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
On 3 January 2013 16:29, Tomasz Figa t.figa@samsung.com wrote:
On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
From: Vikas Sajjan vikas.sajjan@linaro.org
Signed-off-by: Vikas Sajjan vikas.sajjan@linaro.org
include/video/display.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/video/display.h b/include/video/display.h index b639fd0..fb2f437 100644 --- a/include/video/display.h +++ b/include/video/display.h @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
void (*enable_hs)(struct video_source *src, bool enable);
/* frame related */int (*get_frame_done)(struct video_source *src);int (*clear_frame_done)(struct video_source *src);int (*set_early_blank_mode)(struct video_source *src, int power);int (*set_blank_mode)(struct video_source *src, int power);I'm not sure if all those extra ops are needed in any way.
Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only FB_BLANK_UNBLANK status, which basically equals to the already existing enable operation, while set_early_blank mode handles only FB_BLANK_POWERDOWN, being equal to disable callback.
Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as of now, but FB_BLANK_NORMAL will be supported in future. If not for Exynos, i think it will be need for other SoCs which support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
Could you please explain in a bit more details what the set_early_blank_mode and set_blank_mode operations do ?
with reference to Mr. Inki Dae's patch and discussion http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/00413.html http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/02247.html
set_early_blank_mode: - sets the framebuffer blank mode. - this callback should be called prior to fb_blank() by a client driver only if needed set_blank_mode: - sets framebuffer blank mode - this callback should be called after fb_blank() by a client driver only if needed.
In case of MIPI-DSI based video mode LCD Panel, for lcd power off, the power off commands should be transferred to lcd panel with display and mipi-dsi controller enabled, because the commands is set to lcd panel at vsync porch period, hence set_early_blank_mode() was introduced and should be called prior to fb_blank() as mentioned in the above 2 links.
I think Mr. Inki Dae can throw more light on this.
Both get_frame_done and clear_frame_done do not look at anything used at the moment and if frame done status monitoring will be ever needed, I think a better way should be implemented.
You are right, as of now Exynos MIPI DSI Panels are NOT using these callbacks, but as you mentioned we will need frame done status monitoring anyways, so i included these callbacks here. Will check, if we can implement any better method.
Do you expect the entity drivers (and in particular the panel drivers) to require frame done notification ? If so, could you explain your use case(s) ?
In our Exynos MIPI DSIM H/W, once MIPI DSIM transfers whole image frame, interrupt will raised to indicate the same. as part of the mipi_dsim_master_ops() we have get_dsim_frame_done() and clear_dsim_frame_done() ops. But as of now we are also _NOT_ using these ops in any particular use case. So i guess as of now we can park it, later if we find any need for the same we can add it.
-- Regards,
Laurent Pinchart
-- Thanks and Regards Vikas Sajjan SAMSUNG Research India - Banglore.