Thread (9 messages) 9 messages, 2 authors, 2014-05-20

Re: [RFC 2/6] omapdss: add init port functions for different omap revs

From: Archit Taneja <hidden>
Date: 2014-05-20 09:43:24
Also in: linux-omap

On Tuesday 20 May 2014 01:34 PM, Tomi Valkeinen wrote:
On 08/05/14 12:15, Archit Taneja wrote:
quoted
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 to specify the DPI output number.

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 a later DPI instance.

Create DSS revision specific init/uninit_port functions such that we have a
separate functions for OMAP34xx, this helps us deal with the SDI case
separately.
Could we instead have an array of the ports for the said DSS version,
assigned to dss_features? Maybe just something like:

static enum omap_display_type omap34xx_ports[] = {
	OMAP_DISPLAY_TYPE_DPI,
	OMAP_DISPLAY_TYPE_SDI,
};

The index on the array tells the matching 'reg' value.
Oh yeah! That should prevent us creating ops. It would require us to 
create a ports pointer in dss_features, but it's certainly much better 
than having 2 very similar functions.

Archit
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help