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 <archit@xxxxxx>
> ---
> +#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
Attachment:
signature.asc
Description: OpenPGP digital signature
