aboutsummaryrefslogtreecommitdiffstats
path: root/include/video
diff options
context:
space:
mode:
authorArchit Taneja <archit@ti.com>2012-09-07 08:08:00 -0400
committerArchit Taneja <archit@ti.com>2012-09-26 06:59:10 -0400
commit484dc404d233696ef65a8e676f9d4fe563b091ee (patch)
treea4e1e601a357b8318e6f606cd1f75b4865d89536 /include/video
parentfc22a84339d387203cc2a1685fb251a5ad4c9b43 (diff)
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and Devices. These map to pipelines, overlay managers and the panels respectively in hardware. One or more overlays connect to a manager to represent a composition, the manager connects to a device(generally a display) to display the content. The part of DSS hardware which isn't represented by any of the above entities are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI, HDMI, VENC and so on. Currently, an overlay manager directly connects to the display, and the output to which it is actually connected is ignored. The panel driver of the display is responsible of calling output specific functions to configure the output. Adding outputs as a new software entity gives us the following benefits: - Have exact information on the possible connections between managers and outputs: A manager can't connect to each and every output, there only limited hardware links between a manager's video port and some of the outputs. - Remove hacks related to connecting managers and devices: Currently, default links between managers and devices are set in a not so clean way. Matching is done via comparing the device type, and the display types supported by the manager. This isn't sufficient to establish all the possible links between managers, outputs and devices in hardware. - Make panel drivers more generic: The DSS panel drivers currently call interface/output specific functions to configure the hardware IP. When making these calls, the driver isn't actually aware of the underlying output. The output driver extracts information from the panel's omap_dss_device pointer to figure out which interface it is connected to, and then configures the corresponding output block. An example of this is when a DSI panel calls dsi functions, the dsi driver figures out whether the panel is connected to DSI1 or DSI2. This isn't correct, and having output as entities will give the panel driver the exact information on which output to configure. Having outputs also gives the opportunity to make panel drivers generic across different platforms/SoCs, this is achieved as omap specific output calls can be replaced by ops of a particular output type. - Have more complex connections between managers, outputs and devices: OMAPDSS currently doesn't support use cases like 2 outputs connect to a single device. This can be achieved by extending properties of outputs to connect to more managers or devices. - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS as compared to overlays, managers or devices. Add a new struct to represent outputs. An output struct holds pointers to the manager and device structs to which it is connected. Add functions which can register/unregister an output, or look for one. Create an enum which represent each output instance. Signed-off-by: Archit Taneja <archit@ti.com>
Diffstat (limited to 'include/video')
-rw-r--r--include/video/omapdss.h30
1 files changed, 30 insertions, 0 deletions
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ac2e4cca5a23..e202648166d2 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -208,6 +208,16 @@ enum omap_hdmi_flags {
208 OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 << 0, 208 OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 << 0,
209}; 209};
210 210
211enum omap_dss_output_id {
212 OMAP_DSS_OUTPUT_DPI = 1 << 0,
213 OMAP_DSS_OUTPUT_DBI = 1 << 1,
214 OMAP_DSS_OUTPUT_SDI = 1 << 2,
215 OMAP_DSS_OUTPUT_DSI1 = 1 << 3,
216 OMAP_DSS_OUTPUT_DSI2 = 1 << 4,
217 OMAP_DSS_OUTPUT_VENC = 1 << 5,
218 OMAP_DSS_OUTPUT_HDMI = 1 << 6,
219};
220
211/* RFBI */ 221/* RFBI */
212 222
213struct rfbi_timings { 223struct rfbi_timings {
@@ -493,6 +503,24 @@ struct omap_dsi_pin_config {
493 int pins[OMAP_DSS_MAX_DSI_PINS]; 503 int pins[OMAP_DSS_MAX_DSI_PINS];
494}; 504};
495 505
506struct omap_dss_output {
507 struct list_head list;
508
509 /* display type supported by the output */
510 enum omap_display_type type;
511
512 /* output instance */
513 enum omap_dss_output_id id;
514
515 /* output's platform device pointer */
516 struct platform_device *pdev;
517
518 /* dynamic fields */
519 struct omap_overlay_manager *manager;
520
521 struct omap_dss_device *device;
522};
523
496struct omap_dss_device { 524struct omap_dss_device {
497 struct device dev; 525 struct device dev;
498 526
@@ -702,6 +730,8 @@ struct omap_overlay_manager *omap_dss_get_overlay_manager(int num);
702int omap_dss_get_num_overlays(void); 730int omap_dss_get_num_overlays(void);
703struct omap_overlay *omap_dss_get_overlay(int num); 731struct omap_overlay *omap_dss_get_overlay(int num);
704 732
733struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id);
734
705void omapdss_default_get_resolution(struct omap_dss_device *dssdev, 735void omapdss_default_get_resolution(struct omap_dss_device *dssdev,
706 u16 *xres, u16 *yres); 736 u16 *xres, u16 *yres);
707int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev); 737int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);