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 at gmail.com>: >>>>> 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 at samsung.com> >>>>>>>> Acked-by: Inki Dae <inki.dae at samsung.com> >>>>>>>> Acked-by: Kyungmin Park <kyungmin.park at samsung.com> >>>>>>>> --- >>>>>>>> .../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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
