[RFC 00/14] Add DT support to OMAPDSS

[RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

Hi,

This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.

The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.

Some notes:

* DSS Submodules

The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.

* ti,dsi-module-id

There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.

* Display chains

Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts. 

So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.

You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.

* DSI lanes

The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.

 Tomi

Tomi Valkeinen (14):
  ARM: OMAP: remove DSS DT hack
  ARM: OMAP2+: add omapdss_init_of()
  OMAPDSS: Add DT support to DSS, DISPC, DPI
  OMAPDSS: Add DT support to DSI
  OMAPDSS: Add DT support to HDMI
  OMAPDSS: Taal: Add DT support
  OMAPDSS: TFP410: Add DT support
  OMAPDSS: panel-generic-dpi: add DT support
  ARM: omap3.dtsi: add omapdss information
  ARM: omap4.dtsi: add omapdss information
  ARM: omap4-panda.dts: add display information
  ARM: omap4-sdp.dts: add display information
  ARM: omap3-tobi.dts: add lcd (TEST)
  ARM: omap3-beagle.dts: add TFP410

 arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
 arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
 arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
 arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
 arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
 arch/arm/mach-omap2/board-generic.c              |    9 +--
 arch/arm/mach-omap2/common.h                     |    2 +
 arch/arm/mach-omap2/display.c                    |   34 +++++++++
 arch/arm/mach-omap2/dss-common.c                 |   24 ------
 arch/arm/mach-omap2/dss-common.h                 |    2 -
 drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
 drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
 drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
 drivers/video/omap2/dss/dispc.c                  |    7 ++
 drivers/video/omap2/dss/dpi.c                    |    8 ++
 drivers/video/omap2/dss/dsi.c                    |   24 +++++-
 drivers/video/omap2/dss/dss.c                    |    7 ++
 drivers/video/omap2/dss/hdmi.c                   |    7 ++
 drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
 20 files changed, 641 insertions(+), 37 deletions(-)

-- 
1.7.10.4

[RFC 02/14] ARM: OMAP2+: add omapdss_init_of()

[Benoit Cousson]

Hi Tomi,

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> omapdss driver uses a omapdss platform device to pass platform specific
> function pointers and DSS hardware version from the arch code to the
> driver. This device is needed also when booting with DT.
> 
> This patch adds omapdss_init_of() function, called from board-generic at
> init time, which creates the omapdss device.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  arch/arm/mach-omap2/board-generic.c |    1 +
>  arch/arm/mach-omap2/common.h        |    2 ++
>  arch/arm/mach-omap2/display.c       |   34 ++++++++++++++++++++++++++++++++++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index a61544b..29eb085 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
>  
>  	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>  
> +	omapdss_init_of();

Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.

>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 40f4a03..e9ac1fd 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -293,5 +293,7 @@ extern void omap_reserve(void);
>  struct omap_hwmod;
>  extern int omap_dss_reset(struct omap_hwmod *);
>  
> +int __init omapdss_init_of(void);
> +
>  #endif /* __ASSEMBLER__ */
>  #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index ff37be1..c62aee0 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -23,6 +23,8 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>  
>  #include <video/omapdss.h>
>  #include "omap_hwmod.h"
> @@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
>  
>  	return r;
>  }
> +
> +int __init omapdss_init_of(void)
> +{
> +	int r;
> +	enum omapdss_version ver;
> +
> +	static struct omap_dss_board_info board_data = {
> +		.dsi_enable_pads = omap_dsi_enable_pads,
> +		.dsi_disable_pads = omap_dsi_disable_pads,

Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.

> +		.get_context_loss_count = omap_pm_get_dev_context_loss_count,
> +		.set_min_bus_tput = omap_dss_set_min_bus_tput,


All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.

I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.

> +	};
> +
> +	ver = omap_display_get_version();
> +
> +	if (ver == OMAPDSS_VER_UNKNOWN) {
> +		pr_err("DSS not supported on this SoC\n");
> +		return -ENODEV;
> +	}
> +
> +	board_data.version = ver;
> +
> +	omap_display_device.dev.platform_data = &board_data;

Regards,
Benoit

[RFC 00/14] Add DT support to OMAPDSS

[Benoit Cousson]

Hi Tomi,

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> Hi,
> 
> This is an RFC for OMAPDSS DT support. I've only added support for a few boards
> and a few DSS outputs, but they should give quite a good range of different use
> cases. If these work well, I think the rest of the outputs and panels will be
> ok too.
> 
> The purpose of this series is to get comments about the dts changes. There are
> still work to be done, like adding DT binding documentation.
> 
> Some notes:
> 
> * DSS Submodules
> 
> The DSS submodules are children of the dss_core node. This is done because the
> submodules require the dss_core to be alive and initialized to work, even if
> the submodules are not really behind dss_core. Having the submodules as
> children will make runtime PM automatically handle the dependency to dss_core.
> I think usually a node being a child means that it's on the parent's bus, which
> is not the case here. I'm not sure if that's an issue or not.

FWIW, there is a L4_DSS interconnect. It is used internally to connect
all the submodules to the DSS L3 port. So this representation is
perfectly valid and does represent accurately the HW.

Regards,
Benoit

> 
> * ti,dsi-module-id
> 
> There's a ti,dsi-module-id property in the dsi node. The reason for this
> module-id property is that we have muxes in the dss_core that route clocks
> to/from a particular DSI module. So we need some way to index the DSI modules.
> Another option would be to have a list of DSI modules (phandles) in the
> dss_core. Both options feel a bit wrong to me, but I went for the module-id
> approach as that is already used when not using DT.
> 
> * Display chains
> 
> Currently omapdss driver can handle only one display device connected to one
> OMAP SoC output. This is not right in many cases, as there may be multiple
> display devices in a chain, like first an external encoder and then a panel.
> However, I tried to model this right in the dts. 
> 
> So, for example, for Panda HDMI output we have the following display "entities"
> in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
> connector. These are connected using the "video-source" property, which tells
> where the component in question gets its video data.
> 
> You could ask why there's a separate node for HDMI connector. It's true it's
> not really a proper device, but we need some kind of terminator for the display
> chains. For HDMI we could as well have an embedded solution, having a chain
> like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
> marks the end of the chain, and acts as a panel in a sense.
> 
> * DSI lanes
> 
> The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
> connected to the DSI panel. I'm not sure if the panel data is the proper place
> for this, or should the data be separately for the OMAP DSI node.
> 
>  Tomi
> 
> Tomi Valkeinen (14):
>   ARM: OMAP: remove DSS DT hack
>   ARM: OMAP2+: add omapdss_init_of()
>   OMAPDSS: Add DT support to DSS, DISPC, DPI
>   OMAPDSS: Add DT support to DSI
>   OMAPDSS: Add DT support to HDMI
>   OMAPDSS: Taal: Add DT support
>   OMAPDSS: TFP410: Add DT support
>   OMAPDSS: panel-generic-dpi: add DT support
>   ARM: omap3.dtsi: add omapdss information
>   ARM: omap4.dtsi: add omapdss information
>   ARM: omap4-panda.dts: add display information
>   ARM: omap4-sdp.dts: add display information
>   ARM: omap3-tobi.dts: add lcd (TEST)
>   ARM: omap3-beagle.dts: add TFP410
> 
>  arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
>  arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
>  arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
>  arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
>  arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
>  arch/arm/mach-omap2/board-generic.c              |    9 +--
>  arch/arm/mach-omap2/common.h                     |    2 +
>  arch/arm/mach-omap2/display.c                    |   34 +++++++++
>  arch/arm/mach-omap2/dss-common.c                 |   24 ------
>  arch/arm/mach-omap2/dss-common.h                 |    2 -
>  drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
>  drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
>  drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
>  drivers/video/omap2/dss/dispc.c                  |    7 ++
>  drivers/video/omap2/dss/dpi.c                    |    8 ++
>  drivers/video/omap2/dss/dsi.c                    |   24 +++++-
>  drivers/video/omap2/dss/dss.c                    |    7 ++
>  drivers/video/omap2/dss/hdmi.c                   |    7 ++
>  drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
>  20 files changed, 641 insertions(+), 37 deletions(-)
> 

[RFC 00/14] Add DT support to OMAPDSS

[Benoit Cousson]

+ mturquette and Rajendra

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:

...

> * ti,dsi-module-id
> 
> There's a ti,dsi-module-id property in the dsi node. The reason for this
> module-id property is that we have muxes in the dss_core that route clocks
> to/from a particular DSI module. So we need some way to index the DSI modules.
> Another option would be to have a list of DSI modules (phandles) in the
> dss_core. Both options feel a bit wrong to me, but I went for the module-id
> approach as that is already used when not using DT.

That's not a very nice representation. Ideally you should expose 1 clock
node per DSI node, and enabling one will select the proper mux for you.

Regards,
Benoit


> 
> * Display chains
> 
> Currently omapdss driver can handle only one display device connected to one
> OMAP SoC output. This is not right in many cases, as there may be multiple
> display devices in a chain, like first an external encoder and then a panel.
> However, I tried to model this right in the dts. 
> 
> So, for example, for Panda HDMI output we have the following display "entities"
> in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
> connector. These are connected using the "video-source" property, which tells
> where the component in question gets its video data.
> 
> You could ask why there's a separate node for HDMI connector. It's true it's
> not really a proper device, but we need some kind of terminator for the display
> chains. For HDMI we could as well have an embedded solution, having a chain
> like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
> marks the end of the chain, and acts as a panel in a sense.
> 
> * DSI lanes
> 
> The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
> connected to the DSI panel. I'm not sure if the panel data is the proper place
> for this, or should the data be separately for the OMAP DSI node.
> 
>  Tomi
> 
> Tomi Valkeinen (14):
>   ARM: OMAP: remove DSS DT hack
>   ARM: OMAP2+: add omapdss_init_of()
>   OMAPDSS: Add DT support to DSS, DISPC, DPI
>   OMAPDSS: Add DT support to DSI
>   OMAPDSS: Add DT support to HDMI
>   OMAPDSS: Taal: Add DT support
>   OMAPDSS: TFP410: Add DT support
>   OMAPDSS: panel-generic-dpi: add DT support
>   ARM: omap3.dtsi: add omapdss information
>   ARM: omap4.dtsi: add omapdss information
>   ARM: omap4-panda.dts: add display information
>   ARM: omap4-sdp.dts: add display information
>   ARM: omap3-tobi.dts: add lcd (TEST)
>   ARM: omap3-beagle.dts: add TFP410
> 
>  arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
>  arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
>  arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
>  arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
>  arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
>  arch/arm/mach-omap2/board-generic.c              |    9 +--
>  arch/arm/mach-omap2/common.h                     |    2 +
>  arch/arm/mach-omap2/display.c                    |   34 +++++++++
>  arch/arm/mach-omap2/dss-common.c                 |   24 ------
>  arch/arm/mach-omap2/dss-common.h                 |    2 -
>  drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
>  drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
>  drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
>  drivers/video/omap2/dss/dispc.c                  |    7 ++
>  drivers/video/omap2/dss/dpi.c                    |    8 ++
>  drivers/video/omap2/dss/dsi.c                    |   24 +++++-
>  drivers/video/omap2/dss/dss.c                    |    7 ++
>  drivers/video/omap2/dss/hdmi.c                   |    7 ++
>  drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
>  20 files changed, 641 insertions(+), 37 deletions(-)
> 

[RFC 02/14] ARM: OMAP2+: add omapdss_init_of()

[Tomi Valkeinen]

On 2013-03-27 11:28, Benoit Cousson wrote:
> Hi Tomi,

Hi Benoit. Thanks for your comments!

> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>>  arch/arm/mach-omap2/board-generic.c |    1 +
>>  arch/arm/mach-omap2/common.h        |    2 ++
>>  arch/arm/mach-omap2/display.c       |   34 ++++++++++++++++++++++++++++++++++
>>  3 files changed, 37 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>> index a61544b..29eb085 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
>>  
>>  	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>  
>> +	omapdss_init_of();
> 
> Mmm, you should not have to call that explicitly. It looks like a hack
> to me. Everything in theory should be initialized during
> of_platform_populate / driver probe.

All the "real" devices are initialized properly. However, we still have
a "virtual" omapdss device, which does not represent a particular HW
block as such, and is not represented in the DT data. It's a legacy
thing, and slowly on its way out.

However, it still helps us to pass the platform callbacks via platform
data even in DT call, so we have this (hacky) omapdss_init_of() call.

And we also pass the OMAP revision information via the platform data, as
we need to know the DSS HW version. The only way to get that is to know
the OMAP version and revision. If we would set the DSS HW version
information into DT data, we could need separate dts files for each OMAP
revision.

>> +
>> +int __init omapdss_init_of(void)
>> +{
>> +	int r;
>> +	enum omapdss_version ver;
>> +
>> +	static struct omap_dss_board_info board_data = {
>> +		.dsi_enable_pads = omap_dsi_enable_pads,
>> +		.dsi_disable_pads = omap_dsi_disable_pads,
> 
> Pads config should be handle by pinmux framework is possible. Otherwise
> a dedicated driver will be required.

Hmm. These functions touch the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY
(CONTROL_DSIPHY in the TRM) register. It's not a normal padconfig thing
(like, selecting between GPIO and some other function).

Can they be handled by the pinmux framework? I'm not familiar with it.
What do you mean with dedicated driver? Dedicated pinmux driver, or
something else?

>> +		.get_context_loss_count = omap_pm_get_dev_context_loss_count,
>> +		.set_min_bus_tput = omap_dss_set_min_bus_tput,
> 
> 
> All that code should disappear with DT. hacking a platform device with
> pdata is the old way of initializing a device.
> 
> I know that you do have some omap_pm callback, but you'd better get rid
> of them in case of DT boot.
> Fixing that is a generic issue, and as soon as a solution will be done
> to handle these specific hooks, every drivers will be able to use that.

So, what you're saying is that this is not the correct way, but there's
no other way to handle it currently? If so, yes, I know that, but, well,
there's no other way to handle it currently.

I could leave them out, but in that case when booting with DT there must
be no DSS context loss, and OPP must be at OPP100 all the time.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130327/7e442d80/attachment.sig>

[RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

On 2013-03-27 11:30, Benoit Cousson wrote:
> Hi Tomi,
> 
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> This is an RFC for OMAPDSS DT support. I've only added support for a few boards
>> and a few DSS outputs, but they should give quite a good range of different use
>> cases. If these work well, I think the rest of the outputs and panels will be
>> ok too.
>>
>> The purpose of this series is to get comments about the dts changes. There are
>> still work to be done, like adding DT binding documentation.
>>
>> Some notes:
>>
>> * DSS Submodules
>>
>> The DSS submodules are children of the dss_core node. This is done because the
>> submodules require the dss_core to be alive and initialized to work, even if
>> the submodules are not really behind dss_core. Having the submodules as
>> children will make runtime PM automatically handle the dependency to dss_core.
>> I think usually a node being a child means that it's on the parent's bus, which
>> is not the case here. I'm not sure if that's an issue or not.
> 
> FWIW, there is a L4_DSS interconnect. It is used internally to connect
> all the submodules to the DSS L3 port. So this representation is
> perfectly valid and does represent accurately the HW.

Ah, yes, I can see it mentioned in the OMAP4430 Block Diagram figure in
the TRM. No other mentions, though, I guess it's not really relevant =).
But good to know that the DT representation is actually correct.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130327/0b25e833/attachment.sig>

[RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

On 2013-03-27 11:41, Benoit Cousson wrote:
> + mturquette and Rajendra
> 
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> 
> ...
> 
>> * ti,dsi-module-id
>>
>> There's a ti,dsi-module-id property in the dsi node. The reason for this
>> module-id property is that we have muxes in the dss_core that route clocks
>> to/from a particular DSI module. So we need some way to index the DSI modules.
>> Another option would be to have a list of DSI modules (phandles) in the
>> dss_core. Both options feel a bit wrong to me, but I went for the module-id
>> approach as that is already used when not using DT.
> 
> That's not a very nice representation. Ideally you should expose 1 clock
> node per DSI node, and enabling one will select the proper mux for you.

Afaik, we need the DSI module id for the following things:

1) DSI pad configuration (OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY).

2) Setting clk mux in dss_core to select input clock for DSI protocol
engine. The choice is between DSS_CLK from PRCM, or clock from a DSI
PLL. DSI1 module can only use DSI1 PLL clock, and DSI2 module can only
use DSI2 PLL clock.

3) Setting clk mux in dss_core to select input clock for LCD/DISPC. The
choice is between DSS_CLK from PRCM, or a clock from DSI PLL. DISPC can
use either DSI1 or DSI2 PLL, LCD1 can use DSI1 PLL clock, LCD2 can use
DSI2 PLL clock.

4) Selecting the video output from DISPC which is routed to the DSI
module. LCD1 output can go to DSI1, LCD2 output can go to DSI1 or DSI2.

All the above of course change between OMAP versions.

So managing all the above was easiest with a plain module-id assigned to
the DSI device.

I guess 1) could be somehow managed by having separate nodes in the dts
for the DSIPHY control, and a link from the DSI module to that DSIPHY node.

4) could possibly be managed by having each DSS output node having a
list of possible inputs from the DISPC. And, I guess, a link somehow to
a mux node in the dss_core. Or something...

All in all, I don't have any clear idea how these should be handled.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130327/fabd0acb/attachment.sig>