Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-12 20:16 GMT+09:00 Tomasz Figa t.f...@samsung.com: On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector | / \ |
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
On 03/13/2014 08:08 AM, Inki Dae wrote: 2014-03-12 20:16 GMT+09:00 Tomasz Figa t.f...@samsung.com: On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector | / \
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-13 22:41 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/13/2014 08:08 AM, Inki Dae wrote: 2014-03-12 20:16 GMT+09:00 Tomasz Figa t.f...@samsung.com: On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector | / \ | | / \ | | | drm_bridge drm_panel | | | | | | | | FIMD MIPI-DSILVDS bridgePanel Thanks, Inki Dae Will review your patch series soon. Thanks in advance. Regards Andrzej ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector | / \ | | / \ | | | drm_bridge
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Will review your patch series soon. Thanks, Inki Dae 2. I have used video interface bindings to make link between bridge and LVDS panel. Other places where such links can be created are: a) link between DSI master and slave, I wonder if it is always neccessary, DSI bus is also video bus, b) link between FIMD(display controller) and DSI Master, currently Exynos DRM framework uses driver's hardcoded links, converting it to video interface bindings should be done (if required) by separate patches. The patchset is based on Sean's Paul Exynos refactor patches v4 [1]. To work properly porch calculation should be fixed according to my comment [2]. It is the 2nd iteration of the patches, main changes: - based on v4 refactor patches, - added arndale related stuff. Other changes are described in individual patches. [1] http://permalink.gmane.org/gmane.comp.video.dri.devel/99264 [2] http://permalink.gmane.org/gmane.comp.video.dri.devel/99826 Regards Andrzej Andrzej Hajda (21): drm_mipi_dsi: add flags to DSI messages drm/exynos: delay fbdev initialization until an output is connected exynos/dsim: add DT bindings drm/exynos: add DSIM driver panel/s6e8aa0: add DT bindings drm/panel: add S6E8AA0 driver panel/tc358764: add DT bindings drm/panel: add TC358764 driver panel/simple: add video interface DT bindings panel/hv070wsa-100: add DT bindings drm/panel: add support for BOE HV070WSA-100 panel to simple-panel ARM: dts: exynos4: add MIPI DSI Master node ARM: dts: exynos4210-trats: add panel node ARM: dts: exynos4412-trats2: add panel node ARM: dts: exynos5250: add mipi-phy node ARM: dts: exynos5250: add display power domain node ARM: dts: exynos5250: add DSI node ARM: dts: exynos5250-arndale: add display regulators ARM: dts: exynos5250-arndale: add dsi and panel nodes ARM: dts: exynos4210-trats: enable exynos/fimd node ARM: dts: exynos4412-trats2: enable exynos/fimd node .../devicetree/bindings/panel/boe,hv070wsa-100.txt |7 + .../devicetree/bindings/panel/samsung,s6e8aa0.txt | 51 + .../devicetree/bindings/panel/simple-panel.txt |6 + .../devicetree/bindings/panel/toshiba,tc358764.txt | 41 + .../devicetree/bindings/video/exynos_dsim.txt | 53 + arch/arm/boot/dts/exynos4.dtsi | 14 + arch/arm/boot/dts/exynos4210-trats.dts | 42 + arch/arm/boot/dts/exynos4412-trats2.dts| 51 + arch/arm/boot/dts/exynos5250-arndale.dts | 63 + arch/arm/boot/dts/exynos5250.dtsi | 25 + drivers/gpu/drm/exynos/Kconfig |9 + drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 26 +- drivers/gpu/drm/exynos/exynos_drm_drv.h|1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1402 drivers/gpu/drm/exynos/exynos_drm_fb.c |3 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +- drivers/gpu/drm/panel/Kconfig | 14 + drivers/gpu/drm/panel/Makefile |2 + drivers/gpu/drm/panel/panel-s6e8aa0.c | 1064 +++ drivers/gpu/drm/panel/panel-simple.c | 25 +
