From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Date: Wed, 08 Aug 2012 06:17:43 +0000 Subject: Re: [RFC 00/17] OMAPDSS: Change way of passing timings from panel driver to interface Message-Id: <502201B7.9030205@ti.com> List-Id: References: <1343817088-29645-1-git-send-email-archit@ti.com> <1344349948.7216.82.camel@lappyti> In-Reply-To: <1344349948.7216.82.camel@lappyti> 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, sumit.semwal@ti.com, rob@ti.com On Tuesday 07 August 2012 08:02 PM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote: >> This series tries to make interface drivers less dependent on omap_dss_device >> which represents a panel/device connected to that interface. The current way of >> configuring an interface is to populate the panel's omap_dss_device instance >> with parameters common to the panel and the interface, they are either populated >> in the board file, or in the panel driver. Panel timings, number of lanes >> connected to interface, and pixel format are examples of such parameters, these >> are then extracted by the interface driver to configure itself. > > The series looks good. I had only a few comments to make, but obviously > this needs quite a bit of testing. I'll try it out. One thing I'm not sure about is whether these new functions should be aware of the state of the output. For example, if we call set_timings() with DSI video mode which is already enabled, the timings won't really take any impact. Similar issues would occur when we try to make other ops like set_data_lines() or set_pixel_format(). These need to be called before the output is enabled. I was wondering if we would need to add intelligence here to make panel drivers less likely to make mistakes. Archit