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 <[email protected]> > ---
> +#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
signature.asc
Description: OpenPGP digital signature
