* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-14 4:57 Vikas Sajjan 2012-12-17 22:00 ` Laurent Pinchart 0 siblings, 1 reply; 153+ messages in thread From: Vikas Sajjan @ 2012-12-14 4:57 UTC (permalink / raw) To: laurent.pinchart, tomi.valkeinen, alan, thierry.reding, dri-devel, robdclark, inki.dae [-- Attachment #1.1: Type: text/plain, Size: 10979 bytes --] Hi everybody, Here's the second RFC of what was previously known as the Generic Panel Framework. I won't repeat all the background information from the first version here, you can read it at http://lwn.net/Articles/512363/. <http://lwn.net/Articles/512363/> Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. After discussing the Generic Panel Framework at Linaro Connect we came to the conclusion that "panel" is too limiting a name. In addition to panel drivers we also want to share transmitter and bridge drivers between DRM and FBDEV. I have thus introduced the concept of a display entity in this version to represent any hardware block that sources, processes or sinks display-related video streams. This patch set implements the Common Display Framework (CDF). Display entities are connected to at least one video data bus, and optionally to a control bus. The video data busses carry display-related video data out of sources (such as a CRTC in a display controller) to sinks (such as a panel or a monitor), optionally going through transmitters, encoders, decoders, bridges or other similar devices. A CRTC or a panel will usually be connected to a single data bus, while an encoder or a transmitter will be connected to two data busses. While some display entities don't require any configuration (DPI panels are a good example), many of them are connected to a control bus accessible to the CPU. Control requests can be sent on a dedicated control bus (such as I2C or SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To support both options the CDF display entity model separates the control and data busses in different APIs. Display entities are abstract object that must be implemented by a real device. The device sits on its control bus and is registered with the Linux device core and matched with his driver using the control bus specific API. The CDF doesn't create a display entity class or bus, display entity drivers thus standard Linux kernel drivers using existing busses. When a display entity driver probes a device it must create an instance of the display_entity structure, initialize it and register it with the CDF core. The display entity exposes abstract operations through function pointers, and the entity driver must implement those operations. They are divided in two groups, control operations and video operations. Control operations are called by upper-level drivers, usually in response to a request originating from userspace. They control the display entity state and operation. Currently defined control operations are - set_state(), to control the state of the entity (off, standby or on) - update(), to trigger a display update (for entities that implement manual update, such as manual-update panels that store frames in their internal frame buffer) - get_modes(), to retrieve the video modes supported by the entity - get_params(), to retrive the data bus parameters at the entity input (sink) - get_size(), to retrive the entity physical size (applicable to panels only) Video operations are called by downstream entities on upstream entities (from a video data bus point of view) to control the video operation. The only currently defined video operation is - set_stream(), to start (in continuous or single-shot mode) the video stream http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver implemented using the CDF interacts with the other components in the system. The first page shows the panel driver receiving control request from the display controller driver at its top side, usually in response to a DRM or FBDEV API call. It then issues requests on its control bus (several possible control busses are shown on the diagram, the panel driver uses one of them only) and calls video operations of the display controller on its left side to control the video stream. The second page shows a slightly more complex use case, with a display controller that includes an LVDS transceiver (shown as two separate entities on the left hand side), connected to an LVDS to DSI converter that is itself connected to a DSI panel module. The panel module contains a DSI panel controller that drives the LCD panel. While this particular example is probably too theoretical to be found in real devices, it illustrates the concept of display entities chains. The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most green arrow). The driver is aware of the next entity in the chain, and relays the call down, possibly mangling the request and/or the reply, and accessing the device it handles through its control bus (not shown here). When the operations reaches the last entity in the chain the video operations are called upstream to control the video stream. Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the display entities can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling other display entities through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display controller and display entity drivers would take a reference to each other. Those circular references would make driver unloading impossible. One possible solution to this problem would be to simulate an unplug event for the display entity, to force the display driver to release the dislay entities it uses. We would need a userspace API for that though. Better solutions would of course be welcome. Please note taht most of the display entities on devices I own are jut dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. This is why I hope to see you using the CDF with your display device and tell me what needs to be modified/improved/redesigned. This patch set includes three sections: - The first patch adds the generic display entity core - The third patch adds a MIPI DBI bus, which is a mixed control and data video bus using parallel data (similarly to a microprocessor external data bus) - The second, fourth and fifth patches add drivers for DPI panels (no control bus) and two DBI panel controllers. The patches are available in my git tree at git://linuxtv.org/pinchartl/fbdev.git lcdc-panel http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel For convenience I've included Steffen's display helpers patches on which this series is based (see http://www.spinics.net/lists/dri-devel/msg30664.html for more information about those), as well as modifications to the sh-mobile-lcdc driver to use the CDF. You can read the code to see how the driver uses the CDF to interface panels. Please note that the sh-mobile-lcdc implementation is still work in progress, its set_stream operation implementation doesn't enable/disable the video stream yet as it should. I still need to gather notes from v1 and v2 and create proper documentation from them. I didn't want to delay these patches any longer given the number of people who were waiting for them, I will try to do work on documentation next week. As already mentioned in v1, I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If you can find a clever way to solve the cyclic references issue described above I'll buy you a beer at the next conference we will both attend. If you think the proposed solution is too complex, or too simple, I'm all ears. Laurent Pinchart (5): video: Add generic display entity core video: panel: Add DPI panel support video: display: Add MIPI DBI bus support video: panel: Add R61505 panel support video: panel: Add R61517 panel support drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/video/display/Kconfig | 39 +++ drivers/video/display/Makefile | 5 + drivers/video/display/display-core.c | 362 ++++++++++++++++++++++ drivers/video/display/mipi-dbi-bus.c | 228 ++++++++++++++ drivers/video/display/panel-dpi.c | 147 +++++++++ drivers/video/display/panel-r61505.c | 554 ++++++++++++++++++++++++++++++++++ drivers/video/display/panel-r61517.c | 447 +++++++++++++++++++++++++++ include/video/display.h | 155 ++++++++++ include/video/mipi-dbi-bus.h | 125 ++++++++ include/video/panel-dpi.h | 24 ++ include/video/panel-r61505.h | 27 ++ include/video/panel-r61517.h | 28 ++ 14 files changed, 2143 insertions(+), 0 deletions(-) create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile create mode 100644 drivers/video/display/display-core.c create mode 100644 drivers/video/display/mipi-dbi-bus.c create mode 100644 drivers/video/display/panel-dpi.c create mode 100644 drivers/video/display/panel-r61505.c create mode 100644 drivers/video/display/panel-r61517.c create mode 100644 include/video/display.h create mode 100644 include/video/mipi-dbi-bus.h create mode 100644 include/video/panel-dpi.h create mode 100644 include/video/panel-r61505.h create mode 100644 include/video/panel-r61517.h Hi All, I was thinking of porting samsung exynos 5250 display driver as per CDF, but i had certain doubts and wanted to discuss with you guys, 1. Samsung Exynos supports MIPI DSI based display panels, wondering how to accommodate such thing in CDF. I mean how do I register my MIPI DSI driver with CDF. because the s6e8ax0 AMOLED lcd driver registers itself with MIPI DSI driver, and later the MIPI DSI driver probe calls the probe and init sequence of the LCD driver. Wanted know if anybody about any thoughts on this ? 2.One more thing is, when went through the patchset I coudn't get who will register the mipi_dbi_bus_ops? Regards Vikas Sajjan -- Regards, Laurent Pinchart [-- Attachment #1.2: Type: text/html, Size: 12370 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-14 4:57 [RFC v2 0/5] Common Display Framework Vikas Sajjan @ 2012-12-17 22:00 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 22:00 UTC (permalink / raw) To: Vikas Sajjan; +Cc: dri-devel, tomi.valkeinen Hi Vikas, On Friday 14 December 2012 10:27:12 Vikas Sajjan wrote: > > Hi All, > > I was thinking of porting samsung exynos 5250 display driver as per CDF, > > but i had certain doubts and wanted to discuss with you guys, > > 1. Samsung Exynos supports MIPI DSI based display panels, wondering how to > accommodate such thing in. I mean how do I register my MIPI DSI driver > with CDF. because the s6e8ax0 AMOLED lcd driver registers itself with MIPI > DSI driver, and later the MIPI DSI driver probe calls the probe and init > sequence of the LCD driver. > Wanted know if anybody about any thoughts on this ? As explained in my previous mail, MIPI DSI panels should be supported in a similar way as MIPI DPI panels. The DSI API is missing, but only because nobody has implemented it yet. > 2.One more thing is, when went through the patchset I coudn't get who > will register the mipi_dbi_bus_ops? That's the display controller driver. A sample implementation is available at http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel, see the "fbdev: sh_mobile_lcdc: Add generic panel support" and "fbdev: sh_mobile_lcdc: MIPI DBI bus support" patches. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* [RFC v2 0/5] Common Display Framework @ 2012-11-22 21:45 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-11-22 21:45 UTC (permalink / raw) To: linux-fbdev, dri-devel Cc: linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Hi everybody, Here's the second RFC of what was previously known as the Generic Panel Framework. I won't repeat all the background information from the first version here, you can read it at http://lwn.net/Articles/512363/. Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. After discussing the Generic Panel Framework at Linaro Connect we came to the conclusion that "panel" is too limiting a name. In addition to panel drivers we also want to share transmitter and bridge drivers between DRM and FBDEV. I have thus introduced the concept of a display entity in this version to represent any hardware block that sources, processes or sinks display-related video streams. This patch set implements the Common Display Framework (CDF). Display entities are connected to at least one video data bus, and optionally to a control bus. The video data busses carry display-related video data out of sources (such as a CRTC in a display controller) to sinks (such as a panel or a monitor), optionally going through transmitters, encoders, decoders, bridges or other similar devices. A CRTC or a panel will usually be connected to a single data bus, while an encoder or a transmitter will be connected to two data busses. While some display entities don't require any configuration (DPI panels are a good example), many of them are connected to a control bus accessible to the CPU. Control requests can be sent on a dedicated control bus (such as I2C or SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To support both options the CDF display entity model separates the control and data busses in different APIs. Display entities are abstract object that must be implemented by a real device. The device sits on its control bus and is registered with the Linux device core and matched with his driver using the control bus specific API. The CDF doesn't create a display entity class or bus, display entity drivers thus standard Linux kernel drivers using existing busses. When a display entity driver probes a device it must create an instance of the display_entity structure, initialize it and register it with the CDF core. The display entity exposes abstract operations through function pointers, and the entity driver must implement those operations. They are divided in two groups, control operations and video operations. Control operations are called by upper-level drivers, usually in response to a request originating from userspace. They control the display entity state and operation. Currently defined control operations are - set_state(), to control the state of the entity (off, standby or on) - update(), to trigger a display update (for entities that implement manual update, such as manual-update panels that store frames in their internal frame buffer) - get_modes(), to retrieve the video modes supported by the entity - get_params(), to retrive the data bus parameters at the entity input (sink) - get_size(), to retrive the entity physical size (applicable to panels only) Video operations are called by downstream entities on upstream entities (from a video data bus point of view) to control the video operation. The only currently defined video operation is - set_stream(), to start (in continuous or single-shot mode) the video stream http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver implemented using the CDF interacts with the other components in the system. The first page shows the panel driver receiving control request from the display controller driver at its top side, usually in response to a DRM or FBDEV API call. It then issues requests on its control bus (several possible control busses are shown on the diagram, the panel driver uses one of them only) and calls video operations of the display controller on its left side to control the video stream. The second page shows a slightly more complex use case, with a display controller that includes an LVDS transceiver (shown as two separate entities on the left hand side), connected to an LVDS to DSI converter that is itself connected to a DSI panel module. The panel module contains a DSI panel controller that drives the LCD panel. While this particular example is probably too theoretical to be found in real devices, it illustrates the concept of display entities chains. The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most green arrow). The driver is aware of the next entity in the chain, and relays the call down, possibly mangling the request and/or the reply, and accessing the device it handles through its control bus (not shown here). When the operations reaches the last entity in the chain the video operations are called upstream to control the video stream. Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the display entities can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling other display entities through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display controller and display entity drivers would take a reference to each other. Those circular references would make driver unloading impossible. One possible solution to this problem would be to simulate an unplug event for the display entity, to force the display driver to release the dislay entities it uses. We would need a userspace API for that though. Better solutions would of course be welcome. Please note taht most of the display entities on devices I own are jut dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. This is why I hope to see you using the CDF with your display device and tell me what needs to be modified/improved/redesigned. This patch set includes three sections: - The first patch adds the generic display entity core - The third patch adds a MIPI DBI bus, which is a mixed control and data video bus using parallel data (similarly to a microprocessor external data bus) - The second, fourth and fifth patches add drivers for DPI panels (no control bus) and two DBI panel controllers. The patches are available in my git tree at git://linuxtv.org/pinchartl/fbdev.git lcdc-panel http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel For convenience I've included Steffen's display helpers patches on which this series is based (see http://www.spinics.net/lists/dri-devel/msg30664.html for more information about those), as well as modifications to the sh-mobile-lcdc driver to use the CDF. You can read the code to see how the driver uses the CDF to interface panels. Please note that the sh-mobile-lcdc implementation is still work in progress, its set_stream operation implementation doesn't enable/disable the video stream yet as it should. I still need to gather notes from v1 and v2 and create proper documentation from them. I didn't want to delay these patches any longer given the number of people who were waiting for them, I will try to do work on documentation next week. As already mentioned in v1, I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If you can find a clever way to solve the cyclic references issue described above I'll buy you a beer at the next conference we will both attend. If you think the proposed solution is too complex, or too simple, I'm all ears. Laurent Pinchart (5): video: Add generic display entity core video: panel: Add DPI panel support video: display: Add MIPI DBI bus support video: panel: Add R61505 panel support video: panel: Add R61517 panel support drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/video/display/Kconfig | 39 +++ drivers/video/display/Makefile | 5 + drivers/video/display/display-core.c | 362 ++++++++++++++++++++++ drivers/video/display/mipi-dbi-bus.c | 228 ++++++++++++++ drivers/video/display/panel-dpi.c | 147 +++++++++ drivers/video/display/panel-r61505.c | 554 ++++++++++++++++++++++++++++++++++ drivers/video/display/panel-r61517.c | 447 +++++++++++++++++++++++++++ include/video/display.h | 155 ++++++++++ include/video/mipi-dbi-bus.h | 125 ++++++++ include/video/panel-dpi.h | 24 ++ include/video/panel-r61505.h | 27 ++ include/video/panel-r61517.h | 28 ++ 14 files changed, 2143 insertions(+), 0 deletions(-) create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile create mode 100644 drivers/video/display/display-core.c create mode 100644 drivers/video/display/mipi-dbi-bus.c create mode 100644 drivers/video/display/panel-dpi.c create mode 100644 drivers/video/display/panel-r61505.c create mode 100644 drivers/video/display/panel-r61517.c create mode 100644 include/video/display.h create mode 100644 include/video/mipi-dbi-bus.h create mode 100644 include/video/panel-dpi.h create mode 100644 include/video/panel-r61505.h create mode 100644 include/video/panel-r61517.h -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* [RFC v2 0/5] Common Display Framework @ 2012-11-22 21:45 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-11-22 21:45 UTC (permalink / raw) To: linux-fbdev, dri-devel Cc: linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Hi everybody, Here's the second RFC of what was previously known as the Generic Panel Framework. I won't repeat all the background information from the first version here, you can read it at http://lwn.net/Articles/512363/. Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. After discussing the Generic Panel Framework at Linaro Connect we came to the conclusion that "panel" is too limiting a name. In addition to panel drivers we also want to share transmitter and bridge drivers between DRM and FBDEV. I have thus introduced the concept of a display entity in this version to represent any hardware block that sources, processes or sinks display-related video streams. This patch set implements the Common Display Framework (CDF). Display entities are connected to at least one video data bus, and optionally to a control bus. The video data busses carry display-related video data out of sources (such as a CRTC in a display controller) to sinks (such as a panel or a monitor), optionally going through transmitters, encoders, decoders, bridges or other similar devices. A CRTC or a panel will usually be connected to a single data bus, while an encoder or a transmitter will be connected to two data busses. While some display entities don't require any configuration (DPI panels are a good example), many of them are connected to a control bus accessible to the CPU. Control requests can be sent on a dedicated control bus (such as I2C or SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To support both options the CDF display entity model separates the control and data busses in different APIs. Display entities are abstract object that must be implemented by a real device. The device sits on its control bus and is registered with the Linux device core and matched with his driver using the control bus specific API. The CDF doesn't create a display entity class or bus, display entity drivers thus standard Linux kernel drivers using existing busses. When a display entity driver probes a device it must create an instance of the display_entity structure, initialize it and register it with the CDF core. The display entity exposes abstract operations through function pointers, and the entity driver must implement those operations. They are divided in two groups, control operations and video operations. Control operations are called by upper-level drivers, usually in response to a request originating from userspace. They control the display entity state and operation. Currently defined control operations are - set_state(), to control the state of the entity (off, standby or on) - update(), to trigger a display update (for entities that implement manual update, such as manual-update panels that store frames in their internal frame buffer) - get_modes(), to retrieve the video modes supported by the entity - get_params(), to retrive the data bus parameters at the entity input (sink) - get_size(), to retrive the entity physical size (applicable to panels only) Video operations are called by downstream entities on upstream entities (from a video data bus point of view) to control the video operation. The only currently defined video operation is - set_stream(), to start (in continuous or single-shot mode) the video stream http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver implemented using the CDF interacts with the other components in the system. The first page shows the panel driver receiving control request from the display controller driver at its top side, usually in response to a DRM or FBDEV API call. It then issues requests on its control bus (several possible control busses are shown on the diagram, the panel driver uses one of them only) and calls video operations of the display controller on its left side to control the video stream. The second page shows a slightly more complex use case, with a display controller that includes an LVDS transceiver (shown as two separate entities on the left hand side), connected to an LVDS to DSI converter that is itself connected to a DSI panel module. The panel module contains a DSI panel controller that drives the LCD panel. While this particular example is probably too theoretical to be found in real devices, it illustrates the concept of display entities chains. The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most green arrow). The driver is aware of the next entity in the chain, and relays the call down, possibly mangling the request and/or the reply, and accessing the device it handles through its control bus (not shown here). When the operations reaches the last entity in the chain the video operations are called upstream to control the video stream. Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the display entities can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling other display entities through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display controller and display entity drivers would take a reference to each other. Those circular references would make driver unloading impossible. One possible solution to this problem would be to simulate an unplug event for the display entity, to force the display driver to release the dislay entities it uses. We would need a userspace API for that though. Better solutions would of course be welcome. Please note taht most of the display entities on devices I own are jut dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. This is why I hope to see you using the CDF with your display device and tell me what needs to be modified/improved/redesigned. This patch set includes three sections: - The first patch adds the generic display entity core - The third patch adds a MIPI DBI bus, which is a mixed control and data video bus using parallel data (similarly to a microprocessor external data bus) - The second, fourth and fifth patches add drivers for DPI panels (no control bus) and two DBI panel controllers. The patches are available in my git tree at git://linuxtv.org/pinchartl/fbdev.git lcdc-panel http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel For convenience I've included Steffen's display helpers patches on which this series is based (see http://www.spinics.net/lists/dri-devel/msg30664.html for more information about those), as well as modifications to the sh-mobile-lcdc driver to use the CDF. You can read the code to see how the driver uses the CDF to interface panels. Please note that the sh-mobile-lcdc implementation is still work in progress, its set_stream operation implementation doesn't enable/disable the video stream yet as it should. I still need to gather notes from v1 and v2 and create proper documentation from them. I didn't want to delay these patches any longer given the number of people who were waiting for them, I will try to do work on documentation next week. As already mentioned in v1, I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If you can find a clever way to solve the cyclic references issue described above I'll buy you a beer at the next conference we will both attend. If you think the proposed solution is too complex, or too simple, I'm all ears. Laurent Pinchart (5): video: Add generic display entity core video: panel: Add DPI panel support video: display: Add MIPI DBI bus support video: panel: Add R61505 panel support video: panel: Add R61517 panel support drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/video/display/Kconfig | 39 +++ drivers/video/display/Makefile | 5 + drivers/video/display/display-core.c | 362 ++++++++++++++++++++++ drivers/video/display/mipi-dbi-bus.c | 228 ++++++++++++++ drivers/video/display/panel-dpi.c | 147 +++++++++ drivers/video/display/panel-r61505.c | 554 ++++++++++++++++++++++++++++++++++ drivers/video/display/panel-r61517.c | 447 +++++++++++++++++++++++++++ include/video/display.h | 155 ++++++++++ include/video/mipi-dbi-bus.h | 125 ++++++++ include/video/panel-dpi.h | 24 ++ include/video/panel-r61505.h | 27 ++ include/video/panel-r61517.h | 28 ++ 14 files changed, 2143 insertions(+), 0 deletions(-) create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile create mode 100644 drivers/video/display/display-core.c create mode 100644 drivers/video/display/mipi-dbi-bus.c create mode 100644 drivers/video/display/panel-dpi.c create mode 100644 drivers/video/display/panel-r61505.c create mode 100644 drivers/video/display/panel-r61517.c create mode 100644 include/video/display.h create mode 100644 include/video/mipi-dbi-bus.h create mode 100644 include/video/panel-dpi.h create mode 100644 include/video/panel-r61505.h create mode 100644 include/video/panel-r61517.h -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-22 21:45 ` Laurent Pinchart (?) @ 2012-11-23 14:51 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-23 14:51 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 3954 bytes --] Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Hi everybody, > > Here's the second RFC of what was previously known as the Generic Panel > Framework. Nice work! Thanks for working on this. I was doing some testing with the code, seeing how to use it in omapdss. Here are some thoughts: In your model the DSS gets the panel devices connected to it from platform data. After the DSS and the panel drivers are loaded, DSS gets a notification and connects DSS and the panel. I think it's a bit limited way. First of all, it'll make the DT data a bit more complex (although this is not a major problem). With your model, you'll need something like: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: &dpi0 { panel = &dpi-panel; }; / { dpi-panel: dpi-panel { ...panel data...; }; }; Second, it'll prevent hotplug, and even if real hotplug would not be supported, it'll prevent cases where the connected panel must be found dynamically (like reading ID from eeprom). Third, it kinda creates a cyclical dependency: the DSS needs to know about the panel and calls ops in the panel, and the panel calls ops in the DSS. I'm not sure if this is an actual problem, but I usually find it simpler if calls are done only in one direction. What I suggest is take a simpler approach, something alike to how regulators or gpios are used, even if slightly more complex than those: the entity that has a video output (SoC's DSS, external chips) offers that video output as resource. It doesn't know or care who uses it. The user of the video output (panel, external chips) will find the video output (to which it is connected in the HW) by some means, and will use different operations on that output to operate the device. This would give us something like the following DT data: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: / { dpi-panel: dpi-panel { source = <&dpi0>; ...panel data...; }; }; The panel driver would do something like this in its probe: int dpi_panel_probe() { // Find the video source, increase ref src = get_video_source_from_of("source"); // Reserve the video source for us. others can still get and // observe it, but cannot use it as video data source. // I think this should cascade upstream, so that after this call // each video entity from the panel to the SoC's CRTC is // reserved and locked for this video pipeline. reserve_video_source(src); // set DPI HW configuration, like DPI data lines. The // configuration would come from panel's platform data set_dpi_config(src, config); // register this panel as a display. register_display(this); } The DSS's dpi driver would do something like: int dss_dpi_probe() { // register as a DPI video source register_video_source(this); } A DSI-2-DPI chip would do something like: int dsi2dpi_probe() { // get, reserve and config the DSI bus from SoC src = get_video_source_from_of("source"); reserve_video_source(src); set_dsi_config(src, config); // register as a DPI video source register_video_source(this); } Here we wouldn't have similar display_entity as you have, but video sources and displays. Video sources are elements in the video pipeline, and a video source is used only by the next downstream element. The last element in the pipeline would not be a video source, but a display, which would be used by the upper layer. Video source's ops would deal with things related to the video bus in question, like configuring data lanes, sending DSI packets, etc. The display ops would be more high level things, like enable, update, etc. Actually, I guess you could consider the display to represent and deal with the whole pipeline, while video source deals with the bus between two display entities. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-23 14:51 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-23 14:51 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 3954 bytes --] Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Hi everybody, > > Here's the second RFC of what was previously known as the Generic Panel > Framework. Nice work! Thanks for working on this. I was doing some testing with the code, seeing how to use it in omapdss. Here are some thoughts: In your model the DSS gets the panel devices connected to it from platform data. After the DSS and the panel drivers are loaded, DSS gets a notification and connects DSS and the panel. I think it's a bit limited way. First of all, it'll make the DT data a bit more complex (although this is not a major problem). With your model, you'll need something like: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: &dpi0 { panel = &dpi-panel; }; / { dpi-panel: dpi-panel { ...panel data...; }; }; Second, it'll prevent hotplug, and even if real hotplug would not be supported, it'll prevent cases where the connected panel must be found dynamically (like reading ID from eeprom). Third, it kinda creates a cyclical dependency: the DSS needs to know about the panel and calls ops in the panel, and the panel calls ops in the DSS. I'm not sure if this is an actual problem, but I usually find it simpler if calls are done only in one direction. What I suggest is take a simpler approach, something alike to how regulators or gpios are used, even if slightly more complex than those: the entity that has a video output (SoC's DSS, external chips) offers that video output as resource. It doesn't know or care who uses it. The user of the video output (panel, external chips) will find the video output (to which it is connected in the HW) by some means, and will use different operations on that output to operate the device. This would give us something like the following DT data: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: / { dpi-panel: dpi-panel { source = <&dpi0>; ...panel data...; }; }; The panel driver would do something like this in its probe: int dpi_panel_probe() { // Find the video source, increase ref src = get_video_source_from_of("source"); // Reserve the video source for us. others can still get and // observe it, but cannot use it as video data source. // I think this should cascade upstream, so that after this call // each video entity from the panel to the SoC's CRTC is // reserved and locked for this video pipeline. reserve_video_source(src); // set DPI HW configuration, like DPI data lines. The // configuration would come from panel's platform data set_dpi_config(src, config); // register this panel as a display. register_display(this); } The DSS's dpi driver would do something like: int dss_dpi_probe() { // register as a DPI video source register_video_source(this); } A DSI-2-DPI chip would do something like: int dsi2dpi_probe() { // get, reserve and config the DSI bus from SoC src = get_video_source_from_of("source"); reserve_video_source(src); set_dsi_config(src, config); // register as a DPI video source register_video_source(this); } Here we wouldn't have similar display_entity as you have, but video sources and displays. Video sources are elements in the video pipeline, and a video source is used only by the next downstream element. The last element in the pipeline would not be a video source, but a display, which would be used by the upper layer. Video source's ops would deal with things related to the video bus in question, like configuring data lanes, sending DSI packets, etc. The display ops would be more high level things, like enable, update, etc. Actually, I guess you could consider the display to represent and deal with the whole pipeline, while video source deals with the bus between two display entities. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-23 14:51 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-23 14:51 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 3954 bytes --] Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Hi everybody, > > Here's the second RFC of what was previously known as the Generic Panel > Framework. Nice work! Thanks for working on this. I was doing some testing with the code, seeing how to use it in omapdss. Here are some thoughts: In your model the DSS gets the panel devices connected to it from platform data. After the DSS and the panel drivers are loaded, DSS gets a notification and connects DSS and the panel. I think it's a bit limited way. First of all, it'll make the DT data a bit more complex (although this is not a major problem). With your model, you'll need something like: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: &dpi0 { panel = &dpi-panel; }; / { dpi-panel: dpi-panel { ...panel data...; }; }; Second, it'll prevent hotplug, and even if real hotplug would not be supported, it'll prevent cases where the connected panel must be found dynamically (like reading ID from eeprom). Third, it kinda creates a cyclical dependency: the DSS needs to know about the panel and calls ops in the panel, and the panel calls ops in the DSS. I'm not sure if this is an actual problem, but I usually find it simpler if calls are done only in one direction. What I suggest is take a simpler approach, something alike to how regulators or gpios are used, even if slightly more complex than those: the entity that has a video output (SoC's DSS, external chips) offers that video output as resource. It doesn't know or care who uses it. The user of the video output (panel, external chips) will find the video output (to which it is connected in the HW) by some means, and will use different operations on that output to operate the device. This would give us something like the following DT data: soc-base.dtsi: dss { dpi0: dpi { }; }; board.dts: / { dpi-panel: dpi-panel { source = <&dpi0>; ...panel data...; }; }; The panel driver would do something like this in its probe: int dpi_panel_probe() { // Find the video source, increase ref src = get_video_source_from_of("source"); // Reserve the video source for us. others can still get and // observe it, but cannot use it as video data source. // I think this should cascade upstream, so that after this call // each video entity from the panel to the SoC's CRTC is // reserved and locked for this video pipeline. reserve_video_source(src); // set DPI HW configuration, like DPI data lines. The // configuration would come from panel's platform data set_dpi_config(src, config); // register this panel as a display. register_display(this); } The DSS's dpi driver would do something like: int dss_dpi_probe() { // register as a DPI video source register_video_source(this); } A DSI-2-DPI chip would do something like: int dsi2dpi_probe() { // get, reserve and config the DSI bus from SoC src = get_video_source_from_of("source"); reserve_video_source(src); set_dsi_config(src, config); // register as a DPI video source register_video_source(this); } Here we wouldn't have similar display_entity as you have, but video sources and displays. Video sources are elements in the video pipeline, and a video source is used only by the next downstream element. The last element in the pipeline would not be a video source, but a display, which would be used by the upper layer. Video source's ops would deal with things related to the video bus in question, like configuring data lanes, sending DSI packets, etc. The display ops would be more high level things, like enable, update, etc. Actually, I guess you could consider the display to represent and deal with the whole pipeline, while video source deals with the bus between two display entities. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-23 14:51 ` Tomi Valkeinen @ 2012-12-17 14:36 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 14:36 UTC (permalink / raw) To: Tomi Valkeinen Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 5321 bytes --] Hi Tomi, I finally have time to work on a v3 :-) On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > On 2012-11-22 23:45, Laurent Pinchart wrote: > > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > > Hi everybody, > > > > Here's the second RFC of what was previously known as the Generic Panel > > Framework. > > Nice work! Thanks for working on this. > > I was doing some testing with the code, seeing how to use it in omapdss. > Here are some thoughts: > > In your model the DSS gets the panel devices connected to it from > platform data. After the DSS and the panel drivers are loaded, DSS gets > a notification and connects DSS and the panel. > > I think it's a bit limited way. First of all, it'll make the DT data a > bit more complex (although this is not a major problem). With your > model, you'll need something like: > > soc-base.dtsi: > > dss { > dpi0: dpi { > }; > }; > > board.dts: > > &dpi0 { > panel = &dpi-panel; > }; > > / { > dpi-panel: dpi-panel { > ...panel data...; > }; > }; > > Second, it'll prevent hotplug, and even if real hotplug would not be > supported, it'll prevent cases where the connected panel must be found > dynamically (like reading ID from eeprom). Hotplug definitely needs to be supported, as the common display framework also targets HDMI and DP. The notification mechanism was actually designed to support hotplug. How do you see the proposal preventing hotplug ? > Third, it kinda creates a cyclical dependency: the DSS needs to know > about the panel and calls ops in the panel, and the panel calls ops in > the DSS. I'm not sure if this is an actual problem, but I usually find > it simpler if calls are done only in one direction. I don't see any way around that. The panel is not a standalone entity that can only receive calls (as it needs to control video streams, per your request :-)) or only emit calls (as something needs to control it, userspace doesn't control the panel directly). > What I suggest is take a simpler approach, something alike to how regulators > or gpios are used, even if slightly more complex than those: the entity that > has a video output (SoC's DSS, external chips) offers that video output as > resource. It doesn't know or care who uses it. The user of the video output > (panel, external chips) will find the video output (to which it is connected > in the HW) by some means, and will use different operations on that output > to operate the device. > > This would give us something like the following DT data: > > soc-base.dtsi: > > dss { > dpi0: dpi { > }; > }; > > board.dts: > > / { > dpi-panel: dpi-panel { > source = <&dpi0>; > ...panel data...; > }; > }; > > The panel driver would do something like this in its probe: > > int dpi_panel_probe() > { > // Find the video source, increase ref > src = get_video_source_from_of("source"); > > // Reserve the video source for us. others can still get and > // observe it, but cannot use it as video data source. > // I think this should cascade upstream, so that after this call > // each video entity from the panel to the SoC's CRTC is > // reserved and locked for this video pipeline. > reserve_video_source(src); > > // set DPI HW configuration, like DPI data lines. The > // configuration would come from panel's platform data > set_dpi_config(src, config); > > // register this panel as a display. > register_display(this); > } > > > The DSS's dpi driver would do something like: > > int dss_dpi_probe() > { > // register as a DPI video source > register_video_source(this); > } > > A DSI-2-DPI chip would do something like: > > int dsi2dpi_probe() > { > // get, reserve and config the DSI bus from SoC > src = get_video_source_from_of("source"); > reserve_video_source(src); > set_dsi_config(src, config); > > // register as a DPI video source > register_video_source(this); > } > > > Here we wouldn't have similar display_entity as you have, but video sources > and displays. Video sources are elements in the video pipeline, and a video > source is used only by the next downstream element. The last element in the > pipeline would not be a video source, but a display, which would be used by > the upper layer. I don't think we should handle pure sources, pure sinks (displays) and mixed entities (transceivers) differently. I prefer having abstract entities that can have a source and a sink, and expose the corresponding operations. That would make pipeline handling much easier, as the code will only need to deal with a single type of object. Implementing support for entities with multiple sinks and/or sources would also be possible. > Video source's ops would deal with things related to the video bus in > question, like configuring data lanes, sending DSI packets, etc. The > display ops would be more high level things, like enable, update, etc. > Actually, I guess you could consider the display to represent and deal > with the whole pipeline, while video source deals with the bus between > two display entities. What is missing in your proposal is an explanation of how the panel is controlled. What does your register_display() function register the display with, and what then calls the display operations ? -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 14:36 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 14:36 UTC (permalink / raw) To: Tomi Valkeinen Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 5321 bytes --] Hi Tomi, I finally have time to work on a v3 :-) On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > On 2012-11-22 23:45, Laurent Pinchart wrote: > > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > > Hi everybody, > > > > Here's the second RFC of what was previously known as the Generic Panel > > Framework. > > Nice work! Thanks for working on this. > > I was doing some testing with the code, seeing how to use it in omapdss. > Here are some thoughts: > > In your model the DSS gets the panel devices connected to it from > platform data. After the DSS and the panel drivers are loaded, DSS gets > a notification and connects DSS and the panel. > > I think it's a bit limited way. First of all, it'll make the DT data a > bit more complex (although this is not a major problem). With your > model, you'll need something like: > > soc-base.dtsi: > > dss { > dpi0: dpi { > }; > }; > > board.dts: > > &dpi0 { > panel = &dpi-panel; > }; > > / { > dpi-panel: dpi-panel { > ...panel data...; > }; > }; > > Second, it'll prevent hotplug, and even if real hotplug would not be > supported, it'll prevent cases where the connected panel must be found > dynamically (like reading ID from eeprom). Hotplug definitely needs to be supported, as the common display framework also targets HDMI and DP. The notification mechanism was actually designed to support hotplug. How do you see the proposal preventing hotplug ? > Third, it kinda creates a cyclical dependency: the DSS needs to know > about the panel and calls ops in the panel, and the panel calls ops in > the DSS. I'm not sure if this is an actual problem, but I usually find > it simpler if calls are done only in one direction. I don't see any way around that. The panel is not a standalone entity that can only receive calls (as it needs to control video streams, per your request :-)) or only emit calls (as something needs to control it, userspace doesn't control the panel directly). > What I suggest is take a simpler approach, something alike to how regulators > or gpios are used, even if slightly more complex than those: the entity that > has a video output (SoC's DSS, external chips) offers that video output as > resource. It doesn't know or care who uses it. The user of the video output > (panel, external chips) will find the video output (to which it is connected > in the HW) by some means, and will use different operations on that output > to operate the device. > > This would give us something like the following DT data: > > soc-base.dtsi: > > dss { > dpi0: dpi { > }; > }; > > board.dts: > > / { > dpi-panel: dpi-panel { > source = <&dpi0>; > ...panel data...; > }; > }; > > The panel driver would do something like this in its probe: > > int dpi_panel_probe() > { > // Find the video source, increase ref > src = get_video_source_from_of("source"); > > // Reserve the video source for us. others can still get and > // observe it, but cannot use it as video data source. > // I think this should cascade upstream, so that after this call > // each video entity from the panel to the SoC's CRTC is > // reserved and locked for this video pipeline. > reserve_video_source(src); > > // set DPI HW configuration, like DPI data lines. The > // configuration would come from panel's platform data > set_dpi_config(src, config); > > // register this panel as a display. > register_display(this); > } > > > The DSS's dpi driver would do something like: > > int dss_dpi_probe() > { > // register as a DPI video source > register_video_source(this); > } > > A DSI-2-DPI chip would do something like: > > int dsi2dpi_probe() > { > // get, reserve and config the DSI bus from SoC > src = get_video_source_from_of("source"); > reserve_video_source(src); > set_dsi_config(src, config); > > // register as a DPI video source > register_video_source(this); > } > > > Here we wouldn't have similar display_entity as you have, but video sources > and displays. Video sources are elements in the video pipeline, and a video > source is used only by the next downstream element. The last element in the > pipeline would not be a video source, but a display, which would be used by > the upper layer. I don't think we should handle pure sources, pure sinks (displays) and mixed entities (transceivers) differently. I prefer having abstract entities that can have a source and a sink, and expose the corresponding operations. That would make pipeline handling much easier, as the code will only need to deal with a single type of object. Implementing support for entities with multiple sinks and/or sources would also be possible. > Video source's ops would deal with things related to the video bus in > question, like configuring data lanes, sending DSI packets, etc. The > display ops would be more high level things, like enable, update, etc. > Actually, I guess you could consider the display to represent and deal > with the whole pipeline, while video source deals with the bus between > two display entities. What is missing in your proposal is an explanation of how the panel is controlled. What does your register_display() function register the display with, and what then calls the display operations ? -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-17 14:36 ` Laurent Pinchart (?) @ 2012-12-17 15:29 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-17 15:29 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 5869 bytes --] On 2012-12-17 16:36, Laurent Pinchart wrote: > Hi Tomi, > > I finally have time to work on a v3 :-) > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: >> On 2012-11-22 23:45, Laurent Pinchart wrote: >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >>> >>> Hi everybody, >>> >>> Here's the second RFC of what was previously known as the Generic Panel >>> Framework. >> >> Nice work! Thanks for working on this. >> >> I was doing some testing with the code, seeing how to use it in omapdss. >> Here are some thoughts: >> >> In your model the DSS gets the panel devices connected to it from >> platform data. After the DSS and the panel drivers are loaded, DSS gets >> a notification and connects DSS and the panel. >> >> I think it's a bit limited way. First of all, it'll make the DT data a >> bit more complex (although this is not a major problem). With your >> model, you'll need something like: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> &dpi0 { >> panel = &dpi-panel; >> }; >> >> / { >> dpi-panel: dpi-panel { >> ...panel data...; >> }; >> }; >> >> Second, it'll prevent hotplug, and even if real hotplug would not be >> supported, it'll prevent cases where the connected panel must be found >> dynamically (like reading ID from eeprom). > > Hotplug definitely needs to be supported, as the common display framework also > targets HDMI and DP. The notification mechanism was actually designed to > support hotplug. HDMI or DP hotplug may or may not be a different thing than what I talk about here. We may have two kinds of hotplug: real linux device hotplug, i.e. a linux device appears or is removed during runtime, or just a cable hotplug, handled inside a driver, which doesn't have any effect on the linux devices. If we do implement HDMI and DP monitors with real linux drivers, then yes, we could use real hotplug. But we could as well have the monitor driver always registered, and just have a driver internal cable-hotplug system. To be honest, I'm not sure if implementing real hotplug is easily possible, as we don't have real, probable (probe-able =) busses. So even if we'd get a hotplug event of a new display device, what kind of device would the bus master register? It has no way to know that. > How do you see the proposal preventing hotplug ? Well, probably it doesn't prevent. But it doesn't feel right to me. Say, if we have a DPI panel, controlled via foo-bus, which has a probing mechanism. When the foo-bus master detects a new hardware device, it'll create linux device for it. The driver for this device will then be probed. In the probe function it should somehow register itself to the cdf, or perhaps the previous entity in the chain. This sounds to me that the link is from the panel to the previous entity, not the other way around as you describe, and also the previous entity doesn't know of the panel entities. >> Third, it kinda creates a cyclical dependency: the DSS needs to know >> about the panel and calls ops in the panel, and the panel calls ops in >> the DSS. I'm not sure if this is an actual problem, but I usually find >> it simpler if calls are done only in one direction. > > I don't see any way around that. The panel is not a standalone entity that can > only receive calls (as it needs to control video streams, per your request > :-)) or only emit calls (as something needs to control it, userspace doesn't > control the panel directly). Right, but as I see it, the destination of the panel's calls, and the source of the calls to panel are different things. The destination is the bus layer, dealing with the video signal being transferred. The source is a bit higher level thing, something that's controlling the display in general. >> Here we wouldn't have similar display_entity as you have, but video sources >> and displays. Video sources are elements in the video pipeline, and a video >> source is used only by the next downstream element. The last element in the >> pipeline would not be a video source, but a display, which would be used by >> the upper layer. > > I don't think we should handle pure sources, pure sinks (displays) and mixed > entities (transceivers) differently. I prefer having abstract entities that > can have a source and a sink, and expose the corresponding operations. That > would make pipeline handling much easier, as the code will only need to deal > with a single type of object. Implementing support for entities with multiple > sinks and/or sources would also be possible. Ok. I think having pure sources is simpler model, but it's true that if we need to iterate and study the pipeline during runtime, it's probably better to have single entities with multiple sources/sinks. >> Video source's ops would deal with things related to the video bus in >> question, like configuring data lanes, sending DSI packets, etc. The >> display ops would be more high level things, like enable, update, etc. >> Actually, I guess you could consider the display to represent and deal >> with the whole pipeline, while video source deals with the bus between >> two display entities. > > What is missing in your proposal is an explanation of how the panel is > controlled. What does your register_display() function register the display > with, and what then calls the display operations ? In my particular case, the omapfb calls the display operations, which is the higher level "manager" for the whole display. So omapfb does calls both to the DSS side and to the panel side of the pipeline. I agree that making calls to both ends is a bit silly, but then again, I think it also happens in your model, it's just hidden there. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 15:29 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-17 15:29 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 5869 bytes --] On 2012-12-17 16:36, Laurent Pinchart wrote: > Hi Tomi, > > I finally have time to work on a v3 :-) > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: >> On 2012-11-22 23:45, Laurent Pinchart wrote: >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >>> >>> Hi everybody, >>> >>> Here's the second RFC of what was previously known as the Generic Panel >>> Framework. >> >> Nice work! Thanks for working on this. >> >> I was doing some testing with the code, seeing how to use it in omapdss. >> Here are some thoughts: >> >> In your model the DSS gets the panel devices connected to it from >> platform data. After the DSS and the panel drivers are loaded, DSS gets >> a notification and connects DSS and the panel. >> >> I think it's a bit limited way. First of all, it'll make the DT data a >> bit more complex (although this is not a major problem). With your >> model, you'll need something like: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> &dpi0 { >> panel = &dpi-panel; >> }; >> >> / { >> dpi-panel: dpi-panel { >> ...panel data...; >> }; >> }; >> >> Second, it'll prevent hotplug, and even if real hotplug would not be >> supported, it'll prevent cases where the connected panel must be found >> dynamically (like reading ID from eeprom). > > Hotplug definitely needs to be supported, as the common display framework also > targets HDMI and DP. The notification mechanism was actually designed to > support hotplug. HDMI or DP hotplug may or may not be a different thing than what I talk about here. We may have two kinds of hotplug: real linux device hotplug, i.e. a linux device appears or is removed during runtime, or just a cable hotplug, handled inside a driver, which doesn't have any effect on the linux devices. If we do implement HDMI and DP monitors with real linux drivers, then yes, we could use real hotplug. But we could as well have the monitor driver always registered, and just have a driver internal cable-hotplug system. To be honest, I'm not sure if implementing real hotplug is easily possible, as we don't have real, probable (probe-able =) busses. So even if we'd get a hotplug event of a new display device, what kind of device would the bus master register? It has no way to know that. > How do you see the proposal preventing hotplug ? Well, probably it doesn't prevent. But it doesn't feel right to me. Say, if we have a DPI panel, controlled via foo-bus, which has a probing mechanism. When the foo-bus master detects a new hardware device, it'll create linux device for it. The driver for this device will then be probed. In the probe function it should somehow register itself to the cdf, or perhaps the previous entity in the chain. This sounds to me that the link is from the panel to the previous entity, not the other way around as you describe, and also the previous entity doesn't know of the panel entities. >> Third, it kinda creates a cyclical dependency: the DSS needs to know >> about the panel and calls ops in the panel, and the panel calls ops in >> the DSS. I'm not sure if this is an actual problem, but I usually find >> it simpler if calls are done only in one direction. > > I don't see any way around that. The panel is not a standalone entity that can > only receive calls (as it needs to control video streams, per your request > :-)) or only emit calls (as something needs to control it, userspace doesn't > control the panel directly). Right, but as I see it, the destination of the panel's calls, and the source of the calls to panel are different things. The destination is the bus layer, dealing with the video signal being transferred. The source is a bit higher level thing, something that's controlling the display in general. >> Here we wouldn't have similar display_entity as you have, but video sources >> and displays. Video sources are elements in the video pipeline, and a video >> source is used only by the next downstream element. The last element in the >> pipeline would not be a video source, but a display, which would be used by >> the upper layer. > > I don't think we should handle pure sources, pure sinks (displays) and mixed > entities (transceivers) differently. I prefer having abstract entities that > can have a source and a sink, and expose the corresponding operations. That > would make pipeline handling much easier, as the code will only need to deal > with a single type of object. Implementing support for entities with multiple > sinks and/or sources would also be possible. Ok. I think having pure sources is simpler model, but it's true that if we need to iterate and study the pipeline during runtime, it's probably better to have single entities with multiple sources/sinks. >> Video source's ops would deal with things related to the video bus in >> question, like configuring data lanes, sending DSI packets, etc. The >> display ops would be more high level things, like enable, update, etc. >> Actually, I guess you could consider the display to represent and deal >> with the whole pipeline, while video source deals with the bus between >> two display entities. > > What is missing in your proposal is an explanation of how the panel is > controlled. What does your register_display() function register the display > with, and what then calls the display operations ? In my particular case, the omapfb calls the display operations, which is the higher level "manager" for the whole display. So omapfb does calls both to the DSS side and to the panel side of the pipeline. I agree that making calls to both ends is a bit silly, but then again, I think it also happens in your model, it's just hidden there. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 15:29 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-17 15:29 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 5869 bytes --] On 2012-12-17 16:36, Laurent Pinchart wrote: > Hi Tomi, > > I finally have time to work on a v3 :-) > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: >> On 2012-11-22 23:45, Laurent Pinchart wrote: >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >>> >>> Hi everybody, >>> >>> Here's the second RFC of what was previously known as the Generic Panel >>> Framework. >> >> Nice work! Thanks for working on this. >> >> I was doing some testing with the code, seeing how to use it in omapdss. >> Here are some thoughts: >> >> In your model the DSS gets the panel devices connected to it from >> platform data. After the DSS and the panel drivers are loaded, DSS gets >> a notification and connects DSS and the panel. >> >> I think it's a bit limited way. First of all, it'll make the DT data a >> bit more complex (although this is not a major problem). With your >> model, you'll need something like: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> &dpi0 { >> panel = &dpi-panel; >> }; >> >> / { >> dpi-panel: dpi-panel { >> ...panel data...; >> }; >> }; >> >> Second, it'll prevent hotplug, and even if real hotplug would not be >> supported, it'll prevent cases where the connected panel must be found >> dynamically (like reading ID from eeprom). > > Hotplug definitely needs to be supported, as the common display framework also > targets HDMI and DP. The notification mechanism was actually designed to > support hotplug. HDMI or DP hotplug may or may not be a different thing than what I talk about here. We may have two kinds of hotplug: real linux device hotplug, i.e. a linux device appears or is removed during runtime, or just a cable hotplug, handled inside a driver, which doesn't have any effect on the linux devices. If we do implement HDMI and DP monitors with real linux drivers, then yes, we could use real hotplug. But we could as well have the monitor driver always registered, and just have a driver internal cable-hotplug system. To be honest, I'm not sure if implementing real hotplug is easily possible, as we don't have real, probable (probe-able =) busses. So even if we'd get a hotplug event of a new display device, what kind of device would the bus master register? It has no way to know that. > How do you see the proposal preventing hotplug ? Well, probably it doesn't prevent. But it doesn't feel right to me. Say, if we have a DPI panel, controlled via foo-bus, which has a probing mechanism. When the foo-bus master detects a new hardware device, it'll create linux device for it. The driver for this device will then be probed. In the probe function it should somehow register itself to the cdf, or perhaps the previous entity in the chain. This sounds to me that the link is from the panel to the previous entity, not the other way around as you describe, and also the previous entity doesn't know of the panel entities. >> Third, it kinda creates a cyclical dependency: the DSS needs to know >> about the panel and calls ops in the panel, and the panel calls ops in >> the DSS. I'm not sure if this is an actual problem, but I usually find >> it simpler if calls are done only in one direction. > > I don't see any way around that. The panel is not a standalone entity that can > only receive calls (as it needs to control video streams, per your request > :-)) or only emit calls (as something needs to control it, userspace doesn't > control the panel directly). Right, but as I see it, the destination of the panel's calls, and the source of the calls to panel are different things. The destination is the bus layer, dealing with the video signal being transferred. The source is a bit higher level thing, something that's controlling the display in general. >> Here we wouldn't have similar display_entity as you have, but video sources >> and displays. Video sources are elements in the video pipeline, and a video >> source is used only by the next downstream element. The last element in the >> pipeline would not be a video source, but a display, which would be used by >> the upper layer. > > I don't think we should handle pure sources, pure sinks (displays) and mixed > entities (transceivers) differently. I prefer having abstract entities that > can have a source and a sink, and expose the corresponding operations. That > would make pipeline handling much easier, as the code will only need to deal > with a single type of object. Implementing support for entities with multiple > sinks and/or sources would also be possible. Ok. I think having pure sources is simpler model, but it's true that if we need to iterate and study the pipeline during runtime, it's probably better to have single entities with multiple sources/sinks. >> Video source's ops would deal with things related to the video bus in >> question, like configuring data lanes, sending DSI packets, etc. The >> display ops would be more high level things, like enable, update, etc. >> Actually, I guess you could consider the display to represent and deal >> with the whole pipeline, while video source deals with the bus between >> two display entities. > > What is missing in your proposal is an explanation of how the panel is > controlled. What does your register_display() function register the display > with, and what then calls the display operations ? In my particular case, the omapfb calls the display operations, which is the higher level "manager" for the whole display. So omapfb does calls both to the DSS side and to the panel side of the pipeline. I agree that making calls to both ends is a bit silly, but then again, I think it also happens in your model, it's just hidden there. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-17 15:29 ` Tomi Valkeinen @ 2012-12-17 23:18 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 23:18 UTC (permalink / raw) To: Tomi Valkeinen Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 8669 bytes --] Hi Tomi, On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote: > On 2012-12-17 16:36, Laurent Pinchart wrote: > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > >> On 2012-11-22 23:45, Laurent Pinchart wrote: > >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >>> > >>> Hi everybody, > >>> > >>> Here's the second RFC of what was previously known as the Generic Panel > >>> Framework. > >> > >> Nice work! Thanks for working on this. > >> > >> I was doing some testing with the code, seeing how to use it in omapdss. > >> Here are some thoughts: > >> > >> In your model the DSS gets the panel devices connected to it from > >> platform data. After the DSS and the panel drivers are loaded, DSS gets > >> a notification and connects DSS and the panel. > >> > >> I think it's a bit limited way. First of all, it'll make the DT data a > >> bit more complex (although this is not a major problem). With your > >> model, you'll need something like: > >> > >> soc-base.dtsi: > >> > >> dss { > >> dpi0: dpi { > >> }; > >> }; > >> > >> board.dts: > >> > >> &dpi0 { > >> panel = &dpi-panel; > >> }; > >> > >> / { > >> dpi-panel: dpi-panel { > >> ...panel data...; > >> }; > >> }; > >> > >> Second, it'll prevent hotplug, and even if real hotplug would not be > >> supported, it'll prevent cases where the connected panel must be found > >> dynamically (like reading ID from eeprom). > > > > Hotplug definitely needs to be supported, as the common display framework > > also targets HDMI and DP. The notification mechanism was actually > > designed to support hotplug. > > HDMI or DP hotplug may or may not be a different thing than what I talk > about here. We may have two kinds of hotplug: real linux device hotplug, > i.e. a linux device appears or is removed during runtime, or just a cable > hotplug, handled inside a driver, which doesn't have any effect on the linux > devices. > > If we do implement HDMI and DP monitors with real linux drivers, then yes, > we could use real hotplug. But we could as well have the monitor driver > always registered, and just have a driver internal cable-hotplug system. > > To be honest, I'm not sure if implementing real hotplug is easily possible, > as we don't have real, probable (probe-able =) busses. So even if we'd get a > hotplug event of a new display device, what kind of device would the bus > master register? It has no way to know that. I get your point. My design goal is to handle both HDMI/DP and panels through a single hotplug interface. I believe it would be simpler for display controller drivers to handle all display entities with a common API instead of implementing support for HDMI/DP and panels separately. This would require real HDMI and DP monitor drivers. I share your concern, I don't know whether this can work in the end, the only way to find out will be to try it. > > How do you see the proposal preventing hotplug ? > > Well, probably it doesn't prevent. But it doesn't feel right to me. > > Say, if we have a DPI panel, controlled via foo-bus, which has a probing > mechanism. When the foo-bus master detects a new hardware device, it'll > create linux device for it. The driver for this device will then be probed. That's correct. That's how Linux handles devices, and I don't think we should diverge from that model without a very good reason to do so. In my understanding you agree with me here, could you please confirm that ? > In the probe function it should somehow register itself to the cdf, or > perhaps the previous entity in the chain. The panel driver would register the panel device to CDF in its probe function. >From a panel point of view I think we agree that two sets of operations exist. - The panel control operations are called by an upper layer component (let's call it A) to control the panel (retrieve the list of modes, enable the panel, ...). That upper layer component will usually call the panel in response to a userspace request (that can go through several layers in the kernel before reaching the panel), but can also call it in response to a hotplug event, without userspace being involved. - The panel calls video operations of the entity that provides it with a video stream (the video source entity, let's call it B) to configure and control the video bus. A and B could be implemented in the same driver or in two separate drivers, but at the end of the day I don't think that matters much. A needs a reference to the panel, and the panel needs a reference to B, that's all we need to provide, regardless of whether A and B come from the same kernel module or not. > This sounds to me that the link is from the panel to the previous entity, > not the other way around as you describe, and also the previous entity > doesn't know of the panel entities. The data flows from the video source to the panel (I'm 100% confident that we agree on that :-)), and the video source is controlled by the panel as per your request. The link is thus from the video source to the panel, but is controlled by the sink, not the source. > >> Third, it kinda creates a cyclical dependency: the DSS needs to know > >> about the panel and calls ops in the panel, and the panel calls ops in > >> the DSS. I'm not sure if this is an actual problem, but I usually find > >> it simpler if calls are done only in one direction. > > > > I don't see any way around that. The panel is not a standalone entity that > > can only receive calls (as it needs to control video streams, per your > > request :-)) or only emit calls (as something needs to control it, > > userspace doesn't control the panel directly). > > Right, but as I see it, the destination of the panel's calls, and the source > of the calls to panel are different things. The destination is the bus > layer, dealing with the video signal being transferred. The source is a bit > higher level thing, something that's controlling the display in general. That's correct. They can both be implemented in the same driver, but they're different logical entities. (I actually think they should be implemented in the same driver, but that's not very relevant here.) > >> Here we wouldn't have similar display_entity as you have, but video > >> sources and displays. Video sources are elements in the video pipeline, > >> and a video source is used only by the next downstream element. The last > >> element in the pipeline would not be a video source, but a display, which > >> would be used by the upper layer. > > > > I don't think we should handle pure sources, pure sinks (displays) and > > mixed entities (transceivers) differently. I prefer having abstract > > entities that can have a source and a sink, and expose the corresponding > > operations. That would make pipeline handling much easier, as the code > > will only need to deal with a single type of object. Implementing support > > for entities with multiple sinks and/or sources would also be possible. > > Ok. I think having pure sources is simpler model, but it's true that if > we need to iterate and study the pipeline during runtime, it's probably > better to have single entities with multiple sources/sinks. A pure source is an entity with a source pad only that only exposes source pad operations, I think the complexity to handle them from the panel point of view would roughly be the same (there might be an extra argument to a couple of functions with a pad number, but that's more or less it). > >> Video source's ops would deal with things related to the video bus in > >> question, like configuring data lanes, sending DSI packets, etc. The > >> display ops would be more high level things, like enable, update, etc. > >> Actually, I guess you could consider the display to represent and deal > >> with the whole pipeline, while video source deals with the bus between > >> two display entities. > > > > What is missing in your proposal is an explanation of how the panel is > > controlled. What does your register_display() function register the > > display with, and what then calls the display operations ? > > In my particular case, the omapfb calls the display operations, which is > the higher level "manager" for the whole display. So omapfb does calls > both to the DSS side and to the panel side of the pipeline. > > I agree that making calls to both ends is a bit silly, but then again, I > think it also happens in your model, it's just hidden there. That's probably the biggest difference between our models. Let's discuss it face to face tomorrow and hopefully come up with an agreement. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 23:18 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 23:18 UTC (permalink / raw) To: Tomi Valkeinen Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan [-- Attachment #1: Type: text/plain, Size: 8668 bytes --] Hi Tomi, On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote: > On 2012-12-17 16:36, Laurent Pinchart wrote: > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > >> On 2012-11-22 23:45, Laurent Pinchart wrote: > >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >>> > >>> Hi everybody, > >>> > >>> Here's the second RFC of what was previously known as the Generic Panel > >>> Framework. > >> > >> Nice work! Thanks for working on this. > >> > >> I was doing some testing with the code, seeing how to use it in omapdss. > >> Here are some thoughts: > >> > >> In your model the DSS gets the panel devices connected to it from > >> platform data. After the DSS and the panel drivers are loaded, DSS gets > >> a notification and connects DSS and the panel. > >> > >> I think it's a bit limited way. First of all, it'll make the DT data a > >> bit more complex (although this is not a major problem). With your > >> model, you'll need something like: > >> > >> soc-base.dtsi: > >> > >> dss { > >> dpi0: dpi { > >> }; > >> }; > >> > >> board.dts: > >> > >> &dpi0 { > >> panel = &dpi-panel; > >> }; > >> > >> / { > >> dpi-panel: dpi-panel { > >> ...panel data...; > >> }; > >> }; > >> > >> Second, it'll prevent hotplug, and even if real hotplug would not be > >> supported, it'll prevent cases where the connected panel must be found > >> dynamically (like reading ID from eeprom). > > > > Hotplug definitely needs to be supported, as the common display framework > > also targets HDMI and DP. The notification mechanism was actually > > designed to support hotplug. > > HDMI or DP hotplug may or may not be a different thing than what I talk > about here. We may have two kinds of hotplug: real linux device hotplug, > i.e. a linux device appears or is removed during runtime, or just a cable > hotplug, handled inside a driver, which doesn't have any effect on the linux > devices. > > If we do implement HDMI and DP monitors with real linux drivers, then yes, > we could use real hotplug. But we could as well have the monitor driver > always registered, and just have a driver internal cable-hotplug system. > > To be honest, I'm not sure if implementing real hotplug is easily possible, > as we don't have real, probable (probe-able =) busses. So even if we'd get a > hotplug event of a new display device, what kind of device would the bus > master register? It has no way to know that. I get your point. My design goal is to handle both HDMI/DP and panels through a single hotplug interface. I believe it would be simpler for display controller drivers to handle all display entities with a common API instead of implementing support for HDMI/DP and panels separately. This would require real HDMI and DP monitor drivers. I share your concern, I don't know whether this can work in the end, the only way to find out will be to try it. > > How do you see the proposal preventing hotplug ? > > Well, probably it doesn't prevent. But it doesn't feel right to me. > > Say, if we have a DPI panel, controlled via foo-bus, which has a probing > mechanism. When the foo-bus master detects a new hardware device, it'll > create linux device for it. The driver for this device will then be probed. That's correct. That's how Linux handles devices, and I don't think we should diverge from that model without a very good reason to do so. In my understanding you agree with me here, could you please confirm that ? > In the probe function it should somehow register itself to the cdf, or > perhaps the previous entity in the chain. The panel driver would register the panel device to CDF in its probe function. From a panel point of view I think we agree that two sets of operations exist. - The panel control operations are called by an upper layer component (let's call it A) to control the panel (retrieve the list of modes, enable the panel, ...). That upper layer component will usually call the panel in response to a userspace request (that can go through several layers in the kernel before reaching the panel), but can also call it in response to a hotplug event, without userspace being involved. - The panel calls video operations of the entity that provides it with a video stream (the video source entity, let's call it B) to configure and control the video bus. A and B could be implemented in the same driver or in two separate drivers, but at the end of the day I don't think that matters much. A needs a reference to the panel, and the panel needs a reference to B, that's all we need to provide, regardless of whether A and B come from the same kernel module or not. > This sounds to me that the link is from the panel to the previous entity, > not the other way around as you describe, and also the previous entity > doesn't know of the panel entities. The data flows from the video source to the panel (I'm 100% confident that we agree on that :-)), and the video source is controlled by the panel as per your request. The link is thus from the video source to the panel, but is controlled by the sink, not the source. > >> Third, it kinda creates a cyclical dependency: the DSS needs to know > >> about the panel and calls ops in the panel, and the panel calls ops in > >> the DSS. I'm not sure if this is an actual problem, but I usually find > >> it simpler if calls are done only in one direction. > > > > I don't see any way around that. The panel is not a standalone entity that > > can only receive calls (as it needs to control video streams, per your > > request :-)) or only emit calls (as something needs to control it, > > userspace doesn't control the panel directly). > > Right, but as I see it, the destination of the panel's calls, and the source > of the calls to panel are different things. The destination is the bus > layer, dealing with the video signal being transferred. The source is a bit > higher level thing, something that's controlling the display in general. That's correct. They can both be implemented in the same driver, but they're different logical entities. (I actually think they should be implemented in the same driver, but that's not very relevant here.) > >> Here we wouldn't have similar display_entity as you have, but video > >> sources and displays. Video sources are elements in the video pipeline, > >> and a video source is used only by the next downstream element. The last > >> element in the pipeline would not be a video source, but a display, which > >> would be used by the upper layer. > > > > I don't think we should handle pure sources, pure sinks (displays) and > > mixed entities (transceivers) differently. I prefer having abstract > > entities that can have a source and a sink, and expose the corresponding > > operations. That would make pipeline handling much easier, as the code > > will only need to deal with a single type of object. Implementing support > > for entities with multiple sinks and/or sources would also be possible. > > Ok. I think having pure sources is simpler model, but it's true that if > we need to iterate and study the pipeline during runtime, it's probably > better to have single entities with multiple sources/sinks. A pure source is an entity with a source pad only that only exposes source pad operations, I think the complexity to handle them from the panel point of view would roughly be the same (there might be an extra argument to a couple of functions with a pad number, but that's more or less it). > >> Video source's ops would deal with things related to the video bus in > >> question, like configuring data lanes, sending DSI packets, etc. The > >> display ops would be more high level things, like enable, update, etc. > >> Actually, I guess you could consider the display to represent and deal > >> with the whole pipeline, while video source deals with the bus between > >> two display entities. > > > > What is missing in your proposal is an explanation of how the panel is > > controlled. What does your register_display() function register the > > display with, and what then calls the display operations ? > > In my particular case, the omapfb calls the display operations, which is > the higher level "manager" for the whole display. So omapfb does calls > both to the DSS side and to the panel side of the pipeline. > > I agree that making calls to both ends is a bit silly, but then again, I > think it also happens in your model, it's just hidden there. That's probably the biggest difference between our models. Let's discuss it face to face tomorrow and hopefully come up with an agreement. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-17 14:36 ` Laurent Pinchart @ 2012-12-17 16:53 ` Jani Nikula -1 siblings, 0 replies; 153+ messages in thread From: Jani Nikula @ 2012-12-17 16:53 UTC (permalink / raw) To: Laurent Pinchart, Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent - On Mon, 17 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Tomi, > > I finally have time to work on a v3 :-) > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: >> On 2012-11-22 23:45, Laurent Pinchart wrote: >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> > >> > Hi everybody, >> > >> > Here's the second RFC of what was previously known as the Generic Panel >> > Framework. >> >> Nice work! Thanks for working on this. >> >> I was doing some testing with the code, seeing how to use it in omapdss. >> Here are some thoughts: >> >> In your model the DSS gets the panel devices connected to it from >> platform data. After the DSS and the panel drivers are loaded, DSS gets >> a notification and connects DSS and the panel. >> >> I think it's a bit limited way. First of all, it'll make the DT data a >> bit more complex (although this is not a major problem). With your >> model, you'll need something like: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> &dpi0 { >> panel = &dpi-panel; >> }; >> >> / { >> dpi-panel: dpi-panel { >> ...panel data...; >> }; >> }; >> >> Second, it'll prevent hotplug, and even if real hotplug would not be >> supported, it'll prevent cases where the connected panel must be found >> dynamically (like reading ID from eeprom). > > Hotplug definitely needs to be supported, as the common display framework also > targets HDMI and DP. The notification mechanism was actually designed to > support hotplug. I can see the need for a framework for DSI panels and such (in fact Tomi and I have talked about it like 2-3 years ago already!) but what is the story for HDMI and DP? In particular, what's the relationship between DRM and CDF here? Is there a world domination plan to switch the DRM drivers to use this framework too? ;) Do you have some rough plans how DRM and CDF should work together in general? BR, Jani. > > How do you see the proposal preventing hotplug ? > >> Third, it kinda creates a cyclical dependency: the DSS needs to know >> about the panel and calls ops in the panel, and the panel calls ops in >> the DSS. I'm not sure if this is an actual problem, but I usually find >> it simpler if calls are done only in one direction. > > I don't see any way around that. The panel is not a standalone entity that can > only receive calls (as it needs to control video streams, per your request > :-)) or only emit calls (as something needs to control it, userspace doesn't > control the panel directly). > >> What I suggest is take a simpler approach, something alike to how regulators >> or gpios are used, even if slightly more complex than those: the entity that >> has a video output (SoC's DSS, external chips) offers that video output as >> resource. It doesn't know or care who uses it. The user of the video output >> (panel, external chips) will find the video output (to which it is connected >> in the HW) by some means, and will use different operations on that output >> to operate the device. >> >> This would give us something like the following DT data: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> / { >> dpi-panel: dpi-panel { >> source = <&dpi0>; >> ...panel data...; >> }; >> }; >> >> The panel driver would do something like this in its probe: >> >> int dpi_panel_probe() >> { >> // Find the video source, increase ref >> src = get_video_source_from_of("source"); >> >> // Reserve the video source for us. others can still get and >> // observe it, but cannot use it as video data source. >> // I think this should cascade upstream, so that after this call >> // each video entity from the panel to the SoC's CRTC is >> // reserved and locked for this video pipeline. >> reserve_video_source(src); >> >> // set DPI HW configuration, like DPI data lines. The >> // configuration would come from panel's platform data >> set_dpi_config(src, config); >> >> // register this panel as a display. >> register_display(this); >> } >> >> >> The DSS's dpi driver would do something like: >> >> int dss_dpi_probe() >> { >> // register as a DPI video source >> register_video_source(this); >> } >> >> A DSI-2-DPI chip would do something like: >> >> int dsi2dpi_probe() >> { >> // get, reserve and config the DSI bus from SoC >> src = get_video_source_from_of("source"); >> reserve_video_source(src); >> set_dsi_config(src, config); >> >> // register as a DPI video source >> register_video_source(this); >> } >> >> >> Here we wouldn't have similar display_entity as you have, but video sources >> and displays. Video sources are elements in the video pipeline, and a video >> source is used only by the next downstream element. The last element in the >> pipeline would not be a video source, but a display, which would be used by >> the upper layer. > > I don't think we should handle pure sources, pure sinks (displays) and mixed > entities (transceivers) differently. I prefer having abstract entities that > can have a source and a sink, and expose the corresponding operations. That > would make pipeline handling much easier, as the code will only need to deal > with a single type of object. Implementing support for entities with multiple > sinks and/or sources would also be possible. > >> Video source's ops would deal with things related to the video bus in >> question, like configuring data lanes, sending DSI packets, etc. The >> display ops would be more high level things, like enable, update, etc. >> Actually, I guess you could consider the display to represent and deal >> with the whole pipeline, while video source deals with the bus between >> two display entities. > > What is missing in your proposal is an explanation of how the panel is > controlled. What does your register_display() function register the display > with, and what then calls the display operations ? > > -- > Regards, > > Laurent Pinchart > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 16:53 ` Jani Nikula 0 siblings, 0 replies; 153+ messages in thread From: Jani Nikula @ 2012-12-17 16:53 UTC (permalink / raw) To: Laurent Pinchart, Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent - On Mon, 17 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Tomi, > > I finally have time to work on a v3 :-) > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: >> On 2012-11-22 23:45, Laurent Pinchart wrote: >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> > >> > Hi everybody, >> > >> > Here's the second RFC of what was previously known as the Generic Panel >> > Framework. >> >> Nice work! Thanks for working on this. >> >> I was doing some testing with the code, seeing how to use it in omapdss. >> Here are some thoughts: >> >> In your model the DSS gets the panel devices connected to it from >> platform data. After the DSS and the panel drivers are loaded, DSS gets >> a notification and connects DSS and the panel. >> >> I think it's a bit limited way. First of all, it'll make the DT data a >> bit more complex (although this is not a major problem). With your >> model, you'll need something like: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> &dpi0 { >> panel = &dpi-panel; >> }; >> >> / { >> dpi-panel: dpi-panel { >> ...panel data...; >> }; >> }; >> >> Second, it'll prevent hotplug, and even if real hotplug would not be >> supported, it'll prevent cases where the connected panel must be found >> dynamically (like reading ID from eeprom). > > Hotplug definitely needs to be supported, as the common display framework also > targets HDMI and DP. The notification mechanism was actually designed to > support hotplug. I can see the need for a framework for DSI panels and such (in fact Tomi and I have talked about it like 2-3 years ago already!) but what is the story for HDMI and DP? In particular, what's the relationship between DRM and CDF here? Is there a world domination plan to switch the DRM drivers to use this framework too? ;) Do you have some rough plans how DRM and CDF should work together in general? BR, Jani. > > How do you see the proposal preventing hotplug ? > >> Third, it kinda creates a cyclical dependency: the DSS needs to know >> about the panel and calls ops in the panel, and the panel calls ops in >> the DSS. I'm not sure if this is an actual problem, but I usually find >> it simpler if calls are done only in one direction. > > I don't see any way around that. The panel is not a standalone entity that can > only receive calls (as it needs to control video streams, per your request > :-)) or only emit calls (as something needs to control it, userspace doesn't > control the panel directly). > >> What I suggest is take a simpler approach, something alike to how regulators >> or gpios are used, even if slightly more complex than those: the entity that >> has a video output (SoC's DSS, external chips) offers that video output as >> resource. It doesn't know or care who uses it. The user of the video output >> (panel, external chips) will find the video output (to which it is connected >> in the HW) by some means, and will use different operations on that output >> to operate the device. >> >> This would give us something like the following DT data: >> >> soc-base.dtsi: >> >> dss { >> dpi0: dpi { >> }; >> }; >> >> board.dts: >> >> / { >> dpi-panel: dpi-panel { >> source = <&dpi0>; >> ...panel data...; >> }; >> }; >> >> The panel driver would do something like this in its probe: >> >> int dpi_panel_probe() >> { >> // Find the video source, increase ref >> src = get_video_source_from_of("source"); >> >> // Reserve the video source for us. others can still get and >> // observe it, but cannot use it as video data source. >> // I think this should cascade upstream, so that after this call >> // each video entity from the panel to the SoC's CRTC is >> // reserved and locked for this video pipeline. >> reserve_video_source(src); >> >> // set DPI HW configuration, like DPI data lines. The >> // configuration would come from panel's platform data >> set_dpi_config(src, config); >> >> // register this panel as a display. >> register_display(this); >> } >> >> >> The DSS's dpi driver would do something like: >> >> int dss_dpi_probe() >> { >> // register as a DPI video source >> register_video_source(this); >> } >> >> A DSI-2-DPI chip would do something like: >> >> int dsi2dpi_probe() >> { >> // get, reserve and config the DSI bus from SoC >> src = get_video_source_from_of("source"); >> reserve_video_source(src); >> set_dsi_config(src, config); >> >> // register as a DPI video source >> register_video_source(this); >> } >> >> >> Here we wouldn't have similar display_entity as you have, but video sources >> and displays. Video sources are elements in the video pipeline, and a video >> source is used only by the next downstream element. The last element in the >> pipeline would not be a video source, but a display, which would be used by >> the upper layer. > > I don't think we should handle pure sources, pure sinks (displays) and mixed > entities (transceivers) differently. I prefer having abstract entities that > can have a source and a sink, and expose the corresponding operations. That > would make pipeline handling much easier, as the code will only need to deal > with a single type of object. Implementing support for entities with multiple > sinks and/or sources would also be possible. > >> Video source's ops would deal with things related to the video bus in >> question, like configuring data lanes, sending DSI packets, etc. The >> display ops would be more high level things, like enable, update, etc. >> Actually, I guess you could consider the display to represent and deal >> with the whole pipeline, while video source deals with the bus between >> two display entities. > > What is missing in your proposal is an explanation of how the panel is > controlled. What does your register_display() function register the display > with, and what then calls the display operations ? > > -- > Regards, > > Laurent Pinchart > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-17 16:53 ` Jani Nikula @ 2012-12-17 22:19 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 22:19 UTC (permalink / raw) To: Jani Nikula Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > On Mon, 17 Dec 2012, Laurent Pinchart wrote: > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > >> On 2012-11-22 23:45, Laurent Pinchart wrote: > >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> > > >> > Hi everybody, > >> > > >> > Here's the second RFC of what was previously known as the Generic Panel > >> > Framework. > >> > >> Nice work! Thanks for working on this. > >> > >> I was doing some testing with the code, seeing how to use it in omapdss. > >> Here are some thoughts: > >> > >> In your model the DSS gets the panel devices connected to it from > >> platform data. After the DSS and the panel drivers are loaded, DSS gets > >> a notification and connects DSS and the panel. > >> > >> I think it's a bit limited way. First of all, it'll make the DT data a > >> bit more complex (although this is not a major problem). With your > >> model, you'll need something like: > >> > >> soc-base.dtsi: > >> > >> dss { > >> dpi0: dpi { > >> }; > >> }; > >> > >> board.dts: > >> > >> &dpi0 { > >> panel = &dpi-panel; > >> }; > >> > >> / { > >> dpi-panel: dpi-panel { > >> ...panel data...; > >> }; > >> }; > >> > >> Second, it'll prevent hotplug, and even if real hotplug would not be > >> supported, it'll prevent cases where the connected panel must be found > >> dynamically (like reading ID from eeprom). > > > > Hotplug definitely needs to be supported, as the common display framework > > also targets HDMI and DP. The notification mechanism was actually > > designed to support hotplug. > > I can see the need for a framework for DSI panels and such (in fact Tomi > and I have talked about it like 2-3 years ago already!) but what is the > story for HDMI and DP? In particular, what's the relationship between > DRM and CDF here? Is there a world domination plan to switch the DRM > drivers to use this framework too? ;) Do you have some rough plans how > DRM and CDF should work together in general? There's always a world domination plan, isn't there ? :-) I certainly want CDF to be used by DRM (or more accurately KMS). That's what the C stands for, common refers to sharing panel and other display entity drivers between FBDEV, KMS and V4L2. I currently have no plan to expose CDF internals to userspace through the KMS API. We might have to do so later if the hardware complexity grows in such a way that finer control than what KMS provides needs to be exposed to userspace, but I don't think we're there yet. The CDF API will thus only be used internally in the kernel by display controller drivers. The KMS core might get functions to handle common display entity operations, but the bulk of the work will be in the display controller drivers to start with. We will then see what can be abstracted in KMS helper functions. Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF API. That's just a thought for now, I haven't tried to implement them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. Do you have thoughts to share on this topic ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 22:19 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 22:19 UTC (permalink / raw) To: Jani Nikula Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > On Mon, 17 Dec 2012, Laurent Pinchart wrote: > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > >> On 2012-11-22 23:45, Laurent Pinchart wrote: > >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> > > >> > Hi everybody, > >> > > >> > Here's the second RFC of what was previously known as the Generic Panel > >> > Framework. > >> > >> Nice work! Thanks for working on this. > >> > >> I was doing some testing with the code, seeing how to use it in omapdss. > >> Here are some thoughts: > >> > >> In your model the DSS gets the panel devices connected to it from > >> platform data. After the DSS and the panel drivers are loaded, DSS gets > >> a notification and connects DSS and the panel. > >> > >> I think it's a bit limited way. First of all, it'll make the DT data a > >> bit more complex (although this is not a major problem). With your > >> model, you'll need something like: > >> > >> soc-base.dtsi: > >> > >> dss { > >> dpi0: dpi { > >> }; > >> }; > >> > >> board.dts: > >> > >> &dpi0 { > >> panel = &dpi-panel; > >> }; > >> > >> / { > >> dpi-panel: dpi-panel { > >> ...panel data...; > >> }; > >> }; > >> > >> Second, it'll prevent hotplug, and even if real hotplug would not be > >> supported, it'll prevent cases where the connected panel must be found > >> dynamically (like reading ID from eeprom). > > > > Hotplug definitely needs to be supported, as the common display framework > > also targets HDMI and DP. The notification mechanism was actually > > designed to support hotplug. > > I can see the need for a framework for DSI panels and such (in fact Tomi > and I have talked about it like 2-3 years ago already!) but what is the > story for HDMI and DP? In particular, what's the relationship between > DRM and CDF here? Is there a world domination plan to switch the DRM > drivers to use this framework too? ;) Do you have some rough plans how > DRM and CDF should work together in general? There's always a world domination plan, isn't there ? :-) I certainly want CDF to be used by DRM (or more accurately KMS). That's what the C stands for, common refers to sharing panel and other display entity drivers between FBDEV, KMS and V4L2. I currently have no plan to expose CDF internals to userspace through the KMS API. We might have to do so later if the hardware complexity grows in such a way that finer control than what KMS provides needs to be exposed to userspace, but I don't think we're there yet. The CDF API will thus only be used internally in the kernel by display controller drivers. The KMS core might get functions to handle common display entity operations, but the bulk of the work will be in the display controller drivers to start with. We will then see what can be abstracted in KMS helper functions. Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF API. That's just a thought for now, I haven't tried to implement them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. Do you have thoughts to share on this topic ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-17 22:19 ` Laurent Pinchart @ 2012-12-19 14:57 ` Jani Nikula -1 siblings, 0 replies; 153+ messages in thread From: Jani Nikula @ 2012-12-19 14:57 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Jani, > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >> I can see the need for a framework for DSI panels and such (in fact Tomi >> and I have talked about it like 2-3 years ago already!) but what is the >> story for HDMI and DP? In particular, what's the relationship between >> DRM and CDF here? Is there a world domination plan to switch the DRM >> drivers to use this framework too? ;) Do you have some rough plans how >> DRM and CDF should work together in general? > > There's always a world domination plan, isn't there ? :-) > > I certainly want CDF to be used by DRM (or more accurately KMS). That's what > the C stands for, common refers to sharing panel and other display entity > drivers between FBDEV, KMS and V4L2. > > I currently have no plan to expose CDF internals to userspace through the KMS > API. We might have to do so later if the hardware complexity grows in such a > way that finer control than what KMS provides needs to be exposed to > userspace, but I don't think we're there yet. The CDF API will thus only be > used internally in the kernel by display controller drivers. The KMS core > might get functions to handle common display entity operations, but the bulk > of the work will be in the display controller drivers to start with. We will > then see what can be abstracted in KMS helper functions. > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF > API. That's just a thought for now, I haven't tried to implement them, but it > would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. > > Do you have thoughts to share on this topic ? It just seems to me that, at least from a DRM/KMS perspective, adding another layer (=CDF) for HDMI or DP (or legacy outputs) would be overengineering it. They are pretty well standardized, and I don't see there would be a need to write multiple display drivers for them. Each display controller has one, and can easily handle any chip specific requirements right there. It's my gut feeling that an additional framework would just get in the way. Perhaps there could be more common HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, but that's another thing. So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM perspective? Or, put another way, is it more of an alternative to using DRM? Please enlighten me if there's some real benefit here that I fail to see! For DSI panels (or DSI-to-whatever bridges) it's of course another story. You typically need a panel specific driver. And here I see the main point of the whole CDF: decoupling display controllers and the panel drivers, and sharing panel (and converter chip) specific drivers across display controllers. Making it easy to write new drivers, as there would be a model to follow. I'm definitely in favour of coming up with some framework that would tackle that. BR, Jani. ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 14:57 ` Jani Nikula 0 siblings, 0 replies; 153+ messages in thread From: Jani Nikula @ 2012-12-19 14:57 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Jani, > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >> I can see the need for a framework for DSI panels and such (in fact Tomi >> and I have talked about it like 2-3 years ago already!) but what is the >> story for HDMI and DP? In particular, what's the relationship between >> DRM and CDF here? Is there a world domination plan to switch the DRM >> drivers to use this framework too? ;) Do you have some rough plans how >> DRM and CDF should work together in general? > > There's always a world domination plan, isn't there ? :-) > > I certainly want CDF to be used by DRM (or more accurately KMS). That's what > the C stands for, common refers to sharing panel and other display entity > drivers between FBDEV, KMS and V4L2. > > I currently have no plan to expose CDF internals to userspace through the KMS > API. We might have to do so later if the hardware complexity grows in such a > way that finer control than what KMS provides needs to be exposed to > userspace, but I don't think we're there yet. The CDF API will thus only be > used internally in the kernel by display controller drivers. The KMS core > might get functions to handle common display entity operations, but the bulk > of the work will be in the display controller drivers to start with. We will > then see what can be abstracted in KMS helper functions. > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF > API. That's just a thought for now, I haven't tried to implement them, but it > would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. > > Do you have thoughts to share on this topic ? It just seems to me that, at least from a DRM/KMS perspective, adding another layer (ÍF) for HDMI or DP (or legacy outputs) would be overengineering it. They are pretty well standardized, and I don't see there would be a need to write multiple display drivers for them. Each display controller has one, and can easily handle any chip specific requirements right there. It's my gut feeling that an additional framework would just get in the way. Perhaps there could be more common HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, but that's another thing. So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM perspective? Or, put another way, is it more of an alternative to using DRM? Please enlighten me if there's some real benefit here that I fail to see! For DSI panels (or DSI-to-whatever bridges) it's of course another story. You typically need a panel specific driver. And here I see the main point of the whole CDF: decoupling display controllers and the panel drivers, and sharing panel (and converter chip) specific drivers across display controllers. Making it easy to write new drivers, as there would be a model to follow. I'm definitely in favour of coming up with some framework that would tackle that. BR, Jani. ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 14:57 ` Jani Nikula (?) @ 2012-12-19 15:07 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-19 15:07 UTC (permalink / raw) To: Jani Nikula Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2265 bytes --] On 2012-12-19 16:57, Jani Nikula wrote: > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! The use of CDF is an option, not something that has to be done. A DRM driver developer may use it if it gives benefit for him for that particular driver. I don't know much about desktop display hardware, but I guess that using CDF would not really give much there. In some cases it could, if the IPs used on the graphics card are something that are used elsewhere also (sounds quite unlikely, though). In that case there could be separate drivers for the IPs. And note that CDF is not really about the dispc side, i.e. the part that creates the video stream from pixels in the memory. It's more about the components after that, and how to connect those components. > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. Right. But if you implement drivers for DSI panels with CDF for, say, OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. Otherwise it'll be a mishmash with two different models. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 15:07 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-19 15:07 UTC (permalink / raw) To: Jani Nikula Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2265 bytes --] On 2012-12-19 16:57, Jani Nikula wrote: > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! The use of CDF is an option, not something that has to be done. A DRM driver developer may use it if it gives benefit for him for that particular driver. I don't know much about desktop display hardware, but I guess that using CDF would not really give much there. In some cases it could, if the IPs used on the graphics card are something that are used elsewhere also (sounds quite unlikely, though). In that case there could be separate drivers for the IPs. And note that CDF is not really about the dispc side, i.e. the part that creates the video stream from pixels in the memory. It's more about the components after that, and how to connect those components. > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. Right. But if you implement drivers for DSI panels with CDF for, say, OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. Otherwise it'll be a mishmash with two different models. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 15:07 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-19 15:07 UTC (permalink / raw) To: Jani Nikula Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2265 bytes --] On 2012-12-19 16:57, Jani Nikula wrote: > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! The use of CDF is an option, not something that has to be done. A DRM driver developer may use it if it gives benefit for him for that particular driver. I don't know much about desktop display hardware, but I guess that using CDF would not really give much there. In some cases it could, if the IPs used on the graphics card are something that are used elsewhere also (sounds quite unlikely, though). In that case there could be separate drivers for the IPs. And note that CDF is not really about the dispc side, i.e. the part that creates the video stream from pixels in the memory. It's more about the components after that, and how to connect those components. > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. Right. But if you implement drivers for DSI panels with CDF for, say, OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. Otherwise it'll be a mishmash with two different models. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 15:07 ` Tomi Valkeinen @ 2012-12-24 17:31 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:31 UTC (permalink / raw) To: Tomi Valkeinen, Maxime Ripard Cc: Jani Nikula, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2660 bytes --] Hi Tomi, On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote: > On 2012-12-19 16:57, Jani Nikula wrote: > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > The use of CDF is an option, not something that has to be done. A DRM > driver developer may use it if it gives benefit for him for that > particular driver. > > I don't know much about desktop display hardware, but I guess that using > CDF would not really give much there. In some cases it could, if the IPs > used on the graphics card are something that are used elsewhere also > (sounds quite unlikely, though). In that case there could be separate > drivers for the IPs. > > And note that CDF is not really about the dispc side, i.e. the part that > creates the video stream from pixels in the memory. It's more about the > components after that, and how to connect those components. > > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. > > Right. But if you implement drivers for DSI panels with CDF for, say, > OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. > Otherwise it'll be a mishmash with two different models. I second your point here, using CDF for encoders should be simpler, but it will not be enforced. A display controller driver developer who wants to control the on-SoC encoder without conforming to the CDF model will be totally free to do so and won't be blamed. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:31 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:31 UTC (permalink / raw) To: Tomi Valkeinen, Maxime Ripard Cc: Jani Nikula, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2660 bytes --] Hi Tomi, On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote: > On 2012-12-19 16:57, Jani Nikula wrote: > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > The use of CDF is an option, not something that has to be done. A DRM > driver developer may use it if it gives benefit for him for that > particular driver. > > I don't know much about desktop display hardware, but I guess that using > CDF would not really give much there. In some cases it could, if the IPs > used on the graphics card are something that are used elsewhere also > (sounds quite unlikely, though). In that case there could be separate > drivers for the IPs. > > And note that CDF is not really about the dispc side, i.e. the part that > creates the video stream from pixels in the memory. It's more about the > components after that, and how to connect those components. > > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. > > Right. But if you implement drivers for DSI panels with CDF for, say, > OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. > Otherwise it'll be a mishmash with two different models. I second your point here, using CDF for encoders should be simpler, but it will not be enforced. A display controller driver developer who wants to control the on-SoC encoder without conforming to the CDF model will be totally free to do so and won't be blamed. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 14:57 ` Jani Nikula @ 2012-12-19 15:26 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-19 15:26 UTC (permalink / raw) To: Jani Nikula Cc: Laurent Pinchart, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula <jani.nikula@linux.intel.com> wrote: > > Hi Laurent - > > On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> Hi Jani, >> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>> I can see the need for a framework for DSI panels and such (in fact Tomi >>> and I have talked about it like 2-3 years ago already!) but what is the >>> story for HDMI and DP? In particular, what's the relationship between >>> DRM and CDF here? Is there a world domination plan to switch the DRM >>> drivers to use this framework too? ;) Do you have some rough plans how >>> DRM and CDF should work together in general? >> >> There's always a world domination plan, isn't there ? :-) >> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >> the C stands for, common refers to sharing panel and other display entity >> drivers between FBDEV, KMS and V4L2. >> >> I currently have no plan to expose CDF internals to userspace through the KMS >> API. We might have to do so later if the hardware complexity grows in such a >> way that finer control than what KMS provides needs to be exposed to >> userspace, but I don't think we're there yet. The CDF API will thus only be >> used internally in the kernel by display controller drivers. The KMS core >> might get functions to handle common display entity operations, but the bulk >> of the work will be in the display controller drivers to start with. We will >> then see what can be abstracted in KMS helper functions. >> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >> API. That's just a thought for now, I haven't tried to implement them, but it >> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >> >> Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! fwiw, I think there are at least a couple cases where multiple SoC's have the same HDMI IP block. And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF is appropriate for HDMI drivers. Although trying to keep this all independent of DRM (as opposed to just something similar to what drivers/gpu/i2c is today) seems a bit overkill for me. Being able to use the helpers in drm and avoiding an extra layer of translation seems like the better option to me. So my vote would be drivers/gpu/cdf. BR, -R > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. > > > BR, > Jani. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 15:26 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-19 15:26 UTC (permalink / raw) To: Jani Nikula Cc: Laurent Pinchart, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula <jani.nikula@linux.intel.com> wrote: > > Hi Laurent - > > On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> Hi Jani, >> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>> I can see the need for a framework for DSI panels and such (in fact Tomi >>> and I have talked about it like 2-3 years ago already!) but what is the >>> story for HDMI and DP? In particular, what's the relationship between >>> DRM and CDF here? Is there a world domination plan to switch the DRM >>> drivers to use this framework too? ;) Do you have some rough plans how >>> DRM and CDF should work together in general? >> >> There's always a world domination plan, isn't there ? :-) >> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >> the C stands for, common refers to sharing panel and other display entity >> drivers between FBDEV, KMS and V4L2. >> >> I currently have no plan to expose CDF internals to userspace through the KMS >> API. We might have to do so later if the hardware complexity grows in such a >> way that finer control than what KMS provides needs to be exposed to >> userspace, but I don't think we're there yet. The CDF API will thus only be >> used internally in the kernel by display controller drivers. The KMS core >> might get functions to handle common display entity operations, but the bulk >> of the work will be in the display controller drivers to start with. We will >> then see what can be abstracted in KMS helper functions. >> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >> API. That's just a thought for now, I haven't tried to implement them, but it >> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >> >> Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (ÍF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! fwiw, I think there are at least a couple cases where multiple SoC's have the same HDMI IP block. And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF is appropriate for HDMI drivers. Although trying to keep this all independent of DRM (as opposed to just something similar to what drivers/gpu/i2c is today) seems a bit overkill for me. Being able to use the helpers in drm and avoiding an extra layer of translation seems like the better option to me. So my vote would be drivers/gpu/cdf. BR, -R > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. > > > BR, > Jani. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 15:26 ` Rob Clark @ 2012-12-19 15:37 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-19 15:37 UTC (permalink / raw) To: Rob Clark Cc: Jani Nikula, Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 4348 bytes --] On 2012-12-19 17:26, Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula > <jani.nikula@linux.intel.com> wrote: >> >> Hi Laurent - >> >> On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >>> Hi Jani, >>> >>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>>> I can see the need for a framework for DSI panels and such (in fact Tomi >>>> and I have talked about it like 2-3 years ago already!) but what is the >>>> story for HDMI and DP? In particular, what's the relationship between >>>> DRM and CDF here? Is there a world domination plan to switch the DRM >>>> drivers to use this framework too? ;) Do you have some rough plans how >>>> DRM and CDF should work together in general? >>> >>> There's always a world domination plan, isn't there ? :-) >>> >>> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >>> the C stands for, common refers to sharing panel and other display entity >>> drivers between FBDEV, KMS and V4L2. >>> >>> I currently have no plan to expose CDF internals to userspace through the KMS >>> API. We might have to do so later if the hardware complexity grows in such a >>> way that finer control than what KMS provides needs to be exposed to >>> userspace, but I don't think we're there yet. The CDF API will thus only be >>> used internally in the kernel by display controller drivers. The KMS core >>> might get functions to handle common display entity operations, but the bulk >>> of the work will be in the display controller drivers to start with. We will >>> then see what can be abstracted in KMS helper functions. >>> >>> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >>> API. That's just a thought for now, I haven't tried to implement them, but it >>> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >>> >>> Do you have thoughts to share on this topic ? >> >> It just seems to me that, at least from a DRM/KMS perspective, adding >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be >> overengineering it. They are pretty well standardized, and I don't see >> there would be a need to write multiple display drivers for them. Each >> display controller has one, and can easily handle any chip specific >> requirements right there. It's my gut feeling that an additional >> framework would just get in the way. Perhaps there could be more common >> HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, >> but that's another thing. >> >> So is the HDMI/DP drivers using CDF a more interesting idea from a >> non-DRM perspective? Or, put another way, is it more of an alternative >> to using DRM? Please enlighten me if there's some real benefit here that >> I fail to see! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. Well, we need to think about that. I would like to keep CDF independent of DRM. I don't like tying different components/frameworks together if there's no real need for that. Also, something that Laurent mentioned in our face-to-face discussions: Some IPs/chips can be used for other purposes than with DRM. He had an example of a board, that (if I understood right) gets video signal from somewhere outside the board, processes the signal with some IPs/chips, and then outputs the signal. So there's no framebuffer, and the image is not stored anywhere. I think the framework used in these cases is always v4l2. The IPs/chips in the above model may be the exact same IPs/chips that are used with "normal" display. If the CDF was tied to DRM, using the same drivers for normal and these streaming cases would probably not be possible. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 15:37 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-12-19 15:37 UTC (permalink / raw) To: Rob Clark Cc: Jani Nikula, Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 4348 bytes --] On 2012-12-19 17:26, Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula > <jani.nikula@linux.intel.com> wrote: >> >> Hi Laurent - >> >> On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >>> Hi Jani, >>> >>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>>> I can see the need for a framework for DSI panels and such (in fact Tomi >>>> and I have talked about it like 2-3 years ago already!) but what is the >>>> story for HDMI and DP? In particular, what's the relationship between >>>> DRM and CDF here? Is there a world domination plan to switch the DRM >>>> drivers to use this framework too? ;) Do you have some rough plans how >>>> DRM and CDF should work together in general? >>> >>> There's always a world domination plan, isn't there ? :-) >>> >>> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >>> the C stands for, common refers to sharing panel and other display entity >>> drivers between FBDEV, KMS and V4L2. >>> >>> I currently have no plan to expose CDF internals to userspace through the KMS >>> API. We might have to do so later if the hardware complexity grows in such a >>> way that finer control than what KMS provides needs to be exposed to >>> userspace, but I don't think we're there yet. The CDF API will thus only be >>> used internally in the kernel by display controller drivers. The KMS core >>> might get functions to handle common display entity operations, but the bulk >>> of the work will be in the display controller drivers to start with. We will >>> then see what can be abstracted in KMS helper functions. >>> >>> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >>> API. That's just a thought for now, I haven't tried to implement them, but it >>> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >>> >>> Do you have thoughts to share on this topic ? >> >> It just seems to me that, at least from a DRM/KMS perspective, adding >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be >> overengineering it. They are pretty well standardized, and I don't see >> there would be a need to write multiple display drivers for them. Each >> display controller has one, and can easily handle any chip specific >> requirements right there. It's my gut feeling that an additional >> framework would just get in the way. Perhaps there could be more common >> HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, >> but that's another thing. >> >> So is the HDMI/DP drivers using CDF a more interesting idea from a >> non-DRM perspective? Or, put another way, is it more of an alternative >> to using DRM? Please enlighten me if there's some real benefit here that >> I fail to see! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. Well, we need to think about that. I would like to keep CDF independent of DRM. I don't like tying different components/frameworks together if there's no real need for that. Also, something that Laurent mentioned in our face-to-face discussions: Some IPs/chips can be used for other purposes than with DRM. He had an example of a board, that (if I understood right) gets video signal from somewhere outside the board, processes the signal with some IPs/chips, and then outputs the signal. So there's no framebuffer, and the image is not stored anywhere. I think the framework used in these cases is always v4l2. The IPs/chips in the above model may be the exact same IPs/chips that are used with "normal" display. If the CDF was tied to DRM, using the same drivers for normal and these streaming cases would probably not be possible. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 15:37 ` Tomi Valkeinen (?) @ 2012-12-19 16:05 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-19 16:05 UTC (permalink / raw) To: Tomi Valkeinen Cc: Jani Nikula, Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 16:05 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-19 16:05 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, dri-devel, Kyungmin Park, Ragesh Radhakrishnan, Laurent Pinchart, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 16:05 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-19 16:05 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, dri-devel, Kyungmin Park, Ragesh Radhakrishnan, Laurent Pinchart, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 16:05 ` Rob Clark @ 2012-12-24 17:40 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:40 UTC (permalink / raw) To: Rob Clark Cc: Tomi Valkeinen, Jani Nikula, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media, hans.verkuil Hi Rob, (CC'ing Hans Verkuil) On Wednesday 19 December 2012 10:05:27 Rob Clark wrote: > On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > > On 2012-12-19 17:26, Rob Clark wrote: > >> And, there are also external HDMI encoders (for example connected over > >> i2c) that can also be shared between boards. So I think there will be > >> a number of cases where CDF is appropriate for HDMI drivers. Although > >> trying to keep this all independent of DRM (as opposed to just something > >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me. > >> Being able to use the helpers in drm and avoiding an extra layer of > >> translation seems like the better option to me. So my vote would be > >> drivers/gpu/cdf. > > > > Well, we need to think about that. I would like to keep CDF independent > > of DRM. I don't like tying different components/frameworks together if > > there's no real need for that. > > > > Also, something that Laurent mentioned in our face-to-face discussions: > > Some IPs/chips can be used for other purposes than with DRM. > > > > He had an example of a board, that (if I understood right) gets video > > signal from somewhere outside the board, processes the signal with some > > IPs/chips, and then outputs the signal. So there's no framebuffer, and > > the image is not stored anywhere. I think the framework used in these > > cases is always v4l2. > > > > The IPs/chips in the above model may be the exact same IPs/chips that > > are used with "normal" display. If the CDF was tied to DRM, using the > > same drivers for normal and these streaming cases would probably not be > > possible. > > Well, maybe there is a way, but it really seems to be over-complicating > things unnecessarily to keep CDF independent of DRM.. there will be a lot > more traditional uses of CDF compared to one crazy use-case. So I don't > really fancy making it more difficult than in needs to be for everyone. Most of the use cases will be in DRM, we agree on that. However, I don't think that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips that can process/capture/generate up to 18 (if my memory is correct) video streams, and those are extensively used in video conferencing solutions or set top boxes for instance. A couple of the output video streams are display-based and should be handled by DRM/KMS, but most of them are V4L2 streams. That's something we should discuss with Hans Verkuil, he might be able to provide us with more information. > Probably the thing to do is take a step back and reconsider that one crazy > use-case. For example, KMS doesn't enforce that the buffer handled passed > when you create a drm framebuffer object to scan out is a GEM buffer. So on > that one crazy platform, maybe it makes sense to have a DRM/KMS display > driver that takes a handle to identify which video stream coming from the > capture end of the pipeline. Anyways, that is just an off-the-top-of-my- > head idea, probably there are other options too. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:40 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:40 UTC (permalink / raw) To: Rob Clark Cc: Tomi Valkeinen, Jani Nikula, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media, hans.verkuil Hi Rob, (CC'ing Hans Verkuil) On Wednesday 19 December 2012 10:05:27 Rob Clark wrote: > On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > > On 2012-12-19 17:26, Rob Clark wrote: > >> And, there are also external HDMI encoders (for example connected over > >> i2c) that can also be shared between boards. So I think there will be > >> a number of cases where CDF is appropriate for HDMI drivers. Although > >> trying to keep this all independent of DRM (as opposed to just something > >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me. > >> Being able to use the helpers in drm and avoiding an extra layer of > >> translation seems like the better option to me. So my vote would be > >> drivers/gpu/cdf. > > > > Well, we need to think about that. I would like to keep CDF independent > > of DRM. I don't like tying different components/frameworks together if > > there's no real need for that. > > > > Also, something that Laurent mentioned in our face-to-face discussions: > > Some IPs/chips can be used for other purposes than with DRM. > > > > He had an example of a board, that (if I understood right) gets video > > signal from somewhere outside the board, processes the signal with some > > IPs/chips, and then outputs the signal. So there's no framebuffer, and > > the image is not stored anywhere. I think the framework used in these > > cases is always v4l2. > > > > The IPs/chips in the above model may be the exact same IPs/chips that > > are used with "normal" display. If the CDF was tied to DRM, using the > > same drivers for normal and these streaming cases would probably not be > > possible. > > Well, maybe there is a way, but it really seems to be over-complicating > things unnecessarily to keep CDF independent of DRM.. there will be a lot > more traditional uses of CDF compared to one crazy use-case. So I don't > really fancy making it more difficult than in needs to be for everyone. Most of the use cases will be in DRM, we agree on that. However, I don't think that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips that can process/capture/generate up to 18 (if my memory is correct) video streams, and those are extensively used in video conferencing solutions or set top boxes for instance. A couple of the output video streams are display-based and should be handled by DRM/KMS, but most of them are V4L2 streams. That's something we should discuss with Hans Verkuil, he might be able to provide us with more information. > Probably the thing to do is take a step back and reconsider that one crazy > use-case. For example, KMS doesn't enforce that the buffer handled passed > when you create a drm framebuffer object to scan out is a GEM buffer. So on > that one crazy platform, maybe it makes sense to have a DRM/KMS display > driver that takes a handle to identify which video stream coming from the > capture end of the pipeline. Anyways, that is just an off-the-top-of-my- > head idea, probably there are other options too. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 15:26 ` Rob Clark @ 2012-12-24 17:35 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:35 UTC (permalink / raw) To: Rob Clark, Maxime Ripard Cc: Jani Nikula, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >>> I can see the need for a framework for DSI panels and such (in fact Tomi > >>> and I have talked about it like 2-3 years ago already!) but what is the > >>> story for HDMI and DP? In particular, what's the relationship between > >>> DRM and CDF here? Is there a world domination plan to switch the DRM > >>> drivers to use this framework too? ;) Do you have some rough plans how > >>> DRM and CDF should work together in general? > >> > >> There's always a world domination plan, isn't there ? :-) > >> > >> I certainly want CDF to be used by DRM (or more accurately KMS). That's > >> what the C stands for, common refers to sharing panel and other display > >> entity drivers between FBDEV, KMS and V4L2. > >> > >> I currently have no plan to expose CDF internals to userspace through the > >> KMS API. We might have to do so later if the hardware complexity grows > >> in such a way that finer control than what KMS provides needs to be > >> exposed to userspace, but I don't think we're there yet. The CDF API > >> will thus only be used internally in the kernel by display controller > >> drivers. The KMS core might get functions to handle common display > >> entity operations, but the bulk of the work will be in the display > >> controller drivers to start with. We will then see what can be > >> abstracted in KMS helper functions. > >> > >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > >> CDF API. That's just a thought for now, I haven't tried to implement > >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels > >> in a generic way. > >> > >> Do you have thoughts to share on this topic ? > > > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. I don't think there will be any need for translation (except perhaps between the DRM mode structures and the common video mode structure that is being discussed). Add a drm_ prefix to the existing CDF functions and structures, and there you go :-) The reason why I'd like to keep CDF separate from DRM (or at least not requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 drivers. > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:35 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:35 UTC (permalink / raw) To: Rob Clark, Maxime Ripard Cc: Jani Nikula, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >>> I can see the need for a framework for DSI panels and such (in fact Tomi > >>> and I have talked about it like 2-3 years ago already!) but what is the > >>> story for HDMI and DP? In particular, what's the relationship between > >>> DRM and CDF here? Is there a world domination plan to switch the DRM > >>> drivers to use this framework too? ;) Do you have some rough plans how > >>> DRM and CDF should work together in general? > >> > >> There's always a world domination plan, isn't there ? :-) > >> > >> I certainly want CDF to be used by DRM (or more accurately KMS). That's > >> what the C stands for, common refers to sharing panel and other display > >> entity drivers between FBDEV, KMS and V4L2. > >> > >> I currently have no plan to expose CDF internals to userspace through the > >> KMS API. We might have to do so later if the hardware complexity grows > >> in such a way that finer control than what KMS provides needs to be > >> exposed to userspace, but I don't think we're there yet. The CDF API > >> will thus only be used internally in the kernel by display controller > >> drivers. The KMS core might get functions to handle common display > >> entity operations, but the bulk of the work will be in the display > >> controller drivers to start with. We will then see what can be > >> abstracted in KMS helper functions. > >> > >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > >> CDF API. That's just a thought for now, I haven't tried to implement > >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels > >> in a generic way. > >> > >> Do you have thoughts to share on this topic ? > > > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (ÍF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. I don't think there will be any need for translation (except perhaps between the DRM mode structures and the common video mode structure that is being discussed). Add a drm_ prefix to the existing CDF functions and structures, and there you go :-) The reason why I'd like to keep CDF separate from DRM (or at least not requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 drivers. > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-24 17:35 ` Laurent Pinchart @ 2012-12-27 16:10 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 16:10 UTC (permalink / raw) To: Laurent Pinchart Cc: Maxime Ripard, Jani Nikula, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > I don't think there will be any need for translation (except perhaps between > the DRM mode structures and the common video mode structure that is being > discussed). Add a drm_ prefix to the existing CDF functions and structures, > and there you go :-) well, and translation for any properties that we'd want to expose to userspace, etc, etc.. I see there being a big potential for a lot of needless glue BR, -R > The reason why I'd like to keep CDF separate from DRM (or at least not > requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 > drivers. > >> > For DSI panels (or DSI-to-whatever bridges) it's of course another >> > story. You typically need a panel specific driver. And here I see the >> > main point of the whole CDF: decoupling display controllers and the >> > panel drivers, and sharing panel (and converter chip) specific drivers >> > across display controllers. Making it easy to write new drivers, as >> > there would be a model to follow. I'm definitely in favour of coming up >> > with some framework that would tackle that. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 16:10 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 16:10 UTC (permalink / raw) To: Laurent Pinchart Cc: Maxime Ripard, Jani Nikula, Tomi Valkeinen, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > I don't think there will be any need for translation (except perhaps between > the DRM mode structures and the common video mode structure that is being > discussed). Add a drm_ prefix to the existing CDF functions and structures, > and there you go :-) well, and translation for any properties that we'd want to expose to userspace, etc, etc.. I see there being a big potential for a lot of needless glue BR, -R > The reason why I'd like to keep CDF separate from DRM (or at least not > requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 > drivers. > >> > For DSI panels (or DSI-to-whatever bridges) it's of course another >> > story. You typically need a panel specific driver. And here I see the >> > main point of the whole CDF: decoupling display controllers and the >> > panel drivers, and sharing panel (and converter chip) specific drivers >> > across display controllers. Making it easy to write new drivers, as >> > there would be a model to follow. I'm definitely in favour of coming up >> > with some framework that would tackle that. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-19 14:57 ` Jani Nikula @ 2012-12-24 17:27 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:27 UTC (permalink / raw) To: Jani Nikula, Maxime Ripard Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Jani, On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >> I can see the need for a framework for DSI panels and such (in fact Tomi > >> and I have talked about it like 2-3 years ago already!) but what is the > >> story for HDMI and DP? In particular, what's the relationship between > >> DRM and CDF here? Is there a world domination plan to switch the DRM > >> drivers to use this framework too? ;) Do you have some rough plans how > >> DRM and CDF should work together in general? > > > > There's always a world domination plan, isn't there ? :-) > > > > I certainly want CDF to be used by DRM (or more accurately KMS). That's > > what the C stands for, common refers to sharing panel and other display > > entity drivers between FBDEV, KMS and V4L2. > > > > I currently have no plan to expose CDF internals to userspace through the > > KMS API. We might have to do so later if the hardware complexity grows in > > such a way that finer control than what KMS provides needs to be exposed > > to userspace, but I don't think we're there yet. The CDF API will thus > > only be used internally in the kernel by display controller drivers. The > > KMS core might get functions to handle common display entity operations, > > but the bulk of the work will be in the display controller drivers to > > start with. We will then see what can be abstracted in KMS helper > > functions. > > > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > > CDF API. That's just a thought for now, I haven't tried to implement them, > > but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a > > generic way. > > > > Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see there > would be a need to write multiple display drivers for them. Each display > controller has one, and can easily handle any chip specific requirements > right there. It's my gut feeling that an additional framework would just get > in the way. Perhaps there could be more common HDMI/DP helper style code in > DRM to reduce overlap across KMS drivers, but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > perspective? Or, put another way, is it more of an alternative to using DRM? > Please enlighten me if there's some real benefit here that I fail to see! As Rob pointed out, you can have external HDMI/DP encoders, and even internal HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at sharing a single driver between SoCs and boards for a given HDMI/DP encoder. CDF isn't an alternative to DRM/KMS. It should be seen as a framework that helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, although those should be ported to DRM/KMS) sharing encoder and connector code. > For DSI panels (or DSI-to-whatever bridges) it's of course another story. > You typically need a panel specific driver. And here I see the main point of > the whole CDF: decoupling display controllers and the panel drivers, and > sharing panel (and converter chip) specific drivers across display > controllers. Making it easy to write new drivers, as there would be a model > to follow. I'm definitely in favour of coming up with some framework that > would tackle that. That's the main (and original) goal of CDF (originally called Generic Panel Framwork, and renamed to CDF to support encoder drivers as explained above). I'm glad to know that you're in favour of it :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:27 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:27 UTC (permalink / raw) To: Jani Nikula, Maxime Ripard Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Jani, On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >> I can see the need for a framework for DSI panels and such (in fact Tomi > >> and I have talked about it like 2-3 years ago already!) but what is the > >> story for HDMI and DP? In particular, what's the relationship between > >> DRM and CDF here? Is there a world domination plan to switch the DRM > >> drivers to use this framework too? ;) Do you have some rough plans how > >> DRM and CDF should work together in general? > > > > There's always a world domination plan, isn't there ? :-) > > > > I certainly want CDF to be used by DRM (or more accurately KMS). That's > > what the C stands for, common refers to sharing panel and other display > > entity drivers between FBDEV, KMS and V4L2. > > > > I currently have no plan to expose CDF internals to userspace through the > > KMS API. We might have to do so later if the hardware complexity grows in > > such a way that finer control than what KMS provides needs to be exposed > > to userspace, but I don't think we're there yet. The CDF API will thus > > only be used internally in the kernel by display controller drivers. The > > KMS core might get functions to handle common display entity operations, > > but the bulk of the work will be in the display controller drivers to > > start with. We will then see what can be abstracted in KMS helper > > functions. > > > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > > CDF API. That's just a thought for now, I haven't tried to implement them, > > but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a > > generic way. > > > > Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (ÍF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see there > would be a need to write multiple display drivers for them. Each display > controller has one, and can easily handle any chip specific requirements > right there. It's my gut feeling that an additional framework would just get > in the way. Perhaps there could be more common HDMI/DP helper style code in > DRM to reduce overlap across KMS drivers, but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > perspective? Or, put another way, is it more of an alternative to using DRM? > Please enlighten me if there's some real benefit here that I fail to see! As Rob pointed out, you can have external HDMI/DP encoders, and even internal HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at sharing a single driver between SoCs and boards for a given HDMI/DP encoder. CDF isn't an alternative to DRM/KMS. It should be seen as a framework that helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, although those should be ported to DRM/KMS) sharing encoder and connector code. > For DSI panels (or DSI-to-whatever bridges) it's of course another story. > You typically need a panel specific driver. And here I see the main point of > the whole CDF: decoupling display controllers and the panel drivers, and > sharing panel (and converter chip) specific drivers across display > controllers. Making it easy to write new drivers, as there would be a model > to follow. I'm definitely in favour of coming up with some framework that > would tackle that. That's the main (and original) goal of CDF (originally called Generic Panel Framwork, and renamed to CDF to support encoder drivers as explained above). I'm glad to know that you're in favour of it :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-24 17:27 ` Laurent Pinchart @ 2012-12-27 16:04 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 16:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Jani Nikula, Maxime Ripard, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: >> It just seems to me that, at least from a DRM/KMS perspective, adding >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be >> overengineering it. They are pretty well standardized, and I don't see there >> would be a need to write multiple display drivers for them. Each display >> controller has one, and can easily handle any chip specific requirements >> right there. It's my gut feeling that an additional framework would just get >> in the way. Perhaps there could be more common HDMI/DP helper style code in >> DRM to reduce overlap across KMS drivers, but that's another thing. >> >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM >> perspective? Or, put another way, is it more of an alternative to using DRM? >> Please enlighten me if there's some real benefit here that I fail to see! > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. just fwiw, drm already has something a bit like this.. the i2c encoder-slave. With support for a couple external i2c encoders which could in theory be shared between devices. BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 16:04 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 16:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Jani Nikula, Maxime Ripard, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: >> It just seems to me that, at least from a DRM/KMS perspective, adding >> another layer (ÍF) for HDMI or DP (or legacy outputs) would be >> overengineering it. They are pretty well standardized, and I don't see there >> would be a need to write multiple display drivers for them. Each display >> controller has one, and can easily handle any chip specific requirements >> right there. It's my gut feeling that an additional framework would just get >> in the way. Perhaps there could be more common HDMI/DP helper style code in >> DRM to reduce overlap across KMS drivers, but that's another thing. >> >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM >> perspective? Or, put another way, is it more of an alternative to using DRM? >> Please enlighten me if there's some real benefit here that I fail to see! > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. just fwiw, drm already has something a bit like this.. the i2c encoder-slave. With support for a couple external i2c encoders which could in theory be shared between devices. BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 16:04 ` Rob Clark @ 2012-12-27 19:19 ` Sascha Hauer -1 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-27 19:19 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Jani Nikula, Maxime Ripard, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > >> It just seems to me that, at least from a DRM/KMS perspective, adding > >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be > >> overengineering it. They are pretty well standardized, and I don't see there > >> would be a need to write multiple display drivers for them. Each display > >> controller has one, and can easily handle any chip specific requirements > >> right there. It's my gut feeling that an additional framework would just get > >> in the way. Perhaps there could be more common HDMI/DP helper style code in > >> DRM to reduce overlap across KMS drivers, but that's another thing. > >> > >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > >> perspective? Or, put another way, is it more of an alternative to using DRM? > >> Please enlighten me if there's some real benefit here that I fail to see! > > > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. > > just fwiw, drm already has something a bit like this.. the i2c > encoder-slave. With support for a couple external i2c encoders which > could in theory be shared between devices. The problem with this code is that it only works when the i2c device is registered by a master driver. Once the i2c device comes from the devicetree there is no possibility to find it. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 19:19 ` Sascha Hauer 0 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-27 19:19 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Jani Nikula, Maxime Ripard, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > >> It just seems to me that, at least from a DRM/KMS perspective, adding > >> another layer (ÍF) for HDMI or DP (or legacy outputs) would be > >> overengineering it. They are pretty well standardized, and I don't see there > >> would be a need to write multiple display drivers for them. Each display > >> controller has one, and can easily handle any chip specific requirements > >> right there. It's my gut feeling that an additional framework would just get > >> in the way. Perhaps there could be more common HDMI/DP helper style code in > >> DRM to reduce overlap across KMS drivers, but that's another thing. > >> > >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > >> perspective? Or, put another way, is it more of an alternative to using DRM? > >> Please enlighten me if there's some real benefit here that I fail to see! > > > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. > > just fwiw, drm already has something a bit like this.. the i2c > encoder-slave. With support for a couple external i2c encoders which > could in theory be shared between devices. The problem with this code is that it only works when the i2c device is registered by a master driver. Once the i2c device comes from the devicetree there is no possibility to find it. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-22 21:45 ` Laurent Pinchart @ 2012-11-23 19:56 ` Thierry Reding -1 siblings, 0 replies; 153+ messages in thread From: Thierry Reding @ 2012-11-23 19:56 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2570 bytes --] On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] > Display entities are accessed by driver using notifiers. Any driver can > register a display entity notifier with the CDF, which then calls the notifier > when a matching display entity is registered. The reason for this asynchronous > mode of operation, compared to how drivers acquire regulator or clock > resources, is that the display entities can use resources provided by the > display driver. For instance a panel can be a child of the DBI or DSI bus > controlled by the display device, or use a clock provided by that device. We > can't defer the display device probe until the panel is registered and also > defer the panel device probe until the display is registered. As most display > drivers need to handle output devices hotplug (HDMI monitors for instance), > handling other display entities through a notification system seemed to be the > easiest solution. > > Note that this brings a different issue after registration, as display > controller and display entity drivers would take a reference to each other. > Those circular references would make driver unloading impossible. One possible > solution to this problem would be to simulate an unplug event for the display > entity, to force the display driver to release the dislay entities it uses. We > would need a userspace API for that though. Better solutions would of course > be welcome. Maybe I don't understand all of the underlying issues correctly, but a parent/child model would seem like a better solution to me. We discussed this back when designing the DT bindings for Tegra DRM and came to the conclusion that the output resource of the display controller (RGB, HDMI, DSI or TVO) was the most suitable candidate to be the parent of the panel or display attached to it. The reason for that decision was that it keeps the flow of data or addressing of nodes consistent. So the chain would look something like this (on Tegra): CPU +-host1x +-dc +-rgb | +-panel +-hdmi +-monitor In a natural way this makes the output resource the master of the panel or display. From a programming point of view this becomes quite easy to implement and is very similar to how other busses like I2C or SPI are modelled. In device tree these would be represented as subnodes, while with platform data some kind of lookup could be done like for regulators or alternatively a board setup registration mechanism like what's in place for I2C or SPI. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-23 19:56 ` Thierry Reding 0 siblings, 0 replies; 153+ messages in thread From: Thierry Reding @ 2012-11-23 19:56 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 2570 bytes --] On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] > Display entities are accessed by driver using notifiers. Any driver can > register a display entity notifier with the CDF, which then calls the notifier > when a matching display entity is registered. The reason for this asynchronous > mode of operation, compared to how drivers acquire regulator or clock > resources, is that the display entities can use resources provided by the > display driver. For instance a panel can be a child of the DBI or DSI bus > controlled by the display device, or use a clock provided by that device. We > can't defer the display device probe until the panel is registered and also > defer the panel device probe until the display is registered. As most display > drivers need to handle output devices hotplug (HDMI monitors for instance), > handling other display entities through a notification system seemed to be the > easiest solution. > > Note that this brings a different issue after registration, as display > controller and display entity drivers would take a reference to each other. > Those circular references would make driver unloading impossible. One possible > solution to this problem would be to simulate an unplug event for the display > entity, to force the display driver to release the dislay entities it uses. We > would need a userspace API for that though. Better solutions would of course > be welcome. Maybe I don't understand all of the underlying issues correctly, but a parent/child model would seem like a better solution to me. We discussed this back when designing the DT bindings for Tegra DRM and came to the conclusion that the output resource of the display controller (RGB, HDMI, DSI or TVO) was the most suitable candidate to be the parent of the panel or display attached to it. The reason for that decision was that it keeps the flow of data or addressing of nodes consistent. So the chain would look something like this (on Tegra): CPU +-host1x +-dc +-rgb | +-panel +-hdmi +-monitor In a natural way this makes the output resource the master of the panel or display. From a programming point of view this becomes quite easy to implement and is very similar to how other busses like I2C or SPI are modelled. In device tree these would be represented as subnodes, while with platform data some kind of lookup could be done like for regulators or alternatively a board setup registration mechanism like what's in place for I2C or SPI. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-23 19:56 ` Thierry Reding (?) @ 2012-11-24 7:15 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-24 7:15 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 3422 bytes --] On 2012-11-23 21:56, Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] >> Display entities are accessed by driver using notifiers. Any driver can >> register a display entity notifier with the CDF, which then calls the notifier >> when a matching display entity is registered. The reason for this asynchronous >> mode of operation, compared to how drivers acquire regulator or clock >> resources, is that the display entities can use resources provided by the >> display driver. For instance a panel can be a child of the DBI or DSI bus >> controlled by the display device, or use a clock provided by that device. We >> can't defer the display device probe until the panel is registered and also >> defer the panel device probe until the display is registered. As most display >> drivers need to handle output devices hotplug (HDMI monitors for instance), >> handling other display entities through a notification system seemed to be the >> easiest solution. >> >> Note that this brings a different issue after registration, as display >> controller and display entity drivers would take a reference to each other. >> Those circular references would make driver unloading impossible. One possible >> solution to this problem would be to simulate an unplug event for the display >> entity, to force the display driver to release the dislay entities it uses. We >> would need a userspace API for that though. Better solutions would of course >> be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. You didn't explicitly say it, but I presume you are talking about the device model for panels, not just how to refer to the outputs. How would you deal with a, say, DPI panel that is controlled via I2C or SPI? You can have the panel device be both a panel device, child of a RGB output, and an i2c device. The model you propose is currently used in omapdss, and while it seems simple and logical, it's not that simple with panels/chips with separate control and data busses. I think it makes more sense to consider the device as a child of the control bus. So a DPI panel controlled via I2C is an I2C device, and it just happens to use a DPI video output as a resource (like it could use a regulator, gpio, etc). Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-24 7:15 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-24 7:15 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 3422 bytes --] On 2012-11-23 21:56, Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] >> Display entities are accessed by driver using notifiers. Any driver can >> register a display entity notifier with the CDF, which then calls the notifier >> when a matching display entity is registered. The reason for this asynchronous >> mode of operation, compared to how drivers acquire regulator or clock >> resources, is that the display entities can use resources provided by the >> display driver. For instance a panel can be a child of the DBI or DSI bus >> controlled by the display device, or use a clock provided by that device. We >> can't defer the display device probe until the panel is registered and also >> defer the panel device probe until the display is registered. As most display >> drivers need to handle output devices hotplug (HDMI monitors for instance), >> handling other display entities through a notification system seemed to be the >> easiest solution. >> >> Note that this brings a different issue after registration, as display >> controller and display entity drivers would take a reference to each other. >> Those circular references would make driver unloading impossible. One possible >> solution to this problem would be to simulate an unplug event for the display >> entity, to force the display driver to release the dislay entities it uses. We >> would need a userspace API for that though. Better solutions would of course >> be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. You didn't explicitly say it, but I presume you are talking about the device model for panels, not just how to refer to the outputs. How would you deal with a, say, DPI panel that is controlled via I2C or SPI? You can have the panel device be both a panel device, child of a RGB output, and an i2c device. The model you propose is currently used in omapdss, and while it seems simple and logical, it's not that simple with panels/chips with separate control and data busses. I think it makes more sense to consider the device as a child of the control bus. So a DPI panel controlled via I2C is an I2C device, and it just happens to use a DPI video output as a resource (like it could use a regulator, gpio, etc). Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-24 7:15 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2012-11-24 7:15 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 3422 bytes --] On 2012-11-23 21:56, Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] >> Display entities are accessed by driver using notifiers. Any driver can >> register a display entity notifier with the CDF, which then calls the notifier >> when a matching display entity is registered. The reason for this asynchronous >> mode of operation, compared to how drivers acquire regulator or clock >> resources, is that the display entities can use resources provided by the >> display driver. For instance a panel can be a child of the DBI or DSI bus >> controlled by the display device, or use a clock provided by that device. We >> can't defer the display device probe until the panel is registered and also >> defer the panel device probe until the display is registered. As most display >> drivers need to handle output devices hotplug (HDMI monitors for instance), >> handling other display entities through a notification system seemed to be the >> easiest solution. >> >> Note that this brings a different issue after registration, as display >> controller and display entity drivers would take a reference to each other. >> Those circular references would make driver unloading impossible. One possible >> solution to this problem would be to simulate an unplug event for the display >> entity, to force the display driver to release the dislay entities it uses. We >> would need a userspace API for that though. Better solutions would of course >> be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. You didn't explicitly say it, but I presume you are talking about the device model for panels, not just how to refer to the outputs. How would you deal with a, say, DPI panel that is controlled via I2C or SPI? You can have the panel device be both a panel device, child of a RGB output, and an i2c device. The model you propose is currently used in omapdss, and while it seems simple and logical, it's not that simple with panels/chips with separate control and data busses. I think it makes more sense to consider the device as a child of the control bus. So a DPI panel controlled via I2C is an I2C device, and it just happens to use a DPI video output as a resource (like it could use a regulator, gpio, etc). Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-24 7:15 ` Tomi Valkeinen (?) (?) @ 2012-11-26 14:47 ` Alan Cox 2012-12-17 15:15 ` Laurent Pinchart -1 siblings, 1 reply; 153+ messages in thread From: Alan Cox @ 2012-11-26 14:47 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thierry Reding, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Laurent Pinchart, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 2012-11-23 21:56, Thierry Reding wrote: > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > [...] > >> Display entities are accessed by driver using notifiers. Any driver can > >> register a display entity notifier with the CDF, which then calls the notifier > >> when a matching display entity is registered. The framebuffer layer has some similar 'anyone can' type notifier behaviour and its not a good thing. That kind of "any one can" behaviour leads to some really horrible messes unless the connections and the locking are well defined IMHO. Alan ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-26 14:47 ` Alan Cox @ 2012-12-17 15:15 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 15:15 UTC (permalink / raw) To: Alan Cox, Maxime Ripard Cc: Tomi Valkeinen, Thierry Reding, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Philipp Zabel, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Alan, On Monday 26 November 2012 14:47:08 Alan Cox wrote: > On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote: > > On 2012-11-23 21:56, Thierry Reding wrote: > > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > > [...] > > > > > >> Display entities are accessed by driver using notifiers. Any driver can > > >> register a display entity notifier with the CDF, which then calls the > > >> notifier when a matching display entity is registered. > > The framebuffer layer has some similar 'anyone can' type notifier > behaviour and its not a good thing. That kind of "any one can" behaviour > leads to some really horrible messes unless the connections and the > locking are well defined IMHO. I agree with you. I dislike the FBDEV notifier model, and I definitely don't intend to duplicate it in the common display framework. In the CDF model, when the display device driver registers a notifier, it tells the core which device it wants to receive events for. This currently takes the form of a struct device pointer, and the API will also support device nodes in a future version (this is still work in progress). The goal is to implement panel discovery in a way that is compatible with (and very similar to) hotpluggable display discovery. Thinking about it now, the API could be cleaner and less subject to abuse if the notifier was registered for a given video port instead of a given connected device. I'll add that to my TODO list. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 15:15 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 15:15 UTC (permalink / raw) To: Alan Cox, Maxime Ripard Cc: Tomi Valkeinen, Thierry Reding, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Philipp Zabel, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Alan, On Monday 26 November 2012 14:47:08 Alan Cox wrote: > On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote: > > On 2012-11-23 21:56, Thierry Reding wrote: > > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > > [...] > > > > > >> Display entities are accessed by driver using notifiers. Any driver can > > >> register a display entity notifier with the CDF, which then calls the > > >> notifier when a matching display entity is registered. > > The framebuffer layer has some similar 'anyone can' type notifier > behaviour and its not a good thing. That kind of "any one can" behaviour > leads to some really horrible messes unless the connections and the > locking are well defined IMHO. I agree with you. I dislike the FBDEV notifier model, and I definitely don't intend to duplicate it in the common display framework. In the CDF model, when the display device driver registers a notifier, it tells the core which device it wants to receive events for. This currently takes the form of a struct device pointer, and the API will also support device nodes in a future version (this is still work in progress). The goal is to implement panel discovery in a way that is compatible with (and very similar to) hotpluggable display discovery. Thinking about it now, the API could be cleaner and less subject to abuse if the notifier was registered for a given video port instead of a given connected device. I'll add that to my TODO list. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-23 19:56 ` Thierry Reding @ 2012-11-26 7:53 ` Philipp Zabel -1 siblings, 0 replies; 153+ messages in thread From: Philipp Zabel @ 2012-11-26 7:53 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, linux-fbdev, dri-devel, Thomas Petazzoni, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Thierry, Am Freitag, den 23.11.2012, 20:56 +0100 schrieb Thierry Reding: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] > > Display entities are accessed by driver using notifiers. Any driver can > > register a display entity notifier with the CDF, which then calls the notifier > > when a matching display entity is registered. The reason for this asynchronous > > mode of operation, compared to how drivers acquire regulator or clock > > resources, is that the display entities can use resources provided by the > > display driver. For instance a panel can be a child of the DBI or DSI bus > > controlled by the display device, or use a clock provided by that device. We > > can't defer the display device probe until the panel is registered and also > > defer the panel device probe until the display is registered. As most display > > drivers need to handle output devices hotplug (HDMI monitors for instance), > > handling other display entities through a notification system seemed to be the > > easiest solution. > > > > Note that this brings a different issue after registration, as display > > controller and display entity drivers would take a reference to each other. > > Those circular references would make driver unloading impossible. One possible > > solution to this problem would be to simulate an unplug event for the display > > entity, to force the display driver to release the dislay entities it uses. We > > would need a userspace API for that though. Better solutions would of course > > be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. I second Tomi's answer. Also, describing data bus connections implicitly with parent/child relationships doesn't work for entities with multiple inputs. Imagine there are multiple dc's in the above diagram, and the single hdmi encoder can be connected to either of them via multiplexing. regards Philipp ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-26 7:53 ` Philipp Zabel 0 siblings, 0 replies; 153+ messages in thread From: Philipp Zabel @ 2012-11-26 7:53 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, linux-fbdev, dri-devel, Thomas Petazzoni, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Thierry, Am Freitag, den 23.11.2012, 20:56 +0100 schrieb Thierry Reding: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] > > Display entities are accessed by driver using notifiers. Any driver can > > register a display entity notifier with the CDF, which then calls the notifier > > when a matching display entity is registered. The reason for this asynchronous > > mode of operation, compared to how drivers acquire regulator or clock > > resources, is that the display entities can use resources provided by the > > display driver. For instance a panel can be a child of the DBI or DSI bus > > controlled by the display device, or use a clock provided by that device. We > > can't defer the display device probe until the panel is registered and also > > defer the panel device probe until the display is registered. As most display > > drivers need to handle output devices hotplug (HDMI monitors for instance), > > handling other display entities through a notification system seemed to be the > > easiest solution. > > > > Note that this brings a different issue after registration, as display > > controller and display entity drivers would take a reference to each other. > > Those circular references would make driver unloading impossible. One possible > > solution to this problem would be to simulate an unplug event for the display > > entity, to force the display driver to release the dislay entities it uses. We > > would need a userspace API for that though. Better solutions would of course > > be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. I second Tomi's answer. Also, describing data bus connections implicitly with parent/child relationships doesn't work for entities with multiple inputs. Imagine there are multiple dc's in the above diagram, and the single hdmi encoder can be connected to either of them via multiplexing. regards Philipp ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-23 19:56 ` Thierry Reding @ 2012-12-17 14:58 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 14:58 UTC (permalink / raw) To: Thierry Reding Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 3859 bytes --] Hi Thierry, On Friday 23 November 2012 20:56:07 Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] > > > Display entities are accessed by driver using notifiers. Any driver can > > register a display entity notifier with the CDF, which then calls the > > notifier when a matching display entity is registered. The reason for > > this asynchronous mode of operation, compared to how drivers acquire > > regulator or clock resources, is that the display entities can use > > resources provided by the display driver. For instance a panel can be a > > child of the DBI or DSI bus controlled by the display device, or use a > > clock provided by that device. We can't defer the display device probe > > until the panel is registered and also defer the panel device probe until > > the display is registered. As most display drivers need to handle output > > devices hotplug (HDMI monitors for instance), handling other display > > entities through a notification system seemed to be the easiest solution. > > > > Note that this brings a different issue after registration, as display > > controller and display entity drivers would take a reference to each > > other. Those circular references would make driver unloading impossible. > > One possible solution to this problem would be to simulate an unplug event > > for the display entity, to force the display driver to release the dislay > > entities it uses. We would need a userspace API for that though. Better > > solutions would of course be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. That works well for panels that have a shared control and video bus (DBI, DSI) or only a video bus (DPI), but breaks when you need to support panels with separate control and video busses, such as panels with a parallel data bus and an I2C or SPI control bus. Both Linux and DT have a tree-based device model. Devices can have a single parent, so you can't represent your panel as a child of both the video source and the control bus master. We have the exact same problem in V4L2 with I2C camera sensors that output video data on a separate parallel or serial bus, and we decided to handle the device as a child of its control bus master. This model makes usage of the Linux power management model easier (but not straightforward when power management dependencies exist across video busses, outside of the kernel device tree). As the common display framework should handle both panels with common control and video busses and panels with separate busses in a similar fashion, DT bindings needs to reference the panel through a phandle, even though in some cases they could technically just be children of the display controller. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 14:58 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 14:58 UTC (permalink / raw) To: Thierry Reding Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 3859 bytes --] Hi Thierry, On Friday 23 November 2012 20:56:07 Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] > > > Display entities are accessed by driver using notifiers. Any driver can > > register a display entity notifier with the CDF, which then calls the > > notifier when a matching display entity is registered. The reason for > > this asynchronous mode of operation, compared to how drivers acquire > > regulator or clock resources, is that the display entities can use > > resources provided by the display driver. For instance a panel can be a > > child of the DBI or DSI bus controlled by the display device, or use a > > clock provided by that device. We can't defer the display device probe > > until the panel is registered and also defer the panel device probe until > > the display is registered. As most display drivers need to handle output > > devices hotplug (HDMI monitors for instance), handling other display > > entities through a notification system seemed to be the easiest solution. > > > > Note that this brings a different issue after registration, as display > > controller and display entity drivers would take a reference to each > > other. Those circular references would make driver unloading impossible. > > One possible solution to this problem would be to simulate an unplug event > > for the display entity, to force the display driver to release the dislay > > entities it uses. We would need a userspace API for that though. Better > > solutions would of course be welcome. > > Maybe I don't understand all of the underlying issues correctly, but a > parent/child model would seem like a better solution to me. We discussed > this back when designing the DT bindings for Tegra DRM and came to the > conclusion that the output resource of the display controller (RGB, > HDMI, DSI or TVO) was the most suitable candidate to be the parent of > the panel or display attached to it. The reason for that decision was > that it keeps the flow of data or addressing of nodes consistent. So the > chain would look something like this (on Tegra): > > CPU > +-host1x > +-dc > +-rgb > | +-panel > +-hdmi > +-monitor > > In a natural way this makes the output resource the master of the panel > or display. From a programming point of view this becomes quite easy to > implement and is very similar to how other busses like I2C or SPI are > modelled. In device tree these would be represented as subnodes, while > with platform data some kind of lookup could be done like for regulators > or alternatively a board setup registration mechanism like what's in > place for I2C or SPI. That works well for panels that have a shared control and video bus (DBI, DSI) or only a video bus (DPI), but breaks when you need to support panels with separate control and video busses, such as panels with a parallel data bus and an I2C or SPI control bus. Both Linux and DT have a tree-based device model. Devices can have a single parent, so you can't represent your panel as a child of both the video source and the control bus master. We have the exact same problem in V4L2 with I2C camera sensors that output video data on a separate parallel or serial bus, and we decided to handle the device as a child of its control bus master. This model makes usage of the Linux power management model easier (but not straightforward when power management dependencies exist across video busses, outside of the kernel device tree). As the common display framework should handle both panels with common control and video busses and panels with separate busses in a similar fashion, DT bindings needs to reference the panel through a phandle, even though in some cases they could technically just be children of the display controller. -- Regards, Laurent Pinchart [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-22 21:45 ` Laurent Pinchart @ 2012-11-23 21:41 ` Sascha Hauer -1 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-11-23 21:41 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Laurent, On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > The CDF models this using a Russian doll's model. From the display controller > point of view only the first external entity (LVDS to DSI converter) is > visible. The display controller thus calls the control operations implemented > by the LVDS to DSI transmitter driver (left-most green arrow). The driver is > aware of the next entity in the chain, I can't find this in the code. I can see the video operations propagating upstream using the source field of struct display_entity, but how do the control operations propagate downstream? Am I missing something? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-11-23 21:41 ` Sascha Hauer 0 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-11-23 21:41 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Laurent, On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > The CDF models this using a Russian doll's model. From the display controller > point of view only the first external entity (LVDS to DSI converter) is > visible. The display controller thus calls the control operations implemented > by the LVDS to DSI transmitter driver (left-most green arrow). The driver is > aware of the next entity in the chain, I can't find this in the code. I can see the video operations propagating upstream using the source field of struct display_entity, but how do the control operations propagate downstream? Am I missing something? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-23 21:41 ` Sascha Hauer @ 2012-12-17 15:02 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 15:02 UTC (permalink / raw) To: Sascha Hauer, Inki Dae Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Sascha, On Friday 23 November 2012 22:41:58 Sascha Hauer wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > > The CDF models this using a Russian doll's model. From the display > > controller point of view only the first external entity (LVDS to DSI > > converter) is visible. The display controller thus calls the control > > operations implemented by the LVDS to DSI transmitter driver (left-most > > green arrow). The driver is aware of the next entity in the chain, > > I can't find this in the code. I can see the video operations > propagating upstream using the source field of struct display_entity, > but how do the control operations propagate downstream? Am I missing > something? There's no downstream propagation yet, as there's no display entity driver that requires it at the moment. Propagation would be implemented in transceiver drivers for instance. I'll have to find one with public documentation (and hopefully an existing mainline driver) on one of the boards I own. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-17 15:02 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-17 15:02 UTC (permalink / raw) To: Sascha Hauer, Inki Dae Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Sascha, On Friday 23 November 2012 22:41:58 Sascha Hauer wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > > The CDF models this using a Russian doll's model. From the display > > controller point of view only the first external entity (LVDS to DSI > > converter) is visible. The display controller thus calls the control > > operations implemented by the LVDS to DSI transmitter driver (left-most > > green arrow). The driver is aware of the next entity in the chain, > > I can't find this in the code. I can see the video operations > propagating upstream using the source field of struct display_entity, > but how do the control operations propagate downstream? Am I missing > something? There's no downstream propagation yet, as there's no display entity driver that requires it at the moment. Propagation would be implemented in transceiver drivers for instance. I'll have to find one with public documentation (and hopefully an existing mainline driver) on one of the boards I own. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
[parent not found: <CAD025yS5rGMbiRBdDxv=YLP6_fsQndAkr+3t29_mNhcvow_SwA@mail.gmail.com>]
[parent not found: <3133576.BkqAl7V01U@avalon>]
* Re: [RFC v2 0/5] Common Display Framework [not found] ` <3133576.BkqAl7V01U@avalon> @ 2012-12-18 3:01 ` Vikas Sajjan 2012-12-18 6:13 ` Vikas Sajjan ` (2 more replies) 0 siblings, 3 replies; 153+ messages in thread From: Vikas Sajjan @ 2012-12-18 3:01 UTC (permalink / raw) To: Laurent Pinchart Cc: Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1.1: Type: text/plain, Size: 2413 bytes --] Hi Laurent, Thanks for the reply. On 17 December 2012 20:55, Laurent Pinchart < laurent.pinchart@ideasonboard.com> wrote: > Hi Vikas, > > Sorry for the late reply. I now have more time to work on CDF, so delays > should be much shorter. > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > Hi Laurent, > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I > found > > is that, the exynos display controller is MIPI DSI based controller. > > > > But if I look at CDF patches, it has only support for MIPI DBI based > Display > > controller. > > > > So my question is, do we have any generic framework for MIPI DSI based > > display controller? basically I wanted to know, how to go about porting > CDF > > for such kind of display controller. > > MIPI DSI support is not available yet. The only reason for that is that I > don't have any MIPI DSI hardware to write and test the code with :-) > > The common display framework should definitely support MIPI DSI. I think > the > existing MIPI DBI code could be used as a base, so the implementation > shouldn't be too high. > > Yeah, i was also thinking in similar lines, below is my though for MIPI DSI support in CDF. o MIPI DSI support as part of CDF framework will expose § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file ) § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from platform specific init driver call ) · bus ops will be o read data o write data o write command § MIPI DSI will be registered as bus_register() When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP. This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF. I can give this a try. Does the existing Exynos 5250 driver support MIPI > DSI ? > Is the device documentation publicly available ? Can you point me to a MIPI > DSI panel with public documentation (preferably with an existing mainline > driver if possible) ? > > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. i think device documentation is NOT available publicly. -- > Regards, > > Laurent Pinchart > > -- Thanks and Regards Vikas Sajjan [-- Attachment #1.2: Type: text/html, Size: 5709 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 3:01 ` Vikas Sajjan @ 2012-12-18 6:13 ` Vikas Sajjan 2012-12-21 10:00 ` Tomasz Figa 2012-12-24 12:59 ` Laurent Pinchart 2 siblings, 0 replies; 153+ messages in thread From: Vikas Sajjan @ 2012-12-18 6:25 UTC (permalink / raw) To: dri-devel, linux-fbdev, linux-media Hi All, On 17 December 2012 20:55, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Vikas, > > Sorry for the late reply. I now have more time to work on CDF, so delays > should be much shorter. > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > Hi Laurent, > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I found > > is that, the exynos display controller is MIPI DSI based controller. > > > > But if I look at CDF patches, it has only support for MIPI DBI based Display > > controller. > > > > So my question is, do we have any generic framework for MIPI DSI based > > display controller? basically I wanted to know, how to go about porting CDF > > for such kind of display controller. > > MIPI DSI support is not available yet. The only reason for that is that I > don't have any MIPI DSI hardware to write and test the code with :-) > > The common display framework should definitely support MIPI DSI. I think the > existing MIPI DBI code could be used as a base, so the implementation > shouldn't be too high. > Yeah, i was also thinking in similar lines, below is my though for MIPI DSI support in CDF. o MIPI DSI support as part of CDF framework will expose > mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file ) > mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from platform specific init driver call ) · bus ops will be o read data o write data o write command > MIPI DSI will be registered as bus_register() When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP. This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF. > > I can give this a try. Does the existing Exynos 5250 driver support MIPI DSI ? > Is the device documentation publicly available ? Can you point me to a MIPI > DSI panel with public documentation (preferably with an existing mainline > driver if possible) ? > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. i think device documentation is NOT available publicly. > -- > Regards, > > Laurent Pinchart > -- Thanks and Regards Vikas Sajjan ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 6:13 ` Vikas Sajjan 0 siblings, 0 replies; 153+ messages in thread From: Vikas Sajjan @ 2012-12-18 6:13 UTC (permalink / raw) To: dri-devel, linux-fbdev, linux-media Hi All, On 17 December 2012 20:55, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Vikas, > > Sorry for the late reply. I now have more time to work on CDF, so delays > should be much shorter. > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > Hi Laurent, > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I found > > is that, the exynos display controller is MIPI DSI based controller. > > > > But if I look at CDF patches, it has only support for MIPI DBI based Display > > controller. > > > > So my question is, do we have any generic framework for MIPI DSI based > > display controller? basically I wanted to know, how to go about porting CDF > > for such kind of display controller. > > MIPI DSI support is not available yet. The only reason for that is that I > don't have any MIPI DSI hardware to write and test the code with :-) > > The common display framework should definitely support MIPI DSI. I think the > existing MIPI DBI code could be used as a base, so the implementation > shouldn't be too high. > Yeah, i was also thinking in similar lines, below is my though for MIPI DSI support in CDF. o MIPI DSI support as part of CDF framework will expose > mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file ) > mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from platform specific init driver call ) · bus ops will be o read data o write data o write command > MIPI DSI will be registered as bus_register() When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP. This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF. > > I can give this a try. Does the existing Exynos 5250 driver support MIPI DSI ? > Is the device documentation publicly available ? Can you point me to a MIPI > DSI panel with public documentation (preferably with an existing mainline > driver if possible) ? > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. i think device documentation is NOT available publicly. > -- > Regards, > > Laurent Pinchart > -- Thanks and Regards Vikas Sajjan ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 3:01 ` Vikas Sajjan @ 2012-12-21 10:00 ` Tomasz Figa 2012-12-21 10:00 ` Tomasz Figa 2012-12-24 12:59 ` Laurent Pinchart 2 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2012-12-21 10:00 UTC (permalink / raw) To: dri-devel Cc: Vikas Sajjan, Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Vikas, On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > Hi Laurent, > > Thanks for the reply. > > On 17 December 2012 20:55, Laurent Pinchart < > > laurent.pinchart@ideasonboard.com> wrote: > > Hi Vikas, > > > > Sorry for the late reply. I now have more time to work on CDF, so > > delays should be much shorter. > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > Hi Laurent, > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what > > > I > > > > found > > > > > is that, the exynos display controller is MIPI DSI based controller. > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > > Display > > > > > controller. > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > based > > > display controller? basically I wanted to know, how to go about > > > porting > > > > CDF > > > > > for such kind of display controller. > > > > MIPI DSI support is not available yet. The only reason for that is > > that I don't have any MIPI DSI hardware to write and test the code > > with :-) > > > > The common display framework should definitely support MIPI DSI. I > > think the > > existing MIPI DBI code could be used as a base, so the implementation > > shouldn't be too high. > > > > Yeah, i was also thinking in similar lines, below is my though for > > MIPI > > DSI support in CDF. > > o MIPI DSI support as part of CDF framework will expose > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > file ) > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > platform specific init driver call ) > > · bus ops will be > > o read data > > o write data > > o write command > > § MIPI DSI will be registered as bus_register() > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > initialize the MIPI DSI HW IP. > > This probe will also parse the DT file for MIPI DSI based panel, add > the panel device (device_add() ) to kernel and register the display > entity with its control and video ops with CDF. > > I can give this a try. I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I have most of the work done, I have just to solve several remaining problems. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-21 10:00 ` Tomasz Figa 0 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2012-12-21 10:00 UTC (permalink / raw) To: dri-devel Cc: Vikas Sajjan, Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Vikas, On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > Hi Laurent, > > Thanks for the reply. > > On 17 December 2012 20:55, Laurent Pinchart < > > laurent.pinchart@ideasonboard.com> wrote: > > Hi Vikas, > > > > Sorry for the late reply. I now have more time to work on CDF, so > > delays should be much shorter. > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > Hi Laurent, > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what > > > I > > > > found > > > > > is that, the exynos display controller is MIPI DSI based controller. > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > > Display > > > > > controller. > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > based > > > display controller? basically I wanted to know, how to go about > > > porting > > > > CDF > > > > > for such kind of display controller. > > > > MIPI DSI support is not available yet. The only reason for that is > > that I don't have any MIPI DSI hardware to write and test the code > > with :-) > > > > The common display framework should definitely support MIPI DSI. I > > think the > > existing MIPI DBI code could be used as a base, so the implementation > > shouldn't be too high. > > > > Yeah, i was also thinking in similar lines, below is my though for > > MIPI > > DSI support in CDF. > > o MIPI DSI support as part of CDF framework will expose > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > file ) > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > platform specific init driver call ) > > · bus ops will be > > o read data > > o write data > > o write command > > § MIPI DSI will be registered as bus_register() > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > initialize the MIPI DSI HW IP. > > This probe will also parse the DT file for MIPI DSI based panel, add > the panel device (device_add() ) to kernel and register the display > entity with its control and video ops with CDF. > > I can give this a try. I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I have most of the work done, I have just to solve several remaining problems. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-21 10:00 ` Tomasz Figa @ 2012-12-24 14:12 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 14:12 UTC (permalink / raw) To: Tomasz Figa Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Tomasz, On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > Hi Vikas, > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > delays should be much shorter. > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > Hi Laurent, > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what > > > > I found is that, the exynos display controller is MIPI DSI based > > > > controller. > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > > Display controller. > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > based display controller? basically I wanted to know, how to go about > > > > porting CDF for such kind of display controller. > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > that I don't have any MIPI DSI hardware to write and test the code > > > with :-) > > > > > > The common display framework should definitely support MIPI DSI. I > > > think the existing MIPI DBI code could be used as a base, so the > > > implementation shouldn't be too high. > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > MIPI DSI support in CDF. > > > > o MIPI DSI support as part of CDF framework will expose > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > > file ) > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > > platform specific init driver call ) > > · bus ops will be > > o read data > > o write data > > o write command > > § MIPI DSI will be registered as bus_register() > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > > initialize the MIPI DSI HW IP. > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > the panel device (device_add() ) to kernel and register the display > > entity with its control and video ops with CDF. > > > > I can give this a try. > > I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 > LCD driver to use the v2 RFC of Common Display Framework. I have most of > the work done, I have just to solve several remaining problems. Do you already have code that you can publish ? I'm particularly interested (and I think Tomi Valkeinen would be as well) in looking at the DSI operations you expose to DSI sinks (panels, transceivers, ...). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 14:12 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 14:12 UTC (permalink / raw) To: Tomasz Figa Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Tomasz, On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > Hi Vikas, > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > delays should be much shorter. > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > Hi Laurent, > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what > > > > I found is that, the exynos display controller is MIPI DSI based > > > > controller. > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > > Display controller. > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > based display controller? basically I wanted to know, how to go about > > > > porting CDF for such kind of display controller. > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > that I don't have any MIPI DSI hardware to write and test the code > > > with :-) > > > > > > The common display framework should definitely support MIPI DSI. I > > > think the existing MIPI DBI code could be used as a base, so the > > > implementation shouldn't be too high. > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > MIPI DSI support in CDF. > > > > o MIPI DSI support as part of CDF framework will expose > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > > file ) > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > > platform specific init driver call ) > > · bus ops will be > > o read data > > o write data > > o write command > > § MIPI DSI will be registered as bus_register() > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > > initialize the MIPI DSI HW IP. > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > the panel device (device_add() ) to kernel and register the display > > entity with its control and video ops with CDF. > > > > I can give this a try. > > I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 > LCD driver to use the v2 RFC of Common Display Framework. I have most of > the work done, I have just to solve several remaining problems. Do you already have code that you can publish ? I'm particularly interested (and I think Tomi Valkeinen would be as well) in looking at the DSI operations you expose to DSI sinks (panels, transceivers, ...). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-24 14:12 ` Laurent Pinchart (?) @ 2012-12-27 14:43 ` Tomasz Figa -1 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2012-12-27 14:43 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > Hi Tomasz, > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > Hi Vikas, > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > delays should be much shorter. > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > Hi Laurent, > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > what > > > > > I found is that, the exynos display controller is MIPI DSI based > > > > > controller. > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > based > > > > > Display controller. > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > based display controller? basically I wanted to know, how to go > > > > > about > > > > > porting CDF for such kind of display controller. > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > with :-) > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > think the existing MIPI DBI code could be used as a base, so the > > > > implementation shouldn't be too high. > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > MIPI DSI support in CDF. > > > > > > o MIPI DSI support as part of CDF framework will expose > > > § mipi_dsi_register_device(mpi_device) (will be called > > > mach-xxx-dt.c > > > file ) > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > from > > > platform specific init driver call ) > > > · bus ops will be > > > o read data > > > o write data > > > o write command > > > § MIPI DSI will be registered as bus_register() > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > will > > > initialize the MIPI DSI HW IP. > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > the panel device (device_add() ) to kernel and register the display > > > entity with its control and video ops with CDF. > > > > > > I can give this a try. > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > have most of the work done, I have just to solve several remaining > > problems. > Do you already have code that you can publish ? I'm particularly > interested (and I think Tomi Valkeinen would be as well) in looking at > the DSI operations you expose to DSI sinks (panels, transceivers, ...). Well, I'm afraid this might be little below your expectations, but here's an initial RFC of the part defining just the DSI bus. I need a bit more time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. The implementation is very simple and heavily based on your MIPI DBI support and existing Exynos MIPI DSIM framework. Provided operation set is based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately this is my only source of information about MIPI DSI. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform >From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 From: Tomasz Figa <t.figa@samsung.com> Date: Thu, 27 Dec 2012 12:36:15 +0100 Subject: [RFC] video: display: Add generic MIPI DSI bus Signed-off-by: Tomasz Figa <t.figa@samsung.com> --- drivers/video/display/Kconfig | 4 + drivers/video/display/Makefile | 1 + drivers/video/display/mipi-dsi-bus.c | 214 +++++++++++++++++++++++++++++++++++ include/video/display.h | 1 + include/video/mipi-dsi-bus.h | 98 ++++++++++++++++ 5 files changed, 318 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-bus.c create mode 100644 include/video/mipi-dsi-bus.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 13b6aaf..dbaff9d 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI tristate default n +config DISPLAY_MIPI_DSI + tristate + default n + config DISPLAY_PANEL_DPI tristate "DPI (Parallel) Display Panels" ---help--- diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 482bec7..429b3ac8 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o diff --git a/drivers/video/display/mipi-dsi-bus.c b/drivers/video/display/mipi-dsi-bus.c new file mode 100644 index 0000000..2998522 --- /dev/null +++ b/drivers/video/display/mipi-dsi-bus.c @@ -0,0 +1,214 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.c. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/device.h> +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/list.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/pm.h> +#include <linux/pm_runtime.h> + +#include <video/mipi-dsi-bus.h> + +/* ----------------------------------------------------------------------------- + * Bus operations + */ + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_write_command); + +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_read_command); + +/* ----------------------------------------------------------------------------- + * Bus type + */ + +static const struct mipi_dsi_device_id * +mipi_dsi_match_id(const struct mipi_dsi_device_id *id, + struct mipi_dsi_device *dev) +{ + while (id->name[0]) { + if (strcmp(dev->name, id->name) == 0) { + dev->id_entry = id; + return id; + } + id++; + } + return NULL; +} + +static int mipi_dsi_match(struct device *_dev, struct device_driver *_drv) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv); + + if (drv->id_table) + return mipi_dsi_match_id(drv->id_table, dev) != NULL; + + return (strcmp(dev->name, _drv->name) == 0); +} + +static ssize_t modalias_show(struct device *_dev, struct device_attribute *a, + char *buf) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n", + dev->name); + + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; +} + +static struct device_attribute mipi_dsi_dev_attrs[] = { + __ATTR_RO(modalias), + __ATTR_NULL, +}; + +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env *env) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX, + dev->name); + return 0; +} + +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { + .runtime_suspend = pm_generic_runtime_suspend, + .runtime_resume = pm_generic_runtime_resume, + .runtime_idle = pm_generic_runtime_idle, + .suspend = pm_generic_suspend, + .resume = pm_generic_resume, + .freeze = pm_generic_freeze, + .thaw = pm_generic_thaw, + .poweroff = pm_generic_poweroff, + .restore = pm_generic_restore, +}; + +static struct bus_type mipi_dsi_bus_type = { + .name = "mipi-dsi", + .dev_attrs = mipi_dsi_dev_attrs, + .match = mipi_dsi_match, + .uevent = mipi_dsi_uevent, + .pm = &mipi_dsi_dev_pm_ops, +}; + +/* ----------------------------------------------------------------------------- + * Device and driver (un)registration + */ + +/** + * mipi_dsi_device_register - register a DSI device + * @dev: DSI device we're registering + */ +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus) +{ + device_initialize(&dev->dev); + + dev->bus = bus; + dev->dev.bus = &mipi_dsi_bus_type; + dev->dev.parent = bus->dev; + + if (dev->id != -1) + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id); + else + dev_set_name(&dev->dev, "%s", dev->name); + + return device_add(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_register); + +/** + * mipi_dsi_device_unregister - unregister a DSI device + * @dev: DSI device we're unregistering + */ +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev) +{ + device_del(&dev->dev); + put_device(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister); + +static int mipi_dsi_drv_probe(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->probe(dev); +} + +static int mipi_dsi_drv_remove(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->remove(dev); +} + +/** + * mipi_dsi_driver_register - register a driver for DSI devices + * @drv: DSI driver structure + */ +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv) +{ + drv->driver.bus = &mipi_dsi_bus_type; + if (drv->probe) + drv->driver.probe = mipi_dsi_drv_probe; + if (drv->remove) + drv->driver.remove = mipi_dsi_drv_remove; + + return driver_register(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register); + +/** + * mipi_dsi_driver_unregister - unregister a driver for DSI devices + * @drv: DSI driver structure + */ +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv) +{ + driver_unregister(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister); + +/* ----------------------------------------------------------------------------- + * Init/exit + */ + +static int __init mipi_dsi_init(void) +{ + return bus_register(&mipi_dsi_bus_type); +} + +static void __exit mipi_dsi_exit(void) +{ + bus_unregister(&mipi_dsi_bus_type); +} + +module_init(mipi_dsi_init); +module_exit(mipi_dsi_exit) + +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>"); +MODULE_DESCRIPTION("MIPI DSI Bus"); +MODULE_LICENSE("GPL"); diff --git a/include/video/display.h b/include/video/display.h index 75ba270..f86ea6e 100644 --- a/include/video/display.h +++ b/include/video/display.h @@ -70,6 +70,7 @@ enum display_entity_stream_state { enum display_entity_interface_type { DISPLAY_ENTITY_INTERFACE_DPI, DISPLAY_ENTITY_INTERFACE_DBI, + DISPLAY_ENTITY_INTERFACE_DSI, }; struct display_entity_interface_params { diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h new file mode 100644 index 0000000..3efcb39 --- /dev/null +++ b/include/video/mipi-dsi-bus.h @@ -0,0 +1,98 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.h. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __MIPI_DSI_BUS_H__ +#define __MIPI_DSI_BUS_H__ + +#include <linux/device.h> + +struct mipi_dsi_bus; +struct mipi_dsi_device; + +struct mipi_dsi_bus_ops { + int (*write_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); + int (*read_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, + unsigned int len); +}; + +struct mipi_dsi_bus { + struct device *dev; + const struct mipi_dsi_bus_ops *ops; +}; + +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:" +#define MIPI_DSI_NAME_SIZE 32 + +struct mipi_dsi_device_id { + char name[MIPI_DSI_NAME_SIZE]; + __kernel_ulong_t driver_data /* Data private to the driver */ + __aligned(sizeof(__kernel_ulong_t)); +}; + +struct mipi_dsi_device { + const char *name; + int id; + struct device dev; + + const struct mipi_dsi_device_id *id_entry; + struct mipi_dsi_bus *bus; +}; + +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device, dev) + +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus); +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev); + +struct mipi_dsi_driver { + int(*probe)(struct mipi_dsi_device *); + int(*remove)(struct mipi_dsi_device *); + struct device_driver driver; + const struct mipi_dsi_device_id *id_table; +}; + +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, driver) + +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv); +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv); + +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device *dev) +{ + return dev_get_drvdata(&dev->dev); +} + +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev, + void *data) +{ + dev_set_drvdata(&dev->dev, data); +} + +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do + * anything special in module init/exit. This eliminates a lot of + * boilerplate. Each module may only use this macro once, and + * calling it replaces module_init() and module_exit() + */ +#define module_mipi_dsi_driver(__mipi_dsi_driver) \ + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \ + mipi_dsi_driver_unregister) + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len); + +#endif /* __MIPI_DSI_BUS__ */ -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 14:43 ` Tomasz Figa 0 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2012-12-27 14:43 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > Hi Tomasz, > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > Hi Vikas, > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > delays should be much shorter. > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > Hi Laurent, > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > what > > > > > I found is that, the exynos display controller is MIPI DSI based > > > > > controller. > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > based > > > > > Display controller. > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > based display controller? basically I wanted to know, how to go > > > > > about > > > > > porting CDF for such kind of display controller. > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > with :-) > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > think the existing MIPI DBI code could be used as a base, so the > > > > implementation shouldn't be too high. > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > MIPI DSI support in CDF. > > > > > > o MIPI DSI support as part of CDF framework will expose > > > § mipi_dsi_register_device(mpi_device) (will be called > > > mach-xxx-dt.c > > > file ) > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > from > > > platform specific init driver call ) > > > · bus ops will be > > > o read data > > > o write data > > > o write command > > > § MIPI DSI will be registered as bus_register() > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > will > > > initialize the MIPI DSI HW IP. > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > the panel device (device_add() ) to kernel and register the display > > > entity with its control and video ops with CDF. > > > > > > I can give this a try. > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > have most of the work done, I have just to solve several remaining > > problems. > Do you already have code that you can publish ? I'm particularly > interested (and I think Tomi Valkeinen would be as well) in looking at > the DSI operations you expose to DSI sinks (panels, transceivers, ...). Well, I'm afraid this might be little below your expectations, but here's an initial RFC of the part defining just the DSI bus. I need a bit more time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. The implementation is very simple and heavily based on your MIPI DBI support and existing Exynos MIPI DSIM framework. Provided operation set is based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately this is my only source of information about MIPI DSI. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 From: Tomasz Figa <t.figa@samsung.com> Date: Thu, 27 Dec 2012 12:36:15 +0100 Subject: [RFC] video: display: Add generic MIPI DSI bus Signed-off-by: Tomasz Figa <t.figa@samsung.com> --- drivers/video/display/Kconfig | 4 + drivers/video/display/Makefile | 1 + drivers/video/display/mipi-dsi-bus.c | 214 +++++++++++++++++++++++++++++++++++ include/video/display.h | 1 + include/video/mipi-dsi-bus.h | 98 ++++++++++++++++ 5 files changed, 318 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-bus.c create mode 100644 include/video/mipi-dsi-bus.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 13b6aaf..dbaff9d 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI tristate default n +config DISPLAY_MIPI_DSI + tristate + default n + config DISPLAY_PANEL_DPI tristate "DPI (Parallel) Display Panels" ---help--- diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 482bec7..429b3ac8 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o diff --git a/drivers/video/display/mipi-dsi-bus.c b/drivers/video/display/mipi-dsi-bus.c new file mode 100644 index 0000000..2998522 --- /dev/null +++ b/drivers/video/display/mipi-dsi-bus.c @@ -0,0 +1,214 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.c. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/device.h> +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/list.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/pm.h> +#include <linux/pm_runtime.h> + +#include <video/mipi-dsi-bus.h> + +/* ----------------------------------------------------------------------------- + * Bus operations + */ + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_write_command); + +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_read_command); + +/* ----------------------------------------------------------------------------- + * Bus type + */ + +static const struct mipi_dsi_device_id * +mipi_dsi_match_id(const struct mipi_dsi_device_id *id, + struct mipi_dsi_device *dev) +{ + while (id->name[0]) { + if (strcmp(dev->name, id->name) == 0) { + dev->id_entry = id; + return id; + } + id++; + } + return NULL; +} + +static int mipi_dsi_match(struct device *_dev, struct device_driver *_drv) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv); + + if (drv->id_table) + return mipi_dsi_match_id(drv->id_table, dev) != NULL; + + return (strcmp(dev->name, _drv->name) == 0); +} + +static ssize_t modalias_show(struct device *_dev, struct device_attribute *a, + char *buf) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n", + dev->name); + + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; +} + +static struct device_attribute mipi_dsi_dev_attrs[] = { + __ATTR_RO(modalias), + __ATTR_NULL, +}; + +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env *env) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX, + dev->name); + return 0; +} + +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { + .runtime_suspend = pm_generic_runtime_suspend, + .runtime_resume = pm_generic_runtime_resume, + .runtime_idle = pm_generic_runtime_idle, + .suspend = pm_generic_suspend, + .resume = pm_generic_resume, + .freeze = pm_generic_freeze, + .thaw = pm_generic_thaw, + .poweroff = pm_generic_poweroff, + .restore = pm_generic_restore, +}; + +static struct bus_type mipi_dsi_bus_type = { + .name = "mipi-dsi", + .dev_attrs = mipi_dsi_dev_attrs, + .match = mipi_dsi_match, + .uevent = mipi_dsi_uevent, + .pm = &mipi_dsi_dev_pm_ops, +}; + +/* ----------------------------------------------------------------------------- + * Device and driver (un)registration + */ + +/** + * mipi_dsi_device_register - register a DSI device + * @dev: DSI device we're registering + */ +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus) +{ + device_initialize(&dev->dev); + + dev->bus = bus; + dev->dev.bus = &mipi_dsi_bus_type; + dev->dev.parent = bus->dev; + + if (dev->id != -1) + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id); + else + dev_set_name(&dev->dev, "%s", dev->name); + + return device_add(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_register); + +/** + * mipi_dsi_device_unregister - unregister a DSI device + * @dev: DSI device we're unregistering + */ +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev) +{ + device_del(&dev->dev); + put_device(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister); + +static int mipi_dsi_drv_probe(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->probe(dev); +} + +static int mipi_dsi_drv_remove(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->remove(dev); +} + +/** + * mipi_dsi_driver_register - register a driver for DSI devices + * @drv: DSI driver structure + */ +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv) +{ + drv->driver.bus = &mipi_dsi_bus_type; + if (drv->probe) + drv->driver.probe = mipi_dsi_drv_probe; + if (drv->remove) + drv->driver.remove = mipi_dsi_drv_remove; + + return driver_register(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register); + +/** + * mipi_dsi_driver_unregister - unregister a driver for DSI devices + * @drv: DSI driver structure + */ +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv) +{ + driver_unregister(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister); + +/* ----------------------------------------------------------------------------- + * Init/exit + */ + +static int __init mipi_dsi_init(void) +{ + return bus_register(&mipi_dsi_bus_type); +} + +static void __exit mipi_dsi_exit(void) +{ + bus_unregister(&mipi_dsi_bus_type); +} + +module_init(mipi_dsi_init); +module_exit(mipi_dsi_exit) + +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>"); +MODULE_DESCRIPTION("MIPI DSI Bus"); +MODULE_LICENSE("GPL"); diff --git a/include/video/display.h b/include/video/display.h index 75ba270..f86ea6e 100644 --- a/include/video/display.h +++ b/include/video/display.h @@ -70,6 +70,7 @@ enum display_entity_stream_state { enum display_entity_interface_type { DISPLAY_ENTITY_INTERFACE_DPI, DISPLAY_ENTITY_INTERFACE_DBI, + DISPLAY_ENTITY_INTERFACE_DSI, }; struct display_entity_interface_params { diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h new file mode 100644 index 0000000..3efcb39 --- /dev/null +++ b/include/video/mipi-dsi-bus.h @@ -0,0 +1,98 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.h. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __MIPI_DSI_BUS_H__ +#define __MIPI_DSI_BUS_H__ + +#include <linux/device.h> + +struct mipi_dsi_bus; +struct mipi_dsi_device; + +struct mipi_dsi_bus_ops { + int (*write_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); + int (*read_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, + unsigned int len); +}; + +struct mipi_dsi_bus { + struct device *dev; + const struct mipi_dsi_bus_ops *ops; +}; + +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:" +#define MIPI_DSI_NAME_SIZE 32 + +struct mipi_dsi_device_id { + char name[MIPI_DSI_NAME_SIZE]; + __kernel_ulong_t driver_data /* Data private to the driver */ + __aligned(sizeof(__kernel_ulong_t)); +}; + +struct mipi_dsi_device { + const char *name; + int id; + struct device dev; + + const struct mipi_dsi_device_id *id_entry; + struct mipi_dsi_bus *bus; +}; + +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device, dev) + +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus); +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev); + +struct mipi_dsi_driver { + int(*probe)(struct mipi_dsi_device *); + int(*remove)(struct mipi_dsi_device *); + struct device_driver driver; + const struct mipi_dsi_device_id *id_table; +}; + +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, driver) + +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv); +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv); + +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device *dev) +{ + return dev_get_drvdata(&dev->dev); +} + +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev, + void *data) +{ + dev_set_drvdata(&dev->dev, data); +} + +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do + * anything special in module init/exit. This eliminates a lot of + * boilerplate. Each module may only use this macro once, and + * calling it replaces module_init() and module_exit() + */ +#define module_mipi_dsi_driver(__mipi_dsi_driver) \ + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \ + mipi_dsi_driver_unregister) + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len); + +#endif /* __MIPI_DSI_BUS__ */ -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 14:43 ` Tomasz Figa 0 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2012-12-27 14:43 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > Hi Tomasz, > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > Hi Vikas, > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > delays should be much shorter. > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > Hi Laurent, > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > what > > > > > I found is that, the exynos display controller is MIPI DSI based > > > > > controller. > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > based > > > > > Display controller. > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > based display controller? basically I wanted to know, how to go > > > > > about > > > > > porting CDF for such kind of display controller. > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > with :-) > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > think the existing MIPI DBI code could be used as a base, so the > > > > implementation shouldn't be too high. > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > MIPI DSI support in CDF. > > > > > > o MIPI DSI support as part of CDF framework will expose > > > § mipi_dsi_register_device(mpi_device) (will be called > > > mach-xxx-dt.c > > > file ) > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > from > > > platform specific init driver call ) > > > · bus ops will be > > > o read data > > > o write data > > > o write command > > > § MIPI DSI will be registered as bus_register() > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > will > > > initialize the MIPI DSI HW IP. > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > the panel device (device_add() ) to kernel and register the display > > > entity with its control and video ops with CDF. > > > > > > I can give this a try. > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > have most of the work done, I have just to solve several remaining > > problems. > Do you already have code that you can publish ? I'm particularly > interested (and I think Tomi Valkeinen would be as well) in looking at > the DSI operations you expose to DSI sinks (panels, transceivers, ...). Well, I'm afraid this might be little below your expectations, but here's an initial RFC of the part defining just the DSI bus. I need a bit more time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. The implementation is very simple and heavily based on your MIPI DBI support and existing Exynos MIPI DSIM framework. Provided operation set is based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately this is my only source of information about MIPI DSI. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 From: Tomasz Figa <t.figa@samsung.com> Date: Thu, 27 Dec 2012 12:36:15 +0100 Subject: [RFC] video: display: Add generic MIPI DSI bus Signed-off-by: Tomasz Figa <t.figa@samsung.com> --- drivers/video/display/Kconfig | 4 + drivers/video/display/Makefile | 1 + drivers/video/display/mipi-dsi-bus.c | 214 +++++++++++++++++++++++++++++++++++ include/video/display.h | 1 + include/video/mipi-dsi-bus.h | 98 ++++++++++++++++ 5 files changed, 318 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-bus.c create mode 100644 include/video/mipi-dsi-bus.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 13b6aaf..dbaff9d 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI tristate default n +config DISPLAY_MIPI_DSI + tristate + default n + config DISPLAY_PANEL_DPI tristate "DPI (Parallel) Display Panels" ---help--- diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 482bec7..429b3ac8 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o diff --git a/drivers/video/display/mipi-dsi-bus.c b/drivers/video/display/mipi-dsi-bus.c new file mode 100644 index 0000000..2998522 --- /dev/null +++ b/drivers/video/display/mipi-dsi-bus.c @@ -0,0 +1,214 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.c. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/device.h> +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/list.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/pm.h> +#include <linux/pm_runtime.h> + +#include <video/mipi-dsi-bus.h> + +/* ----------------------------------------------------------------------------- + * Bus operations + */ + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_write_command); + +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len) +{ + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf, len); +} +EXPORT_SYMBOL_GPL(mipi_dsi_read_command); + +/* ----------------------------------------------------------------------------- + * Bus type + */ + +static const struct mipi_dsi_device_id * +mipi_dsi_match_id(const struct mipi_dsi_device_id *id, + struct mipi_dsi_device *dev) +{ + while (id->name[0]) { + if (strcmp(dev->name, id->name) = 0) { + dev->id_entry = id; + return id; + } + id++; + } + return NULL; +} + +static int mipi_dsi_match(struct device *_dev, struct device_driver *_drv) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv); + + if (drv->id_table) + return mipi_dsi_match_id(drv->id_table, dev) != NULL; + + return (strcmp(dev->name, _drv->name) = 0); +} + +static ssize_t modalias_show(struct device *_dev, struct device_attribute *a, + char *buf) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n", + dev->name); + + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; +} + +static struct device_attribute mipi_dsi_dev_attrs[] = { + __ATTR_RO(modalias), + __ATTR_NULL, +}; + +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env *env) +{ + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX, + dev->name); + return 0; +} + +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { + .runtime_suspend = pm_generic_runtime_suspend, + .runtime_resume = pm_generic_runtime_resume, + .runtime_idle = pm_generic_runtime_idle, + .suspend = pm_generic_suspend, + .resume = pm_generic_resume, + .freeze = pm_generic_freeze, + .thaw = pm_generic_thaw, + .poweroff = pm_generic_poweroff, + .restore = pm_generic_restore, +}; + +static struct bus_type mipi_dsi_bus_type = { + .name = "mipi-dsi", + .dev_attrs = mipi_dsi_dev_attrs, + .match = mipi_dsi_match, + .uevent = mipi_dsi_uevent, + .pm = &mipi_dsi_dev_pm_ops, +}; + +/* ----------------------------------------------------------------------------- + * Device and driver (un)registration + */ + +/** + * mipi_dsi_device_register - register a DSI device + * @dev: DSI device we're registering + */ +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus) +{ + device_initialize(&dev->dev); + + dev->bus = bus; + dev->dev.bus = &mipi_dsi_bus_type; + dev->dev.parent = bus->dev; + + if (dev->id != -1) + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id); + else + dev_set_name(&dev->dev, "%s", dev->name); + + return device_add(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_register); + +/** + * mipi_dsi_device_unregister - unregister a DSI device + * @dev: DSI device we're unregistering + */ +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev) +{ + device_del(&dev->dev); + put_device(&dev->dev); +} +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister); + +static int mipi_dsi_drv_probe(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->probe(dev); +} + +static int mipi_dsi_drv_remove(struct device *_dev) +{ + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); + + return drv->remove(dev); +} + +/** + * mipi_dsi_driver_register - register a driver for DSI devices + * @drv: DSI driver structure + */ +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv) +{ + drv->driver.bus = &mipi_dsi_bus_type; + if (drv->probe) + drv->driver.probe = mipi_dsi_drv_probe; + if (drv->remove) + drv->driver.remove = mipi_dsi_drv_remove; + + return driver_register(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register); + +/** + * mipi_dsi_driver_unregister - unregister a driver for DSI devices + * @drv: DSI driver structure + */ +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv) +{ + driver_unregister(&drv->driver); +} +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister); + +/* ----------------------------------------------------------------------------- + * Init/exit + */ + +static int __init mipi_dsi_init(void) +{ + return bus_register(&mipi_dsi_bus_type); +} + +static void __exit mipi_dsi_exit(void) +{ + bus_unregister(&mipi_dsi_bus_type); +} + +module_init(mipi_dsi_init); +module_exit(mipi_dsi_exit) + +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>"); +MODULE_DESCRIPTION("MIPI DSI Bus"); +MODULE_LICENSE("GPL"); diff --git a/include/video/display.h b/include/video/display.h index 75ba270..f86ea6e 100644 --- a/include/video/display.h +++ b/include/video/display.h @@ -70,6 +70,7 @@ enum display_entity_stream_state { enum display_entity_interface_type { DISPLAY_ENTITY_INTERFACE_DPI, DISPLAY_ENTITY_INTERFACE_DBI, + DISPLAY_ENTITY_INTERFACE_DSI, }; struct display_entity_interface_params { diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h new file mode 100644 index 0000000..3efcb39 --- /dev/null +++ b/include/video/mipi-dsi-bus.h @@ -0,0 +1,98 @@ +/* + * MIPI DSI Bus + * + * Copyright (C) 2012 Samsung Electronics Co., Ltd. + * Contacts: Tomasz Figa <t.figa@samsung.com> + * + * Heavily based ond mipi-dbi-bus.h. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __MIPI_DSI_BUS_H__ +#define __MIPI_DSI_BUS_H__ + +#include <linux/device.h> + +struct mipi_dsi_bus; +struct mipi_dsi_device; + +struct mipi_dsi_bus_ops { + int (*write_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); + int (*read_command)(struct mipi_dsi_bus *bus, + struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, + unsigned int len); +}; + +struct mipi_dsi_bus { + struct device *dev; + const struct mipi_dsi_bus_ops *ops; +}; + +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:" +#define MIPI_DSI_NAME_SIZE 32 + +struct mipi_dsi_device_id { + char name[MIPI_DSI_NAME_SIZE]; + __kernel_ulong_t driver_data /* Data private to the driver */ + __aligned(sizeof(__kernel_ulong_t)); +}; + +struct mipi_dsi_device { + const char *name; + int id; + struct device dev; + + const struct mipi_dsi_device_id *id_entry; + struct mipi_dsi_bus *bus; +}; + +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device, dev) + +int mipi_dsi_device_register(struct mipi_dsi_device *dev, + struct mipi_dsi_bus *bus); +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev); + +struct mipi_dsi_driver { + int(*probe)(struct mipi_dsi_device *); + int(*remove)(struct mipi_dsi_device *); + struct device_driver driver; + const struct mipi_dsi_device_id *id_table; +}; + +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, driver) + +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv); +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv); + +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device *dev) +{ + return dev_get_drvdata(&dev->dev); +} + +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev, + void *data) +{ + dev_set_drvdata(&dev->dev, data); +} + +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do + * anything special in module init/exit. This eliminates a lot of + * boilerplate. Each module may only use this macro once, and + * calling it replaces module_init() and module_exit() + */ +#define module_mipi_dsi_driver(__mipi_dsi_driver) \ + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \ + mipi_dsi_driver_unregister) + +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, + const unsigned char *buf, unsigned int len); +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, + unsigned int addr, unsigned char *buf, unsigned int len); + +#endif /* __MIPI_DSI_BUS__ */ -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 14:43 ` Tomasz Figa @ 2012-12-28 3:26 ` Vikas Sajjan -1 siblings, 0 replies; 153+ messages in thread From: Vikas Sajjan @ 2012-12-28 3:38 UTC (permalink / raw) To: Tomasz Figa Cc: Laurent Pinchart, dri-devel, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media On 27 December 2012 20:13, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Laurent, > > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: >> > > On 17 December 2012 20:55, Laurent Pinchart wrote: >> > > > Hi Vikas, >> > > > >> > > > Sorry for the late reply. I now have more time to work on CDF, so >> > > > delays should be much shorter. >> > > > >> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: >> > > > > Hi Laurent, >> > > > > >> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, >> > > > > what >> > > > > I found is that, the exynos display controller is MIPI DSI based >> > > > > controller. >> > > > > >> > > > > But if I look at CDF patches, it has only support for MIPI DBI >> > > > > based >> > > > > Display controller. >> > > > > >> > > > > So my question is, do we have any generic framework for MIPI DSI >> > > > > based display controller? basically I wanted to know, how to go >> > > > > about >> > > > > porting CDF for such kind of display controller. >> > > > >> > > > MIPI DSI support is not available yet. The only reason for that is >> > > > that I don't have any MIPI DSI hardware to write and test the code >> > > > with :-) >> > > > >> > > > The common display framework should definitely support MIPI DSI. I >> > > > think the existing MIPI DBI code could be used as a base, so the >> > > > implementation shouldn't be too high. >> > > > >> > > > Yeah, i was also thinking in similar lines, below is my though for >> > > > MIPI DSI support in CDF. >> > > >> > > o MIPI DSI support as part of CDF framework will expose >> > > § mipi_dsi_register_device(mpi_device) (will be called >> > > mach-xxx-dt.c >> > > file ) >> > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called >> > > from >> > > platform specific init driver call ) >> > > · bus ops will be >> > > o read data >> > > o write data >> > > o write command >> > > § MIPI DSI will be registered as bus_register() >> > > >> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) >> > > will >> > > initialize the MIPI DSI HW IP. >> > > >> > > This probe will also parse the DT file for MIPI DSI based panel, add >> > > the panel device (device_add() ) to kernel and register the display >> > > entity with its control and video ops with CDF. >> > > >> > > I can give this a try. >> > >> > I am currently in progress of reworking Exynos MIPI DSIM code and >> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I >> > have most of the work done, I have just to solve several remaining >> > problems. >> Do you already have code that you can publish ? I'm particularly >> interested (and I think Tomi Valkeinen would be as well) in looking at >> the DSI operations you expose to DSI sinks (panels, transceivers, ...). > > Well, I'm afraid this might be little below your expectations, but here's > an initial RFC of the part defining just the DSI bus. I need a bit more > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. > > The implementation is very simple and heavily based on your MIPI DBI > support and existing Exynos MIPI DSIM framework. Provided operation set is > based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately > this is my only source of information about MIPI DSI. > > Best regards, > -- > Tomasz Figa > Samsung Poland R&D Center > SW Solution Development, Linux Platform > > From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 > From: Tomasz Figa <t.figa@samsung.com> > Date: Thu, 27 Dec 2012 12:36:15 +0100 > Subject: [RFC] video: display: Add generic MIPI DSI bus > > Signed-off-by: Tomasz Figa <t.figa@samsung.com> > --- > drivers/video/display/Kconfig | 4 + > drivers/video/display/Makefile | 1 + > drivers/video/display/mipi-dsi-bus.c | 214 > +++++++++++++++++++++++++++++++++++ > include/video/display.h | 1 + > include/video/mipi-dsi-bus.h | 98 ++++++++++++++++ > 5 files changed, 318 insertions(+) > create mode 100644 drivers/video/display/mipi-dsi-bus.c > create mode 100644 include/video/mipi-dsi-bus.h > > diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig > index 13b6aaf..dbaff9d 100644 > --- a/drivers/video/display/Kconfig > +++ b/drivers/video/display/Kconfig > @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI > tristate > default n > > +config DISPLAY_MIPI_DSI > + tristate > + default n > + > config DISPLAY_PANEL_DPI > tristate "DPI (Parallel) Display Panels" > ---help--- > diff --git a/drivers/video/display/Makefile > b/drivers/video/display/Makefile > index 482bec7..429b3ac8 100644 > --- a/drivers/video/display/Makefile > +++ b/drivers/video/display/Makefile > @@ -1,5 +1,6 @@ > obj-$(CONFIG_DISPLAY_CORE) += display-core.o > obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o > +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o > obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o > obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o > obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o > diff --git a/drivers/video/display/mipi-dsi-bus.c > b/drivers/video/display/mipi-dsi-bus.c > new file mode 100644 > index 0000000..2998522 > --- /dev/null > +++ b/drivers/video/display/mipi-dsi-bus.c > @@ -0,0 +1,214 @@ > +/* > + * MIPI DSI Bus > + * > + * Copyright (C) 2012 Samsung Electronics Co., Ltd. > + * Contacts: Tomasz Figa <t.figa@samsung.com> > + * > + * Heavily based ond mipi-dbi-bus.c. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include <linux/device.h> > +#include <linux/export.h> > +#include <linux/kernel.h> > +#include <linux/list.h> > +#include <linux/module.h> > +#include <linux/mutex.h> > +#include <linux/pm.h> > +#include <linux/pm_runtime.h> > + > +#include <video/mipi-dsi-bus.h> > + > +/* > ----------------------------------------------------------------------------- > + * Bus operations > + */ > + > +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len) > +{ > + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_write_command); > + > +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, unsigned int len) > +{ > + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf, > len); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_read_command); > + > +/* > ----------------------------------------------------------------------------- > + * Bus type > + */ > + > +static const struct mipi_dsi_device_id * > +mipi_dsi_match_id(const struct mipi_dsi_device_id *id, > + struct mipi_dsi_device *dev) > +{ > + while (id->name[0]) { > + if (strcmp(dev->name, id->name) = 0) { > + dev->id_entry = id; > + return id; > + } > + id++; > + } > + return NULL; > +} > + > +static int mipi_dsi_match(struct device *_dev, struct device_driver > *_drv) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv); > + > + if (drv->id_table) > + return mipi_dsi_match_id(drv->id_table, dev) != NULL; > + > + return (strcmp(dev->name, _drv->name) = 0); > +} > + > +static ssize_t modalias_show(struct device *_dev, struct device_attribute > *a, > + char *buf) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n", > + dev->name); > + > + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; > +} > + > +static struct device_attribute mipi_dsi_dev_attrs[] = { > + __ATTR_RO(modalias), > + __ATTR_NULL, > +}; > + > +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env > *env) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX, > + dev->name); > + return 0; > +} > + > +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { > + .runtime_suspend = pm_generic_runtime_suspend, > + .runtime_resume = pm_generic_runtime_resume, > + .runtime_idle = pm_generic_runtime_idle, > + .suspend = pm_generic_suspend, > + .resume = pm_generic_resume, > + .freeze = pm_generic_freeze, > + .thaw = pm_generic_thaw, > + .poweroff = pm_generic_poweroff, > + .restore = pm_generic_restore, > +}; > + > +static struct bus_type mipi_dsi_bus_type = { > + .name = "mipi-dsi", > + .dev_attrs = mipi_dsi_dev_attrs, > + .match = mipi_dsi_match, > + .uevent = mipi_dsi_uevent, > + .pm = &mipi_dsi_dev_pm_ops, > +}; > + > +/* > ----------------------------------------------------------------------------- > + * Device and driver (un)registration > + */ > + > +/** > + * mipi_dsi_device_register - register a DSI device > + * @dev: DSI device we're registering > + */ > +int mipi_dsi_device_register(struct mipi_dsi_device *dev, > + struct mipi_dsi_bus *bus) > +{ > + device_initialize(&dev->dev); > + > + dev->bus = bus; > + dev->dev.bus = &mipi_dsi_bus_type; > + dev->dev.parent = bus->dev; > + > + if (dev->id != -1) > + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id); > + else > + dev_set_name(&dev->dev, "%s", dev->name); > + > + return device_add(&dev->dev); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_device_register); > + > +/** > + * mipi_dsi_device_unregister - unregister a DSI device > + * @dev: DSI device we're unregistering > + */ > +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev) > +{ > + device_del(&dev->dev); > + put_device(&dev->dev); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister); > + > +static int mipi_dsi_drv_probe(struct device *_dev) > +{ > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + return drv->probe(dev); > +} > + > +static int mipi_dsi_drv_remove(struct device *_dev) > +{ > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + return drv->remove(dev); > +} > + > +/** > + * mipi_dsi_driver_register - register a driver for DSI devices > + * @drv: DSI driver structure > + */ > +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv) > +{ > + drv->driver.bus = &mipi_dsi_bus_type; > + if (drv->probe) > + drv->driver.probe = mipi_dsi_drv_probe; > + if (drv->remove) > + drv->driver.remove = mipi_dsi_drv_remove; > + > + return driver_register(&drv->driver); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register); > + > +/** > + * mipi_dsi_driver_unregister - unregister a driver for DSI devices > + * @drv: DSI driver structure > + */ > +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv) > +{ > + driver_unregister(&drv->driver); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister); > + > +/* > ----------------------------------------------------------------------------- > + * Init/exit > + */ > + > +static int __init mipi_dsi_init(void) > +{ > + return bus_register(&mipi_dsi_bus_type); > +} > + As per the discussion what Laurent and Tomi had ( http://lists.freedesktop.org/archives/dri-devel/2012-December/032038.html), both DSI and DBI doesn't need to be registered as real bus. Please refer to Tomi's pacthset for DSI support. ( git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf ) anyways i am working on Exynos MIPI DSI as per the new CDF proposed by Tomi and Laurent. > +static void __exit mipi_dsi_exit(void) > +{ > + bus_unregister(&mipi_dsi_bus_type); > +} > + > +module_init(mipi_dsi_init); > +module_exit(mipi_dsi_exit) > + > +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>"); > +MODULE_DESCRIPTION("MIPI DSI Bus"); > +MODULE_LICENSE("GPL"); > diff --git a/include/video/display.h b/include/video/display.h > index 75ba270..f86ea6e 100644 > --- a/include/video/display.h > +++ b/include/video/display.h > @@ -70,6 +70,7 @@ enum display_entity_stream_state { > enum display_entity_interface_type { > DISPLAY_ENTITY_INTERFACE_DPI, > DISPLAY_ENTITY_INTERFACE_DBI, > + DISPLAY_ENTITY_INTERFACE_DSI, > }; > > struct display_entity_interface_params { > diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h > new file mode 100644 > index 0000000..3efcb39 > --- /dev/null > +++ b/include/video/mipi-dsi-bus.h > @@ -0,0 +1,98 @@ > +/* > + * MIPI DSI Bus > + * > + * Copyright (C) 2012 Samsung Electronics Co., Ltd. > + * Contacts: Tomasz Figa <t.figa@samsung.com> > + * > + * Heavily based ond mipi-dbi-bus.h. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#ifndef __MIPI_DSI_BUS_H__ > +#define __MIPI_DSI_BUS_H__ > + > +#include <linux/device.h> > + > +struct mipi_dsi_bus; > +struct mipi_dsi_device; > + > +struct mipi_dsi_bus_ops { > + int (*write_command)(struct mipi_dsi_bus *bus, > + struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len); > + int (*read_command)(struct mipi_dsi_bus *bus, > + struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, > + unsigned int len); > +}; > + > +struct mipi_dsi_bus { > + struct device *dev; > + const struct mipi_dsi_bus_ops *ops; > +}; > + > +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:" > +#define MIPI_DSI_NAME_SIZE 32 > + > +struct mipi_dsi_device_id { > + char name[MIPI_DSI_NAME_SIZE]; > + __kernel_ulong_t driver_data /* Data private to the driver */ > + __aligned(sizeof(__kernel_ulong_t)); > +}; > + > +struct mipi_dsi_device { > + const char *name; > + int id; > + struct device dev; > + > + const struct mipi_dsi_device_id *id_entry; > + struct mipi_dsi_bus *bus; > +}; > + > +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device, > dev) > + > +int mipi_dsi_device_register(struct mipi_dsi_device *dev, > + struct mipi_dsi_bus *bus); > +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev); > + > +struct mipi_dsi_driver { > + int(*probe)(struct mipi_dsi_device *); > + int(*remove)(struct mipi_dsi_device *); > + struct device_driver driver; > + const struct mipi_dsi_device_id *id_table; > +}; > + > +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, > driver) > + > +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv); > +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv); > + > +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device > *dev) > +{ > + return dev_get_drvdata(&dev->dev); > +} > + > +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev, > + void *data) > +{ > + dev_set_drvdata(&dev->dev, data); > +} > + > +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do > + * anything special in module init/exit. This eliminates a lot of > + * boilerplate. Each module may only use this macro once, and > + * calling it replaces module_init() and module_exit() > + */ > +#define module_mipi_dsi_driver(__mipi_dsi_driver) \ > + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \ > + mipi_dsi_driver_unregister) > + > +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len); > +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, unsigned int len); > + > +#endif /* __MIPI_DSI_BUS__ */ > -- > 1.8.0.2 > > -- Thanks and Regards Vikas Sajjan ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-28 3:26 ` Vikas Sajjan 0 siblings, 0 replies; 153+ messages in thread From: Vikas Sajjan @ 2012-12-28 3:26 UTC (permalink / raw) To: Tomasz Figa Cc: Laurent Pinchart, dri-devel, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media On 27 December 2012 20:13, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Laurent, > > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: >> > > On 17 December 2012 20:55, Laurent Pinchart wrote: >> > > > Hi Vikas, >> > > > >> > > > Sorry for the late reply. I now have more time to work on CDF, so >> > > > delays should be much shorter. >> > > > >> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: >> > > > > Hi Laurent, >> > > > > >> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, >> > > > > what >> > > > > I found is that, the exynos display controller is MIPI DSI based >> > > > > controller. >> > > > > >> > > > > But if I look at CDF patches, it has only support for MIPI DBI >> > > > > based >> > > > > Display controller. >> > > > > >> > > > > So my question is, do we have any generic framework for MIPI DSI >> > > > > based display controller? basically I wanted to know, how to go >> > > > > about >> > > > > porting CDF for such kind of display controller. >> > > > >> > > > MIPI DSI support is not available yet. The only reason for that is >> > > > that I don't have any MIPI DSI hardware to write and test the code >> > > > with :-) >> > > > >> > > > The common display framework should definitely support MIPI DSI. I >> > > > think the existing MIPI DBI code could be used as a base, so the >> > > > implementation shouldn't be too high. >> > > > >> > > > Yeah, i was also thinking in similar lines, below is my though for >> > > > MIPI DSI support in CDF. >> > > >> > > o MIPI DSI support as part of CDF framework will expose >> > > § mipi_dsi_register_device(mpi_device) (will be called >> > > mach-xxx-dt.c >> > > file ) >> > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called >> > > from >> > > platform specific init driver call ) >> > > · bus ops will be >> > > o read data >> > > o write data >> > > o write command >> > > § MIPI DSI will be registered as bus_register() >> > > >> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) >> > > will >> > > initialize the MIPI DSI HW IP. >> > > >> > > This probe will also parse the DT file for MIPI DSI based panel, add >> > > the panel device (device_add() ) to kernel and register the display >> > > entity with its control and video ops with CDF. >> > > >> > > I can give this a try. >> > >> > I am currently in progress of reworking Exynos MIPI DSIM code and >> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I >> > have most of the work done, I have just to solve several remaining >> > problems. >> Do you already have code that you can publish ? I'm particularly >> interested (and I think Tomi Valkeinen would be as well) in looking at >> the DSI operations you expose to DSI sinks (panels, transceivers, ...). > > Well, I'm afraid this might be little below your expectations, but here's > an initial RFC of the part defining just the DSI bus. I need a bit more > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. > > The implementation is very simple and heavily based on your MIPI DBI > support and existing Exynos MIPI DSIM framework. Provided operation set is > based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately > this is my only source of information about MIPI DSI. > > Best regards, > -- > Tomasz Figa > Samsung Poland R&D Center > SW Solution Development, Linux Platform > > From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 > From: Tomasz Figa <t.figa@samsung.com> > Date: Thu, 27 Dec 2012 12:36:15 +0100 > Subject: [RFC] video: display: Add generic MIPI DSI bus > > Signed-off-by: Tomasz Figa <t.figa@samsung.com> > --- > drivers/video/display/Kconfig | 4 + > drivers/video/display/Makefile | 1 + > drivers/video/display/mipi-dsi-bus.c | 214 > +++++++++++++++++++++++++++++++++++ > include/video/display.h | 1 + > include/video/mipi-dsi-bus.h | 98 ++++++++++++++++ > 5 files changed, 318 insertions(+) > create mode 100644 drivers/video/display/mipi-dsi-bus.c > create mode 100644 include/video/mipi-dsi-bus.h > > diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig > index 13b6aaf..dbaff9d 100644 > --- a/drivers/video/display/Kconfig > +++ b/drivers/video/display/Kconfig > @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI > tristate > default n > > +config DISPLAY_MIPI_DSI > + tristate > + default n > + > config DISPLAY_PANEL_DPI > tristate "DPI (Parallel) Display Panels" > ---help--- > diff --git a/drivers/video/display/Makefile > b/drivers/video/display/Makefile > index 482bec7..429b3ac8 100644 > --- a/drivers/video/display/Makefile > +++ b/drivers/video/display/Makefile > @@ -1,5 +1,6 @@ > obj-$(CONFIG_DISPLAY_CORE) += display-core.o > obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o > +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o > obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o > obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o > obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o > diff --git a/drivers/video/display/mipi-dsi-bus.c > b/drivers/video/display/mipi-dsi-bus.c > new file mode 100644 > index 0000000..2998522 > --- /dev/null > +++ b/drivers/video/display/mipi-dsi-bus.c > @@ -0,0 +1,214 @@ > +/* > + * MIPI DSI Bus > + * > + * Copyright (C) 2012 Samsung Electronics Co., Ltd. > + * Contacts: Tomasz Figa <t.figa@samsung.com> > + * > + * Heavily based ond mipi-dbi-bus.c. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include <linux/device.h> > +#include <linux/export.h> > +#include <linux/kernel.h> > +#include <linux/list.h> > +#include <linux/module.h> > +#include <linux/mutex.h> > +#include <linux/pm.h> > +#include <linux/pm_runtime.h> > + > +#include <video/mipi-dsi-bus.h> > + > +/* > ----------------------------------------------------------------------------- > + * Bus operations > + */ > + > +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len) > +{ > + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_write_command); > + > +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, unsigned int len) > +{ > + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf, > len); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_read_command); > + > +/* > ----------------------------------------------------------------------------- > + * Bus type > + */ > + > +static const struct mipi_dsi_device_id * > +mipi_dsi_match_id(const struct mipi_dsi_device_id *id, > + struct mipi_dsi_device *dev) > +{ > + while (id->name[0]) { > + if (strcmp(dev->name, id->name) == 0) { > + dev->id_entry = id; > + return id; > + } > + id++; > + } > + return NULL; > +} > + > +static int mipi_dsi_match(struct device *_dev, struct device_driver > *_drv) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv); > + > + if (drv->id_table) > + return mipi_dsi_match_id(drv->id_table, dev) != NULL; > + > + return (strcmp(dev->name, _drv->name) == 0); > +} > + > +static ssize_t modalias_show(struct device *_dev, struct device_attribute > *a, > + char *buf) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n", > + dev->name); > + > + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; > +} > + > +static struct device_attribute mipi_dsi_dev_attrs[] = { > + __ATTR_RO(modalias), > + __ATTR_NULL, > +}; > + > +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env > *env) > +{ > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX, > + dev->name); > + return 0; > +} > + > +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { > + .runtime_suspend = pm_generic_runtime_suspend, > + .runtime_resume = pm_generic_runtime_resume, > + .runtime_idle = pm_generic_runtime_idle, > + .suspend = pm_generic_suspend, > + .resume = pm_generic_resume, > + .freeze = pm_generic_freeze, > + .thaw = pm_generic_thaw, > + .poweroff = pm_generic_poweroff, > + .restore = pm_generic_restore, > +}; > + > +static struct bus_type mipi_dsi_bus_type = { > + .name = "mipi-dsi", > + .dev_attrs = mipi_dsi_dev_attrs, > + .match = mipi_dsi_match, > + .uevent = mipi_dsi_uevent, > + .pm = &mipi_dsi_dev_pm_ops, > +}; > + > +/* > ----------------------------------------------------------------------------- > + * Device and driver (un)registration > + */ > + > +/** > + * mipi_dsi_device_register - register a DSI device > + * @dev: DSI device we're registering > + */ > +int mipi_dsi_device_register(struct mipi_dsi_device *dev, > + struct mipi_dsi_bus *bus) > +{ > + device_initialize(&dev->dev); > + > + dev->bus = bus; > + dev->dev.bus = &mipi_dsi_bus_type; > + dev->dev.parent = bus->dev; > + > + if (dev->id != -1) > + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id); > + else > + dev_set_name(&dev->dev, "%s", dev->name); > + > + return device_add(&dev->dev); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_device_register); > + > +/** > + * mipi_dsi_device_unregister - unregister a DSI device > + * @dev: DSI device we're unregistering > + */ > +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev) > +{ > + device_del(&dev->dev); > + put_device(&dev->dev); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister); > + > +static int mipi_dsi_drv_probe(struct device *_dev) > +{ > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + return drv->probe(dev); > +} > + > +static int mipi_dsi_drv_remove(struct device *_dev) > +{ > + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver); > + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev); > + > + return drv->remove(dev); > +} > + > +/** > + * mipi_dsi_driver_register - register a driver for DSI devices > + * @drv: DSI driver structure > + */ > +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv) > +{ > + drv->driver.bus = &mipi_dsi_bus_type; > + if (drv->probe) > + drv->driver.probe = mipi_dsi_drv_probe; > + if (drv->remove) > + drv->driver.remove = mipi_dsi_drv_remove; > + > + return driver_register(&drv->driver); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register); > + > +/** > + * mipi_dsi_driver_unregister - unregister a driver for DSI devices > + * @drv: DSI driver structure > + */ > +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv) > +{ > + driver_unregister(&drv->driver); > +} > +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister); > + > +/* > ----------------------------------------------------------------------------- > + * Init/exit > + */ > + > +static int __init mipi_dsi_init(void) > +{ > + return bus_register(&mipi_dsi_bus_type); > +} > + As per the discussion what Laurent and Tomi had ( http://lists.freedesktop.org/archives/dri-devel/2012-December/032038.html), both DSI and DBI doesn't need to be registered as real bus. Please refer to Tomi's pacthset for DSI support. ( git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf ) anyways i am working on Exynos MIPI DSI as per the new CDF proposed by Tomi and Laurent. > +static void __exit mipi_dsi_exit(void) > +{ > + bus_unregister(&mipi_dsi_bus_type); > +} > + > +module_init(mipi_dsi_init); > +module_exit(mipi_dsi_exit) > + > +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>"); > +MODULE_DESCRIPTION("MIPI DSI Bus"); > +MODULE_LICENSE("GPL"); > diff --git a/include/video/display.h b/include/video/display.h > index 75ba270..f86ea6e 100644 > --- a/include/video/display.h > +++ b/include/video/display.h > @@ -70,6 +70,7 @@ enum display_entity_stream_state { > enum display_entity_interface_type { > DISPLAY_ENTITY_INTERFACE_DPI, > DISPLAY_ENTITY_INTERFACE_DBI, > + DISPLAY_ENTITY_INTERFACE_DSI, > }; > > struct display_entity_interface_params { > diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h > new file mode 100644 > index 0000000..3efcb39 > --- /dev/null > +++ b/include/video/mipi-dsi-bus.h > @@ -0,0 +1,98 @@ > +/* > + * MIPI DSI Bus > + * > + * Copyright (C) 2012 Samsung Electronics Co., Ltd. > + * Contacts: Tomasz Figa <t.figa@samsung.com> > + * > + * Heavily based ond mipi-dbi-bus.h. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#ifndef __MIPI_DSI_BUS_H__ > +#define __MIPI_DSI_BUS_H__ > + > +#include <linux/device.h> > + > +struct mipi_dsi_bus; > +struct mipi_dsi_device; > + > +struct mipi_dsi_bus_ops { > + int (*write_command)(struct mipi_dsi_bus *bus, > + struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len); > + int (*read_command)(struct mipi_dsi_bus *bus, > + struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, > + unsigned int len); > +}; > + > +struct mipi_dsi_bus { > + struct device *dev; > + const struct mipi_dsi_bus_ops *ops; > +}; > + > +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:" > +#define MIPI_DSI_NAME_SIZE 32 > + > +struct mipi_dsi_device_id { > + char name[MIPI_DSI_NAME_SIZE]; > + __kernel_ulong_t driver_data /* Data private to the driver */ > + __aligned(sizeof(__kernel_ulong_t)); > +}; > + > +struct mipi_dsi_device { > + const char *name; > + int id; > + struct device dev; > + > + const struct mipi_dsi_device_id *id_entry; > + struct mipi_dsi_bus *bus; > +}; > + > +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device, > dev) > + > +int mipi_dsi_device_register(struct mipi_dsi_device *dev, > + struct mipi_dsi_bus *bus); > +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev); > + > +struct mipi_dsi_driver { > + int(*probe)(struct mipi_dsi_device *); > + int(*remove)(struct mipi_dsi_device *); > + struct device_driver driver; > + const struct mipi_dsi_device_id *id_table; > +}; > + > +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, > driver) > + > +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv); > +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv); > + > +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device > *dev) > +{ > + return dev_get_drvdata(&dev->dev); > +} > + > +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev, > + void *data) > +{ > + dev_set_drvdata(&dev->dev, data); > +} > + > +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do > + * anything special in module init/exit. This eliminates a lot of > + * boilerplate. Each module may only use this macro once, and > + * calling it replaces module_init() and module_exit() > + */ > +#define module_mipi_dsi_driver(__mipi_dsi_driver) \ > + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \ > + mipi_dsi_driver_unregister) > + > +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd, > + const unsigned char *buf, unsigned int len); > +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd, > + unsigned int addr, unsigned char *buf, unsigned int len); > + > +#endif /* __MIPI_DSI_BUS__ */ > -- > 1.8.0.2 > > -- Thanks and Regards Vikas Sajjan ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 14:43 ` Tomasz Figa @ 2013-01-08 8:18 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:18 UTC (permalink / raw) To: Tomasz Figa Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Tomasz, On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > > Hi Vikas, > > > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > > delays should be much shorter. > > > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > > Hi Laurent, > > > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > > what I found is that, the exynos display controller is MIPI DSI > > > > > > based controller. > > > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > > based Display controller. > > > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > > based display controller? basically I wanted to know, how to go > > > > > > about porting CDF for such kind of display controller. > > > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > > with :-) > > > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > > think the existing MIPI DBI code could be used as a base, so the > > > > > implementation shouldn't be too high. > > > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > > MIPI DSI support in CDF. > > > > > > > > o MIPI DSI support as part of CDF framework will expose > > > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > > > > file ) > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > > from platform specific init driver call ) > > > > · bus ops will be > > > > o read data > > > > o write data > > > > o write command > > > > § MIPI DSI will be registered as bus_register() > > > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > > will initialize the MIPI DSI HW IP. > > > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > > the panel device (device_add() ) to kernel and register the display > > > > entity with its control and video ops with CDF. > > > > > > > > I can give this a try. > > > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > > have most of the work done, I have just to solve several remaining > > > problems. > > > > Do you already have code that you can publish ? I'm particularly > > interested (and I think Tomi Valkeinen would be as well) in looking at > > the DSI operations you expose to DSI sinks (panels, transceivers, ...). > > Well, I'm afraid this might be little below your expectations, but here's > an initial RFC of the part defining just the DSI bus. I need a bit more > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. No worries. I was particularly interested in the DSI operations you needed to export, they seem pretty simple. Thank you for sharing the code. > The implementation is very simple and heavily based on your MIPI DBI > support and existing Exynos MIPI DSIM framework. Provided operation set is > based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately > this is my only source of information about MIPI DSI. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 8:18 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:18 UTC (permalink / raw) To: Tomasz Figa Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media Hi Tomasz, On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > > Hi Vikas, > > > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > > delays should be much shorter. > > > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > > Hi Laurent, > > > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > > what I found is that, the exynos display controller is MIPI DSI > > > > > > based controller. > > > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > > based Display controller. > > > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > > based display controller? basically I wanted to know, how to go > > > > > > about porting CDF for such kind of display controller. > > > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > > with :-) > > > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > > think the existing MIPI DBI code could be used as a base, so the > > > > > implementation shouldn't be too high. > > > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > > MIPI DSI support in CDF. > > > > > > > > o MIPI DSI support as part of CDF framework will expose > > > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > > > > file ) > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > > from platform specific init driver call ) > > > > · bus ops will be > > > > o read data > > > > o write data > > > > o write command > > > > § MIPI DSI will be registered as bus_register() > > > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > > will initialize the MIPI DSI HW IP. > > > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > > the panel device (device_add() ) to kernel and register the display > > > > entity with its control and video ops with CDF. > > > > > > > > I can give this a try. > > > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > > have most of the work done, I have just to solve several remaining > > > problems. > > > > Do you already have code that you can publish ? I'm particularly > > interested (and I think Tomi Valkeinen would be as well) in looking at > > the DSI operations you expose to DSI sinks (panels, transceivers, ...). > > Well, I'm afraid this might be little below your expectations, but here's > an initial RFC of the part defining just the DSI bus. I need a bit more > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. No worries. I was particularly interested in the DSI operations you needed to export, they seem pretty simple. Thank you for sharing the code. > The implementation is very simple and heavily based on your MIPI DBI > support and existing Exynos MIPI DSIM framework. Provided operation set is > based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately > this is my only source of information about MIPI DSI. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 8:18 ` Laurent Pinchart @ 2013-01-08 10:12 ` Marcus Lorentzon -1 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-01-08 10:12 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 01/08/2013 09:18 AM, Laurent Pinchart wrote: > On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: >> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >>>> > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: >>>>> > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: >>>>>> > > > > > Hi Vikas, >>>>>> > > > > > >>>>>> > > > > > Sorry for the late reply. I now have more time to work on CDF, so >>>>>> > > > > > delays should be much shorter. >>>>>> > > > > > >>>>>> > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: >>>>>>> > > > > > > Hi Laurent, >>>>>>> > > > > > > >>>>>>> > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, >>>>>>> > > > > > > what I found is that, the exynos display controller is MIPI DSI >>>>>>> > > > > > > based controller. >>>>>>> > > > > > > >>>>>>> > > > > > > But if I look at CDF patches, it has only support for MIPI DBI >>>>>>> > > > > > > based Display controller. >>>>>>> > > > > > > >>>>>>> > > > > > > So my question is, do we have any generic framework for MIPI DSI >>>>>>> > > > > > > based display controller? basically I wanted to know, how to go >>>>>>> > > > > > > about porting CDF for such kind of display controller. >>>>>> > > > > > >>>>>> > > > > > MIPI DSI support is not available yet. The only reason for that is >>>>>> > > > > > that I don't have any MIPI DSI hardware to write and test the code >>>>>> > > > > > with:-) >>>>>> > > > > > >>>>>> > > > > > The common display framework should definitely support MIPI DSI. I >>>>>> > > > > > think the existing MIPI DBI code could be used as a base, so the >>>>>> > > > > > implementation shouldn't be too high. >>>>>> > > > > > >>>>>> > > > > > Yeah, i was also thinking in similar lines, below is my though for >>>>>> > > > > > MIPI DSI support in CDF. >>>>> > > > > >>>>> > > > > o MIPI DSI support as part of CDF framework will expose >>>>> > > > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c >>>>> > > > > file ) >>>>> > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called >>>>> > > > > from platform specific init driver call ) >>>>> > > > > · bus ops will be >>>>> > > > > o read data >>>>> > > > > o write data >>>>> > > > > o write command >>>>> > > > > § MIPI DSI will be registered as bus_register() >>>>> > > > > >>>>> > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) >>>>> > > > > will initialize the MIPI DSI HW IP. >>>>> > > > > >>>>> > > > > This probe will also parse the DT file for MIPI DSI based panel, add >>>>> > > > > the panel device (device_add() ) to kernel and register the display >>>>> > > > > entity with its control and video ops with CDF. >>>>> > > > > >>>>> > > > > I can give this a try. >>>> > > > >>>> > > > I am currently in progress of reworking Exynos MIPI DSIM code and >>>> > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I >>>> > > > have most of the work done, I have just to solve several remaining >>>> > > > problems. >>> > > >>> > > Do you already have code that you can publish ? I'm particularly >>> > > interested (and I think Tomi Valkeinen would be as well) in looking at >>> > > the DSI operations you expose to DSI sinks (panels, transceivers, ...). >> > >> > Well, I'm afraid this might be little below your expectations, but here's >> > an initial RFC of the part defining just the DSI bus. I need a bit more >> > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. > No worries. I was particularly interested in the DSI operations you needed to > export, they seem pretty simple. Thank you for sharing the code. > FYI, here is STE "DSI API": http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l361 But it is not perfect. After a couple of products we realized that most panel drivers want an easy way to send a bunch of init commands in one go. So I think it should be an op for sending an array of commands at once. Something like struct dsi_cmd { enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ u8 cmd; int dataLen; u8 *data; } struct dsi_ops { int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); ... } The rest of "DSI write API" could be made helpers on top of this one op. This grouping also allows driver to describe intent to send a bunch of commands together which might be of interest with mode set (if you need to synchronize a bunch of commands with a mode set, like setting smart panel rotation in synch with new framebuffer in dsi video mode). I also looked at the video source in Tomi's git tree (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/include/video/display.h). I think I would prefer a single "setup" op taking a "struct dsi_config" as argument. Then each DSI formatter/encoder driver could decide best way to set that up. We have something similar at http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l118 And I think I still prefer the dsi_bus in favor of the abstract video source. It just looks like a home made bus with bus-ops ... can't you do something similar using the normal driver framework? enable/disable looks like suspend/resume, register/unregister_vid_src is like bus_(un)register_device, ... the video source anyway seems unattached to the panel stuff with the find_video_source call. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 10:12 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-01-08 10:12 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 01/08/2013 09:18 AM, Laurent Pinchart wrote: > On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: >> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >>>> > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: >>>>> > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: >>>>>> > > > > > Hi Vikas, >>>>>> > > > > > >>>>>> > > > > > Sorry for the late reply. I now have more time to work on CDF, so >>>>>> > > > > > delays should be much shorter. >>>>>> > > > > > >>>>>> > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: >>>>>>> > > > > > > Hi Laurent, >>>>>>> > > > > > > >>>>>>> > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, >>>>>>> > > > > > > what I found is that, the exynos display controller is MIPI DSI >>>>>>> > > > > > > based controller. >>>>>>> > > > > > > >>>>>>> > > > > > > But if I look at CDF patches, it has only support for MIPI DBI >>>>>>> > > > > > > based Display controller. >>>>>>> > > > > > > >>>>>>> > > > > > > So my question is, do we have any generic framework for MIPI DSI >>>>>>> > > > > > > based display controller? basically I wanted to know, how to go >>>>>>> > > > > > > about porting CDF for such kind of display controller. >>>>>> > > > > > >>>>>> > > > > > MIPI DSI support is not available yet. The only reason for that is >>>>>> > > > > > that I don't have any MIPI DSI hardware to write and test the code >>>>>> > > > > > with:-) >>>>>> > > > > > >>>>>> > > > > > The common display framework should definitely support MIPI DSI. I >>>>>> > > > > > think the existing MIPI DBI code could be used as a base, so the >>>>>> > > > > > implementation shouldn't be too high. >>>>>> > > > > > >>>>>> > > > > > Yeah, i was also thinking in similar lines, below is my though for >>>>>> > > > > > MIPI DSI support in CDF. >>>>> > > > > >>>>> > > > > o MIPI DSI support as part of CDF framework will expose >>>>> > > > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c >>>>> > > > > file ) >>>>> > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called >>>>> > > > > from platform specific init driver call ) >>>>> > > > > · bus ops will be >>>>> > > > > o read data >>>>> > > > > o write data >>>>> > > > > o write command >>>>> > > > > § MIPI DSI will be registered as bus_register() >>>>> > > > > >>>>> > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) >>>>> > > > > will initialize the MIPI DSI HW IP. >>>>> > > > > >>>>> > > > > This probe will also parse the DT file for MIPI DSI based panel, add >>>>> > > > > the panel device (device_add() ) to kernel and register the display >>>>> > > > > entity with its control and video ops with CDF. >>>>> > > > > >>>>> > > > > I can give this a try. >>>> > > > >>>> > > > I am currently in progress of reworking Exynos MIPI DSIM code and >>>> > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I >>>> > > > have most of the work done, I have just to solve several remaining >>>> > > > problems. >>> > > >>> > > Do you already have code that you can publish ? I'm particularly >>> > > interested (and I think Tomi Valkeinen would be as well) in looking at >>> > > the DSI operations you expose to DSI sinks (panels, transceivers, ...). >> > >> > Well, I'm afraid this might be little below your expectations, but here's >> > an initial RFC of the part defining just the DSI bus. I need a bit more >> > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. > No worries. I was particularly interested in the DSI operations you needed to > export, they seem pretty simple. Thank you for sharing the code. > FYI, here is STE "DSI API": http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l361 But it is not perfect. After a couple of products we realized that most panel drivers want an easy way to send a bunch of init commands in one go. So I think it should be an op for sending an array of commands at once. Something like struct dsi_cmd { enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ u8 cmd; int dataLen; u8 *data; } struct dsi_ops { int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); ... } The rest of "DSI write API" could be made helpers on top of this one op. This grouping also allows driver to describe intent to send a bunch of commands together which might be of interest with mode set (if you need to synchronize a bunch of commands with a mode set, like setting smart panel rotation in synch with new framebuffer in dsi video mode). I also looked at the video source in Tomi's git tree (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/include/video/display.h). I think I would prefer a single "setup" op taking a "struct dsi_config" as argument. Then each DSI formatter/encoder driver could decide best way to set that up. We have something similar at http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l118 And I think I still prefer the dsi_bus in favor of the abstract video source. It just looks like a home made bus with bus-ops ... can't you do something similar using the normal driver framework? enable/disable looks like suspend/resume, register/unregister_vid_src is like bus_(un)register_device, ... the video source anyway seems unattached to the panel stuff with the find_video_source call. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 10:12 ` Marcus Lorentzon @ 2013-01-08 16:36 ` Tomasz Figa -1 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2013-01-08 16:36 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: > On 01/08/2013 09:18 AM, Laurent Pinchart wrote: > > On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: > >> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > >>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > >>>> > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > >>>>> > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > >>>>>> > > > > > Hi Vikas, > >>>>>> > > > > > > >>>>>> > > > > > Sorry for the late reply. I now have more time to > >>>>>> > > > > > work on CDF, so > >>>>>> > > > > > delays should be much shorter. > >>>>>> > > > > > > >>>>>> > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > >>>>>>> > > > > > > Hi Laurent, > >>>>>>> > > > > > > > >>>>>>> > > > > > > I was thinking of porting CDF to samsung > >>>>>>> > > > > > > EXYNOS 5250 platform, > >>>>>>> > > > > > > what I found is that, the exynos display > >>>>>>> > > > > > > controller is MIPI DSI > >>>>>>> > > > > > > based controller. > >>>>>>> > > > > > > > >>>>>>> > > > > > > But if I look at CDF patches, it has only > >>>>>>> > > > > > > support for MIPI DBI > >>>>>>> > > > > > > based Display controller. > >>>>>>> > > > > > > > >>>>>>> > > > > > > So my question is, do we have any generic > >>>>>>> > > > > > > framework for MIPI DSI > >>>>>>> > > > > > > based display controller? basically I wanted > >>>>>>> > > > > > > to know, how to go > >>>>>>> > > > > > > about porting CDF for such kind of display > >>>>>>> > > > > > > controller. > >>>>>> > > > > > > >>>>>> > > > > > MIPI DSI support is not available yet. The only > >>>>>> > > > > > reason for that is > >>>>>> > > > > > that I don't have any MIPI DSI hardware to write > >>>>>> > > > > > and test the code > >>>>>> > > > > > with:-) > >>>>>> > > > > > > >>>>>> > > > > > The common display framework should definitely > >>>>>> > > > > > support MIPI DSI. I > >>>>>> > > > > > think the existing MIPI DBI code could be used as > >>>>>> > > > > > a base, so the > >>>>>> > > > > > implementation shouldn't be too high. > >>>>>> > > > > > > >>>>>> > > > > > Yeah, i was also thinking in similar lines, below > >>>>>> > > > > > is my though for > >>>>>> > > > > > MIPI DSI support in CDF. > >>>>> > > > > > >>>>> > > > > o MIPI DSI support as part of CDF framework will > >>>>> > > > > expose > >>>>> > > > > § mipi_dsi_register_device(mpi_device) (will be > >>>>> > > > > called mach-xxx-dt.c > >>>>> > > > > file ) > >>>>> > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) > >>>>> > > > > (will be called > >>>>> > > > > from platform specific init driver call ) > >>>>> > > > > · bus ops will be > >>>>> > > > > o read data > >>>>> > > > > o write data > >>>>> > > > > o write command > >>>>> > > > > § MIPI DSI will be registered as bus_register() > >>>>> > > > > > >>>>> > > > > When MIPI DSI probe is called, it (e.g., Exynos or > >>>>> > > > > OMAP MIPI DSI) > >>>>> > > > > will initialize the MIPI DSI HW IP. > >>>>> > > > > > >>>>> > > > > This probe will also parse the DT file for MIPI DSI > >>>>> > > > > based panel, add > >>>>> > > > > the panel device (device_add() ) to kernel and > >>>>> > > > > register the display > >>>>> > > > > entity with its control and video ops with CDF. > >>>>> > > > > > >>>>> > > > > I can give this a try. > >>>> > > > > >>>> > > > I am currently in progress of reworking Exynos MIPI DSIM > >>>> > > > code and > >>>> > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display > >>>> > > > Framework. I > >>>> > > > have most of the work done, I have just to solve several > >>>> > > > remaining > >>>> > > > problems. > >>> > > > >>> > > Do you already have code that you can publish ? I'm > >>> > > particularly > >>> > > interested (and I think Tomi Valkeinen would be as well) in > >>> > > looking at > >>> > > the DSI operations you expose to DSI sinks (panels, > >>> > > transceivers, ...). > >> > > >> > Well, I'm afraid this might be little below your expectations, but > >> > here's an initial RFC of the part defining just the DSI bus. I > >> > need a bit more time for patches for Exynos MIPI DSI master and > >> > s6e8ax0 LCD. > > > > No worries. I was particularly interested in the DSI operations you > > needed to export, they seem pretty simple. Thank you for sharing the > > code. > FYI, > here is STE "DSI API": > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > #l361 > > But it is not perfect. After a couple of products we realized that most > panel drivers want an easy way to send a bunch of init commands in one > go. So I think it should be an op for sending an array of commands at > once. Something like > > struct dsi_cmd { > enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ > u8 cmd; > int dataLen; > u8 *data; > } > struct dsi_ops { > int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); > ... > } Yes, this should be flexible enough to cover most of (or even whole) DSI specification. However I'm not sure whether the dsi_write name would be appropriate, since DSI packet types include also read and special transactions. So, according to DSI terminology, maybe dsi_transaction would be better? > > The rest of "DSI write API" could be made helpers on top of this one op. > This grouping also allows driver to describe intent to send a bunch of > commands together which might be of interest with mode set (if you need > to synchronize a bunch of commands with a mode set, like setting smart > panel rotation in synch with new framebuffer in dsi video mode). > > I also looked at the video source in Tomi's git tree > (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf > /include/video/display.h). I think I would prefer a single "setup" op > taking a "struct dsi_config" as argument. Then each DSI > formatter/encoder driver could decide best way to set that up. We have > something similar at > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > #l118 Yes, this would be definitely better, because such configuration changes usually come together (i.e. display connected, which needs complete reconfiguration of all parameters). > And I think I still prefer the dsi_bus in favor of the abstract video > source. It just looks like a home made bus with bus-ops ... can't you do > something similar using the normal driver framework? enable/disable > looks like suspend/resume, register/unregister_vid_src is like > bus_(un)register_device, ... the video source anyway seems unattached > to the panel stuff with the find_video_source call. DSI needs specific power management. It's necessary to power up the panel first to make it wait for Tinit event and then enable DSI master to trigger such event. Only then rest of panel initialization can be completed. Also, as discussed in previous posts, some panels might use DSI only for video data and another interface (I2C, SPI) for control data. In such case it would be impossible to represent such device in a reasonable way using current driver model. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 16:36 ` Tomasz Figa 0 siblings, 0 replies; 153+ messages in thread From: Tomasz Figa @ 2013-01-08 16:36 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: > On 01/08/2013 09:18 AM, Laurent Pinchart wrote: > > On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: > >> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > >>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > >>>> > > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > >>>>> > > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > >>>>>> > > > > > Hi Vikas, > >>>>>> > > > > > > >>>>>> > > > > > Sorry for the late reply. I now have more time to > >>>>>> > > > > > work on CDF, so > >>>>>> > > > > > delays should be much shorter. > >>>>>> > > > > > > >>>>>> > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > >>>>>>> > > > > > > Hi Laurent, > >>>>>>> > > > > > > > >>>>>>> > > > > > > I was thinking of porting CDF to samsung > >>>>>>> > > > > > > EXYNOS 5250 platform, > >>>>>>> > > > > > > what I found is that, the exynos display > >>>>>>> > > > > > > controller is MIPI DSI > >>>>>>> > > > > > > based controller. > >>>>>>> > > > > > > > >>>>>>> > > > > > > But if I look at CDF patches, it has only > >>>>>>> > > > > > > support for MIPI DBI > >>>>>>> > > > > > > based Display controller. > >>>>>>> > > > > > > > >>>>>>> > > > > > > So my question is, do we have any generic > >>>>>>> > > > > > > framework for MIPI DSI > >>>>>>> > > > > > > based display controller? basically I wanted > >>>>>>> > > > > > > to know, how to go > >>>>>>> > > > > > > about porting CDF for such kind of display > >>>>>>> > > > > > > controller. > >>>>>> > > > > > > >>>>>> > > > > > MIPI DSI support is not available yet. The only > >>>>>> > > > > > reason for that is > >>>>>> > > > > > that I don't have any MIPI DSI hardware to write > >>>>>> > > > > > and test the code > >>>>>> > > > > > with:-) > >>>>>> > > > > > > >>>>>> > > > > > The common display framework should definitely > >>>>>> > > > > > support MIPI DSI. I > >>>>>> > > > > > think the existing MIPI DBI code could be used as > >>>>>> > > > > > a base, so the > >>>>>> > > > > > implementation shouldn't be too high. > >>>>>> > > > > > > >>>>>> > > > > > Yeah, i was also thinking in similar lines, below > >>>>>> > > > > > is my though for > >>>>>> > > > > > MIPI DSI support in CDF. > >>>>> > > > > > >>>>> > > > > o MIPI DSI support as part of CDF framework will > >>>>> > > > > expose > >>>>> > > > > § mipi_dsi_register_device(mpi_device) (will be > >>>>> > > > > called mach-xxx-dt.c > >>>>> > > > > file ) > >>>>> > > > > § mipi_dsi_register_driver(mipi_driver, bus ops) > >>>>> > > > > (will be called > >>>>> > > > > from platform specific init driver call ) > >>>>> > > > > · bus ops will be > >>>>> > > > > o read data > >>>>> > > > > o write data > >>>>> > > > > o write command > >>>>> > > > > § MIPI DSI will be registered as bus_register() > >>>>> > > > > > >>>>> > > > > When MIPI DSI probe is called, it (e.g., Exynos or > >>>>> > > > > OMAP MIPI DSI) > >>>>> > > > > will initialize the MIPI DSI HW IP. > >>>>> > > > > > >>>>> > > > > This probe will also parse the DT file for MIPI DSI > >>>>> > > > > based panel, add > >>>>> > > > > the panel device (device_add() ) to kernel and > >>>>> > > > > register the display > >>>>> > > > > entity with its control and video ops with CDF. > >>>>> > > > > > >>>>> > > > > I can give this a try. > >>>> > > > > >>>> > > > I am currently in progress of reworking Exynos MIPI DSIM > >>>> > > > code and > >>>> > > > s6e8ax0 LCD driver to use the v2 RFC of Common Display > >>>> > > > Framework. I > >>>> > > > have most of the work done, I have just to solve several > >>>> > > > remaining > >>>> > > > problems. > >>> > > > >>> > > Do you already have code that you can publish ? I'm > >>> > > particularly > >>> > > interested (and I think Tomi Valkeinen would be as well) in > >>> > > looking at > >>> > > the DSI operations you expose to DSI sinks (panels, > >>> > > transceivers, ...). > >> > > >> > Well, I'm afraid this might be little below your expectations, but > >> > here's an initial RFC of the part defining just the DSI bus. I > >> > need a bit more time for patches for Exynos MIPI DSI master and > >> > s6e8ax0 LCD. > > > > No worries. I was particularly interested in the DSI operations you > > needed to export, they seem pretty simple. Thank you for sharing the > > code. > FYI, > here is STE "DSI API": > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > =include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > #l361 > > But it is not perfect. After a couple of products we realized that most > panel drivers want an easy way to send a bunch of init commands in one > go. So I think it should be an op for sending an array of commands at > once. Something like > > struct dsi_cmd { > enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ > u8 cmd; > int dataLen; > u8 *data; > } > struct dsi_ops { > int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); > ... > } Yes, this should be flexible enough to cover most of (or even whole) DSI specification. However I'm not sure whether the dsi_write name would be appropriate, since DSI packet types include also read and special transactions. So, according to DSI terminology, maybe dsi_transaction would be better? > > The rest of "DSI write API" could be made helpers on top of this one op. > This grouping also allows driver to describe intent to send a bunch of > commands together which might be of interest with mode set (if you need > to synchronize a bunch of commands with a mode set, like setting smart > panel rotation in synch with new framebuffer in dsi video mode). > > I also looked at the video source in Tomi's git tree > (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf > /include/video/display.h). I think I would prefer a single "setup" op > taking a "struct dsi_config" as argument. Then each DSI > formatter/encoder driver could decide best way to set that up. We have > something similar at > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > =include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > #l118 Yes, this would be definitely better, because such configuration changes usually come together (i.e. display connected, which needs complete reconfiguration of all parameters). > And I think I still prefer the dsi_bus in favor of the abstract video > source. It just looks like a home made bus with bus-ops ... can't you do > something similar using the normal driver framework? enable/disable > looks like suspend/resume, register/unregister_vid_src is like > bus_(un)register_device, ... the video source anyway seems unattached > to the panel stuff with the find_video_source call. DSI needs specific power management. It's necessary to power up the panel first to make it wait for Tinit event and then enable DSI master to trigger such event. Only then rest of panel initialization can be completed. Also, as discussed in previous posts, some panels might use DSI only for video data and another interface (I2C, SPI) for control data. In such case it would be impossible to represent such device in a reasonable way using current driver model. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 16:36 ` Tomasz Figa @ 2013-01-08 17:08 ` Marcus Lorentzon -1 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-01-08 17:08 UTC (permalink / raw) To: Tomasz Figa Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 01/08/2013 05:36 PM, Tomasz Figa wrote: > On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: >> On 01/08/2013 09:18 AM, Laurent Pinchart wrote: >>> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: >>>>> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >>>>>> > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >>>>>>> > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan > wrote: >>>>>>>> > > > On 17 December 2012 20:55, Laurent Pinchart wrote: >>>>>>>>> > > > > Hi Vikas, >>>>>>>>> > > > > >>>>>>>>> > > > > Sorry for the late reply. I now have more time to >>>>>>>>> > > > > work on CDF, so >>>>>>>>> > > > > delays should be much shorter. >>>>>>>>> > > > > >>>>>>>>> > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan > wrote: >>>>>>>>>> > > > > > Hi Laurent, >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > I was thinking of porting CDF to samsung >>>>>>>>>> > > > > > EXYNOS 5250 platform, >>>>>>>>>> > > > > > what I found is that, the exynos display >>>>>>>>>> > > > > > controller is MIPI DSI >>>>>>>>>> > > > > > based controller. >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > But if I look at CDF patches, it has only >>>>>>>>>> > > > > > support for MIPI DBI >>>>>>>>>> > > > > > based Display controller. >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > So my question is, do we have any generic >>>>>>>>>> > > > > > framework for MIPI DSI >>>>>>>>>> > > > > > based display controller? basically I wanted >>>>>>>>>> > > > > > to know, how to go >>>>>>>>>> > > > > > about porting CDF for such kind of display >>>>>>>>>> > > > > > controller. >>>>>>>>> > > > > >>>>>>>>> > > > > MIPI DSI support is not available yet. The only >>>>>>>>> > > > > reason for that is >>>>>>>>> > > > > that I don't have any MIPI DSI hardware to write >>>>>>>>> > > > > and test the code >>>>>>>>> > > > > with:-) >>>>>>>>> > > > > >>>>>>>>> > > > > The common display framework should definitely >>>>>>>>> > > > > support MIPI DSI. I >>>>>>>>> > > > > think the existing MIPI DBI code could be used as >>>>>>>>> > > > > a base, so the >>>>>>>>> > > > > implementation shouldn't be too high. >>>>>>>>> > > > > >>>>>>>>> > > > > Yeah, i was also thinking in similar lines, below >>>>>>>>> > > > > is my though for >>>>>>>>> > > > > MIPI DSI support in CDF. >>>>>>>> > > > >>>>>>>> > > > o MIPI DSI support as part of CDF framework will >>>>>>>> > > > expose >>>>>>>> > > > § mipi_dsi_register_device(mpi_device) (will be >>>>>>>> > > > called mach-xxx-dt.c >>>>>>>> > > > file ) >>>>>>>> > > > § mipi_dsi_register_driver(mipi_driver, bus ops) >>>>>>>> > > > (will be called >>>>>>>> > > > from platform specific init driver call ) >>>>>>>> > > > · bus ops will be >>>>>>>> > > > o read data >>>>>>>> > > > o write data >>>>>>>> > > > o write command >>>>>>>> > > > § MIPI DSI will be registered as bus_register() >>>>>>>> > > > >>>>>>>> > > > When MIPI DSI probe is called, it (e.g., Exynos or >>>>>>>> > > > OMAP MIPI DSI) >>>>>>>> > > > will initialize the MIPI DSI HW IP. >>>>>>>> > > > >>>>>>>> > > > This probe will also parse the DT file for MIPI DSI >>>>>>>> > > > based panel, add >>>>>>>> > > > the panel device (device_add() ) to kernel and >>>>>>>> > > > register the display >>>>>>>> > > > entity with its control and video ops with CDF. >>>>>>>> > > > >>>>>>>> > > > I can give this a try. >>>>>>> > > >>>>>>> > > I am currently in progress of reworking Exynos MIPI DSIM >>>>>>> > > code and >>>>>>> > > s6e8ax0 LCD driver to use the v2 RFC of Common Display >>>>>>> > > Framework. I >>>>>>> > > have most of the work done, I have just to solve several >>>>>>> > > remaining >>>>>>> > > problems. >>>>>> > >>>>>> > Do you already have code that you can publish ? I'm >>>>>> > particularly >>>>>> > interested (and I think Tomi Valkeinen would be as well) in >>>>>> > looking at >>>>>> > the DSI operations you expose to DSI sinks (panels, >>>>>> > transceivers, ...). >>>>> >>>>> Well, I'm afraid this might be little below your expectations, but >>>>> here's an initial RFC of the part defining just the DSI bus. I >>>>> need a bit more time for patches for Exynos MIPI DSI master and >>>>> s6e8ax0 LCD. >>> No worries. I was particularly interested in the DSI operations you >>> needed to export, they seem pretty simple. Thank you for sharing the >>> code. >> FYI, >> here is STE "DSI API": >> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f >> =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD >> #l361 >> >> But it is not perfect. After a couple of products we realized that most >> panel drivers want an easy way to send a bunch of init commands in one >> go. So I think it should be an op for sending an array of commands at >> once. Something like >> >> struct dsi_cmd { >> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >> u8 cmd; >> int dataLen; >> u8 *data; >> } >> struct dsi_ops { >> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >> ... >> } > Yes, this should be flexible enough to cover most of (or even whole) DSI > specification. > > However I'm not sure whether the dsi_write name would be appropriate, > since DSI packet types include also read and special transactions. So, > according to DSI terminology, maybe dsi_transaction would be better? I think read should still be separate. At least on my HW read and write are quite different. But all "transactions" are very much the same in HW setup. The ... was dsi_write etc ;) Like set_max_packet_size should maybe be an ops. Since only the implementer of the "video source" will know what the max read return packet size for that DSI IP is. The panels don't know that. Maybe another ops to retrieve some info about the caps of the video source would help that. Then a helper could call that and then the dsi_write one. >> And I think I still prefer the dsi_bus in favor of the abstract video >> source. It just looks like a home made bus with bus-ops ... can't you do >> something similar using the normal driver framework? enable/disable >> looks like suspend/resume, register/unregister_vid_src is like >> bus_(un)register_device, ... the video source anyway seems unattached >> to the panel stuff with the find_video_source call. > DSI needs specific power management. It's necessary to power up the panel > first to make it wait for Tinit event and then enable DSI master to > trigger such event. Only then rest of panel initialization can be > completed. I know, we have a very complex sequence for our HDMI encoder which uses sort of continuous DSI cmmand mode. And power/clock on sequences are tricky to get right in our current "CDF" API (mcde_display). But I fail to see how the current video source API is different from just using the bus/device APIs. > > Also, as discussed in previous posts, some panels might use DSI only for > video data and another interface (I2C, SPI) for control data. In such case > it would be impossible to represent such device in a reasonable way using > current driver model. > I understand that you need to get hold of both the control and data bus device in the driver. (Toshiba DSI-LVDS bridge is a good example and commonly used "encoder" that can use both DSI and I2C control interface.) But the control bus you get from device probe, and I guess you could call bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which will have access to dsi bus ops just as you call find_video_source("mysource") to access the "databus" ops directly with a logical device (display entity). I'm not saying I would refuse to use video sources. I just think the two models are so similar so it would be worth exploring how a device model style API would look like and to compare against. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 17:08 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-01-08 17:08 UTC (permalink / raw) To: Tomasz Figa Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 01/08/2013 05:36 PM, Tomasz Figa wrote: > On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: >> On 01/08/2013 09:18 AM, Laurent Pinchart wrote: >>> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote: >>>>> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >>>>>> > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >>>>>>> > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan > wrote: >>>>>>>> > > > On 17 December 2012 20:55, Laurent Pinchart wrote: >>>>>>>>> > > > > Hi Vikas, >>>>>>>>> > > > > >>>>>>>>> > > > > Sorry for the late reply. I now have more time to >>>>>>>>> > > > > work on CDF, so >>>>>>>>> > > > > delays should be much shorter. >>>>>>>>> > > > > >>>>>>>>> > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan > wrote: >>>>>>>>>> > > > > > Hi Laurent, >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > I was thinking of porting CDF to samsung >>>>>>>>>> > > > > > EXYNOS 5250 platform, >>>>>>>>>> > > > > > what I found is that, the exynos display >>>>>>>>>> > > > > > controller is MIPI DSI >>>>>>>>>> > > > > > based controller. >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > But if I look at CDF patches, it has only >>>>>>>>>> > > > > > support for MIPI DBI >>>>>>>>>> > > > > > based Display controller. >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > So my question is, do we have any generic >>>>>>>>>> > > > > > framework for MIPI DSI >>>>>>>>>> > > > > > based display controller? basically I wanted >>>>>>>>>> > > > > > to know, how to go >>>>>>>>>> > > > > > about porting CDF for such kind of display >>>>>>>>>> > > > > > controller. >>>>>>>>> > > > > >>>>>>>>> > > > > MIPI DSI support is not available yet. The only >>>>>>>>> > > > > reason for that is >>>>>>>>> > > > > that I don't have any MIPI DSI hardware to write >>>>>>>>> > > > > and test the code >>>>>>>>> > > > > with:-) >>>>>>>>> > > > > >>>>>>>>> > > > > The common display framework should definitely >>>>>>>>> > > > > support MIPI DSI. I >>>>>>>>> > > > > think the existing MIPI DBI code could be used as >>>>>>>>> > > > > a base, so the >>>>>>>>> > > > > implementation shouldn't be too high. >>>>>>>>> > > > > >>>>>>>>> > > > > Yeah, i was also thinking in similar lines, below >>>>>>>>> > > > > is my though for >>>>>>>>> > > > > MIPI DSI support in CDF. >>>>>>>> > > > >>>>>>>> > > > o MIPI DSI support as part of CDF framework will >>>>>>>> > > > expose >>>>>>>> > > > § mipi_dsi_register_device(mpi_device) (will be >>>>>>>> > > > called mach-xxx-dt.c >>>>>>>> > > > file ) >>>>>>>> > > > § mipi_dsi_register_driver(mipi_driver, bus ops) >>>>>>>> > > > (will be called >>>>>>>> > > > from platform specific init driver call ) >>>>>>>> > > > · bus ops will be >>>>>>>> > > > o read data >>>>>>>> > > > o write data >>>>>>>> > > > o write command >>>>>>>> > > > § MIPI DSI will be registered as bus_register() >>>>>>>> > > > >>>>>>>> > > > When MIPI DSI probe is called, it (e.g., Exynos or >>>>>>>> > > > OMAP MIPI DSI) >>>>>>>> > > > will initialize the MIPI DSI HW IP. >>>>>>>> > > > >>>>>>>> > > > This probe will also parse the DT file for MIPI DSI >>>>>>>> > > > based panel, add >>>>>>>> > > > the panel device (device_add() ) to kernel and >>>>>>>> > > > register the display >>>>>>>> > > > entity with its control and video ops with CDF. >>>>>>>> > > > >>>>>>>> > > > I can give this a try. >>>>>>> > > >>>>>>> > > I am currently in progress of reworking Exynos MIPI DSIM >>>>>>> > > code and >>>>>>> > > s6e8ax0 LCD driver to use the v2 RFC of Common Display >>>>>>> > > Framework. I >>>>>>> > > have most of the work done, I have just to solve several >>>>>>> > > remaining >>>>>>> > > problems. >>>>>> > >>>>>> > Do you already have code that you can publish ? I'm >>>>>> > particularly >>>>>> > interested (and I think Tomi Valkeinen would be as well) in >>>>>> > looking at >>>>>> > the DSI operations you expose to DSI sinks (panels, >>>>>> > transceivers, ...). >>>>> >>>>> Well, I'm afraid this might be little below your expectations, but >>>>> here's an initial RFC of the part defining just the DSI bus. I >>>>> need a bit more time for patches for Exynos MIPI DSI master and >>>>> s6e8ax0 LCD. >>> No worries. I was particularly interested in the DSI operations you >>> needed to export, they seem pretty simple. Thank you for sharing the >>> code. >> FYI, >> here is STE "DSI API": >> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f >> =include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD >> #l361 >> >> But it is not perfect. After a couple of products we realized that most >> panel drivers want an easy way to send a bunch of init commands in one >> go. So I think it should be an op for sending an array of commands at >> once. Something like >> >> struct dsi_cmd { >> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >> u8 cmd; >> int dataLen; >> u8 *data; >> } >> struct dsi_ops { >> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >> ... >> } > Yes, this should be flexible enough to cover most of (or even whole) DSI > specification. > > However I'm not sure whether the dsi_write name would be appropriate, > since DSI packet types include also read and special transactions. So, > according to DSI terminology, maybe dsi_transaction would be better? I think read should still be separate. At least on my HW read and write are quite different. But all "transactions" are very much the same in HW setup. The ... was dsi_write etc ;) Like set_max_packet_size should maybe be an ops. Since only the implementer of the "video source" will know what the max read return packet size for that DSI IP is. The panels don't know that. Maybe another ops to retrieve some info about the caps of the video source would help that. Then a helper could call that and then the dsi_write one. >> And I think I still prefer the dsi_bus in favor of the abstract video >> source. It just looks like a home made bus with bus-ops ... can't you do >> something similar using the normal driver framework? enable/disable >> looks like suspend/resume, register/unregister_vid_src is like >> bus_(un)register_device, ... the video source anyway seems unattached >> to the panel stuff with the find_video_source call. > DSI needs specific power management. It's necessary to power up the panel > first to make it wait for Tinit event and then enable DSI master to > trigger such event. Only then rest of panel initialization can be > completed. I know, we have a very complex sequence for our HDMI encoder which uses sort of continuous DSI cmmand mode. And power/clock on sequences are tricky to get right in our current "CDF" API (mcde_display). But I fail to see how the current video source API is different from just using the bus/device APIs. > > Also, as discussed in previous posts, some panels might use DSI only for > video data and another interface (I2C, SPI) for control data. In such case > it would be impossible to represent such device in a reasonable way using > current driver model. > I understand that you need to get hold of both the control and data bus device in the driver. (Toshiba DSI-LVDS bridge is a good example and commonly used "encoder" that can use both DSI and I2C control interface.) But the control bus you get from device probe, and I guess you could call bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which will have access to dsi bus ops just as you call find_video_source("mysource") to access the "databus" ops directly with a logical device (display entity). I'm not saying I would refuse to use video sources. I just think the two models are so similar so it would be worth exploring how a device model style API would look like and to compare against. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 17:08 ` Marcus Lorentzon @ 2013-02-01 23:35 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:35 UTC (permalink / raw) To: Marcus Lorentzon Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Marcus, On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: > On 01/08/2013 05:36 PM, Tomasz Figa wrote: > > On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: [snip] > >> FYI, > >> here is STE "DSI API": > >> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > >> =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > >> #l361 Thank you. > >> But it is not perfect. After a couple of products we realized that most > >> panel drivers want an easy way to send a bunch of init commands in one > >> go. So I think it should be an op for sending an array of commands at > >> once. Something like > >> > >> struct dsi_cmd { > >> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ > >> u8 cmd; > >> int dataLen; > >> u8 *data; > >> } > >> > >> struct dsi_ops { > >> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); > >> ... > >> } Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI transmitter drivers need to iterate over the commands manually ? In the later case a lower-level API might be easier to implement in DSI transmitter drivers. Helper functions could provide the higher-level API you proposed. > > Yes, this should be flexible enough to cover most of (or even whole) DSI > > specification. > > > > However I'm not sure whether the dsi_write name would be appropriate, > > since DSI packet types include also read and special transactions. So, > > according to DSI terminology, maybe dsi_transaction would be better? Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions ? > I think read should still be separate. At least on my HW read and write > are quite different. But all "transactions" are very much the same in HW > setup. The ... was dsi_write etc ;) Like set_max_packet_size should > maybe be an ops. Since only the implementer of the "video source" will > know what the max read return packet size for that DSI IP is. The panels > don't know that. Maybe another ops to retrieve some info about the caps > of the video source would help that. Then a helper could call that and > then the dsi_write one. If panels (or helper functions) need information about the DSI transmitter capabilities, sure, we can add an op. > >> And I think I still prefer the dsi_bus in favor of the abstract video > >> source. It just looks like a home made bus with bus-ops ... can't you do > >> something similar using the normal driver framework? enable/disable > >> looks like suspend/resume, register/unregister_vid_src is like > >> bus_(un)register_device, ... the video source anyway seems unattached > >> to the panel stuff with the find_video_source call. The Linux driver framework is based on control busses. DSI usually handles both control and video transfer, but the control and data busses can also be separate (think DPI + SPI/I2C for instance). In that case the panel will be a child of its control bus master, and will need a separate interface to access video data operations. As a separate video interface is thus needed, I think we should use it for DSI as well. My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI and DSI can be used interchangeably in this discussions, they both share the caracteristic of having a common control + data bus), and panels were children of the DBI bus master. The DBI bus API was only used for control, not for data transfers. Tomi then removed the DBI bus and moved the control operations to the video source, turning the DBI panels into platform devices. I still favor my initial approach, but I can agree to drop the DBI bus if there's a consensus on that. Video bus operations will be separate in any case. > > DSI needs specific power management. It's necessary to power up the panel > > first to make it wait for Tinit event and then enable DSI master to > > trigger such event. Only then rest of panel initialization can be > > completed. > > I know, we have a very complex sequence for our HDMI encoder which uses > sort of continuous DSI cmmand mode. And power/clock on sequences are > tricky to get right in our current "CDF" API (mcde_display). But I fail > to see how the current video source API is different from just using the > bus/device APIs. As mentioned above, the video source API handles video transfers, while the bus/device API handles control transfers. Operations such as "start the video stream" will thus be video source APIs. Operations such as "enable the DSI master", used to trigger the Tinit event (whatever that is :-)) at power up time would probably be DSI bus operations. > > Also, as discussed in previous posts, some panels might use DSI only for > > video data and another interface (I2C, SPI) for control data. In such case > > it would be impossible to represent such device in a reasonable way using > > current driver model. > > I understand that you need to get hold of both the control and data bus > device in the driver. (Toshiba DSI-LVDS bridge is a good example and > commonly used "encoder" that can use both DSI and I2C control interface.) > But the control bus you get from device probe, and I guess you could call > bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which > will have access to dsi bus ops just as you call > find_video_source("mysource") to access the "databus" ops directly with > a logical device (display entity). > I'm not saying I would refuse to use video sources. I just think the two > models are so similar so it would be worth exploring how a device model > style API would look like and to compare against. I don't think we should use the Linux device model for data busses. It hasn't been designed for that use case, and definitely doesn't support devices that would be children of two separate masters (control and data). For shared bus devices such as DSI, having a DSI bus was my preference to start with, as mentioned above :-) However, even in that case, I think it would still make sense to use video sources to control the video operations. As usual the devil is in the details, so there will probably be some tricky problems we'll need to solve, but that will require coding the proposed solution. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-01 23:35 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:35 UTC (permalink / raw) To: Marcus Lorentzon Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Marcus, On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: > On 01/08/2013 05:36 PM, Tomasz Figa wrote: > > On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: [snip] > >> FYI, > >> here is STE "DSI API": > >> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f > >> =include/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD > >> #l361 Thank you. > >> But it is not perfect. After a couple of products we realized that most > >> panel drivers want an easy way to send a bunch of init commands in one > >> go. So I think it should be an op for sending an array of commands at > >> once. Something like > >> > >> struct dsi_cmd { > >> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ > >> u8 cmd; > >> int dataLen; > >> u8 *data; > >> } > >> > >> struct dsi_ops { > >> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); > >> ... > >> } Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI transmitter drivers need to iterate over the commands manually ? In the later case a lower-level API might be easier to implement in DSI transmitter drivers. Helper functions could provide the higher-level API you proposed. > > Yes, this should be flexible enough to cover most of (or even whole) DSI > > specification. > > > > However I'm not sure whether the dsi_write name would be appropriate, > > since DSI packet types include also read and special transactions. So, > > according to DSI terminology, maybe dsi_transaction would be better? Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions ? > I think read should still be separate. At least on my HW read and write > are quite different. But all "transactions" are very much the same in HW > setup. The ... was dsi_write etc ;) Like set_max_packet_size should > maybe be an ops. Since only the implementer of the "video source" will > know what the max read return packet size for that DSI IP is. The panels > don't know that. Maybe another ops to retrieve some info about the caps > of the video source would help that. Then a helper could call that and > then the dsi_write one. If panels (or helper functions) need information about the DSI transmitter capabilities, sure, we can add an op. > >> And I think I still prefer the dsi_bus in favor of the abstract video > >> source. It just looks like a home made bus with bus-ops ... can't you do > >> something similar using the normal driver framework? enable/disable > >> looks like suspend/resume, register/unregister_vid_src is like > >> bus_(un)register_device, ... the video source anyway seems unattached > >> to the panel stuff with the find_video_source call. The Linux driver framework is based on control busses. DSI usually handles both control and video transfer, but the control and data busses can also be separate (think DPI + SPI/I2C for instance). In that case the panel will be a child of its control bus master, and will need a separate interface to access video data operations. As a separate video interface is thus needed, I think we should use it for DSI as well. My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI and DSI can be used interchangeably in this discussions, they both share the caracteristic of having a common control + data bus), and panels were children of the DBI bus master. The DBI bus API was only used for control, not for data transfers. Tomi then removed the DBI bus and moved the control operations to the video source, turning the DBI panels into platform devices. I still favor my initial approach, but I can agree to drop the DBI bus if there's a consensus on that. Video bus operations will be separate in any case. > > DSI needs specific power management. It's necessary to power up the panel > > first to make it wait for Tinit event and then enable DSI master to > > trigger such event. Only then rest of panel initialization can be > > completed. > > I know, we have a very complex sequence for our HDMI encoder which uses > sort of continuous DSI cmmand mode. And power/clock on sequences are > tricky to get right in our current "CDF" API (mcde_display). But I fail > to see how the current video source API is different from just using the > bus/device APIs. As mentioned above, the video source API handles video transfers, while the bus/device API handles control transfers. Operations such as "start the video stream" will thus be video source APIs. Operations such as "enable the DSI master", used to trigger the Tinit event (whatever that is :-)) at power up time would probably be DSI bus operations. > > Also, as discussed in previous posts, some panels might use DSI only for > > video data and another interface (I2C, SPI) for control data. In such case > > it would be impossible to represent such device in a reasonable way using > > current driver model. > > I understand that you need to get hold of both the control and data bus > device in the driver. (Toshiba DSI-LVDS bridge is a good example and > commonly used "encoder" that can use both DSI and I2C control interface.) > But the control bus you get from device probe, and I guess you could call > bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which > will have access to dsi bus ops just as you call > find_video_source("mysource") to access the "databus" ops directly with > a logical device (display entity). > I'm not saying I would refuse to use video sources. I just think the two > models are so similar so it would be worth exploring how a device model > style API would look like and to compare against. I don't think we should use the Linux device model for data busses. It hasn't been designed for that use case, and definitely doesn't support devices that would be children of two separate masters (control and data). For shared bus devices such as DSI, having a DSI bus was my preference to start with, as mentioned above :-) However, even in that case, I think it would still make sense to use video sources to control the video operations. As usual the devil is in the details, so there will probably be some tricky problems we'll need to solve, but that will require coding the proposed solution. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-02-01 23:35 ` Laurent Pinchart @ 2013-02-04 10:05 ` Marcus Lorentzon -1 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-02-04 10:05 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 02/02/2013 12:35 AM, Laurent Pinchart wrote: > Hi Marcus, > > On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: >> On 01/08/2013 05:36 PM, Tomasz Figa wrote: >>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: [...] >>>> But it is not perfect. After a couple of products we realized that most >>>> panel drivers want an easy way to send a bunch of init commands in one >>>> go. So I think it should be an op for sending an array of commands at >>>> once. Something like >>>> >>>> struct dsi_cmd { >>>> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >>>> u8 cmd; >>>> int dataLen; >>>> u8 *data; >>>> } >>>> >>>> struct dsi_ops { >>>> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >>>> ... >>>> } > Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI > transmitter drivers need to iterate over the commands manually ? In the later > case a lower-level API might be easier to implement in DSI transmitter > drivers. Helper functions could provide the higher-level API you proposed. The HW has a FIFO, so it can handle a few. Currently we use the low level type of call with one call per command. But we have found DSI command mode panels that don't accept any commands during the "update" (write start+continues). And so we must use a mutex/state machine to exclude any async calls to send DSI commands during update. But if you need to send more than one command per frame this will be hard (like CABC and backlight commands). It will be a ping pong between update and command calls. One option is to expose the mutex to the caller so it can make many calls before the next update grabs the mutex again. So maybe we could create a helper that handle the op for list of commands and another op for single command that you actually have to implement. >>> Yes, this should be flexible enough to cover most of (or even whole) DSI >>> specification. >>> >>> However I'm not sure whether the dsi_write name would be appropriate, >>> since DSI packet types include also read and special transactions. So, >>> according to DSI terminology, maybe dsi_transaction would be better? > Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions > ? No transactions. And I don't want to mix reads and writes. It should be similar to I2C and other stream control busses. So one read and one write should be fine. And then a bunch of helpers on top for callers to use, like one per major DSI packet type. >> I think read should still be separate. At least on my HW read and write >> are quite different. But all "transactions" are very much the same in HW >> setup. The ... was dsi_write etc ;) Like set_max_packet_size should >> maybe be an ops. Since only the implementer of the "video source" will >> know what the max read return packet size for that DSI IP is. The panels >> don't know that. Maybe another ops to retrieve some info about the caps >> of the video source would help that. Then a helper could call that and >> then the dsi_write one. > If panels (or helper functions) need information about the DSI transmitter > capabilities, sure, we can add an op. Yes, a "video source" op for getting caps would be ok too. But so far the only limits I have found is the read/write sizes. But if anyone else has other limits, please list them so we could add them to this struct dsi_host_caps. >>>> And I think I still prefer the dsi_bus in favor of the abstract video >>>> source. It just looks like a home made bus with bus-ops ... can't you do >>>> something similar using the normal driver framework? enable/disable >>>> looks like suspend/resume, register/unregister_vid_src is like >>>> bus_(un)register_device, ... the video source anyway seems unattached >>>> to the panel stuff with the find_video_source call. > The Linux driver framework is based on control busses. DSI usually handles > both control and video transfer, but the control and data busses can also be > separate (think DPI + SPI/I2C for instance). In that case the panel will be a > child of its control bus master, and will need a separate interface to access > video data operations. As a separate video interface is thus needed, I think > we should use it for DSI as well. > > My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI > and DSI can be used interchangeably in this discussions, they both share the > caracteristic of having a common control + data bus), and panels were children > of the DBI bus master. The DBI bus API was only used for control, not for data > transfers. Tomi then removed the DBI bus and moved the control operations to > the video source, turning the DBI panels into platform devices. I still favor > my initial approach, but I can agree to drop the DBI bus if there's a > consensus on that. Video bus operations will be separate in any case. As discussed at FOSDEM I will give DSI bus with full feature set a try. BTW. Who got the action to ask Greg about devices with multiple parents/buses? >>> Also, as discussed in previous posts, some panels might use DSI only for >>> video data and another interface (I2C, SPI) for control data. In such case >>> it would be impossible to represent such device in a reasonable way using >>> current driver model. >> I understand that you need to get hold of both the control and data bus >> device in the driver. (Toshiba DSI-LVDS bridge is a good example and >> commonly used "encoder" that can use both DSI and I2C control interface.) >> But the control bus you get from device probe, and I guess you could call >> bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which >> will have access to dsi bus ops just as you call >> find_video_source("mysource") to access the "databus" ops directly with >> a logical device (display entity). >> I'm not saying I would refuse to use video sources. I just think the two >> models are so similar so it would be worth exploring how a device model >> style API would look like and to compare against. > I don't think we should use the Linux device model for data busses. It hasn't > been designed for that use case, and definitely doesn't support devices that > would be children of two separate masters (control and data). For shared bus > devices such as DSI, having a DSI bus was my preference to start with, as > mentioned above :-) However, even in that case, I think it would still make > sense to use video sources to control the video operations. As usual the devil > is in the details, so there will probably be some tricky problems we'll need > to solve, but that will require coding the proposed solution. > I will give it a try after asking Greg for guidelines. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-04 10:05 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-02-04 10:05 UTC (permalink / raw) To: Laurent Pinchart Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 02/02/2013 12:35 AM, Laurent Pinchart wrote: > Hi Marcus, > > On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: >> On 01/08/2013 05:36 PM, Tomasz Figa wrote: >>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: [...] >>>> But it is not perfect. After a couple of products we realized that most >>>> panel drivers want an easy way to send a bunch of init commands in one >>>> go. So I think it should be an op for sending an array of commands at >>>> once. Something like >>>> >>>> struct dsi_cmd { >>>> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >>>> u8 cmd; >>>> int dataLen; >>>> u8 *data; >>>> } >>>> >>>> struct dsi_ops { >>>> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >>>> ... >>>> } > Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI > transmitter drivers need to iterate over the commands manually ? In the later > case a lower-level API might be easier to implement in DSI transmitter > drivers. Helper functions could provide the higher-level API you proposed. The HW has a FIFO, so it can handle a few. Currently we use the low level type of call with one call per command. But we have found DSI command mode panels that don't accept any commands during the "update" (write start+continues). And so we must use a mutex/state machine to exclude any async calls to send DSI commands during update. But if you need to send more than one command per frame this will be hard (like CABC and backlight commands). It will be a ping pong between update and command calls. One option is to expose the mutex to the caller so it can make many calls before the next update grabs the mutex again. So maybe we could create a helper that handle the op for list of commands and another op for single command that you actually have to implement. >>> Yes, this should be flexible enough to cover most of (or even whole) DSI >>> specification. >>> >>> However I'm not sure whether the dsi_write name would be appropriate, >>> since DSI packet types include also read and special transactions. So, >>> according to DSI terminology, maybe dsi_transaction would be better? > Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions > ? No transactions. And I don't want to mix reads and writes. It should be similar to I2C and other stream control busses. So one read and one write should be fine. And then a bunch of helpers on top for callers to use, like one per major DSI packet type. >> I think read should still be separate. At least on my HW read and write >> are quite different. But all "transactions" are very much the same in HW >> setup. The ... was dsi_write etc ;) Like set_max_packet_size should >> maybe be an ops. Since only the implementer of the "video source" will >> know what the max read return packet size for that DSI IP is. The panels >> don't know that. Maybe another ops to retrieve some info about the caps >> of the video source would help that. Then a helper could call that and >> then the dsi_write one. > If panels (or helper functions) need information about the DSI transmitter > capabilities, sure, we can add an op. Yes, a "video source" op for getting caps would be ok too. But so far the only limits I have found is the read/write sizes. But if anyone else has other limits, please list them so we could add them to this struct dsi_host_caps. >>>> And I think I still prefer the dsi_bus in favor of the abstract video >>>> source. It just looks like a home made bus with bus-ops ... can't you do >>>> something similar using the normal driver framework? enable/disable >>>> looks like suspend/resume, register/unregister_vid_src is like >>>> bus_(un)register_device, ... the video source anyway seems unattached >>>> to the panel stuff with the find_video_source call. > The Linux driver framework is based on control busses. DSI usually handles > both control and video transfer, but the control and data busses can also be > separate (think DPI + SPI/I2C for instance). In that case the panel will be a > child of its control bus master, and will need a separate interface to access > video data operations. As a separate video interface is thus needed, I think > we should use it for DSI as well. > > My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI > and DSI can be used interchangeably in this discussions, they both share the > caracteristic of having a common control + data bus), and panels were children > of the DBI bus master. The DBI bus API was only used for control, not for data > transfers. Tomi then removed the DBI bus and moved the control operations to > the video source, turning the DBI panels into platform devices. I still favor > my initial approach, but I can agree to drop the DBI bus if there's a > consensus on that. Video bus operations will be separate in any case. As discussed at FOSDEM I will give DSI bus with full feature set a try. BTW. Who got the action to ask Greg about devices with multiple parents/buses? >>> Also, as discussed in previous posts, some panels might use DSI only for >>> video data and another interface (I2C, SPI) for control data. In such case >>> it would be impossible to represent such device in a reasonable way using >>> current driver model. >> I understand that you need to get hold of both the control and data bus >> device in the driver. (Toshiba DSI-LVDS bridge is a good example and >> commonly used "encoder" that can use both DSI and I2C control interface.) >> But the control bus you get from device probe, and I guess you could call >> bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which >> will have access to dsi bus ops just as you call >> find_video_source("mysource") to access the "databus" ops directly with >> a logical device (display entity). >> I'm not saying I would refuse to use video sources. I just think the two >> models are so similar so it would be worth exploring how a device model >> style API would look like and to compare against. > I don't think we should use the Linux device model for data busses. It hasn't > been designed for that use case, and definitely doesn't support devices that > would be children of two separate masters (control and data). For shared bus > devices such as DSI, having a DSI bus was my preference to start with, as > mentioned above :-) However, even in that case, I think it would still make > sense to use video sources to control the video operations. As usual the devil > is in the details, so there will probably be some tricky problems we'll need > to solve, but that will require coding the proposed solution. > I will give it a try after asking Greg for guidelines. /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-02-04 10:05 ` Marcus Lorentzon @ 2013-02-06 9:52 ` Archit Taneja -1 siblings, 0 replies; 153+ messages in thread From: Archit Taneja @ 2013-02-06 9:52 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Vikas Sajjan, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote: > On 02/02/2013 12:35 AM, Laurent Pinchart wrote: >> Hi Marcus, >> >> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: >>> On 01/08/2013 05:36 PM, Tomasz Figa wrote: >>>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: > [...] >>>>> But it is not perfect. After a couple of products we realized that >>>>> most >>>>> panel drivers want an easy way to send a bunch of init commands in one >>>>> go. So I think it should be an op for sending an array of commands at >>>>> once. Something like >>>>> >>>>> struct dsi_cmd { >>>>> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >>>>> u8 cmd; >>>>> int dataLen; >>>>> u8 *data; >>>>> } >>>>> >>>>> struct dsi_ops { >>>>> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >>>>> ... >>>>> } >> Do you have DSI IP(s) that can handle a list of commands ? Or would >> all DSI >> transmitter drivers need to iterate over the commands manually ? In >> the later >> case a lower-level API might be easier to implement in DSI transmitter >> drivers. Helper functions could provide the higher-level API you >> proposed. > > The HW has a FIFO, so it can handle a few. Currently we use the low > level type of call with one call per command. But we have found DSI > command mode panels that don't accept any commands during the "update" > (write start+continues). And so we must use a mutex/state machine to > exclude any async calls to send DSI commands during update. But if you > need to send more than one command per frame this will be hard (like > CABC and backlight commands). It will be a ping pong between update and > command calls. One option is to expose the mutex to the caller so it can > make many calls before the next update grabs the mutex again. > So maybe we could create a helper that handle the op for list of > commands and another op for single command that you actually have to > implement. fyi, the DSI IP on OMAP3+ SoCs also has a FIFO. It can provide interrupts after each command is pushed out, and also when the FIFO gets empty(all commands are pushed). The only thing to take care is to not overflow FIFO. DSI video mode panels generally have a few dozen internal registers which need to be configured via DSI commands. It's more fast(and convenient) to configure a handful of internal registers in one shot, and then perform a single BTA to know from the panel whether the commands were received correctly. Regards, Archit ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-06 9:52 ` Archit Taneja 0 siblings, 0 replies; 153+ messages in thread From: Archit Taneja @ 2013-02-06 9:52 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Vikas Sajjan, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark, Ragesh Radhakrishnan, Tomi Valkeinen, Bryan Wu, Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec, linux-media On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote: > On 02/02/2013 12:35 AM, Laurent Pinchart wrote: >> Hi Marcus, >> >> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote: >>> On 01/08/2013 05:36 PM, Tomasz Figa wrote: >>>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote: > [...] >>>>> But it is not perfect. After a couple of products we realized that >>>>> most >>>>> panel drivers want an easy way to send a bunch of init commands in one >>>>> go. So I think it should be an op for sending an array of commands at >>>>> once. Something like >>>>> >>>>> struct dsi_cmd { >>>>> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ >>>>> u8 cmd; >>>>> int dataLen; >>>>> u8 *data; >>>>> } >>>>> >>>>> struct dsi_ops { >>>>> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); >>>>> ... >>>>> } >> Do you have DSI IP(s) that can handle a list of commands ? Or would >> all DSI >> transmitter drivers need to iterate over the commands manually ? In >> the later >> case a lower-level API might be easier to implement in DSI transmitter >> drivers. Helper functions could provide the higher-level API you >> proposed. > > The HW has a FIFO, so it can handle a few. Currently we use the low > level type of call with one call per command. But we have found DSI > command mode panels that don't accept any commands during the "update" > (write start+continues). And so we must use a mutex/state machine to > exclude any async calls to send DSI commands during update. But if you > need to send more than one command per frame this will be hard (like > CABC and backlight commands). It will be a ping pong between update and > command calls. One option is to expose the mutex to the caller so it can > make many calls before the next update grabs the mutex again. > So maybe we could create a helper that handle the op for list of > commands and another op for single command that you actually have to > implement. fyi, the DSI IP on OMAP3+ SoCs also has a FIFO. It can provide interrupts after each command is pushed out, and also when the FIFO gets empty(all commands are pushed). The only thing to take care is to not overflow FIFO. DSI video mode panels generally have a few dozen internal registers which need to be configured via DSI commands. It's more fast(and convenient) to configure a handful of internal registers in one shot, and then perform a single BTA to know from the panel whether the commands were received correctly. Regards, Archit ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-02-04 10:05 ` Marcus Lorentzon @ 2013-02-08 10:51 ` Tomi Valkeinen -1 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2013-02-08 10:51 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 938 bytes --] On 2013-02-04 12:05, Marcus Lorentzon wrote: > As discussed at FOSDEM I will give DSI bus with full feature set a > try. Please do, but as a reminder I want to raise the issues I see with a DSI bus: - A device can be a child of only one bus. So if DSI is used only for video, the device is a child of, say, i2c bus, and thus there's no DSI bus. How to configure and use DSI in this case? - If DSI is used for both control and video, we have two separate APIs for the bus. What I mean here is that for the video-only case above, we need a video-only-API for DSI. This API should contain all necessary methods to configure DSI. But we need similar methods for the control API also. So, I hope you come up with some solution for this, but as I see it, it's easily the most simple and clear option to have one video_source style entity for the DSI bus itself, which is used for both control and video. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-08 10:51 ` Tomi Valkeinen 0 siblings, 0 replies; 153+ messages in thread From: Tomi Valkeinen @ 2013-02-08 10:51 UTC (permalink / raw) To: Marcus Lorentzon Cc: Laurent Pinchart, Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1: Type: text/plain, Size: 938 bytes --] On 2013-02-04 12:05, Marcus Lorentzon wrote: > As discussed at FOSDEM I will give DSI bus with full feature set a > try. Please do, but as a reminder I want to raise the issues I see with a DSI bus: - A device can be a child of only one bus. So if DSI is used only for video, the device is a child of, say, i2c bus, and thus there's no DSI bus. How to configure and use DSI in this case? - If DSI is used for both control and video, we have two separate APIs for the bus. What I mean here is that for the video-only case above, we need a video-only-API for DSI. This API should contain all necessary methods to configure DSI. But we need similar methods for the control API also. So, I hope you come up with some solution for this, but as I see it, it's easily the most simple and clear option to have one video_source style entity for the DSI bus itself, which is used for both control and video. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-02-08 10:51 ` Tomi Valkeinen @ 2013-02-08 12:43 ` Marcus Lorentzon -1 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-02-08 12:43 UTC (permalink / raw) To: Tomi Valkeinen Cc: Laurent Pinchart, Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 02/08/2013 11:51 AM, Tomi Valkeinen wrote: > On 2013-02-04 12:05, Marcus Lorentzon wrote: > >> As discussed at FOSDEM I will give DSI bus with full feature set a >> try. > Please do, but as a reminder I want to raise the issues I see with a DSI > bus: > > - A device can be a child of only one bus. So if DSI is used only for > video, the device is a child of, say, i2c bus, and thus there's no DSI > bus. How to configure and use DSI in this case? > > - If DSI is used for both control and video, we have two separate APIs > for the bus. What I mean here is that for the video-only case above, we > need a video-only-API for DSI. This API should contain all necessary > methods to configure DSI. But we need similar methods for the control > API also. > > So, I hope you come up with some solution for this, but as I see it, > it's easily the most simple and clear option to have one video_source > style entity for the DSI bus itself, which is used for both control and > video. > > Thanks, it is not that I'm totally against the video source stuff. And I share your concerns, none of the solutions are perfect. It just doesn't feel right to create this dummy source "device" without investigating the DSI bus route. But I will try to write up some history/problem description and ask Greg KH for guidance. If he has a strong opinion either way, there is not much more to discuss ;) /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-08 12:43 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2013-02-08 12:43 UTC (permalink / raw) To: Tomi Valkeinen Cc: Laurent Pinchart, Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 02/08/2013 11:51 AM, Tomi Valkeinen wrote: > On 2013-02-04 12:05, Marcus Lorentzon wrote: > >> As discussed at FOSDEM I will give DSI bus with full feature set a >> try. > Please do, but as a reminder I want to raise the issues I see with a DSI > bus: > > - A device can be a child of only one bus. So if DSI is used only for > video, the device is a child of, say, i2c bus, and thus there's no DSI > bus. How to configure and use DSI in this case? > > - If DSI is used for both control and video, we have two separate APIs > for the bus. What I mean here is that for the video-only case above, we > need a video-only-API for DSI. This API should contain all necessary > methods to configure DSI. But we need similar methods for the control > API also. > > So, I hope you come up with some solution for this, but as I see it, > it's easily the most simple and clear option to have one video_source > style entity for the DSI bus itself, which is used for both control and > video. > > Thanks, it is not that I'm totally against the video source stuff. And I share your concerns, none of the solutions are perfect. It just doesn't feel right to create this dummy source "device" without investigating the DSI bus route. But I will try to write up some history/problem description and ask Greg KH for guidance. If he has a strong opinion either way, there is not much more to discuss ;) /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 10:12 ` Marcus Lorentzon @ 2013-02-01 23:37 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:37 UTC (permalink / raw) To: Marcus Lorentzon Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Marcus, On Tuesday 08 January 2013 11:12:26 Marcus Lorentzon wrote: [snip] > I also looked at the video source in Tomi's git tree > (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/inc > lude/video/display.h). I think I would prefer a single "setup" op taking a > "struct dsi_config" as argument. Then each DSI formatter/encoder driver > could decide best way to set that up. We have something similar at > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=inc > lude/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l118 A single setup function indeed seems easier, but I don't have enough experience with DSI to have a strong opinion on that. We'll have to compare implementations if there's a disagreement on this. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-01 23:37 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:37 UTC (permalink / raw) To: Marcus Lorentzon Cc: Tomasz Figa, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, sunil joshi, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Marcus, On Tuesday 08 January 2013 11:12:26 Marcus Lorentzon wrote: [snip] > I also looked at the video source in Tomi's git tree > (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/inc > lude/video/display.h). I think I would prefer a single "setup" op taking a > "struct dsi_config" as argument. Then each DSI formatter/encoder driver > could decide best way to set that up. We have something similar at > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=inc > lude/video/mcde.h;hI9ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l118 A single setup function indeed seems easier, but I don't have enough experience with DSI to have a strong opinion on that. We'll have to compare implementations if there's a disagreement on this. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 3:01 ` Vikas Sajjan @ 2012-12-24 12:59 ` Laurent Pinchart 2012-12-21 10:00 ` Tomasz Figa 2012-12-24 12:59 ` Laurent Pinchart 2 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:00 UTC (permalink / raw) To: Vikas Sajjan Cc: Jesse Barker, Ragesh Radhakrishnan, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Sumit Semwal, Sebastien Guiriec, linux-media, sunil joshi Hi Vikas, On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote: > On 17 December 2012 20:55, Laurent Pinchart wrote: > > Hi Vikas, > > > > Sorry for the late reply. I now have more time to work on CDF, so delays > > should be much shorter. > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > Hi Laurent, > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I > > > found is that, the exynos display controller is MIPI DSI based > > > controller. > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > Display controller. > > > > > > So my question is, do we have any generic framework for MIPI DSI based > > > display controller? basically I wanted to know, how to go about porting > > > CDF for such kind of display controller. > > > > MIPI DSI support is not available yet. The only reason for that is that I > > don't have any MIPI DSI hardware to write and test the code with :-) > > > > The common display framework should definitely support MIPI DSI. I think > > the existing MIPI DBI code could be used as a base, so the implementation > > shouldn't be too high. > > > > Yeah, i was also thinking in similar lines, below is my though for MIPI > > DSI support in CDF. > > o MIPI DSI support as part of CDF framework will expose > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > file) > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > platform specific init driver call ) > · bus ops will be > o read data > o write data > o write command > § MIPI DSI will be registered as bus_register() > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > initialize the MIPI DSI HW IP. > > This probe will also parse the DT file for MIPI DSI based panel, add > the panel device (device_add() ) to kernel and register the display > entity with its control and video ops with CDF. After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that creating a real bus for DBI and DSI, although possible, wasn't required. DSI operations should thus be provided through display entity video source operations. You can find a proposed implementation in Tomi's patch set. > > I can give this a try. Does the existing Exynos 5250 driver support MIPI > > DSI ? Is the device documentation publicly available ? Can you point me to > > a MIPI DSI panel with public documentation (preferably with an existing > > mainline driver if possible) ? > > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. > > i think device documentation is NOT available publicly. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 12:59 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 12:59 UTC (permalink / raw) To: Vikas Sajjan Cc: Jesse Barker, Ragesh Radhakrishnan, Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, dri-devel, Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Sumit Semwal, Sebastien Guiriec, linux-media, sunil joshi Hi Vikas, On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote: > On 17 December 2012 20:55, Laurent Pinchart wrote: > > Hi Vikas, > > > > Sorry for the late reply. I now have more time to work on CDF, so delays > > should be much shorter. > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > Hi Laurent, > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I > > > found is that, the exynos display controller is MIPI DSI based > > > controller. > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > Display controller. > > > > > > So my question is, do we have any generic framework for MIPI DSI based > > > display controller? basically I wanted to know, how to go about porting > > > CDF for such kind of display controller. > > > > MIPI DSI support is not available yet. The only reason for that is that I > > don't have any MIPI DSI hardware to write and test the code with :-) > > > > The common display framework should definitely support MIPI DSI. I think > > the existing MIPI DBI code could be used as a base, so the implementation > > shouldn't be too high. > > > > Yeah, i was also thinking in similar lines, below is my though for MIPI > > DSI support in CDF. > > o MIPI DSI support as part of CDF framework will expose > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > file) > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > platform specific init driver call ) > · bus ops will be > o read data > o write data > o write command > § MIPI DSI will be registered as bus_register() > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > initialize the MIPI DSI HW IP. > > This probe will also parse the DT file for MIPI DSI based panel, add > the panel device (device_add() ) to kernel and register the display > entity with its control and video ops with CDF. After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that creating a real bus for DBI and DSI, although possible, wasn't required. DSI operations should thus be provided through display entity video source operations. You can find a proposed implementation in Tomi's patch set. > > I can give this a try. Does the existing Exynos 5250 driver support MIPI > > DSI ? Is the device documentation publicly available ? Can you point me to > > a MIPI DSI panel with public documentation (preferably with an existing > > mainline driver if possible) ? > > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. > > i think device documentation is NOT available publicly. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-11-22 21:45 ` Laurent Pinchart (?) @ 2012-12-18 5:04 ` Dave Airlie -1 siblings, 0 replies; 153+ messages in thread From: Dave Airlie @ 2012-12-18 5:04 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 5:04 ` Dave Airlie 0 siblings, 0 replies; 153+ messages in thread From: Dave Airlie @ 2012-12-18 5:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 5:04 ` Dave Airlie 0 siblings, 0 replies; 153+ messages in thread From: Dave Airlie @ 2012-12-18 5:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media > > Many developers showed interest in the first RFC, and I've had the opportunity > to discuss it with most of them. I would like to thank (in no particular > order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus > Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for > inviting me to Connect and providing a venue to discuss this topic. > So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are "shared" with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 5:04 ` Dave Airlie @ 2012-12-18 6:21 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-18 6:21 UTC (permalink / raw) To: Dave Airlie Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> Many developers showed interest in the first RFC, and I've had the opportunity >> to discuss it with most of them. I would like to thank (in no particular >> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >> inviting me to Connect and providing a venue to discuss this topic. >> > > So this might be a bit off topic but this whole CDF triggered me > looking at stuff I generally avoid: > > The biggest problem I'm having currently with the whole ARM graphics > and output world is the proliferation of platform drivers for every > little thing. The whole ordering of operations with respect to things > like suspend/resume or dynamic power management is going to be a real > nightmare if there are dependencies between the drivers. How do you > enforce ordering of s/r operations between all the various components? I tend to think that sub-devices are useful just to have a way to probe hw which may or may not be there, since on ARM we often don't have any alternative.. but beyond that, suspend/resume, and other life-cycle aspects, they should really be treated as all one device. Especially to avoid undefined suspend/resume ordering. CDF or some sort of mechanism to share panel drivers between drivers is useful. Keeping it within drm, is probably a good idea, if nothing else to simplify re-use of helper fxns (like avi-infoframe stuff, for example) and avoid dealing with merging changes across multiple trees. Treating them more like shared libraries and less like sub-devices which can be dynamically loaded/unloaded (ie. they should be not built as separate modules or suspend/resumed or probed/removed independently of the master driver) is a really good idea to avoid uncovering nasty synchronization issues later (remove vs modeset or pageflip) or surprising userspace in bad ways. > The other thing I'd like you guys to do is kill the idea of fbdev and > v4l drivers that are "shared" with the drm codebase, really just > implement fbdev and v4l on top of the drm layer, some people might > think this is some sort of maintainer thing, but really nothing else > makes sense, and having these shared display frameworks just to avoid > having using drm/kms drivers seems totally pointless. Fix the drm > fbdev emulation if an fbdev interface is needed. But creating a fourth > framework because our previous 3 frameworks didn't work out doesn't > seem like a situation I want to get behind too much. yeah, let's not have multiple frameworks to do the same thing.. For fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is perhaps bit more flexible when it comes to random arbitrary hw pipelines than kms. But to take advantage of that, your userspace isn't going to be portable anyways, so you might as well use driver specific properties/ioctls. But I tend to think that is more useful for cameras. And from userspace perspective, kms planes are less painful to use for output than v4l2, so lets stick to drm/kms for output (and not try to add camera/capture support to kms).. k, thx BR, -R > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 6:21 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-18 6:21 UTC (permalink / raw) To: Dave Airlie Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> Many developers showed interest in the first RFC, and I've had the opportunity >> to discuss it with most of them. I would like to thank (in no particular >> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >> inviting me to Connect and providing a venue to discuss this topic. >> > > So this might be a bit off topic but this whole CDF triggered me > looking at stuff I generally avoid: > > The biggest problem I'm having currently with the whole ARM graphics > and output world is the proliferation of platform drivers for every > little thing. The whole ordering of operations with respect to things > like suspend/resume or dynamic power management is going to be a real > nightmare if there are dependencies between the drivers. How do you > enforce ordering of s/r operations between all the various components? I tend to think that sub-devices are useful just to have a way to probe hw which may or may not be there, since on ARM we often don't have any alternative.. but beyond that, suspend/resume, and other life-cycle aspects, they should really be treated as all one device. Especially to avoid undefined suspend/resume ordering. CDF or some sort of mechanism to share panel drivers between drivers is useful. Keeping it within drm, is probably a good idea, if nothing else to simplify re-use of helper fxns (like avi-infoframe stuff, for example) and avoid dealing with merging changes across multiple trees. Treating them more like shared libraries and less like sub-devices which can be dynamically loaded/unloaded (ie. they should be not built as separate modules or suspend/resumed or probed/removed independently of the master driver) is a really good idea to avoid uncovering nasty synchronization issues later (remove vs modeset or pageflip) or surprising userspace in bad ways. > The other thing I'd like you guys to do is kill the idea of fbdev and > v4l drivers that are "shared" with the drm codebase, really just > implement fbdev and v4l on top of the drm layer, some people might > think this is some sort of maintainer thing, but really nothing else > makes sense, and having these shared display frameworks just to avoid > having using drm/kms drivers seems totally pointless. Fix the drm > fbdev emulation if an fbdev interface is needed. But creating a fourth > framework because our previous 3 frameworks didn't work out doesn't > seem like a situation I want to get behind too much. yeah, let's not have multiple frameworks to do the same thing.. For fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is perhaps bit more flexible when it comes to random arbitrary hw pipelines than kms. But to take advantage of that, your userspace isn't going to be portable anyways, so you might as well use driver specific properties/ioctls. But I tend to think that is more useful for cameras. And from userspace perspective, kms planes are less painful to use for output than v4l2, so lets stick to drm/kms for output (and not try to add camera/capture support to kms).. k, thx BR, -R > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 6:21 ` Rob Clark @ 2012-12-18 8:30 ` Daniel Vetter -1 siblings, 0 replies; 153+ messages in thread From: Daniel Vetter @ 2012-12-18 8:30 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Laurent Pinchart, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx Yeah, I guess having a v4l device also exported by the same driver that exports the drm interface might make sense in some cases. But in many cases I think the video part is just an independent IP block and shuffling data around with dma-buf is all we really need. So yeah, I guess sharing display resources between v4l and drm kms driver should be a last resort option, since coordination (especially if it's supposed to be somewhat dynamic) will be extremely hairy. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 8:30 ` Daniel Vetter 0 siblings, 0 replies; 153+ messages in thread From: Daniel Vetter @ 2012-12-18 8:30 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Laurent Pinchart, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx Yeah, I guess having a v4l device also exported by the same driver that exports the drm interface might make sense in some cases. But in many cases I think the video part is just an independent IP block and shuffling data around with dma-buf is all we really need. So yeah, I guess sharing display resources between v4l and drm kms driver should be a last resort option, since coordination (especially if it's supposed to be somewhat dynamic) will be extremely hairy. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 8:30 ` Daniel Vetter (?) @ 2012-12-18 9:38 ` Inki Dae 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-24 14:08 ` Laurent Pinchart -1 siblings, 2 replies; 153+ messages in thread From: Inki Dae @ 2012-12-18 9:38 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, Laurent Pinchart, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media [-- Attachment #1.1: Type: text/plain, Size: 4539 bytes --] 2012/12/18 Daniel Vetter <daniel@ffwll.ch> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: > >> The other thing I'd like you guys to do is kill the idea of fbdev and > >> v4l drivers that are "shared" with the drm codebase, really just > >> implement fbdev and v4l on top of the drm layer, some people might > >> think this is some sort of maintainer thing, but really nothing else > >> makes sense, and having these shared display frameworks just to avoid > >> having using drm/kms drivers seems totally pointless. Fix the drm > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > >> framework because our previous 3 frameworks didn't work out doesn't > >> seem like a situation I want to get behind too much. > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > arbitrary hw pipelines than kms. But to take advantage of that, your > > userspace isn't going to be portable anyways, so you might as well use > > driver specific properties/ioctls. But I tend to think that is more > > useful for cameras. And from userspace perspective, kms planes are > > less painful to use for output than v4l2, so lets stick to drm/kms for > > output (and not try to add camera/capture support to kms).. k, thx > > Yeah, I guess having a v4l device also exported by the same driver > that exports the drm interface might make sense in some cases. But in > many cases I think the video part is just an independent IP block and > shuffling data around with dma-buf is all we really need. So yeah, I > guess sharing display resources between v4l and drm kms driver should > be a last resort option, since coordination (especially if it's > supposed to be somewhat dynamic) will be extremely hairy. > I think the one reason that the CDF was appeared is to avoid duplicating codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to avoid ordering issue. And for this, those should be re-implemented in based on drm framework so that those could be treated as all one device. Actually, in case of Exynos, some guys tried to duplicate eDP driver into exynos drm framework in same issue. So I think the best way is to avoid duplicating codes and resolve ordering issue such as s/r operations between all the various components. And the below is my opinion, ----------------------------------------------------- Display Controller-------------CDF---------------|MIPI-DSI/DBI---------------LCD Panel| ----------------------------------------------------- 1. to access MIPI-DSI/DBI and LCD Panel drivers. - Display Controller is controlled by linux framebuffer or drm kms based specific drivers like now. And each driver calls some interfaces of CDF. 2. to control the power of these devices. - drm kms based specific driver calls dpms operation and next the dpms operation calls fb blank operation of linux framebuffer. But for this, we need some interfaces that it can connect between drm and linux framebuffer framework and you can refer to the below link. http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html - linux framebuffer based driver calls fb blank operation. fb blank(fb)------------------pm runtime(fb)--------------------fb_blank----------mipi and lcd dpms(drm kms)------------pm runtime(drm kms)----------fb_blank----------mipi and lcd 3. suspend/resume - pm suspend/resume are implemented only in linux framebuffer or drm kms based specific drivers. - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank interfaces. s/r(fb)-----------------------------------------------pm runtime(fb)----------------fb blank-------mipi and lcd s/r(drm kms)--------dpms(drm kms)-------pm runtime(drm kms)------fb_blank------mipi and lcd We could resolve ordering issue to suspend/resume simply duplicating relevant drivers but couldn't avoid duplicating codes. So I think we could avoid the ordering issue using fb blank interface of linux framebuffer and also duplicating codes. Thanks, Inki Dae > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > [-- Attachment #1.2: Type: text/html, Size: 5869 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 9:38 ` Inki Dae @ 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-24 14:08 ` Laurent Pinchart 1 sibling, 0 replies; 153+ messages in thread From: Stéphane Marchesin @ 2012-12-19 20:13 UTC (permalink / raw) To: Inki Dae Cc: Daniel Vetter, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, Laurent Pinchart, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae <inki.dae@samsung.com> wrote: > > > 2012/12/18 Daniel Vetter <daniel@ffwll.ch> >> >> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: >> >> The other thing I'd like you guys to do is kill the idea of fbdev and >> >> v4l drivers that are "shared" with the drm codebase, really just >> >> implement fbdev and v4l on top of the drm layer, some people might >> >> think this is some sort of maintainer thing, but really nothing else >> >> makes sense, and having these shared display frameworks just to avoid >> >> having using drm/kms drivers seems totally pointless. Fix the drm >> >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> >> framework because our previous 3 frameworks didn't work out doesn't >> >> seem like a situation I want to get behind too much. >> > >> > yeah, let's not have multiple frameworks to do the same thing.. For >> > fbdev, it is pretty clear that it is a dead end. For v4l2 >> > (subdev+mcf), it is perhaps bit more flexible when it comes to random >> > arbitrary hw pipelines than kms. But to take advantage of that, your >> > userspace isn't going to be portable anyways, so you might as well use >> > driver specific properties/ioctls. But I tend to think that is more >> > useful for cameras. And from userspace perspective, kms planes are >> > less painful to use for output than v4l2, so lets stick to drm/kms for >> > output (and not try to add camera/capture support to kms).. k, thx >> >> Yeah, I guess having a v4l device also exported by the same driver >> that exports the drm interface might make sense in some cases. But in >> many cases I think the video part is just an independent IP block and >> shuffling data around with dma-buf is all we really need. So yeah, I >> guess sharing display resources between v4l and drm kms driver should >> be a last resort option, since coordination (especially if it's >> supposed to be somewhat dynamic) will be extremely hairy. > > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. Actually, > in case of Exynos, some guys tried to duplicate eDP driver into exynos drm > framework in same issue. If you're talking about us, this is misleading, as we didn't try to duplicate the eDP driver. What we did is remove it from driver/video and put it in DRM. The reason for that is that it's not needed for fbdev, since KMS helpers let you implement fbdev. So we can just remove all the exynos graphics support from drivers/video since it becomes obsolete with the KMS fbdev helpers. And everything can be in DRM. And later, we can remove the multiple platform drivers from DRM as well, since they're not needed either. Stéphane > So I think the best way is to avoid duplicating > codes and resolve ordering issue such as s/r operations between all the > various components. > > And the below is my opinion, > > > ----------------------------------------------------- > Display > Controller-------------CDF---------------|MIPI-DSI/DBI---------------LCD > Panel| > > ----------------------------------------------------- > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms based > specific drivers like now. And each driver calls some interfaces of CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)------------------pm > runtime(fb)--------------------fb_blank----------mipi and lcd > dpms(drm kms)------------pm runtime(drm > kms)----------fb_blank----------mipi and lcd > > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm kms > based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)-----------------------------------------------pm > runtime(fb)----------------fb blank-------mipi and lcd > s/r(drm kms)--------dpms(drm kms)-------pm runtime(drm > kms)------fb_blank------mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. > > Thanks, > Inki Dae > > >> >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 20:13 ` Stéphane Marchesin 0 siblings, 0 replies; 153+ messages in thread From: Stéphane Marchesin @ 2012-12-19 20:13 UTC (permalink / raw) To: Inki Dae Cc: Daniel Vetter, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park, Tomi Valkeinen, Laurent Pinchart, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae <inki.dae@samsung.com> wrote: > > > 2012/12/18 Daniel Vetter <daniel@ffwll.ch> >> >> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: >> >> The other thing I'd like you guys to do is kill the idea of fbdev and >> >> v4l drivers that are "shared" with the drm codebase, really just >> >> implement fbdev and v4l on top of the drm layer, some people might >> >> think this is some sort of maintainer thing, but really nothing else >> >> makes sense, and having these shared display frameworks just to avoid >> >> having using drm/kms drivers seems totally pointless. Fix the drm >> >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> >> framework because our previous 3 frameworks didn't work out doesn't >> >> seem like a situation I want to get behind too much. >> > >> > yeah, let's not have multiple frameworks to do the same thing.. For >> > fbdev, it is pretty clear that it is a dead end. For v4l2 >> > (subdev+mcf), it is perhaps bit more flexible when it comes to random >> > arbitrary hw pipelines than kms. But to take advantage of that, your >> > userspace isn't going to be portable anyways, so you might as well use >> > driver specific properties/ioctls. But I tend to think that is more >> > useful for cameras. And from userspace perspective, kms planes are >> > less painful to use for output than v4l2, so lets stick to drm/kms for >> > output (and not try to add camera/capture support to kms).. k, thx >> >> Yeah, I guess having a v4l device also exported by the same driver >> that exports the drm interface might make sense in some cases. But in >> many cases I think the video part is just an independent IP block and >> shuffling data around with dma-buf is all we really need. So yeah, I >> guess sharing display resources between v4l and drm kms driver should >> be a last resort option, since coordination (especially if it's >> supposed to be somewhat dynamic) will be extremely hairy. > > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. Actually, > in case of Exynos, some guys tried to duplicate eDP driver into exynos drm > framework in same issue. If you're talking about us, this is misleading, as we didn't try to duplicate the eDP driver. What we did is remove it from driver/video and put it in DRM. The reason for that is that it's not needed for fbdev, since KMS helpers let you implement fbdev. So we can just remove all the exynos graphics support from drivers/video since it becomes obsolete with the KMS fbdev helpers. And everything can be in DRM. And later, we can remove the multiple platform drivers from DRM as well, since they're not needed either. Stéphane > So I think the best way is to avoid duplicating > codes and resolve ordering issue such as s/r operations between all the > various components. > > And the below is my opinion, > > > ----------------------------------------------------- > Display > Controller-------------CDF---------------|MIPI-DSI/DBI---------------LCD > Panel| > > ----------------------------------------------------- > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms based > specific drivers like now. And each driver calls some interfaces of CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)------------------pm > runtime(fb)--------------------fb_blank----------mipi and lcd > dpms(drm kms)------------pm runtime(drm > kms)----------fb_blank----------mipi and lcd > > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm kms > based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)-----------------------------------------------pm > runtime(fb)----------------fb blank-------mipi and lcd > s/r(drm kms)--------dpms(drm kms)-------pm runtime(drm > kms)------fb_blank------mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. > > Thanks, > Inki Dae > > >> >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 9:38 ` Inki Dae @ 2012-12-24 14:08 ` Laurent Pinchart 2012-12-24 14:08 ` Laurent Pinchart 1 sibling, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 14:08 UTC (permalink / raw) To: Inki Dae Cc: Daniel Vetter, Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Inki, On Tuesday 18 December 2012 18:38:31 Inki Dae wrote: > 2012/12/18 Daniel Vetter <daniel@ffwll.ch> > > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: > > >> The other thing I'd like you guys to do is kill the idea of fbdev and > > >> v4l drivers that are "shared" with the drm codebase, really just > > >> implement fbdev and v4l on top of the drm layer, some people might > > >> think this is some sort of maintainer thing, but really nothing else > > >> makes sense, and having these shared display frameworks just to avoid > > >> having using drm/kms drivers seems totally pointless. Fix the drm > > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > > >> framework because our previous 3 frameworks didn't work out doesn't > > >> seem like a situation I want to get behind too much. > > > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > > arbitrary hw pipelines than kms. But to take advantage of that, your > > > userspace isn't going to be portable anyways, so you might as well use > > > driver specific properties/ioctls. But I tend to think that is more > > > useful for cameras. And from userspace perspective, kms planes are > > > less painful to use for output than v4l2, so lets stick to drm/kms for > > > output (and not try to add camera/capture support to kms).. k, thx > > > > Yeah, I guess having a v4l device also exported by the same driver > > that exports the drm interface might make sense in some cases. But in > > many cases I think the video part is just an independent IP block and > > shuffling data around with dma-buf is all we really need. So yeah, I > > guess sharing display resources between v4l and drm kms driver should > > be a last resort option, since coordination (especially if it's > > supposed to be somewhat dynamic) will be extremely hairy. > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. > Actually, in case of Exynos, some guys tried to duplicate eDP driver into > exynos drm framework in same issue. So I think the best way is to avoid > duplicating codes and resolve ordering issue such as s/r operations between > all the various components. > > And the below is my opinion, > > +--------------------------------+ > Display Controller -------- CDF --------- |MIPI-DSI/DBI-----------LCD Panel| > +--------------------------------+ > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms > based specific drivers like now. And each driver calls some interfaces of > CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html (Just FYI, I plan to clean up the backlight framework when I'll be done with CDF, to remove the FBDEV dependency) > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)---------pm runtime(fb)-----------fb_blank----------mipi and lcd > dpms(drm kms)--------pm runtime(drm kms)------fb_blank----------mipi and lcd > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm > kms based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)------------------------pm runtime(fb)--------fb blank---mipi and lcd > s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. As I mentioned before, we have multiple ordering issues related to suspend and resume. Panels and display controllers will likely want to enforce a S/R order on the video bus, and control busses will also require a specific S/R order. My plan is to use early suspend/late resume in the display controller driver to control the video busses, and let the PM core handle control bus ordering issues. This will of course need to be prototyped and tested. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 14:08 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 14:08 UTC (permalink / raw) To: Inki Dae Cc: Daniel Vetter, Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Inki, On Tuesday 18 December 2012 18:38:31 Inki Dae wrote: > 2012/12/18 Daniel Vetter <daniel@ffwll.ch> > > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: > > >> The other thing I'd like you guys to do is kill the idea of fbdev and > > >> v4l drivers that are "shared" with the drm codebase, really just > > >> implement fbdev and v4l on top of the drm layer, some people might > > >> think this is some sort of maintainer thing, but really nothing else > > >> makes sense, and having these shared display frameworks just to avoid > > >> having using drm/kms drivers seems totally pointless. Fix the drm > > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > > >> framework because our previous 3 frameworks didn't work out doesn't > > >> seem like a situation I want to get behind too much. > > > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > > arbitrary hw pipelines than kms. But to take advantage of that, your > > > userspace isn't going to be portable anyways, so you might as well use > > > driver specific properties/ioctls. But I tend to think that is more > > > useful for cameras. And from userspace perspective, kms planes are > > > less painful to use for output than v4l2, so lets stick to drm/kms for > > > output (and not try to add camera/capture support to kms).. k, thx > > > > Yeah, I guess having a v4l device also exported by the same driver > > that exports the drm interface might make sense in some cases. But in > > many cases I think the video part is just an independent IP block and > > shuffling data around with dma-buf is all we really need. So yeah, I > > guess sharing display resources between v4l and drm kms driver should > > be a last resort option, since coordination (especially if it's > > supposed to be somewhat dynamic) will be extremely hairy. > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. > Actually, in case of Exynos, some guys tried to duplicate eDP driver into > exynos drm framework in same issue. So I think the best way is to avoid > duplicating codes and resolve ordering issue such as s/r operations between > all the various components. > > And the below is my opinion, > > +--------------------------------+ > Display Controller -------- CDF --------- |MIPI-DSI/DBI-----------LCD Panel| > +--------------------------------+ > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms > based specific drivers like now. And each driver calls some interfaces of > CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html (Just FYI, I plan to clean up the backlight framework when I'll be done with CDF, to remove the FBDEV dependency) > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)---------pm runtime(fb)-----------fb_blank----------mipi and lcd > dpms(drm kms)--------pm runtime(drm kms)------fb_blank----------mipi and lcd > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm > kms based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)------------------------pm runtime(fb)--------fb blank---mipi and lcd > s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. As I mentioned before, we have multiple ordering issues related to suspend and resume. Panels and display controllers will likely want to enforce a S/R order on the video bus, and control busses will also require a specific S/R order. My plan is to use early suspend/late resume in the display controller driver to control the video busses, and let the PM core handle control bus ordering issues. This will of course need to be prototyped and tested. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 8:30 ` Daniel Vetter @ 2012-12-24 13:39 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:39 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Daniel, On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote: > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: > >> The other thing I'd like you guys to do is kill the idea of fbdev and > >> v4l drivers that are "shared" with the drm codebase, really just > >> implement fbdev and v4l on top of the drm layer, some people might > >> think this is some sort of maintainer thing, but really nothing else > >> makes sense, and having these shared display frameworks just to avoid > >> having using drm/kms drivers seems totally pointless. Fix the drm > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > >> framework because our previous 3 frameworks didn't work out doesn't > >> seem like a situation I want to get behind too much. > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > arbitrary hw pipelines than kms. But to take advantage of that, your > > userspace isn't going to be portable anyways, so you might as well use > > driver specific properties/ioctls. But I tend to think that is more > > useful for cameras. And from userspace perspective, kms planes are > > less painful to use for output than v4l2, so lets stick to drm/kms for > > output (and not try to add camera/capture support to kms).. k, thx > > Yeah, I guess having a v4l device also exported by the same driver that > exports the drm interface might make sense in some cases. But in many cases > I think the video part is just an independent IP block and shuffling data > around with dma-buf is all we really need. So yeah, I guess sharing display > resources between v4l and drm kms driver should be a last resort option, > since coordination (especially if it's supposed to be somewhat dynamic) will > be extremely hairy. I totally agree. As explained in my replies to Dave and Rob, I don't want to share devices between the different subsystems at runtime, but I'd like to avoid writing two drivers for a single device that can be used for display and graphics on one board, and video output on another board (HDMI transmitters are a good example). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 13:39 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:39 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Daniel, On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote: > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote: > >> The other thing I'd like you guys to do is kill the idea of fbdev and > >> v4l drivers that are "shared" with the drm codebase, really just > >> implement fbdev and v4l on top of the drm layer, some people might > >> think this is some sort of maintainer thing, but really nothing else > >> makes sense, and having these shared display frameworks just to avoid > >> having using drm/kms drivers seems totally pointless. Fix the drm > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > >> framework because our previous 3 frameworks didn't work out doesn't > >> seem like a situation I want to get behind too much. > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > arbitrary hw pipelines than kms. But to take advantage of that, your > > userspace isn't going to be portable anyways, so you might as well use > > driver specific properties/ioctls. But I tend to think that is more > > useful for cameras. And from userspace perspective, kms planes are > > less painful to use for output than v4l2, so lets stick to drm/kms for > > output (and not try to add camera/capture support to kms).. k, thx > > Yeah, I guess having a v4l device also exported by the same driver that > exports the drm interface might make sense in some cases. But in many cases > I think the video part is just an independent IP block and shuffling data > around with dma-buf is all we really need. So yeah, I guess sharing display > resources between v4l and drm kms driver should be a last resort option, > since coordination (especially if it's supposed to be somewhat dynamic) will > be extremely hairy. I totally agree. As explained in my replies to Dave and Rob, I don't want to share devices between the different subsystems at runtime, but I'd like to avoid writing two drivers for a single device that can be used for display and graphics on one board, and video output on another board (HDMI transmitters are a good example). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 6:21 ` Rob Clark @ 2012-12-18 10:59 ` Sylwester Nawrocki -1 siblings, 0 replies; 153+ messages in thread From: Sylwester Nawrocki @ 2012-12-18 10:59 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 12/18/2012 07:21 AM, Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied@gmail.com> wrote: >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? There have been already some ideas proposed to resolve this at the PM subsystem level [1]. And this problem is of course not only specific to platform drivers. The idea of having monolithic drivers, just because we can't get the suspend/resume sequences right otherwise, doesn't really sound appealing. SoC IPs get reused on multiple different SoC series, no only by single manufacturer. Whole graphics/video subsystems are composed from smaller blocks in SoCs, with various number of distinct sub-blocks and same sub-blocks repeated different number of times in a specific SoC revision. Expressing an IP as a platform device seems justified to me, often these platform devices have enough differences to treat them as such. E.g. belong in different power domain/use different clocks. Except there is big issue with the power management... However probably more important is to be able to have driver for a specific IP in a separate module. And this suspend/resume ordering issue is not only about the platform devices. E.g. camera subsystem can be composed of an image sensor sub-device driver, which is most often an I2C client driver, and of multiple SoC processing blocks. The image sensor can have dependencies on the SoC sub-blocks. So even if we created monolithic driver for the SoC part, there are still two pieces to get s/r ordering right - I2C client and SoC drivers. And please don't propose to merge the sensor sub-device driver too. There has been a lot of effort in V4L2 to separate those various functional blocks into sub-devices, so they can be freely reused, without reimplementing same functionality in each driver. BTW, there has been a nice talk about these topics at ELCE [2], particularly slide 22 is interesting. I believe the solution for these issues really needs to be sought in the PM subsystem itself. > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. [1] https://lkml.org/lkml/2009/9/9/373 [2] http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf Thanks, Sylwester ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 10:59 ` Sylwester Nawrocki 0 siblings, 0 replies; 153+ messages in thread From: Sylwester Nawrocki @ 2012-12-18 10:59 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On 12/18/2012 07:21 AM, Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied@gmail.com> wrote: >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? There have been already some ideas proposed to resolve this at the PM subsystem level [1]. And this problem is of course not only specific to platform drivers. The idea of having monolithic drivers, just because we can't get the suspend/resume sequences right otherwise, doesn't really sound appealing. SoC IPs get reused on multiple different SoC series, no only by single manufacturer. Whole graphics/video subsystems are composed from smaller blocks in SoCs, with various number of distinct sub-blocks and same sub-blocks repeated different number of times in a specific SoC revision. Expressing an IP as a platform device seems justified to me, often these platform devices have enough differences to treat them as such. E.g. belong in different power domain/use different clocks. Except there is big issue with the power management... However probably more important is to be able to have driver for a specific IP in a separate module. And this suspend/resume ordering issue is not only about the platform devices. E.g. camera subsystem can be composed of an image sensor sub-device driver, which is most often an I2C client driver, and of multiple SoC processing blocks. The image sensor can have dependencies on the SoC sub-blocks. So even if we created monolithic driver for the SoC part, there are still two pieces to get s/r ordering right - I2C client and SoC drivers. And please don't propose to merge the sensor sub-device driver too. There has been a lot of effort in V4L2 to separate those various functional blocks into sub-devices, so they can be freely reused, without reimplementing same functionality in each driver. BTW, there has been a nice talk about these topics at ELCE [2], particularly slide 22 is interesting. I believe the solution for these issues really needs to be sought in the PM subsystem itself. > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. [1] https://lkml.org/lkml/2009/9/9/373 [2] http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf Thanks, Sylwester ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 10:59 ` Sylwester Nawrocki @ 2012-12-24 17:19 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:19 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Sylwester, On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote: > On 12/18/2012 07:21 AM, Rob Clark wrote: > > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied@gmail.com> wrote: > >> So this might be a bit off topic but this whole CDF triggered me > >> looking at stuff I generally avoid: > >> > >> The biggest problem I'm having currently with the whole ARM graphics > >> and output world is the proliferation of platform drivers for every > >> little thing. The whole ordering of operations with respect to things > >> like suspend/resume or dynamic power management is going to be a real > >> nightmare if there are dependencies between the drivers. How do you > >> enforce ordering of s/r operations between all the various components? > > There have been already some ideas proposed to resolve this at the PM > subsystem level [1]. And this problem is of course not only specific to > platform drivers. The idea of having monolithic drivers, just because we > can't get the suspend/resume sequences right otherwise, doesn't really sound > appealing. SoC IPs get reused on multiple different SoC series, no only by > single manufacturer. Whole graphics/video subsystems are composed from > smaller blocks in SoCs, with various number of distinct sub-blocks and same > sub-blocks repeated different number of times in a specific SoC revision. > Expressing an IP as a platform device seems justified to me, often these > platform devices have enough differences to treat them as such. E.g. belong > in different power domain/use different clocks. Except there is big issue > with the power management... However probably more important is to be able > to have driver for a specific IP in a separate module. > > And this suspend/resume ordering issue is not only about the platform > devices. E.g. camera subsystem can be composed of an image sensor sub-device > driver, which is most often an I2C client driver, and of multiple SoC > processing blocks. The image sensor can have dependencies on the SoC sub- > blocks. So even if we created monolithic driver for the SoC part, there are > still two pieces to get s/r ordering right - I2C client and SoC drivers. And > please don't propose to merge the sensor sub-device driver too. There has > been a lot of effort in V4L2 to separate those various functional blocks > into sub-devices, so they can be freely reused, without reimplementing same > functionality in each driver. BTW, there has been a nice talk about these > topics at ELCE [2], particularly slide 22 is interesting. > > I believe the solution for these issues really needs to be sought in the PM > subsystem itself. I tend to agree with you, or at least I believe we should research a proper solution in the PM framework. In the meantime, though, I think early suspend/late resume might provide an intermediate solution. > > I tend to think that sub-devices are useful just to have a way to > > probe hw which may or may not be there, since on ARM we often don't > > have any alternative.. but beyond that, suspend/resume, and other > > life-cycle aspects, they should really be treated as all one device. > > Especially to avoid undefined suspend/resume ordering. > > [1] https://lkml.org/lkml/2009/9/9/373 > [2] > http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:19 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:19 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Rob Clark, Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Sylwester, On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote: > On 12/18/2012 07:21 AM, Rob Clark wrote: > > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied@gmail.com> wrote: > >> So this might be a bit off topic but this whole CDF triggered me > >> looking at stuff I generally avoid: > >> > >> The biggest problem I'm having currently with the whole ARM graphics > >> and output world is the proliferation of platform drivers for every > >> little thing. The whole ordering of operations with respect to things > >> like suspend/resume or dynamic power management is going to be a real > >> nightmare if there are dependencies between the drivers. How do you > >> enforce ordering of s/r operations between all the various components? > > There have been already some ideas proposed to resolve this at the PM > subsystem level [1]. And this problem is of course not only specific to > platform drivers. The idea of having monolithic drivers, just because we > can't get the suspend/resume sequences right otherwise, doesn't really sound > appealing. SoC IPs get reused on multiple different SoC series, no only by > single manufacturer. Whole graphics/video subsystems are composed from > smaller blocks in SoCs, with various number of distinct sub-blocks and same > sub-blocks repeated different number of times in a specific SoC revision. > Expressing an IP as a platform device seems justified to me, often these > platform devices have enough differences to treat them as such. E.g. belong > in different power domain/use different clocks. Except there is big issue > with the power management... However probably more important is to be able > to have driver for a specific IP in a separate module. > > And this suspend/resume ordering issue is not only about the platform > devices. E.g. camera subsystem can be composed of an image sensor sub-device > driver, which is most often an I2C client driver, and of multiple SoC > processing blocks. The image sensor can have dependencies on the SoC sub- > blocks. So even if we created monolithic driver for the SoC part, there are > still two pieces to get s/r ordering right - I2C client and SoC drivers. And > please don't propose to merge the sensor sub-device driver too. There has > been a lot of effort in V4L2 to separate those various functional blocks > into sub-devices, so they can be freely reused, without reimplementing same > functionality in each driver. BTW, there has been a nice talk about these > topics at ELCE [2], particularly slide 22 is interesting. > > I believe the solution for these issues really needs to be sought in the PM > subsystem itself. I tend to agree with you, or at least I believe we should research a proper solution in the PM framework. In the meantime, though, I think early suspend/late resume might provide an intermediate solution. > > I tend to think that sub-devices are useful just to have a way to > > probe hw which may or may not be there, since on ARM we often don't > > have any alternative.. but beyond that, suspend/resume, and other > > life-cycle aspects, they should really be treated as all one device. > > Especially to avoid undefined suspend/resume ordering. > > [1] https://lkml.org/lkml/2009/9/9/373 > [2] > http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 6:21 ` Rob Clark @ 2012-12-19 20:05 ` Stéphane Marchesin -1 siblings, 0 replies; 153+ messages in thread From: Stéphane Marchesin @ 2012-12-19 20:05 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Laurent Pinchart, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >>> inviting me to Connect and providing a venue to discuss this topic. >>> >> >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane > but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. > > CDF or some sort of mechanism to share panel drivers between drivers > is useful. Keeping it within drm, is probably a good idea, if nothing > else to simplify re-use of helper fxns (like avi-infoframe stuff, for > example) and avoid dealing with merging changes across multiple trees. > Treating them more like shared libraries and less like sub-devices > which can be dynamically loaded/unloaded (ie. they should be not built > as separate modules or suspend/resumed or probed/removed independently > of the master driver) is a really good idea to avoid uncovering nasty > synchronization issues later (remove vs modeset or pageflip) or > surprising userspace in bad ways. > >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx > > BR, > -R > >> Dave. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-19 20:05 ` Stéphane Marchesin 0 siblings, 0 replies; 153+ messages in thread From: Stéphane Marchesin @ 2012-12-19 20:05 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Laurent Pinchart, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >>> inviting me to Connect and providing a venue to discuss this topic. >>> >> >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane > but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. > > CDF or some sort of mechanism to share panel drivers between drivers > is useful. Keeping it within drm, is probably a good idea, if nothing > else to simplify re-use of helper fxns (like avi-infoframe stuff, for > example) and avoid dealing with merging changes across multiple trees. > Treating them more like shared libraries and less like sub-devices > which can be dynamically loaded/unloaded (ie. they should be not built > as separate modules or suspend/resumed or probed/removed independently > of the master driver) is a really good idea to avoid uncovering nasty > synchronization issues later (remove vs modeset or pageflip) or > surprising userspace in bad ways. > >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx > > BR, > -R > >> Dave. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 6:21 ` Rob Clark @ 2012-12-24 13:37 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:37 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to probe hw > which may or may not be there, since on ARM we often don't have any > alternative.. but beyond that, suspend/resume, and other life-cycle aspects, > they should really be treated as all one device. Especially to avoid > undefined suspend/resume ordering. I tend to agree, except that I try to reuse the existing PM infrastructure when possible to avoid reinventing the wheel. So far handling suspend/resume ordering related to data busses in early suspend/late resume operations and allowing the Linux PM core to handle control busses using the Linux device tree worked pretty well. > CDF or some sort of mechanism to share panel drivers between drivers is > useful. Keeping it within drm, is probably a good idea, if nothing else to > simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > avoid dealing with merging changes across multiple trees. Treating them more > like shared libraries and less like sub-devices which can be dynamically > loaded/unloaded (ie. they should be not built as separate modules or > suspend/resumed or probed/removed independently of the master driver) is a > really good idea to avoid uncovering nasty synchronization issues later > (remove vs modeset or pageflip) or surprising userspace in bad ways. We've tried that in V4L2 years ago and realized that the approach led to a dead-end, especially when OF/DT got involved. With DT-based device probing, I2C camera sensors started getting probed asynchronously to the main camera device, as they are children of the I2C bus master. We will have similar issues with I2C HDMI transmitters or panels, so we should be prepared for it. On PC hardware the I2C devices are connected to an I2C master provided by the GPU, but on embedded devices they are usually connected to an independent I2C master. We thus can't have a single self-contained driver that controls everything internally, and need to interface with the rest of the SoC drivers. I agree that probing/removing devices independently of the master driver can lead to bad surprises, which is why I want to establish clear rules in CDF regarding what can and can't be done with display entities. Reference counting will be one way to make sure that devices don't disappear all of a sudden. > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For fbdev, > it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is > perhaps bit more flexible when it comes to random arbitrary hw pipelines > than kms. But to take advantage of that, your userspace isn't going to be > portable anyways, so you might as well use driver specific > properties/ioctls. But I tend to think that is more useful for cameras. > And from userspace perspective, kms planes are less painful to use for > output than v4l2, so lets stick to drm/kms for output (and not try to add > camera/capture support to kms).. Agreed. I've started to advocate the deprecation of FBDEV during LPC. The positive response has motivated me to continue doing so :-) For V4L2 the situation is a little bit different, I think V4L2 shouldn't be used for graphics and display hardware, but it still has use cases on the video output side for pure video devices (such as pass-through video pipelines with embedded processing for instance). As those can use subdevices found in display and graphics hardware, I'd like to avoid code duplication. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 13:37 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:37 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to probe hw > which may or may not be there, since on ARM we often don't have any > alternative.. but beyond that, suspend/resume, and other life-cycle aspects, > they should really be treated as all one device. Especially to avoid > undefined suspend/resume ordering. I tend to agree, except that I try to reuse the existing PM infrastructure when possible to avoid reinventing the wheel. So far handling suspend/resume ordering related to data busses in early suspend/late resume operations and allowing the Linux PM core to handle control busses using the Linux device tree worked pretty well. > CDF or some sort of mechanism to share panel drivers between drivers is > useful. Keeping it within drm, is probably a good idea, if nothing else to > simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > avoid dealing with merging changes across multiple trees. Treating them more > like shared libraries and less like sub-devices which can be dynamically > loaded/unloaded (ie. they should be not built as separate modules or > suspend/resumed or probed/removed independently of the master driver) is a > really good idea to avoid uncovering nasty synchronization issues later > (remove vs modeset or pageflip) or surprising userspace in bad ways. We've tried that in V4L2 years ago and realized that the approach led to a dead-end, especially when OF/DT got involved. With DT-based device probing, I2C camera sensors started getting probed asynchronously to the main camera device, as they are children of the I2C bus master. We will have similar issues with I2C HDMI transmitters or panels, so we should be prepared for it. On PC hardware the I2C devices are connected to an I2C master provided by the GPU, but on embedded devices they are usually connected to an independent I2C master. We thus can't have a single self-contained driver that controls everything internally, and need to interface with the rest of the SoC drivers. I agree that probing/removing devices independently of the master driver can lead to bad surprises, which is why I want to establish clear rules in CDF regarding what can and can't be done with display entities. Reference counting will be one way to make sure that devices don't disappear all of a sudden. > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For fbdev, > it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is > perhaps bit more flexible when it comes to random arbitrary hw pipelines > than kms. But to take advantage of that, your userspace isn't going to be > portable anyways, so you might as well use driver specific > properties/ioctls. But I tend to think that is more useful for cameras. > And from userspace perspective, kms planes are less painful to use for > output than v4l2, so lets stick to drm/kms for output (and not try to add > camera/capture support to kms).. Agreed. I've started to advocate the deprecation of FBDEV during LPC. The positive response has motivated me to continue doing so :-) For V4L2 the situation is a little bit different, I think V4L2 shouldn't be used for graphics and display hardware, but it still has use cases on the video output side for pure video devices (such as pass-through video pipelines with embedded processing for instance). As those can use subdevices found in display and graphics hardware, I'd like to avoid code duplication. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-24 13:37 ` Laurent Pinchart @ 2012-12-27 15:54 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 15:54 UTC (permalink / raw) To: Laurent Pinchart Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rob, > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> Many developers showed interest in the first RFC, and I've had the >> >> opportunity to discuss it with most of them. I would like to thank (in >> >> no particular order) Tomi Valkeinen for all the time he spend helping me >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to >> >> discuss this topic. >> > >> > So this might be a bit off topic but this whole CDF triggered me >> > looking at stuff I generally avoid: >> > >> > The biggest problem I'm having currently with the whole ARM graphics >> > and output world is the proliferation of platform drivers for every >> > little thing. The whole ordering of operations with respect to things >> > like suspend/resume or dynamic power management is going to be a real >> > nightmare if there are dependencies between the drivers. How do you >> > enforce ordering of s/r operations between all the various components? >> >> I tend to think that sub-devices are useful just to have a way to probe hw >> which may or may not be there, since on ARM we often don't have any >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, >> they should really be treated as all one device. Especially to avoid >> undefined suspend/resume ordering. > > I tend to agree, except that I try to reuse the existing PM infrastructure > when possible to avoid reinventing the wheel. So far handling suspend/resume > ordering related to data busses in early suspend/late resume operations and > allowing the Linux PM core to handle control busses using the Linux device > tree worked pretty well. > >> CDF or some sort of mechanism to share panel drivers between drivers is >> useful. Keeping it within drm, is probably a good idea, if nothing else to >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and >> avoid dealing with merging changes across multiple trees. Treating them more >> like shared libraries and less like sub-devices which can be dynamically >> loaded/unloaded (ie. they should be not built as separate modules or >> suspend/resumed or probed/removed independently of the master driver) is a >> really good idea to avoid uncovering nasty synchronization issues later >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > We've tried that in V4L2 years ago and realized that the approach led to a > dead-end, especially when OF/DT got involved. With DT-based device probing, > I2C camera sensors started getting probed asynchronously to the main camera > device, as they are children of the I2C bus master. We will have similar > issues with I2C HDMI transmitters or panels, so we should be prepared for it. What I've done to avoid that so far is that the master device registers the drivers for it's output sub-devices before registering it's own device. At least this way I can control that they are probed first. Not the prettiest thing, but avoids even uglier problems. > On PC hardware the I2C devices are connected to an I2C master provided by the > GPU, but on embedded devices they are usually connected to an independent I2C > master. We thus can't have a single self-contained driver that controls > everything internally, and need to interface with the rest of the SoC drivers. > > I agree that probing/removing devices independently of the master driver can > lead to bad surprises, which is why I want to establish clear rules in CDF > regarding what can and can't be done with display entities. Reference counting > will be one way to make sure that devices don't disappear all of a sudden. That at least helps cover some issues.. although it doesn't really help userspace confusion. Anyways, with enough work perhaps all problems could be solved.. otoh, there are plenty of other important problems to solve in the world of gpus and kms, so my preference is always not to needlessly over-complicate CDF and instead leave some time for other things BR, -R >> > The other thing I'd like you guys to do is kill the idea of fbdev and >> > v4l drivers that are "shared" with the drm codebase, really just >> > implement fbdev and v4l on top of the drm layer, some people might >> > think this is some sort of maintainer thing, but really nothing else >> > makes sense, and having these shared display frameworks just to avoid >> > having using drm/kms drivers seems totally pointless. Fix the drm >> > fbdev emulation if an fbdev interface is needed. But creating a fourth >> > framework because our previous 3 frameworks didn't work out doesn't >> > seem like a situation I want to get behind too much. >> >> yeah, let's not have multiple frameworks to do the same thing.. For fbdev, >> it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is >> perhaps bit more flexible when it comes to random arbitrary hw pipelines >> than kms. But to take advantage of that, your userspace isn't going to be >> portable anyways, so you might as well use driver specific >> properties/ioctls. But I tend to think that is more useful for cameras. >> And from userspace perspective, kms planes are less painful to use for >> output than v4l2, so lets stick to drm/kms for output (and not try to add >> camera/capture support to kms).. > > Agreed. I've started to advocate the deprecation of FBDEV during LPC. The > positive response has motivated me to continue doing so :-) For V4L2 the > situation is a little bit different, I think V4L2 shouldn't be used for > graphics and display hardware, but it still has use cases on the video output > side for pure video devices (such as pass-through video pipelines with > embedded processing for instance). As those can use subdevices found in > display and graphics hardware, I'd like to avoid code duplication. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 15:54 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 15:54 UTC (permalink / raw) To: Laurent Pinchart Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rob, > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> Many developers showed interest in the first RFC, and I've had the >> >> opportunity to discuss it with most of them. I would like to thank (in >> >> no particular order) Tomi Valkeinen for all the time he spend helping me >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to >> >> discuss this topic. >> > >> > So this might be a bit off topic but this whole CDF triggered me >> > looking at stuff I generally avoid: >> > >> > The biggest problem I'm having currently with the whole ARM graphics >> > and output world is the proliferation of platform drivers for every >> > little thing. The whole ordering of operations with respect to things >> > like suspend/resume or dynamic power management is going to be a real >> > nightmare if there are dependencies between the drivers. How do you >> > enforce ordering of s/r operations between all the various components? >> >> I tend to think that sub-devices are useful just to have a way to probe hw >> which may or may not be there, since on ARM we often don't have any >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, >> they should really be treated as all one device. Especially to avoid >> undefined suspend/resume ordering. > > I tend to agree, except that I try to reuse the existing PM infrastructure > when possible to avoid reinventing the wheel. So far handling suspend/resume > ordering related to data busses in early suspend/late resume operations and > allowing the Linux PM core to handle control busses using the Linux device > tree worked pretty well. > >> CDF or some sort of mechanism to share panel drivers between drivers is >> useful. Keeping it within drm, is probably a good idea, if nothing else to >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and >> avoid dealing with merging changes across multiple trees. Treating them more >> like shared libraries and less like sub-devices which can be dynamically >> loaded/unloaded (ie. they should be not built as separate modules or >> suspend/resumed or probed/removed independently of the master driver) is a >> really good idea to avoid uncovering nasty synchronization issues later >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > We've tried that in V4L2 years ago and realized that the approach led to a > dead-end, especially when OF/DT got involved. With DT-based device probing, > I2C camera sensors started getting probed asynchronously to the main camera > device, as they are children of the I2C bus master. We will have similar > issues with I2C HDMI transmitters or panels, so we should be prepared for it. What I've done to avoid that so far is that the master device registers the drivers for it's output sub-devices before registering it's own device. At least this way I can control that they are probed first. Not the prettiest thing, but avoids even uglier problems. > On PC hardware the I2C devices are connected to an I2C master provided by the > GPU, but on embedded devices they are usually connected to an independent I2C > master. We thus can't have a single self-contained driver that controls > everything internally, and need to interface with the rest of the SoC drivers. > > I agree that probing/removing devices independently of the master driver can > lead to bad surprises, which is why I want to establish clear rules in CDF > regarding what can and can't be done with display entities. Reference counting > will be one way to make sure that devices don't disappear all of a sudden. That at least helps cover some issues.. although it doesn't really help userspace confusion. Anyways, with enough work perhaps all problems could be solved.. otoh, there are plenty of other important problems to solve in the world of gpus and kms, so my preference is always not to needlessly over-complicate CDF and instead leave some time for other things BR, -R >> > The other thing I'd like you guys to do is kill the idea of fbdev and >> > v4l drivers that are "shared" with the drm codebase, really just >> > implement fbdev and v4l on top of the drm layer, some people might >> > think this is some sort of maintainer thing, but really nothing else >> > makes sense, and having these shared display frameworks just to avoid >> > having using drm/kms drivers seems totally pointless. Fix the drm >> > fbdev emulation if an fbdev interface is needed. But creating a fourth >> > framework because our previous 3 frameworks didn't work out doesn't >> > seem like a situation I want to get behind too much. >> >> yeah, let's not have multiple frameworks to do the same thing.. For fbdev, >> it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is >> perhaps bit more flexible when it comes to random arbitrary hw pipelines >> than kms. But to take advantage of that, your userspace isn't going to be >> portable anyways, so you might as well use driver specific >> properties/ioctls. But I tend to think that is more useful for cameras. >> And from userspace perspective, kms planes are less painful to use for >> output than v4l2, so lets stick to drm/kms for output (and not try to add >> camera/capture support to kms).. > > Agreed. I've started to advocate the deprecation of FBDEV during LPC. The > positive response has motivated me to continue doing so :-) For V4L2 the > situation is a little bit different, I think V4L2 shouldn't be used for > graphics and display hardware, but it still has use cases on the video output > side for pure video devices (such as pass-through video pipelines with > embedded processing for instance). As those can use subdevices found in > display and graphics hardware, I'd like to avoid code duplication. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 15:54 ` Rob Clark @ 2012-12-27 19:18 ` Sascha Hauer -1 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-27 19:18 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > Hi Rob, > > > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> >> Many developers showed interest in the first RFC, and I've had the > >> >> opportunity to discuss it with most of them. I would like to thank (in > >> >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> >> discuss this topic. > >> > > >> > So this might be a bit off topic but this whole CDF triggered me > >> > looking at stuff I generally avoid: > >> > > >> > The biggest problem I'm having currently with the whole ARM graphics > >> > and output world is the proliferation of platform drivers for every > >> > little thing. The whole ordering of operations with respect to things > >> > like suspend/resume or dynamic power management is going to be a real > >> > nightmare if there are dependencies between the drivers. How do you > >> > enforce ordering of s/r operations between all the various components? > >> > >> I tend to think that sub-devices are useful just to have a way to probe hw > >> which may or may not be there, since on ARM we often don't have any > >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, > >> they should really be treated as all one device. Especially to avoid > >> undefined suspend/resume ordering. > > > > I tend to agree, except that I try to reuse the existing PM infrastructure > > when possible to avoid reinventing the wheel. So far handling suspend/resume > > ordering related to data busses in early suspend/late resume operations and > > allowing the Linux PM core to handle control busses using the Linux device > > tree worked pretty well. > > > >> CDF or some sort of mechanism to share panel drivers between drivers is > >> useful. Keeping it within drm, is probably a good idea, if nothing else to > >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > >> avoid dealing with merging changes across multiple trees. Treating them more > >> like shared libraries and less like sub-devices which can be dynamically > >> loaded/unloaded (ie. they should be not built as separate modules or > >> suspend/resumed or probed/removed independently of the master driver) is a > >> really good idea to avoid uncovering nasty synchronization issues later > >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > > > We've tried that in V4L2 years ago and realized that the approach led to a > > dead-end, especially when OF/DT got involved. With DT-based device probing, > > I2C camera sensors started getting probed asynchronously to the main camera > > device, as they are children of the I2C bus master. We will have similar > > issues with I2C HDMI transmitters or panels, so we should be prepared for it. > > What I've done to avoid that so far is that the master device > registers the drivers for it's output sub-devices before registering > it's own device. At least this way I can control that they are probed > first. Not the prettiest thing, but avoids even uglier problems. This implies that the master driver knows all potential subdevices, something which is not true for SoCs which have external i2c encoders attached to unrelated i2c controllers. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 19:18 ` Sascha Hauer 0 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-27 19:18 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > Hi Rob, > > > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> >> Many developers showed interest in the first RFC, and I've had the > >> >> opportunity to discuss it with most of them. I would like to thank (in > >> >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> >> discuss this topic. > >> > > >> > So this might be a bit off topic but this whole CDF triggered me > >> > looking at stuff I generally avoid: > >> > > >> > The biggest problem I'm having currently with the whole ARM graphics > >> > and output world is the proliferation of platform drivers for every > >> > little thing. The whole ordering of operations with respect to things > >> > like suspend/resume or dynamic power management is going to be a real > >> > nightmare if there are dependencies between the drivers. How do you > >> > enforce ordering of s/r operations between all the various components? > >> > >> I tend to think that sub-devices are useful just to have a way to probe hw > >> which may or may not be there, since on ARM we often don't have any > >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, > >> they should really be treated as all one device. Especially to avoid > >> undefined suspend/resume ordering. > > > > I tend to agree, except that I try to reuse the existing PM infrastructure > > when possible to avoid reinventing the wheel. So far handling suspend/resume > > ordering related to data busses in early suspend/late resume operations and > > allowing the Linux PM core to handle control busses using the Linux device > > tree worked pretty well. > > > >> CDF or some sort of mechanism to share panel drivers between drivers is > >> useful. Keeping it within drm, is probably a good idea, if nothing else to > >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > >> avoid dealing with merging changes across multiple trees. Treating them more > >> like shared libraries and less like sub-devices which can be dynamically > >> loaded/unloaded (ie. they should be not built as separate modules or > >> suspend/resumed or probed/removed independently of the master driver) is a > >> really good idea to avoid uncovering nasty synchronization issues later > >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > > > We've tried that in V4L2 years ago and realized that the approach led to a > > dead-end, especially when OF/DT got involved. With DT-based device probing, > > I2C camera sensors started getting probed asynchronously to the main camera > > device, as they are children of the I2C bus master. We will have similar > > issues with I2C HDMI transmitters or panels, so we should be prepared for it. > > What I've done to avoid that so far is that the master device > registers the drivers for it's output sub-devices before registering > it's own device. At least this way I can control that they are probed > first. Not the prettiest thing, but avoids even uglier problems. This implies that the master driver knows all potential subdevices, something which is not true for SoCs which have external i2c encoders attached to unrelated i2c controllers. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 19:18 ` Sascha Hauer @ 2012-12-27 19:57 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 19:57 UTC (permalink / raw) To: Sascha Hauer Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart >> <laurent.pinchart@ideasonboard.com> wrote: >> > Hi Rob, >> > >> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: >> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> >> Many developers showed interest in the first RFC, and I've had the >> >> >> opportunity to discuss it with most of them. I would like to thank (in >> >> >> no particular order) Tomi Valkeinen for all the time he spend helping me >> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect >> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to >> >> >> discuss this topic. >> >> > >> >> > So this might be a bit off topic but this whole CDF triggered me >> >> > looking at stuff I generally avoid: >> >> > >> >> > The biggest problem I'm having currently with the whole ARM graphics >> >> > and output world is the proliferation of platform drivers for every >> >> > little thing. The whole ordering of operations with respect to things >> >> > like suspend/resume or dynamic power management is going to be a real >> >> > nightmare if there are dependencies between the drivers. How do you >> >> > enforce ordering of s/r operations between all the various components? >> >> >> >> I tend to think that sub-devices are useful just to have a way to probe hw >> >> which may or may not be there, since on ARM we often don't have any >> >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, >> >> they should really be treated as all one device. Especially to avoid >> >> undefined suspend/resume ordering. >> > >> > I tend to agree, except that I try to reuse the existing PM infrastructure >> > when possible to avoid reinventing the wheel. So far handling suspend/resume >> > ordering related to data busses in early suspend/late resume operations and >> > allowing the Linux PM core to handle control busses using the Linux device >> > tree worked pretty well. >> > >> >> CDF or some sort of mechanism to share panel drivers between drivers is >> >> useful. Keeping it within drm, is probably a good idea, if nothing else to >> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and >> >> avoid dealing with merging changes across multiple trees. Treating them more >> >> like shared libraries and less like sub-devices which can be dynamically >> >> loaded/unloaded (ie. they should be not built as separate modules or >> >> suspend/resumed or probed/removed independently of the master driver) is a >> >> really good idea to avoid uncovering nasty synchronization issues later >> >> (remove vs modeset or pageflip) or surprising userspace in bad ways. >> > >> > We've tried that in V4L2 years ago and realized that the approach led to a >> > dead-end, especially when OF/DT got involved. With DT-based device probing, >> > I2C camera sensors started getting probed asynchronously to the main camera >> > device, as they are children of the I2C bus master. We will have similar >> > issues with I2C HDMI transmitters or panels, so we should be prepared for it. >> >> What I've done to avoid that so far is that the master device >> registers the drivers for it's output sub-devices before registering >> it's own device. At least this way I can control that they are probed >> first. Not the prettiest thing, but avoids even uglier problems. > > This implies that the master driver knows all potential subdevices, > something which is not true for SoCs which have external i2c encoders > attached to unrelated i2c controllers. well, it can be brute-forced.. ie. drm driver calls common register_all_panels() fxn, which, well, registers all the panel/display subdev's based on their corresponding CONFIG_FOO_PANEL defines. If you anyways aren't building the panels as separate modules, that would work. Maybe not the most *elegant* approach, but simple and functional. I guess it partly depends on the structure in devicetree. If you are assuming that the i2c encoder belongs inside the i2c bus, like: &i2cN { foo-i2c-encoder { .... }; }; and you are letting devicetree create the devices, then it doesn't quite work. I'm not entirely convinced you should do it that way. Really any device like that is going to be hooked up to at least a couple busses.. i2c, some sort of bus carrying pixel data, maybe some gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and then use phandle stuff to link it to the various other busses it needs: mydrmdev { foo-i2c-encoder { i2c = <&i2cN>; gpio = <&gpioM 2 3> ... }; }; ok, admittedly that is a bit different from other proposals about how this all fits in devicetree.. but otoh, I'm not a huge believer in letting something that is supposed to make life easier (DT), actually make things harder or more complicated. Plus this CDF stuff all needs to also work on platforms not using OF/DT. BR, -R > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 19:57 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 19:57 UTC (permalink / raw) To: Sascha Hauer Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart >> <laurent.pinchart@ideasonboard.com> wrote: >> > Hi Rob, >> > >> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: >> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >> >> >> Many developers showed interest in the first RFC, and I've had the >> >> >> opportunity to discuss it with most of them. I would like to thank (in >> >> >> no particular order) Tomi Valkeinen for all the time he spend helping me >> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect >> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to >> >> >> discuss this topic. >> >> > >> >> > So this might be a bit off topic but this whole CDF triggered me >> >> > looking at stuff I generally avoid: >> >> > >> >> > The biggest problem I'm having currently with the whole ARM graphics >> >> > and output world is the proliferation of platform drivers for every >> >> > little thing. The whole ordering of operations with respect to things >> >> > like suspend/resume or dynamic power management is going to be a real >> >> > nightmare if there are dependencies between the drivers. How do you >> >> > enforce ordering of s/r operations between all the various components? >> >> >> >> I tend to think that sub-devices are useful just to have a way to probe hw >> >> which may or may not be there, since on ARM we often don't have any >> >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, >> >> they should really be treated as all one device. Especially to avoid >> >> undefined suspend/resume ordering. >> > >> > I tend to agree, except that I try to reuse the existing PM infrastructure >> > when possible to avoid reinventing the wheel. So far handling suspend/resume >> > ordering related to data busses in early suspend/late resume operations and >> > allowing the Linux PM core to handle control busses using the Linux device >> > tree worked pretty well. >> > >> >> CDF or some sort of mechanism to share panel drivers between drivers is >> >> useful. Keeping it within drm, is probably a good idea, if nothing else to >> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and >> >> avoid dealing with merging changes across multiple trees. Treating them more >> >> like shared libraries and less like sub-devices which can be dynamically >> >> loaded/unloaded (ie. they should be not built as separate modules or >> >> suspend/resumed or probed/removed independently of the master driver) is a >> >> really good idea to avoid uncovering nasty synchronization issues later >> >> (remove vs modeset or pageflip) or surprising userspace in bad ways. >> > >> > We've tried that in V4L2 years ago and realized that the approach led to a >> > dead-end, especially when OF/DT got involved. With DT-based device probing, >> > I2C camera sensors started getting probed asynchronously to the main camera >> > device, as they are children of the I2C bus master. We will have similar >> > issues with I2C HDMI transmitters or panels, so we should be prepared for it. >> >> What I've done to avoid that so far is that the master device >> registers the drivers for it's output sub-devices before registering >> it's own device. At least this way I can control that they are probed >> first. Not the prettiest thing, but avoids even uglier problems. > > This implies that the master driver knows all potential subdevices, > something which is not true for SoCs which have external i2c encoders > attached to unrelated i2c controllers. well, it can be brute-forced.. ie. drm driver calls common register_all_panels() fxn, which, well, registers all the panel/display subdev's based on their corresponding CONFIG_FOO_PANEL defines. If you anyways aren't building the panels as separate modules, that would work. Maybe not the most *elegant* approach, but simple and functional. I guess it partly depends on the structure in devicetree. If you are assuming that the i2c encoder belongs inside the i2c bus, like: &i2cN { foo-i2c-encoder { .... }; }; and you are letting devicetree create the devices, then it doesn't quite work. I'm not entirely convinced you should do it that way. Really any device like that is going to be hooked up to at least a couple busses.. i2c, some sort of bus carrying pixel data, maybe some gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and then use phandle stuff to link it to the various other busses it needs: mydrmdev { foo-i2c-encoder { i2c = <&i2cN>; gpio = <&gpioM 2 3> ... }; }; ok, admittedly that is a bit different from other proposals about how this all fits in devicetree.. but otoh, I'm not a huge believer in letting something that is supposed to make life easier (DT), actually make things harder or more complicated. Plus this CDF stuff all needs to also work on platforms not using OF/DT. BR, -R > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 19:57 ` Rob Clark @ 2012-12-28 0:04 ` Sascha Hauer -1 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-28 0:04 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > This implies that the master driver knows all potential subdevices, > > something which is not true for SoCs which have external i2c encoders > > attached to unrelated i2c controllers. > > well, it can be brute-forced.. ie. drm driver calls common > register_all_panels() fxn, which, well, registers all the > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > defines. If you anyways aren't building the panels as separate > modules, that would work. Maybe not the most *elegant* approach, but > simple and functional. > > I guess it partly depends on the structure in devicetree. If you are > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > foo-i2c-encoder { > .... > }; > }; > > and you are letting devicetree create the devices, then it doesn't > quite work. I'm not entirely convinced you should do it that way. > Really any device like that is going to be hooked up to at least a > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > then use phandle stuff to link it to the various other busses it > needs: > > mydrmdev { > foo-i2c-encoder { > i2c = <&i2cN>; > gpio = <&gpioM 2 3> > ... > }; > }; This seems to shift initialization order problem to another place. Here we have to make sure the controller is initialized before the drm driver. Same with suspend/resume. It's not only i2c devices, also platform devices. On i.MX for example we have a hdmi transmitter which is somewhere on the physical address space. I think grouping the different units together in a devicetree blob because we think they might form a logical virtual device is not going to work. It might make it easier from a drm perspective, but I think doing this will make for a lot of special cases. What will happen for example if you have two encoder devices in a row to configure? The foo-i2c-encoder would then get another child node. Right now the devicetree is strictly ordered by (control-, not data-) bus topology. Linux has great helper code to support this model. Giving up this help to brute force a different topology and then trying to fit the result back into the Linux Bus hierarchy doesn't sound like a good idea to me. > > ok, admittedly that is a bit different from other proposals about how > this all fits in devicetree.. but otoh, I'm not a huge believer in > letting something that is supposed to make life easier (DT), actually > make things harder or more complicated. Plus this CDF stuff all needs > to also work on platforms not using OF/DT. Right, but every other platform I know of is also described by its bus topology, be it platform device based or PCI or maybe even USB based. CDF has to solve the same problem as ASoC and soc-camera: subdevices for a virtual device can come from many different corners of the system. BTW one example for a i2c encoder would be the SiI9022 which could not only be part of a drm device, but also of an ASoC device. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-28 0:04 ` Sascha Hauer 0 siblings, 0 replies; 153+ messages in thread From: Sascha Hauer @ 2012-12-28 0:04 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > This implies that the master driver knows all potential subdevices, > > something which is not true for SoCs which have external i2c encoders > > attached to unrelated i2c controllers. > > well, it can be brute-forced.. ie. drm driver calls common > register_all_panels() fxn, which, well, registers all the > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > defines. If you anyways aren't building the panels as separate > modules, that would work. Maybe not the most *elegant* approach, but > simple and functional. > > I guess it partly depends on the structure in devicetree. If you are > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > foo-i2c-encoder { > .... > }; > }; > > and you are letting devicetree create the devices, then it doesn't > quite work. I'm not entirely convinced you should do it that way. > Really any device like that is going to be hooked up to at least a > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > then use phandle stuff to link it to the various other busses it > needs: > > mydrmdev { > foo-i2c-encoder { > i2c = <&i2cN>; > gpio = <&gpioM 2 3> > ... > }; > }; This seems to shift initialization order problem to another place. Here we have to make sure the controller is initialized before the drm driver. Same with suspend/resume. It's not only i2c devices, also platform devices. On i.MX for example we have a hdmi transmitter which is somewhere on the physical address space. I think grouping the different units together in a devicetree blob because we think they might form a logical virtual device is not going to work. It might make it easier from a drm perspective, but I think doing this will make for a lot of special cases. What will happen for example if you have two encoder devices in a row to configure? The foo-i2c-encoder would then get another child node. Right now the devicetree is strictly ordered by (control-, not data-) bus topology. Linux has great helper code to support this model. Giving up this help to brute force a different topology and then trying to fit the result back into the Linux Bus hierarchy doesn't sound like a good idea to me. > > ok, admittedly that is a bit different from other proposals about how > this all fits in devicetree.. but otoh, I'm not a huge believer in > letting something that is supposed to make life easier (DT), actually > make things harder or more complicated. Plus this CDF stuff all needs > to also work on platforms not using OF/DT. Right, but every other platform I know of is also described by its bus topology, be it platform device based or PCI or maybe even USB based. CDF has to solve the same problem as ASoC and soc-camera: subdevices for a virtual device can come from many different corners of the system. BTW one example for a i2c encoder would be the SiI9022 which could not only be part of a drm device, but also of an ASoC device. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-28 0:04 ` Sascha Hauer @ 2013-01-08 8:33 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:33 UTC (permalink / raw) To: Sascha Hauer Cc: Rob Clark, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Friday 28 December 2012 01:04:04 Sascha Hauer wrote: > On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote: > > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > > > This implies that the master driver knows all potential subdevices, > > > something which is not true for SoCs which have external i2c encoders > > > attached to unrelated i2c controllers. > > > > well, it can be brute-forced.. ie. drm driver calls common > > register_all_panels() fxn, which, well, registers all the > > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > > defines. If you anyways aren't building the panels as separate > > modules, that would work. Maybe not the most *elegant* approach, but > > simple and functional. > > > > I guess it partly depends on the structure in devicetree. If you are > > > > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > > > > foo-i2c-encoder { > > > > .... > > > > }; > > > > }; > > > > and you are letting devicetree create the devices, then it doesn't > > quite work. I'm not entirely convinced you should do it that way. > > Really any device like that is going to be hooked up to at least a > > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > > then use phandle stuff to link it to the various other busses it > > > > needs: > > mydrmdev { > > foo-i2c-encoder { > > i2c = <&i2cN>; > > gpio = <&gpioM 2 3> > > ... > > }; > > }; > > This seems to shift initialization order problem to another place. Here we > have to make sure the controller is initialized before the drm driver. Same > with suspend/resume. > > It's not only i2c devices, also platform devices. On i.MX for example we > have a hdmi transmitter which is somewhere on the physical address space. > > I think grouping the different units together in a devicetree blob because > we think they might form a logical virtual device is not going to work. It > might make it easier from a drm perspective, but I think doing this will > make for a lot of special cases. What will happen for example if you have > two encoder devices in a row to configure? The foo-i2c-encoder would then > get another child node. > > Right now the devicetree is strictly ordered by (control-, not data-) bus > topology. Linux has great helper code to support this model. Giving up this > help to brute force a different topology and then trying to fit the result > back into the Linux Bus hierarchy doesn't sound like a good idea to me. I agree. The Linux device model is architectured around a control bus based tree, I don't want to change that. With devices hooked up on several busses we will have dependency issues anyway, regardless of how we describe them in DT. If we hook up the nodes from a data bus perspective we will run into control bus dependency issues. It's thus better in my opinion to keep the classic control bus based model and solve the data bus dependency issues. > > ok, admittedly that is a bit different from other proposals about how > > this all fits in devicetree.. but otoh, I'm not a huge believer in > > letting something that is supposed to make life easier (DT), actually > > make things harder or more complicated. Plus this CDF stuff all needs > > to also work on platforms not using OF/DT. > > Right, but every other platform I know of is also described by its bus > topology, be it platform device based or PCI or maybe even USB based. > > CDF has to solve the same problem as ASoC and soc-camera: subdevices for > a virtual device can come from many different corners of the system. BTW > one example for a i2c encoder would be the SiI9022 which could not only > be part of a drm device, but also of an ASoC device. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 8:33 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:33 UTC (permalink / raw) To: Sascha Hauer Cc: Rob Clark, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Friday 28 December 2012 01:04:04 Sascha Hauer wrote: > On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote: > > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > > > This implies that the master driver knows all potential subdevices, > > > something which is not true for SoCs which have external i2c encoders > > > attached to unrelated i2c controllers. > > > > well, it can be brute-forced.. ie. drm driver calls common > > register_all_panels() fxn, which, well, registers all the > > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > > defines. If you anyways aren't building the panels as separate > > modules, that would work. Maybe not the most *elegant* approach, but > > simple and functional. > > > > I guess it partly depends on the structure in devicetree. If you are > > > > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > > > > foo-i2c-encoder { > > > > .... > > > > }; > > > > }; > > > > and you are letting devicetree create the devices, then it doesn't > > quite work. I'm not entirely convinced you should do it that way. > > Really any device like that is going to be hooked up to at least a > > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > > then use phandle stuff to link it to the various other busses it > > > > needs: > > mydrmdev { > > foo-i2c-encoder { > > i2c = <&i2cN>; > > gpio = <&gpioM 2 3> > > ... > > }; > > }; > > This seems to shift initialization order problem to another place. Here we > have to make sure the controller is initialized before the drm driver. Same > with suspend/resume. > > It's not only i2c devices, also platform devices. On i.MX for example we > have a hdmi transmitter which is somewhere on the physical address space. > > I think grouping the different units together in a devicetree blob because > we think they might form a logical virtual device is not going to work. It > might make it easier from a drm perspective, but I think doing this will > make for a lot of special cases. What will happen for example if you have > two encoder devices in a row to configure? The foo-i2c-encoder would then > get another child node. > > Right now the devicetree is strictly ordered by (control-, not data-) bus > topology. Linux has great helper code to support this model. Giving up this > help to brute force a different topology and then trying to fit the result > back into the Linux Bus hierarchy doesn't sound like a good idea to me. I agree. The Linux device model is architectured around a control bus based tree, I don't want to change that. With devices hooked up on several busses we will have dependency issues anyway, regardless of how we describe them in DT. If we hook up the nodes from a data bus perspective we will run into control bus dependency issues. It's thus better in my opinion to keep the classic control bus based model and solve the data bus dependency issues. > > ok, admittedly that is a bit different from other proposals about how > > this all fits in devicetree.. but otoh, I'm not a huge believer in > > letting something that is supposed to make life easier (DT), actually > > make things harder or more complicated. Plus this CDF stuff all needs > > to also work on platforms not using OF/DT. > > Right, but every other platform I know of is also described by its bus > topology, be it platform device based or PCI or maybe even USB based. > > CDF has to solve the same problem as ASoC and soc-camera: subdevices for > a virtual device can come from many different corners of the system. BTW > one example for a i2c encoder would be the SiI9022 which could not only > be part of a drm device, but also of an ASoC device. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 15:54 ` Rob Clark @ 2013-01-08 8:25 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:25 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Thursday 27 December 2012 09:54:55 Rob Clark wrote: > On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart wrote: > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> >> Many developers showed interest in the first RFC, and I've had the > >> >> opportunity to discuss it with most of them. I would like to thank (in > >> >> no particular order) Tomi Valkeinen for all the time he spend helping > >> >> me to draft v2, Marcus Lorentzon for his useful input during Linaro > >> >> Connect Q4 2012, and Linaro for inviting me to Connect and providing a > >> >> venue to discuss this topic. > >> > > >> > So this might be a bit off topic but this whole CDF triggered me > >> > looking at stuff I generally avoid: > >> > > >> > The biggest problem I'm having currently with the whole ARM graphics > >> > and output world is the proliferation of platform drivers for every > >> > little thing. The whole ordering of operations with respect to things > >> > like suspend/resume or dynamic power management is going to be a real > >> > nightmare if there are dependencies between the drivers. How do you > >> > enforce ordering of s/r operations between all the various components? > >> > >> I tend to think that sub-devices are useful just to have a way to probe > >> hw which may or may not be there, since on ARM we often don't have any > >> alternative.. but beyond that, suspend/resume, and other life-cycle > >> aspects, they should really be treated as all one device. Especially to > >> avoid undefined suspend/resume ordering. > > > > I tend to agree, except that I try to reuse the existing PM infrastructure > > when possible to avoid reinventing the wheel. So far handling > > suspend/resume ordering related to data busses in early suspend/late > > resume operations and allowing the Linux PM core to handle control busses > > using the Linux device tree worked pretty well. > > > >> CDF or some sort of mechanism to share panel drivers between drivers is > >> useful. Keeping it within drm, is probably a good idea, if nothing else > >> to simplify re-use of helper fxns (like avi-infoframe stuff, for example) > >> and avoid dealing with merging changes across multiple trees. Treating > >> them more like shared libraries and less like sub-devices which can be > >> dynamically loaded/unloaded (ie. they should be not built as separate > >> modules or suspend/resumed or probed/removed independently of the master > >> driver) is a really good idea to avoid uncovering nasty synchronization > >> issues later (remove vs modeset or pageflip) or surprising userspace in > >> bad ways. > > > > We've tried that in V4L2 years ago and realized that the approach led to a > > dead-end, especially when OF/DT got involved. With DT-based device > > probing, I2C camera sensors started getting probed asynchronously to the > > main camera device, as they are children of the I2C bus master. We will > > have similar issues with I2C HDMI transmitters or panels, so we should be > > prepared for it. > > What I've done to avoid that so far is that the master device registers the > drivers for it's output sub-devices before registering it's own device. I'm not sure to follow you here. The master device doesn't register anything, do you mean the master device driver ? If so, how does the master device driver register its own device ? Devices are not registered by their driver. > At least this way I can control that they are probed first. Not the > prettiest thing, but avoids even uglier problems. > > > On PC hardware the I2C devices are connected to an I2C master provided by > > the GPU, but on embedded devices they are usually connected to an > > independent I2C master. We thus can't have a single self-contained driver > > that controls everything internally, and need to interface with the rest > > of the SoC drivers. > > > > I agree that probing/removing devices independently of the master driver > > can lead to bad surprises, which is why I want to establish clear rules > > in CDF regarding what can and can't be done with display entities. > > Reference counting will be one way to make sure that devices don't > > disappear all of a sudden. > > That at least helps cover some issues.. although it doesn't really help > userspace confusion. > > Anyways, with enough work perhaps all problems could be solved.. otoh, there > are plenty of other important problems to solve in the world of gpus and > kms, so my preference is always not to needlessly over-complicate CDF and > instead leave some time for other things My customer is interested in CDF at the moment. If they ask me to solve other GPU-related problems, sure, I can work on that, but that's not planned. > >> > The other thing I'd like you guys to do is kill the idea of fbdev and > >> > v4l drivers that are "shared" with the drm codebase, really just > >> > implement fbdev and v4l on top of the drm layer, some people might > >> > think this is some sort of maintainer thing, but really nothing else > >> > makes sense, and having these shared display frameworks just to avoid > >> > having using drm/kms drivers seems totally pointless. Fix the drm > >> > fbdev emulation if an fbdev interface is needed. But creating a fourth > >> > framework because our previous 3 frameworks didn't work out doesn't > >> > seem like a situation I want to get behind too much. > >> > >> yeah, let's not have multiple frameworks to do the same thing.. For > >> fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), > >> it is perhaps bit more flexible when it comes to random arbitrary hw > >> pipelines than kms. But to take advantage of that, your userspace isn't > >> going to be portable anyways, so you might as well use driver specific > >> properties/ioctls. But I tend to think that is more useful for cameras. > >> And from userspace perspective, kms planes are less painful to use for > >> output than v4l2, so lets stick to drm/kms for output (and not try to add > >> camera/capture support to kms).. > > > > Agreed. I've started to advocate the deprecation of FBDEV during LPC. The > > positive response has motivated me to continue doing so :-) For V4L2 the > > situation is a little bit different, I think V4L2 shouldn't be used for > > graphics and display hardware, but it still has use cases on the video > > output side for pure video devices (such as pass-through video pipelines > > with embedded processing for instance). As those can use subdevices found > > in display and graphics hardware, I'd like to avoid code duplication. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 8:25 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:25 UTC (permalink / raw) To: Rob Clark Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rob, On Thursday 27 December 2012 09:54:55 Rob Clark wrote: > On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart wrote: > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: > >> >> Many developers showed interest in the first RFC, and I've had the > >> >> opportunity to discuss it with most of them. I would like to thank (in > >> >> no particular order) Tomi Valkeinen for all the time he spend helping > >> >> me to draft v2, Marcus Lorentzon for his useful input during Linaro > >> >> Connect Q4 2012, and Linaro for inviting me to Connect and providing a > >> >> venue to discuss this topic. > >> > > >> > So this might be a bit off topic but this whole CDF triggered me > >> > looking at stuff I generally avoid: > >> > > >> > The biggest problem I'm having currently with the whole ARM graphics > >> > and output world is the proliferation of platform drivers for every > >> > little thing. The whole ordering of operations with respect to things > >> > like suspend/resume or dynamic power management is going to be a real > >> > nightmare if there are dependencies between the drivers. How do you > >> > enforce ordering of s/r operations between all the various components? > >> > >> I tend to think that sub-devices are useful just to have a way to probe > >> hw which may or may not be there, since on ARM we often don't have any > >> alternative.. but beyond that, suspend/resume, and other life-cycle > >> aspects, they should really be treated as all one device. Especially to > >> avoid undefined suspend/resume ordering. > > > > I tend to agree, except that I try to reuse the existing PM infrastructure > > when possible to avoid reinventing the wheel. So far handling > > suspend/resume ordering related to data busses in early suspend/late > > resume operations and allowing the Linux PM core to handle control busses > > using the Linux device tree worked pretty well. > > > >> CDF or some sort of mechanism to share panel drivers between drivers is > >> useful. Keeping it within drm, is probably a good idea, if nothing else > >> to simplify re-use of helper fxns (like avi-infoframe stuff, for example) > >> and avoid dealing with merging changes across multiple trees. Treating > >> them more like shared libraries and less like sub-devices which can be > >> dynamically loaded/unloaded (ie. they should be not built as separate > >> modules or suspend/resumed or probed/removed independently of the master > >> driver) is a really good idea to avoid uncovering nasty synchronization > >> issues later (remove vs modeset or pageflip) or surprising userspace in > >> bad ways. > > > > We've tried that in V4L2 years ago and realized that the approach led to a > > dead-end, especially when OF/DT got involved. With DT-based device > > probing, I2C camera sensors started getting probed asynchronously to the > > main camera device, as they are children of the I2C bus master. We will > > have similar issues with I2C HDMI transmitters or panels, so we should be > > prepared for it. > > What I've done to avoid that so far is that the master device registers the > drivers for it's output sub-devices before registering it's own device. I'm not sure to follow you here. The master device doesn't register anything, do you mean the master device driver ? If so, how does the master device driver register its own device ? Devices are not registered by their driver. > At least this way I can control that they are probed first. Not the > prettiest thing, but avoids even uglier problems. > > > On PC hardware the I2C devices are connected to an I2C master provided by > > the GPU, but on embedded devices they are usually connected to an > > independent I2C master. We thus can't have a single self-contained driver > > that controls everything internally, and need to interface with the rest > > of the SoC drivers. > > > > I agree that probing/removing devices independently of the master driver > > can lead to bad surprises, which is why I want to establish clear rules > > in CDF regarding what can and can't be done with display entities. > > Reference counting will be one way to make sure that devices don't > > disappear all of a sudden. > > That at least helps cover some issues.. although it doesn't really help > userspace confusion. > > Anyways, with enough work perhaps all problems could be solved.. otoh, there > are plenty of other important problems to solve in the world of gpus and > kms, so my preference is always not to needlessly over-complicate CDF and > instead leave some time for other things My customer is interested in CDF at the moment. If they ask me to solve other GPU-related problems, sure, I can work on that, but that's not planned. > >> > The other thing I'd like you guys to do is kill the idea of fbdev and > >> > v4l drivers that are "shared" with the drm codebase, really just > >> > implement fbdev and v4l on top of the drm layer, some people might > >> > think this is some sort of maintainer thing, but really nothing else > >> > makes sense, and having these shared display frameworks just to avoid > >> > having using drm/kms drivers seems totally pointless. Fix the drm > >> > fbdev emulation if an fbdev interface is needed. But creating a fourth > >> > framework because our previous 3 frameworks didn't work out doesn't > >> > seem like a situation I want to get behind too much. > >> > >> yeah, let's not have multiple frameworks to do the same thing.. For > >> fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), > >> it is perhaps bit more flexible when it comes to random arbitrary hw > >> pipelines than kms. But to take advantage of that, your userspace isn't > >> going to be portable anyways, so you might as well use driver specific > >> properties/ioctls. But I tend to think that is more useful for cameras. > >> And from userspace perspective, kms planes are less painful to use for > >> output than v4l2, so lets stick to drm/kms for output (and not try to add > >> camera/capture support to kms).. > > > > Agreed. I've started to advocate the deprecation of FBDEV during LPC. The > > positive response has motivated me to continue doing so :-) For V4L2 the > > situation is a little bit different, I think V4L2 shouldn't be used for > > graphics and display hardware, but it still has use cases on the video > > output side for pure video devices (such as pass-through video pipelines > > with embedded processing for instance). As those can use subdevices found > > in display and graphics hardware, I'd like to avoid code duplication. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 8:25 ` Laurent Pinchart @ 2013-01-08 16:13 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2013-01-08 16:13 UTC (permalink / raw) To: Laurent Pinchart Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rob, > > On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >> What I've done to avoid that so far is that the master device registers the >> drivers for it's output sub-devices before registering it's own device. > > I'm not sure to follow you here. The master device doesn't register anything, > do you mean the master device driver ? If so, how does the master device > driver register its own device ? Devices are not registered by their driver. sorry, that should have read "master driver registers drivers for it's sub-devices.." BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 16:13 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2013-01-08 16:13 UTC (permalink / raw) To: Laurent Pinchart Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rob, > > On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >> What I've done to avoid that so far is that the master device registers the >> drivers for it's output sub-devices before registering it's own device. > > I'm not sure to follow you here. The master device doesn't register anything, > do you mean the master device driver ? If so, how does the master device > driver register its own device ? Devices are not registered by their driver. sorry, that should have read "master driver registers drivers for it's sub-devices.." BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-08 16:13 ` Rob Clark (?) @ 2013-01-09 8:23 ` Rahul Sharma -1 siblings, 0 replies; 153+ messages in thread From: Rahul Sharma @ 2013-01-09 8:35 UTC (permalink / raw) To: Rob Clark Cc: Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Laurent Pinchart, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-09 8:23 ` Rahul Sharma 0 siblings, 0 replies; 153+ messages in thread From: Rahul Sharma @ 2013-01-09 8:23 UTC (permalink / raw) To: Rob Clark Cc: Thomas Petazzoni, Linux Fbdev development list, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Tomi Valkeinen, Laurent Pinchart, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-09 8:23 ` Rahul Sharma 0 siblings, 0 replies; 153+ messages in thread From: Rahul Sharma @ 2013-01-09 8:23 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-09 8:23 ` Rahul Sharma @ 2013-02-01 23:42 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:42 UTC (permalink / raw) To: Rahul Sharma Cc: Rob Clark, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rahul, On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: > Hi Laurent, > > CDF will also be helpful in supporting Panels with integrated audio > (HDMI/DP) if we can add audio related control operations to > display_entity_control_ops. Video controls will be called by crtc in DRM/V4L > and audio controls from Alsa. I knew that would come up at some point :-) I agree with you that adding audio support would be a very nice improvement, and I'm totally open to that, but I will concentrate on video, at least to start with. The first reason is that I'm not familiar enough with ALSA, and the second that there's only 24h per day :-) Please feel free, of course, to submit a proposal for audio support. > Secondly, if I need to support get_modes operation in hdmi/dp panel, I need > to implement edid parser inside the panel driver. It will be meaningful to > add get_edid control operation for hdmi/dp. Even if EDID data is parsed in the panel driver, raw EDID will still need to be exported, so a get_edid control operation (or something similar) is definitely needed. There's no disagreement on this, I just haven't included that operation yet because my test hardware is purely panel-based. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-01 23:42 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-02-01 23:42 UTC (permalink / raw) To: Rahul Sharma Cc: Rob Clark, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media Hi Rahul, On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: > Hi Laurent, > > CDF will also be helpful in supporting Panels with integrated audio > (HDMI/DP) if we can add audio related control operations to > display_entity_control_ops. Video controls will be called by crtc in DRM/V4L > and audio controls from Alsa. I knew that would come up at some point :-) I agree with you that adding audio support would be a very nice improvement, and I'm totally open to that, but I will concentrate on video, at least to start with. The first reason is that I'm not familiar enough with ALSA, and the second that there's only 24h per day :-) Please feel free, of course, to submit a proposal for audio support. > Secondly, if I need to support get_modes operation in hdmi/dp panel, I need > to implement edid parser inside the panel driver. It will be meaningful to > add get_edid control operation for hdmi/dp. Even if EDID data is parsed in the panel driver, raw EDID will still need to be exported, so a get_edid control operation (or something similar) is definitely needed. There's no disagreement on this, I just haven't included that operation yet because my test hardware is purely panel-based. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-02-01 23:42 ` Laurent Pinchart @ 2013-02-02 10:08 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2013-02-02 10:08 UTC (permalink / raw) To: Laurent Pinchart Cc: Rahul Sharma, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rahul, > > On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: >> Hi Laurent, >> >> CDF will also be helpful in supporting Panels with integrated audio >> (HDMI/DP) if we can add audio related control operations to >> display_entity_control_ops. Video controls will be called by crtc in DRM/V4L >> and audio controls from Alsa. > > I knew that would come up at some point :-) I agree with you that adding audio > support would be a very nice improvement, and I'm totally open to that, but I > will concentrate on video, at least to start with. The first reason is that > I'm not familiar enough with ALSA, and the second that there's only 24h per > day :-) > > Please feel free, of course, to submit a proposal for audio support. > >> Secondly, if I need to support get_modes operation in hdmi/dp panel, I need >> to implement edid parser inside the panel driver. It will be meaningful to >> add get_edid control operation for hdmi/dp. > > Even if EDID data is parsed in the panel driver, raw EDID will still need to > be exported, so a get_edid control operation (or something similar) is > definitely needed. There's no disagreement on this, I just haven't included > that operation yet because my test hardware is purely panel-based. one of (probably many) places that just keeping CDF (CDH? common display helpers..) inside DRM makes life easier :-P BR, -R > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-02-02 10:08 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2013-02-02 10:08 UTC (permalink / raw) To: Laurent Pinchart Cc: Rahul Sharma, Thomas Petazzoni, Linux Fbdev development list, Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Rahul, > > On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: >> Hi Laurent, >> >> CDF will also be helpful in supporting Panels with integrated audio >> (HDMI/DP) if we can add audio related control operations to >> display_entity_control_ops. Video controls will be called by crtc in DRM/V4L >> and audio controls from Alsa. > > I knew that would come up at some point :-) I agree with you that adding audio > support would be a very nice improvement, and I'm totally open to that, but I > will concentrate on video, at least to start with. The first reason is that > I'm not familiar enough with ALSA, and the second that there's only 24h per > day :-) > > Please feel free, of course, to submit a proposal for audio support. > >> Secondly, if I need to support get_modes operation in hdmi/dp panel, I need >> to implement edid parser inside the panel driver. It will be meaningful to >> add get_edid control operation for hdmi/dp. > > Even if EDID data is parsed in the panel driver, raw EDID will still need to > be exported, so a get_edid control operation (or something similar) is > definitely needed. There's no disagreement on this, I just haven't included > that operation yet because my test hardware is purely panel-based. one of (probably many) places that just keeping CDF (CDH? common display helpers..) inside DRM makes life easier :-P BR, -R > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 5:04 ` Dave Airlie (?) @ 2012-12-18 10:39 ` Marcus Lorentzon -1 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2012-12-18 10:39 UTC (permalink / raw) To: Dave Airlie Cc: Laurent Pinchart, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan, marcus.lorentzon On 12/18/2012 06:04 AM, Dave Airlie wrote: >> Many developers showed interest in the first RFC, and I've had the opportunity >> to discuss it with most of them. I would like to thank (in no particular >> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >> inviting me to Connect and providing a venue to discuss this topic. >> > So this might be a bit off topic but this whole CDF triggered me > looking at stuff I generally avoid: I like the effort, right now it seems like x86 and arm display sub systems are quite different in terms of DRM driver (and HW) design. I think this is partly due to little information shared about these different architectures and ideas behind the choices made. I hope some discussion will light up both sides. And an early discussion will hopefully give you less pain when CDF drivers starts to get pushed your way. > The biggest problem I'm having currently with the whole ARM graphics > and output world is the proliferation of platform drivers for every > little thing. The whole ordering of operations with respect to things > like suspend/resume or dynamic power management is going to be a real > nightmare if there are dependencies between the drivers. How do you > enforce ordering of s/r operations between all the various components? Could you give an example? Personally I don't think it is that many. I might not have counted the plat devs in all arm drivers. But the STE one have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). Then of course there are all these panel devices. But I hope that when CDF is "finished" we will have DSI devices on the DSI bus and DBI devices on the DBI bus. I think most vendors have used platform devices for these since they normally can't be probed in a generic way. But as they are off SoC I feel this is not the best choice. And then many of the panels are I2C devices (control bus) and that I guess is similar to "x86" encoders/connectors? Another part of the difference I feel is that in x86 a DRM device is most likely a PCI device, and as such has one huge driver for all IPs on that board. The closest thing we get to that in ARM is probably the DSS (collection of IPs on SoC, like 3D, 2D, display output, encoders). But it doesn't fell right to create a single driver for all these. And as you know often 3D is even from a separate vendor. All these lead up to a slight increase in the number of devices and drivers. Right way, I feel so, but you are welcome to show a better way. > The other thing I'd like you guys to do is kill the idea of fbdev and > v4l drivers that are "shared" with the drm codebase, really just > implement fbdev and v4l on top of the drm layer, some people might > think this is some sort of maintainer thing, but really nothing else > makes sense, and having these shared display frameworks just to avoid > having using drm/kms drivers seems totally pointless. Fix the drm > fbdev emulation if an fbdev interface is needed. But creating a fourth > framework because our previous 3 frameworks didn't work out doesn't > seem like a situation I want to get behind too much. > I have no intention to use CDF outside KMS connector/encoder and I have not heard Laurent talk about this either. Personally I see CDF as "helpers" to create and reuse connector/encoder drivers between SoCs instead of each SoC do their own panel drivers (which would be about a hundred, times the number of supported SoCs). We probably need to discuss the connector/encoder mappings to CDF/panels. But I think we need to flush out the higher level details like control bus vs. data bus vs. display entities. While I like the generic way of the display entities, I also like the pure bus/device/driver model without too many generalizations. Do you have any support in x86 world that could be compared to mobile phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips between the on chip/cpu/SoC CRTC and the external LCD depending on product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? And if you do, how do you model/setup/share all those in DRM driver? Or it is manageable (< 10) and not up in the hundreds of different encoders/lcd-drivers? /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 10:39 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2012-12-18 10:39 UTC (permalink / raw) To: Dave Airlie Cc: Laurent Pinchart, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen On 12/18/2012 06:04 AM, Dave Airlie wrote: >> Many developers showed interest in the first RFC, and I've had the opportunity >> to discuss it with most of them. I would like to thank (in no particular >> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >> inviting me to Connect and providing a venue to discuss this topic. >> > So this might be a bit off topic but this whole CDF triggered me > looking at stuff I generally avoid: I like the effort, right now it seems like x86 and arm display sub systems are quite different in terms of DRM driver (and HW) design. I think this is partly due to little information shared about these different architectures and ideas behind the choices made. I hope some discussion will light up both sides. And an early discussion will hopefully give you less pain when CDF drivers starts to get pushed your way. > The biggest problem I'm having currently with the whole ARM graphics > and output world is the proliferation of platform drivers for every > little thing. The whole ordering of operations with respect to things > like suspend/resume or dynamic power management is going to be a real > nightmare if there are dependencies between the drivers. How do you > enforce ordering of s/r operations between all the various components? Could you give an example? Personally I don't think it is that many. I might not have counted the plat devs in all arm drivers. But the STE one have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). Then of course there are all these panel devices. But I hope that when CDF is "finished" we will have DSI devices on the DSI bus and DBI devices on the DBI bus. I think most vendors have used platform devices for these since they normally can't be probed in a generic way. But as they are off SoC I feel this is not the best choice. And then many of the panels are I2C devices (control bus) and that I guess is similar to "x86" encoders/connectors? Another part of the difference I feel is that in x86 a DRM device is most likely a PCI device, and as such has one huge driver for all IPs on that board. The closest thing we get to that in ARM is probably the DSS (collection of IPs on SoC, like 3D, 2D, display output, encoders). But it doesn't fell right to create a single driver for all these. And as you know often 3D is even from a separate vendor. All these lead up to a slight increase in the number of devices and drivers. Right way, I feel so, but you are welcome to show a better way. > The other thing I'd like you guys to do is kill the idea of fbdev and > v4l drivers that are "shared" with the drm codebase, really just > implement fbdev and v4l on top of the drm layer, some people might > think this is some sort of maintainer thing, but really nothing else > makes sense, and having these shared display frameworks just to avoid > having using drm/kms drivers seems totally pointless. Fix the drm > fbdev emulation if an fbdev interface is needed. But creating a fourth > framework because our previous 3 frameworks didn't work out doesn't > seem like a situation I want to get behind too much. > I have no intention to use CDF outside KMS connector/encoder and I have not heard Laurent talk about this either. Personally I see CDF as "helpers" to create and reuse connector/encoder drivers between SoCs instead of each SoC do their own panel drivers (which would be about a hundred, times the number of supported SoCs). We probably need to discuss the connector/encoder mappings to CDF/panels. But I think we need to flush out the higher level details like control bus vs. data bus vs. display entities. While I like the generic way of the display entities, I also like the pure bus/device/driver model without too many generalizations. Do you have any support in x86 world that could be compared to mobile phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips between the on chip/cpu/SoC CRTC and the external LCD depending on product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? And if you do, how do you model/setup/share all those in DRM driver? Or it is manageable (< 10) and not up in the hundreds of different encoders/lcd-drivers? /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-18 10:39 ` Marcus Lorentzon 0 siblings, 0 replies; 153+ messages in thread From: Marcus Lorentzon @ 2012-12-18 10:39 UTC (permalink / raw) To: Dave Airlie Cc: Laurent Pinchart, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen On 12/18/2012 06:04 AM, Dave Airlie wrote: >> Many developers showed interest in the first RFC, and I've had the opportunity >> to discuss it with most of them. I would like to thank (in no particular >> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >> inviting me to Connect and providing a venue to discuss this topic. >> > So this might be a bit off topic but this whole CDF triggered me > looking at stuff I generally avoid: I like the effort, right now it seems like x86 and arm display sub systems are quite different in terms of DRM driver (and HW) design. I think this is partly due to little information shared about these different architectures and ideas behind the choices made. I hope some discussion will light up both sides. And an early discussion will hopefully give you less pain when CDF drivers starts to get pushed your way. > The biggest problem I'm having currently with the whole ARM graphics > and output world is the proliferation of platform drivers for every > little thing. The whole ordering of operations with respect to things > like suspend/resume or dynamic power management is going to be a real > nightmare if there are dependencies between the drivers. How do you > enforce ordering of s/r operations between all the various components? Could you give an example? Personally I don't think it is that many. I might not have counted the plat devs in all arm drivers. But the STE one have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). Then of course there are all these panel devices. But I hope that when CDF is "finished" we will have DSI devices on the DSI bus and DBI devices on the DBI bus. I think most vendors have used platform devices for these since they normally can't be probed in a generic way. But as they are off SoC I feel this is not the best choice. And then many of the panels are I2C devices (control bus) and that I guess is similar to "x86" encoders/connectors? Another part of the difference I feel is that in x86 a DRM device is most likely a PCI device, and as such has one huge driver for all IPs on that board. The closest thing we get to that in ARM is probably the DSS (collection of IPs on SoC, like 3D, 2D, display output, encoders). But it doesn't fell right to create a single driver for all these. And as you know often 3D is even from a separate vendor. All these lead up to a slight increase in the number of devices and drivers. Right way, I feel so, but you are welcome to show a better way. > The other thing I'd like you guys to do is kill the idea of fbdev and > v4l drivers that are "shared" with the drm codebase, really just > implement fbdev and v4l on top of the drm layer, some people might > think this is some sort of maintainer thing, but really nothing else > makes sense, and having these shared display frameworks just to avoid > having using drm/kms drivers seems totally pointless. Fix the drm > fbdev emulation if an fbdev interface is needed. But creating a fourth > framework because our previous 3 frameworks didn't work out doesn't > seem like a situation I want to get behind too much. > I have no intention to use CDF outside KMS connector/encoder and I have not heard Laurent talk about this either. Personally I see CDF as "helpers" to create and reuse connector/encoder drivers between SoCs instead of each SoC do their own panel drivers (which would be about a hundred, times the number of supported SoCs). We probably need to discuss the connector/encoder mappings to CDF/panels. But I think we need to flush out the higher level details like control bus vs. data bus vs. display entities. While I like the generic way of the display entities, I also like the pure bus/device/driver model without too many generalizations. Do you have any support in x86 world that could be compared to mobile phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips between the on chip/cpu/SoC CRTC and the external LCD depending on product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? And if you do, how do you model/setup/share all those in DRM driver? Or it is manageable (< 10) and not up in the hundreds of different encoders/lcd-drivers? /BR /Marcus ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 10:39 ` Marcus Lorentzon (?) @ 2012-12-24 17:09 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:09 UTC (permalink / raw) To: Marcus Lorentzon Cc: Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan, marcus.lorentzon Hi Marcus, On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote: > On 12/18/2012 06:04 AM, Dave Airlie wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > I like the effort, right now it seems like x86 and arm display sub systems > are quite different in terms of DRM driver (and HW) design. I think this is > partly due to little information shared about these different architectures > and ideas behind the choices made. I hope some discussion will light up both > sides. And an early discussion will hopefully give you less pain when CDF > drivers starts to get pushed your way. On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > Could you give an example? Personally I don't think it is that many. I > might not have counted the plat devs in all arm drivers. But the STE one > have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). > Then of course there are all these panel devices. But I hope that when > CDF is "finished" we will have DSI devices on the DSI bus and DBI > devices on the DBI bus. I think most vendors have used platform devices > for these since they normally can't be probed in a generic way. But as > they are off SoC I feel this is not the best choice. And then many of > the panels are I2C devices (control bus) and that I guess is similar to > "x86" encoders/connectors? Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the platform bus. Although I still believe that DSI and DBI busses would make sense, I agree that they don't provide much in terms of probing and power management. You can read the discussion at http://www.spinics.net/lists/linux- fbdev/msg09250.html. > Another part of the difference I feel is that in x86 a DRM device is > most likely a PCI device, and as such has one huge driver for all IPs on > that board. The closest thing we get to that in ARM is probably the DSS > (collection of IPs on SoC, like 3D, 2D, display output, encoders). But > it doesn't fell right to create a single driver for all these. And as > you know often 3D is even from a separate vendor. All these lead up to a > slight increase in the number of devices and drivers. Right way, I feel > so, but you are welcome to show a better way. > > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > I have no intention to use CDF outside KMS connector/encoder and I have > not heard Laurent talk about this either. I don't either. CDF will mostly target KMS connectors, and can also be used for KMS encoders. I have no plan to touch the CRTC. > Personally I see CDF as "helpers" to create and reuse connector/encoder > drivers between SoCs instead of each SoC do their own panel drivers (which > would be about a hundred, times the number of supported SoCs). We probably > need to discuss the connector/encoder mappings to CDF/panels. That's a topic I was planning to discuss at some point. One of the issues is that the KMS model can only have 3 entities in the pipeline, while hardware pipelines (especially in the embedded world) could be made of 4 or more entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI connector). We might not have to expose all details to userspace, but we need mapping rules. > But I think we need to flush out the higher level details like control bus > vs. data bus vs. display entities. While I like the generic way of the > display entities, I also like the pure bus/device/driver model without too > many generalizations. > Do you have any support in x86 world that could be compared to mobile > phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips > between the on chip/cpu/SoC CRTC and the external LCD depending on > product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? > And if you do, how do you model/setup/share all those in DRM driver? Or > it is manageable (< 10) and not up in the hundreds of different > encoders/lcd-drivers? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:09 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:09 UTC (permalink / raw) To: Marcus Lorentzon Cc: Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Hi Marcus, On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote: > On 12/18/2012 06:04 AM, Dave Airlie wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > I like the effort, right now it seems like x86 and arm display sub systems > are quite different in terms of DRM driver (and HW) design. I think this is > partly due to little information shared about these different architectures > and ideas behind the choices made. I hope some discussion will light up both > sides. And an early discussion will hopefully give you less pain when CDF > drivers starts to get pushed your way. On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > Could you give an example? Personally I don't think it is that many. I > might not have counted the plat devs in all arm drivers. But the STE one > have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). > Then of course there are all these panel devices. But I hope that when > CDF is "finished" we will have DSI devices on the DSI bus and DBI > devices on the DBI bus. I think most vendors have used platform devices > for these since they normally can't be probed in a generic way. But as > they are off SoC I feel this is not the best choice. And then many of > the panels are I2C devices (control bus) and that I guess is similar to > "x86" encoders/connectors? Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the platform bus. Although I still believe that DSI and DBI busses would make sense, I agree that they don't provide much in terms of probing and power management. You can read the discussion at http://www.spinics.net/lists/linux- fbdev/msg09250.html. > Another part of the difference I feel is that in x86 a DRM device is > most likely a PCI device, and as such has one huge driver for all IPs on > that board. The closest thing we get to that in ARM is probably the DSS > (collection of IPs on SoC, like 3D, 2D, display output, encoders). But > it doesn't fell right to create a single driver for all these. And as > you know often 3D is even from a separate vendor. All these lead up to a > slight increase in the number of devices and drivers. Right way, I feel > so, but you are welcome to show a better way. > > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > I have no intention to use CDF outside KMS connector/encoder and I have > not heard Laurent talk about this either. I don't either. CDF will mostly target KMS connectors, and can also be used for KMS encoders. I have no plan to touch the CRTC. > Personally I see CDF as "helpers" to create and reuse connector/encoder > drivers between SoCs instead of each SoC do their own panel drivers (which > would be about a hundred, times the number of supported SoCs). We probably > need to discuss the connector/encoder mappings to CDF/panels. That's a topic I was planning to discuss at some point. One of the issues is that the KMS model can only have 3 entities in the pipeline, while hardware pipelines (especially in the embedded world) could be made of 4 or more entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI connector). We might not have to expose all details to userspace, but we need mapping rules. > But I think we need to flush out the higher level details like control bus > vs. data bus vs. display entities. While I like the generic way of the > display entities, I also like the pure bus/device/driver model without too > many generalizations. > Do you have any support in x86 world that could be compared to mobile > phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips > between the on chip/cpu/SoC CRTC and the external LCD depending on > product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? > And if you do, how do you model/setup/share all those in DRM driver? Or > it is manageable (< 10) and not up in the hundreds of different > encoders/lcd-drivers? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 17:09 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 17:09 UTC (permalink / raw) To: Marcus Lorentzon Cc: Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Hi Marcus, On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote: > On 12/18/2012 06:04 AM, Dave Airlie wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > I like the effort, right now it seems like x86 and arm display sub systems > are quite different in terms of DRM driver (and HW) design. I think this is > partly due to little information shared about these different architectures > and ideas behind the choices made. I hope some discussion will light up both > sides. And an early discussion will hopefully give you less pain when CDF > drivers starts to get pushed your way. On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > Could you give an example? Personally I don't think it is that many. I > might not have counted the plat devs in all arm drivers. But the STE one > have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). > Then of course there are all these panel devices. But I hope that when > CDF is "finished" we will have DSI devices on the DSI bus and DBI > devices on the DBI bus. I think most vendors have used platform devices > for these since they normally can't be probed in a generic way. But as > they are off SoC I feel this is not the best choice. And then many of > the panels are I2C devices (control bus) and that I guess is similar to > "x86" encoders/connectors? Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the platform bus. Although I still believe that DSI and DBI busses would make sense, I agree that they don't provide much in terms of probing and power management. You can read the discussion at http://www.spinics.net/lists/linux- fbdev/msg09250.html. > Another part of the difference I feel is that in x86 a DRM device is > most likely a PCI device, and as such has one huge driver for all IPs on > that board. The closest thing we get to that in ARM is probably the DSS > (collection of IPs on SoC, like 3D, 2D, display output, encoders). But > it doesn't fell right to create a single driver for all these. And as > you know often 3D is even from a separate vendor. All these lead up to a > slight increase in the number of devices and drivers. Right way, I feel > so, but you are welcome to show a better way. > > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > I have no intention to use CDF outside KMS connector/encoder and I have > not heard Laurent talk about this either. I don't either. CDF will mostly target KMS connectors, and can also be used for KMS encoders. I have no plan to touch the CRTC. > Personally I see CDF as "helpers" to create and reuse connector/encoder > drivers between SoCs instead of each SoC do their own panel drivers (which > would be about a hundred, times the number of supported SoCs). We probably > need to discuss the connector/encoder mappings to CDF/panels. That's a topic I was planning to discuss at some point. One of the issues is that the KMS model can only have 3 entities in the pipeline, while hardware pipelines (especially in the embedded world) could be made of 4 or more entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI connector). We might not have to expose all details to userspace, but we need mapping rules. > But I think we need to flush out the higher level details like control bus > vs. data bus vs. display entities. While I like the generic way of the > display entities, I also like the pure bus/device/driver model without too > many generalizations. > Do you have any support in x86 world that could be compared to mobile > phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips > between the on chip/cpu/SoC CRTC and the external LCD depending on > product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? > And if you do, how do you model/setup/share all those in DRM driver? Or > it is manageable (< 10) and not up in the hundreds of different > encoders/lcd-drivers? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-24 17:09 ` Laurent Pinchart (?) @ 2012-12-27 15:57 ` Rob Clark -1 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 15:57 UTC (permalink / raw) To: Laurent Pinchart Cc: Marcus Lorentzon, Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan, marcus.lorentzon On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On the topic of discussions, would anyone be interested in a > BoF/brainstorming/whatever session during the FOSDEM ? I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it looks like at least Daniel will be there. If enough others are, it could be a good idea. BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 15:57 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 15:57 UTC (permalink / raw) To: Laurent Pinchart Cc: Marcus Lorentzon, Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On the topic of discussions, would anyone be interested in a > BoF/brainstorming/whatever session during the FOSDEM ? I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it looks like at least Daniel will be there. If enough others are, it could be a good idea. BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-27 15:57 ` Rob Clark 0 siblings, 0 replies; 153+ messages in thread From: Rob Clark @ 2012-12-27 15:57 UTC (permalink / raw) To: Laurent Pinchart Cc: Marcus Lorentzon, Dave Airlie, linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Inki Dae, Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On the topic of discussions, would anyone be interested in a > BoF/brainstorming/whatever session during the FOSDEM ? I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it looks like at least Daniel will be there. If enough others are, it could be a good idea. BR, -R ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-27 15:57 ` Rob Clark (?) @ 2013-01-06 17:46 ` Daniel Vetter -1 siblings, 0 replies; 153+ messages in thread From: Daniel Vetter @ 2013-01-06 17:46 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, marcus.lorentzon, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media, Luc Verhaegen On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On the topic of discussions, would anyone be interested in a > > BoF/brainstorming/whatever session during the FOSDEM ? > > I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it > looks like at least Daniel will be there. If enough others are, it > could be a good idea. Seconded. Jesse should be there, too, and from the Helsinki guys Ville and Andy should show up. Doesn't look like Jani will be able to make it. I think something on Sunday (to not clash with the X devroom) would be good. Should we apply for an offical BOF/Is there a process for tahat? Adding Luc in case he knows ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-06 17:46 ` Daniel Vetter 0 siblings, 0 replies; 153+ messages in thread From: Daniel Vetter @ 2013-01-06 17:46 UTC (permalink / raw) To: Rob Clark Cc: Thomas Petazzoni, linux-fbdev, marcus.lorentzon, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, linux-media, Laurent Pinchart, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, Benjamin Gaignard On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On the topic of discussions, would anyone be interested in a > > BoF/brainstorming/whatever session during the FOSDEM ? > > I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it > looks like at least Daniel will be there. If enough others are, it > could be a good idea. Seconded. Jesse should be there, too, and from the Helsinki guys Ville and Andy should show up. Doesn't look like Jani will be able to make it. I think something on Sunday (to not clash with the X devroom) would be good. Should we apply for an offical BOF/Is there a process for tahat? Adding Luc in case he knows ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-06 17:46 ` Daniel Vetter 0 siblings, 0 replies; 153+ messages in thread From: Daniel Vetter @ 2013-01-06 17:46 UTC (permalink / raw) To: Rob Clark Cc: Thomas Petazzoni, linux-fbdev, marcus.lorentzon, Tom Gall, Kyungmin Park, dri-devel, Ragesh Radhakrishnan, Tomi Valkeinen, linux-media, Laurent Pinchart, Philipp Zabel, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, Benjamin Gaignard On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On the topic of discussions, would anyone be interested in a > > BoF/brainstorming/whatever session during the FOSDEM ? > > I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it > looks like at least Daniel will be there. If enough others are, it > could be a good idea. Seconded. Jesse should be there, too, and from the Helsinki guys Ville and Andy should show up. Doesn't look like Jani will be able to make it. I think something on Sunday (to not clash with the X devroom) would be good. Should we apply for an offical BOF/Is there a process for tahat? Adding Luc in case he knows ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2013-01-06 17:46 ` Daniel Vetter @ 2013-01-08 8:41 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:41 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, marcus.lorentzon, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media, Luc Verhaegen Hi Daniel, On Sunday 06 January 2013 18:46:47 Daniel Vetter wrote: > On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote: > > On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart wrote: > > > On the topic of discussions, would anyone be interested in a > > > BoF/brainstorming/whatever session during the FOSDEM ? > > > > I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it > > looks like at least Daniel will be there. If enough others are, it > > could be a good idea. > > Seconded. Jesse should be there, too, and from the Helsinki guys Ville and > Andy should show up. Doesn't look like Jani will be able to make it. I think > something on Sunday (to not clash with the X devroom) would be good. > > Should we apply for an offical BOF/Is there a process for tahat? Adding > Luc in case he knows ... >From the event website it looks like there are free rooms on Sunday, it would be good if we could secure one of them. Are there other X/display related topics that need to be discussed on Sunday ? How much time should we set aside ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2013-01-08 8:41 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2013-01-08 8:41 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan, dri-devel, marcus.lorentzon, Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media, Luc Verhaegen Hi Daniel, On Sunday 06 January 2013 18:46:47 Daniel Vetter wrote: > On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote: > > On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart wrote: > > > On the topic of discussions, would anyone be interested in a > > > BoF/brainstorming/whatever session during the FOSDEM ? > > > > I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it > > looks like at least Daniel will be there. If enough others are, it > > could be a good idea. > > Seconded. Jesse should be there, too, and from the Helsinki guys Ville and > Andy should show up. Doesn't look like Jani will be able to make it. I think > something on Sunday (to not clash with the X devroom) would be good. > > Should we apply for an offical BOF/Is there a process for tahat? Adding > Luc in case he knows ... From the event website it looks like there are free rooms on Sunday, it would be good if we could secure one of them. Are there other X/display related topics that need to be discussed on Sunday ? How much time should we set aside ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework 2012-12-18 5:04 ` Dave Airlie @ 2012-12-24 13:24 ` Laurent Pinchart -1 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:24 UTC (permalink / raw) To: Dave Airlie Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Dave, On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote: > > Many developers showed interest in the first RFC, and I've had the > > opportunity to discuss it with most of them. I would like to thank (in no > > particular order) Tomi Valkeinen for all the time he spend helping me to > > draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 > > 2012, and Linaro for inviting me to Connect and providing a venue to > > discuss this topic. > > So this might be a bit off topic but this whole CDF triggered me looking at > stuff I generally avoid: > > The biggest problem I'm having currently with the whole ARM graphics and > output world is the proliferation of platform drivers for every little > thing. The whole ordering of operations with respect to things like > suspend/resume or dynamic power management is going to be a real nightmare > if there are dependencies between the drivers. We share the same concern, although my analysis of the problem is somewhat different. The power management ordering issues isn't only caused by the software architecture, but also comes from complex hardware requirements. The root cause, in my opinion, is the split control and data busses: as soon as a device sits on multiple busses and has power management ordering requirements related to those busses the Linux power management model breaks. Note that the problem isn't restricted to the display, we have run into the exact same issues years ago on the video capture side. > How do you enforce ordering of s/r operations between all the various > components? The way we have handled this problem on the camera side is to use early suspend and late resume operations to handle the data (video) busses suspend and resume operations, and let the kernel handle the rest using the control bus based device tree model. The camera controller stops the video pipeline in its early suspend operation (and resumes it in the late resume operation) by calling operations provided by the entities (through function pointers of course, we don't want direct dependencies between the drivers). The control suspend/resume (such as sending a standby command through I2C to put the chip in low-power mode, or turning its power supply or clock off) is then handled by the PM core. > The other thing I'd like you guys to do is kill the idea of fbdev and v4l > drivers that are "shared" with the drm codebase, really just implement fbdev > and v4l on top of the drm layer, some people might think this is some sort > of maintainer thing, but really nothing else makes sense, and having these > shared display frameworks just to avoid having using drm/kms drivers seems > totally pointless. Fix the drm fbdev emulation if an fbdev interface is > needed. But creating a fourth framework because our previous 3 frameworks > didn't work out doesn't seem like a situation I want to get behind too much. I think there's a misunderstanding here. I'm definitely not trying to create a framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top of the same hardware device. That's an idea I really dislike, and I fully agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 isn't really a display and graphics API anyway. My goal here is to share code for chips that are used by different "devices" (in the sense of an agregate device, such as a camera or a graphics card) supported by different subsystems. For instance, the same I2C-controlled HDMI transmitter can be used by a display device when connected to a display controller on an SoC, but can also be used by a video output device when connected to a video output (some complex TI SoCs have pass-through video pipelines with no associated frame buffer, making the V4L2 API better suited than DRM/KMS). As the first device would be supported by a DRM/KMS driver and the second device by a pure V4L2 driver, we need a common framework to share code between both. If the same framework can be used to share panel drivers between DRM/KMS and pure FBDEV drivers (we have a bunch of those, not all of them will be ported to DRM/KMS, at least not in the very near future) that's also a bonus. To summarize my point, CDF aims at creating a self-contained framework that can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various display-related devices. It does not provide any userspace API, and does not offer any way to share devices between the three subsystems at runtime. In a way you can think of CDF as a DRM panel framework, but without the drm_ prefix. I hope this clarifies my goals. If not, or if there's still concerns and/or disagreements, let's discuss them. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
* Re: [RFC v2 0/5] Common Display Framework @ 2012-12-24 13:24 ` Laurent Pinchart 0 siblings, 0 replies; 153+ messages in thread From: Laurent Pinchart @ 2012-12-24 13:24 UTC (permalink / raw) To: Dave Airlie Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker, Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall, Tomi Valkeinen, Vikas Sajjan Hi Dave, On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote: > > Many developers showed interest in the first RFC, and I've had the > > opportunity to discuss it with most of them. I would like to thank (in no > > particular order) Tomi Valkeinen for all the time he spend helping me to > > draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 > > 2012, and Linaro for inviting me to Connect and providing a venue to > > discuss this topic. > > So this might be a bit off topic but this whole CDF triggered me looking at > stuff I generally avoid: > > The biggest problem I'm having currently with the whole ARM graphics and > output world is the proliferation of platform drivers for every little > thing. The whole ordering of operations with respect to things like > suspend/resume or dynamic power management is going to be a real nightmare > if there are dependencies between the drivers. We share the same concern, although my analysis of the problem is somewhat different. The power management ordering issues isn't only caused by the software architecture, but also comes from complex hardware requirements. The root cause, in my opinion, is the split control and data busses: as soon as a device sits on multiple busses and has power management ordering requirements related to those busses the Linux power management model breaks. Note that the problem isn't restricted to the display, we have run into the exact same issues years ago on the video capture side. > How do you enforce ordering of s/r operations between all the various > components? The way we have handled this problem on the camera side is to use early suspend and late resume operations to handle the data (video) busses suspend and resume operations, and let the kernel handle the rest using the control bus based device tree model. The camera controller stops the video pipeline in its early suspend operation (and resumes it in the late resume operation) by calling operations provided by the entities (through function pointers of course, we don't want direct dependencies between the drivers). The control suspend/resume (such as sending a standby command through I2C to put the chip in low-power mode, or turning its power supply or clock off) is then handled by the PM core. > The other thing I'd like you guys to do is kill the idea of fbdev and v4l > drivers that are "shared" with the drm codebase, really just implement fbdev > and v4l on top of the drm layer, some people might think this is some sort > of maintainer thing, but really nothing else makes sense, and having these > shared display frameworks just to avoid having using drm/kms drivers seems > totally pointless. Fix the drm fbdev emulation if an fbdev interface is > needed. But creating a fourth framework because our previous 3 frameworks > didn't work out doesn't seem like a situation I want to get behind too much. I think there's a misunderstanding here. I'm definitely not trying to create a framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top of the same hardware device. That's an idea I really dislike, and I fully agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 isn't really a display and graphics API anyway. My goal here is to share code for chips that are used by different "devices" (in the sense of an agregate device, such as a camera or a graphics card) supported by different subsystems. For instance, the same I2C-controlled HDMI transmitter can be used by a display device when connected to a display controller on an SoC, but can also be used by a video output device when connected to a video output (some complex TI SoCs have pass-through video pipelines with no associated frame buffer, making the V4L2 API better suited than DRM/KMS). As the first device would be supported by a DRM/KMS driver and the second device by a pure V4L2 driver, we need a common framework to share code between both. If the same framework can be used to share panel drivers between DRM/KMS and pure FBDEV drivers (we have a bunch of those, not all of them will be ported to DRM/KMS, at least not in the very near future) that's also a bonus. To summarize my point, CDF aims at creating a self-contained framework that can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various display-related devices. It does not provide any userspace API, and does not offer any way to share devices between the three subsystems at runtime. In a way you can think of CDF as a DRM panel framework, but without the drm_ prefix. I hope this clarifies my goals. If not, or if there's still concerns and/or disagreements, let's discuss them. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 153+ messages in thread
end of thread, other threads:[~2013-02-08 12:44 UTC | newest] Thread overview: 153+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-12-14 4:57 [RFC v2 0/5] Common Display Framework Vikas Sajjan 2012-12-17 22:00 ` Laurent Pinchart -- strict thread matches above, loose matches on Subject: below -- 2012-11-22 21:45 Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-23 14:51 ` Tomi Valkeinen 2012-11-23 14:51 ` Tomi Valkeinen 2012-11-23 14:51 ` Tomi Valkeinen 2012-12-17 14:36 ` Laurent Pinchart 2012-12-17 14:36 ` Laurent Pinchart 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 23:18 ` Laurent Pinchart 2012-12-17 23:18 ` Laurent Pinchart 2012-12-17 16:53 ` Jani Nikula 2012-12-17 16:53 ` Jani Nikula 2012-12-17 22:19 ` Laurent Pinchart 2012-12-17 22:19 ` Laurent Pinchart 2012-12-19 14:57 ` Jani Nikula 2012-12-19 14:57 ` Jani Nikula 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-24 17:31 ` Laurent Pinchart 2012-12-24 17:31 ` Laurent Pinchart 2012-12-19 15:26 ` Rob Clark 2012-12-19 15:26 ` Rob Clark 2012-12-19 15:37 ` Tomi Valkeinen 2012-12-19 15:37 ` Tomi Valkeinen 2012-12-19 16:05 ` Rob Clark 2012-12-19 16:05 ` Rob Clark 2012-12-19 16:05 ` Rob Clark 2012-12-24 17:40 ` Laurent Pinchart 2012-12-24 17:40 ` Laurent Pinchart 2012-12-24 17:35 ` Laurent Pinchart 2012-12-24 17:35 ` Laurent Pinchart 2012-12-27 16:10 ` Rob Clark 2012-12-27 16:10 ` Rob Clark 2012-12-24 17:27 ` Laurent Pinchart 2012-12-24 17:27 ` Laurent Pinchart 2012-12-27 16:04 ` Rob Clark 2012-12-27 16:04 ` Rob Clark 2012-12-27 19:19 ` Sascha Hauer 2012-12-27 19:19 ` Sascha Hauer 2012-11-23 19:56 ` Thierry Reding 2012-11-23 19:56 ` Thierry Reding 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-26 14:47 ` Alan Cox 2012-12-17 15:15 ` Laurent Pinchart 2012-12-17 15:15 ` Laurent Pinchart 2012-11-26 7:53 ` Philipp Zabel 2012-11-26 7:53 ` Philipp Zabel 2012-12-17 14:58 ` Laurent Pinchart 2012-12-17 14:58 ` Laurent Pinchart 2012-11-23 21:41 ` Sascha Hauer 2012-11-23 21:41 ` Sascha Hauer 2012-12-17 15:02 ` Laurent Pinchart 2012-12-17 15:02 ` Laurent Pinchart [not found] ` <CAD025yS5rGMbiRBdDxv=YLP6_fsQndAkr+3t29_mNhcvow_SwA@mail.gmail.com> [not found] ` <3133576.BkqAl7V01U@avalon> 2012-12-18 3:01 ` Vikas Sajjan 2012-12-18 6:25 ` Vikas Sajjan 2012-12-18 6:13 ` Vikas Sajjan 2012-12-21 10:00 ` Tomasz Figa 2012-12-21 10:00 ` Tomasz Figa 2012-12-24 14:12 ` Laurent Pinchart 2012-12-24 14:12 ` Laurent Pinchart 2012-12-27 14:43 ` Tomasz Figa 2012-12-27 14:43 ` Tomasz Figa 2012-12-27 14:43 ` Tomasz Figa 2012-12-28 3:38 ` Vikas Sajjan 2012-12-28 3:26 ` Vikas Sajjan 2013-01-08 8:18 ` Laurent Pinchart 2013-01-08 8:18 ` Laurent Pinchart 2013-01-08 10:12 ` Marcus Lorentzon 2013-01-08 10:12 ` Marcus Lorentzon 2013-01-08 16:36 ` Tomasz Figa 2013-01-08 16:36 ` Tomasz Figa 2013-01-08 17:08 ` Marcus Lorentzon 2013-01-08 17:08 ` Marcus Lorentzon 2013-02-01 23:35 ` Laurent Pinchart 2013-02-01 23:35 ` Laurent Pinchart 2013-02-04 10:05 ` Marcus Lorentzon 2013-02-04 10:05 ` Marcus Lorentzon 2013-02-06 9:52 ` Archit Taneja 2013-02-06 9:52 ` Archit Taneja 2013-02-08 10:51 ` Tomi Valkeinen 2013-02-08 10:51 ` Tomi Valkeinen 2013-02-08 12:43 ` Marcus Lorentzon 2013-02-08 12:43 ` Marcus Lorentzon 2013-02-01 23:37 ` Laurent Pinchart 2013-02-01 23:37 ` Laurent Pinchart 2012-12-24 13:00 ` Laurent Pinchart 2012-12-24 12:59 ` Laurent Pinchart 2012-12-18 5:04 ` Dave Airlie 2012-12-18 5:04 ` Dave Airlie 2012-12-18 5:04 ` Dave Airlie 2012-12-18 6:21 ` Rob Clark 2012-12-18 6:21 ` Rob Clark 2012-12-18 8:30 ` Daniel Vetter 2012-12-18 8:30 ` Daniel Vetter 2012-12-18 9:38 ` Inki Dae 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-24 14:08 ` Laurent Pinchart 2012-12-24 14:08 ` Laurent Pinchart 2012-12-24 13:39 ` Laurent Pinchart 2012-12-24 13:39 ` Laurent Pinchart 2012-12-18 10:59 ` Sylwester Nawrocki 2012-12-18 10:59 ` Sylwester Nawrocki 2012-12-24 17:19 ` Laurent Pinchart 2012-12-24 17:19 ` Laurent Pinchart 2012-12-19 20:05 ` Stéphane Marchesin 2012-12-19 20:05 ` Stéphane Marchesin 2012-12-24 13:37 ` Laurent Pinchart 2012-12-24 13:37 ` Laurent Pinchart 2012-12-27 15:54 ` Rob Clark 2012-12-27 15:54 ` Rob Clark 2012-12-27 19:18 ` Sascha Hauer 2012-12-27 19:18 ` Sascha Hauer 2012-12-27 19:57 ` Rob Clark 2012-12-27 19:57 ` Rob Clark 2012-12-28 0:04 ` Sascha Hauer 2012-12-28 0:04 ` Sascha Hauer 2013-01-08 8:33 ` Laurent Pinchart 2013-01-08 8:33 ` Laurent Pinchart 2013-01-08 8:25 ` Laurent Pinchart 2013-01-08 8:25 ` Laurent Pinchart 2013-01-08 16:13 ` Rob Clark 2013-01-08 16:13 ` Rob Clark 2013-01-09 8:35 ` Rahul Sharma 2013-01-09 8:23 ` Rahul Sharma 2013-01-09 8:23 ` Rahul Sharma 2013-02-01 23:42 ` Laurent Pinchart 2013-02-01 23:42 ` Laurent Pinchart 2013-02-02 10:08 ` Rob Clark 2013-02-02 10:08 ` Rob Clark 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-24 17:09 ` Laurent Pinchart 2012-12-24 17:09 ` Laurent Pinchart 2012-12-24 17:09 ` Laurent Pinchart 2012-12-27 15:57 ` Rob Clark 2012-12-27 15:57 ` Rob Clark 2012-12-27 15:57 ` Rob Clark 2013-01-06 17:46 ` Daniel Vetter 2013-01-06 17:46 ` Daniel Vetter 2013-01-06 17:46 ` Daniel Vetter 2013-01-08 8:41 ` Laurent Pinchart 2013-01-08 8:41 ` Laurent Pinchart 2012-12-24 13:24 ` Laurent Pinchart 2012-12-24 13:24 ` Laurent Pinchart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.