Re: [PATCH v3 4/7] OMAPDSS: DSS: init dss ports cleanly

On 04/06/14 09:41, Archit Taneja wrote:

The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.

For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property in dts to specify the DPI output instance.

The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
'reg' is used to specify whether the output is SDI, or another DPI instance.

We create a list of port types supported for each DSS rev, with the index of the
port in the list matching the reg id. This allows us to have a more generic way
to init/uninit ports within DSS, and support multiple DPI ports.

Also, make the uninit_port functions iterative since we will have multiple DPI
ports to uninit in the future.

Signed-off-by: Archit Taneja <redacted>
---

+#ifdef CONFIG_OMAP2_DSS_DPI
 int dpi_init_port(struct platform_device *pdev, struct device_node *port) __init;
 void dpi_uninit_port(struct device_node *port) __exit;
+#else
+static inline int __init dpi_init_port(struct platform_device *pdev,
+		struct device_node *port)
+{
+	WARN("%s: DPI not compiled in\n", __func__);
+	return 0;
+}

If I'm not mistaken, this, and the SDI one, will be called if the DT
data contains DPI/SDI port, but the DPI/SDI support is not compiled in.
I don't think that's a reason to give a warning, there's nothing wrong
with leaving the DPI/SDI support out.

 Tomi