Hi ALL,
On 05/28/2014 03:44 PM, Andrzej Hajda wrote:
On 05/28/2014 06:50 AM, Inki Dae wrote:
On 2014년 05월 28일 05:21, Thierry Reding wrote:
On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote:
2014-05-27 16:53 GMT+09:00 Thierry Reding <thierry.reding@xxxxxxxxx>:
On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote:
Hi Thierry,
On 05/26/2014 03:41 PM, Thierry Reding wrote:
On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Signed-off-by: YoungJun Cho <yj44.cho@xxxxxxxxxxx>
Acked-by: Inki Dae <inki.dae@xxxxxxxxxxx>
Acked-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 ++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
You're totally confusing me here. Half of this patch series is about
adding i80 support to Exynos FIMD, and then you go and add what is
apparently a DSI peripheral driver here that's supposed to be used by
this new i80 support. Nothing I've been able to dig up indicates that
i80 or DSI are in anyway related.
FIMD can produce parallel RGB output or command mode in i80 style output
via parallel lines.
DSIM can accept parallel RGB stream in this case it produces MIPI DSI
video mode signal or it can accept i80 and in this case it translates it
to MIPI DSI command mode.
Then the command mode timings aren't a property of the panel at all.
Then the video mode timings aren't also a property of the panel.
Which interface mipi and display controller should use would be
decided by lcd panel type: display controller can use i80 interface
based lcd panel, and also mipi controller can use i80 interface based
lcd panel.
In here, the only difference is that lcd panel receives packets,
which includes video data or command data, packed with mipi protocol
via lane lines or receives video data or command data via parallel
lines.
And the below is LCD types,
RGB interface panel.
i80 interface panel.
MIPI based RGB interface panel.
MIPI based i80 interface panel.
RGB interface also is called video mode, and i80 interface also is
called cpu mode. In case of omap SoC, it is also called Smart panel.
i80 interface is just one of LCD types. So I think this interface
timings should be handled by frameworks related to mode in same way as
RGB interface.
Some clarification about names.
I am not an expert in command/cpu mode interface, so feel free to
correct me.
Those different terms were quite confusing for me so after some digging
(for example here [1])
I have found/ensured there is a following relation between different names:
MIPI DPI - RGB interface
MIPI DBI type A - CPU mode m68 style
MIPI DBI type B - CPU mode i80 style
MIPI DBI type C - SPI, maybe also other serial interfaces (?)
MIPI DSI - based on D-PHY-s serial protocol which can work in video or
command mode.
To add more confusion CPU mode is also named MPU mode or sys mode.
To avoid confusion in the discussion I propose use i80 only to describe
DBI type B interface,
and DSI command mode, DSI video mode to describe DSI modes.
[1]: http://www.allshore.com/pdf/DA8620.pdf
LCD is a display technology, it has nothing to do with the interface. My
point is that from Andrzej's description, and in fact from this patch
series in general, the S6E3FA0 panel is a DSI panel. Associating timings
that are i80 specific to it is therefore wrong.
Consider for instance what would happen if somebody were to use the same
panel on some other device (connected to a DSI controller). If you
specify i80 timings for the panel then the new device won't know what to
do with them because it expects DSI-related timings.
Let me try to summarize the above to make sure we're all on the same
page:
- FIMD is a display controller that can be configured to either
send RGB data or i80 data
- DSIM takes either RGB as input and outputs DSI (video mode) or
i80 as input and outputs DSI (command mode)
In both cases the panel is connected to DSIM and it takes DSI as input,
because it is a DSI panel (it doesn't understand RGB or i80). The panel
needs to describe the properties of the DSI interface so that DSIM can
be configured appropriately. DSIM in turn works as a bridge or encoder
that converts RGB or i80 to DSI (video or command mode). So it makes no
sense to describe the i80 timings for the panel because it has nothing
to do with i80. Instead the DSIM is the hardware that needs to specify
the i80 timings, so that FIMD can be configured to generate the timings
that DSIM needs.
CPU interface MIPI lane
FIMD ----------------------- DSIM --------------------- LCD Panel
Hmm... reasonable. So your point is that command mode timing should be
placed in fimd device node, not panel device node? And panel device node
should provide only a property that DSIM driver can set LCD mode
properly to i80 or rgb interface mode, and also FIMD driver can set LCD
mode to i80 or rgb interface mode.
I have no access to s6e3fa0 datasheet and Exynos datasheet I have access to
is not very verbose on the subject but it seems to be reasonable that
cs-setup, wr-setup, wr-active and wr-hold are properties only of i80
interface,
ie interface between FIMD and DSIM and they have nothing to do with DSI
command mode panel.
Those properties should be provided by DSIM to FIMD, I guess they can be
even hardcoded
in DSIM driver, no bindings required. There is still a question how DSIM
should tell FIMD about them.
I am not sure about mechanism of passing them from DSIM to FIMD, maybe
adjusting drm_display_mode
is a solution, maybe different way of communication should be used (I
see here again interface_tracker use case [2]).
[2]:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/77451
On the other side width, height and clock are properties of the panel so
they should stay
with the panel, maybe width and height could be moved from dts to
driver, I am not sure about frequency.
Is there my missing point?
And in case of Exynos, now video timing property is also placed in panel
device node so it needs to move to fimd device node.
No, video timings are properties of panels so they should stay in
panels, display
controllers should just ask panels about them.
Andrzej, do you have other opinion? I have looked into dts files for
other SoC and In most SoC, it seems that display controller node has
video timing property, not panel node. Thierry's pointing seems
reasonable to me.
I guess there could be many reasons: historical, backward compatibility,
laziness of developers :).
I agree with Thierry also.
So if everybody agrees there is only one serious issue: how the i80
properties
should be passed from DSIM to FIMD, am I right?
Right, this issue was difficult for me.
So in my first RFC v1, I placed them in FIMD dts[1].
I didn't think of that(placed them in DSIM), moved them to panel.
[1] : http://www.spinics.net/lists/dri-devel/msg57960.html
And do you think that it is also required to rename cmdmode to i80mode?
Thank you.
Best regards YJ
Regards
Andrzej
Thanks,
Inki Dae
Thierry
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
