From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Date: Tue, 20 May 2014 09:43:24 +0000 Subject: Re: [RFC 2/6] omapdss: add init port functions for different omap revs Message-Id: <537B20EC.6020303@ti.com> List-Id: References: <1399540517-17883-1-git-send-email-archit@ti.com> <1399540517-17883-2-git-send-email-archit@ti.com> <537B0CA1.5060100@ti.com> In-Reply-To: <537B0CA1.5060100@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org On Tuesday 20 May 2014 01:34 PM, Tomi Valkeinen wrote: > On 08/05/14 12:15, 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 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