summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: VENC: Remove cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-221-11/+0Star
| | | | | | | | | | | | OMAP4 checks are removed from VENC to provide it a cleaner interface. These checks were introduced by patches "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> and "OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4" (cc1d3e032d) by Danny Kukawka <danny.kukawka@bisect.de> to prevent VENC from crashing OMAP4 kernel. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* ARM: OMAP: Disable venc for OMAP4Chandrabhanu Mahapatra2012-08-221-1/+0Star
| | | | | | | | | | This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> to prevent VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration of a device for VENC on OMAP4. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSS: Cleanup cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-221-41/+79
| | | | | | | | | | All the cpu_is checks have been moved to dss_init_features function providing a much more generic and cleaner interface. The OMAP version and revision specific initializations in various functions are cleaned and the necessary data are moved to dss_features structure which is local to dss.c. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSS: Remove redundant functionsChandrabhanu Mahapatra2012-08-222-47/+0Star
| | | | | | | | Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these functions have become redundant and no longer used. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Cleanup cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-221-155/+279
| | | | | | | | | | All the cpu_is checks have been moved to dispc_init_features function providing a much more generic and cleaner interface. The OMAP version and revision specific functions and data are initialized by dispc_features structure which is local to dispc.c. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: fix initial HDMI enableTomi Valkeinen2012-08-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Commit 7849398fa28c21dad24292b838b059a862f99f16 introduced a bug, causing the following error to be reported: [ 370.827819] cannot lock PLL [ 370.830749] CFG1 0x1e [ 370.833160] CFG2 0x602004 [ 370.835876] CFG4 0x40000 [ 370.838562] omapdss HDMI: Failed to lock PLL However, HDMI output is still enabled. The problem is that we enable the HDMI video output temporarily when reading EDID or detecting if a HDMI cable is connected (ugh), and the commit above changes the behavior of the driver so that the video timings are not yet configured at the point when EDID is read. This patch fixes the problem by configuring the initial VGA timings at HDMI probe. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge output work from ArchitTomi Valkeinen2012-08-1723-368/+837
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The series removes bunch of dssdev references from the omapdss output drivers. This is made to let us move to a common panel framework later, and also allows us to implement OMAP's writeback support, which has been proven difficult with the current output drivers. OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings OMAPDSS: DPI: Add locking for DPI interface OMAPDSS: Displays: Add locking in generic DPI panel driver OMAPDSS: DPI: Maintain our own timings field in driver data OMAPDSS: DPI displays: Take care of panel timings in the driver itself OMAPDSS: DSI: Maintain own copy of timings in driver data OMAPDSS: DSI: Add function to set panel size for command mode panels OMAPDSS: DSI: Update manager timings on a manual update OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings OMAPDSS: HDMI: Add locking for hdmi interface set timing functions OMAPDSS: SDI: Create a function to set timings OMAPDSS: SDI: Maintain our own timings field in driver data OMAPDSS: VENC: Split VENC into interface and panel driver OMAPDSS: VENC: Maintain our own timings field in driver data OMAPDSS: RFBI: Remove partial update support OMAPDSS: RFBI: Add function to set panel size OMAPDSS: DSI: Maintain copy of pixel format in driver data OMAPDSS: RFBI: Maintain copy of pixel size in driver data OMAPDSS: RFBI: Maintain copy of number of data lines in driver data OMAPDSS: DPI: Maintain copy of number of data lines in driver data OMAPDSS: SDI: Maintain copy of data pairs in driver data OMAPDSS: DSI: Maintain copy of operation mode in driver data OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings OMAPDSS: DSI: Maintain copy of video mode timings in driver data OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data OMAPDSS: VENC: Maintain copy of venc type in driver data OMAPDSS: VENC: Maintian copy of video output polarity info in private data
| * OMAPDSS: VENC: Maintian copy of video output polarity info in private dataArchit Taneja2012-08-163-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the omap_dss_device struct to configure the video output polarity. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own polarity field. A panel driver is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the interface. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: VENC: Maintain copy of venc type in driver dataArchit Taneja2012-08-163-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the omap_dss_device struct to configure the venc type. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own 'venc type' field. A panel driver is expected to call omapdss_venc_set_type() before enabling the interface or changing the type via display sysfs attributes. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Maitain copy of rfbi timings in driver dataArchit Taneja2012-08-163-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the rfbi specific timings requested by the panel driver. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own rfbi specific timings field. The panel driver is expected to call omapdss_rfbi_set_interface_timings() to configure the rfbi timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Maintain copy of video mode timings in driver dataArchit Taneja2012-08-162-16/+36
| | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to receive the video mode timings requested by the panel driver. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own video mode timings field. The panel driver is expected to call omapdss_dsi_set_videomode_timings() to configure the video mode timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timingsArchit Taneja2012-08-162-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct omap_dss_dsi_videomode_data holds fields which need to be configured for DSI to operate in video mode. Rename the struct to dsi_videomode_timings. One reason to do this is because most of the fields in the struct are timings related. The other reason is to create a generic op for output specific timings. This generic op can be considered as a way to set custom or private timings for the output. In the case of OMAP, DSI and RFBI require some more timings apart from the relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings can be considered as these output specific timings respectively. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Maintain copy of operation mode in driver dataArchit Taneja2012-08-163-11/+34
| | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to know the mode of operation of the DSI protocol(command or video mode). This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own operation mode field. The panel driver is expected to call omapdss_dsi_set_operation_mode() before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: SDI: Maintain copy of data pairs in driver dataArchit Taneja2012-08-165-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SDI driver currently relies on the omap_dss_device struct to configure the number of data pairs as specified by the panel. This makes the SDI interface driver dependent on the omap_dss_device struct. Make the SDI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_sdi_set_datapairs() before enabling the interface. Even though we configure the number of data pairs here, this function would be finally mapped to a generic interface op called set_data_lines. The datapairs argument type has been changed from u8 to int at some places to be in sync with the 'set_data_lines' ops of other interfaces. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI: Maintain copy of number of data lines in driver dataArchit Taneja2012-08-169-1/+20
| | | | | | | | | | | | | | | | | | | | | | The DPI driver currently relies on the omap_dss_device struct to configure the number of data lines as specified by the panel. This makes the DPI interface driver dependent on the omap_dss_device struct. Make the DPI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_dpi_set_data_lines() before enabling the interface. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Maintain copy of number of data lines in driver dataArchit Taneja2012-08-163-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to configure the number of data lines as specified by the panel. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format before enabling the interface or calling omap_rfbi_configure(). Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Maintain copy of pixel size in driver dataArchit Taneja2012-08-163-11/+23
| | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the desired pixel size of the panel. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own pixel format field. A panel driver is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format before enabling the interface or calling omap_rfbi_configure(). Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Maintain copy of pixel format in driver dataArchit Taneja2012-08-163-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to receive the desired pixel format of the panel. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own pixel format field. The panel driver is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Add function to set panel sizeArchit Taneja2012-08-153-14/+37
| | | | | | | | | | | | | | | | | | | | | | | | RFBI drivers requires configuration of the update area. Since we don't support partial updates, the size to be configures is the panel size itself. Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the other fields are configured to an initial value when RFBI is enabled. A panel driver is expected to call omapdss_rfbi_set_size() configure the size of the panel. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Remove partial update supportArchit Taneja2012-08-153-66/+31Star
| | | | | | | | | | | | | | | | | | | | | | | | Partial update suppport was removed from DISPC and DSI sometime back. The RFBI driver still tries to support partial update without the underlying support in DISPC. Remove partial update support from RFBI, only support updates which span acros the whole panel size. This also helps in DSI and RFBI having similar update ops. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: VENC: Maintain our own timings field in driver dataArchit Taneja2012-08-152-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the timings in omap_dss_device struct to configure the DISPC and VENC blocks accordingly. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own timings field. The panel driver is expected to call omapdss_venc_set_timings() to set these timings before the panel is enabled. Call omapdss_venc_set_timings() before enabling venc output, this is done to atleast have the venc output configured to the panel's default timings if the DSS user didn't explicitly call the venc panel driver's set_timings op. Make the VENC panel driver configure the new timings is the omap_dss_device struct(dssdev->panel.timings). The VENC driver is responsible for maintaining only it's own copy of timings. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: VENC: Split VENC into interface and panel driverArchit Taneja2012-08-154-156/+308
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current venc.c driver contains both the interface and panel driver code. This makes the driver hard to read, and difficult to understand the work split between the interface and panel driver and the how the locking works. This also makes it easier to clearly define the VENC interface ops called by the panel driver. Split venc.c into venc.c and venc_panel.c representing the interface and panel driver respectively. This split is done along the lines of the HDMI interface and panel drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: SDI: Maintain our own timings field in driver dataArchit Taneja2012-08-152-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SDI driver currently relies on the timings in omap_dss_device struct to configure the DISPC accordingly. This makes the SDI interface driver dependent on the omap_dss_device struct. Make the SDI driver data maintain it's own timings field. The panel driver is expected to call omapdss_sdi_set_timings() to set these timings before the panel is enabled. Make the SDI panel driver configure the new timings is the omap_dss_device struct(dssdev->panel.timings). The SDI driver is responsible for maintaining only it's own copy of timings. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: SDI: Create a function to set timingsArchit Taneja2012-08-153-12/+20
| | | | | | | | | | | | | | | | | | | | | | Create function omapdss_sdi_set_timings(). Configuring new timings is done the same way as before, SDI is disabled, and re-enabled with the new timings in dssdev. This just moves the code from the panel drivers to the SDI driver. The panel drivers shouldn't be aware of how SDI manages to configure a new set of timings. This should be taken care of by the SDI driver itself. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: HDMI: Add locking for hdmi interface set timing functionsArchit Taneja2012-08-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | The hdmi interface driver exposes functions to the hdmi panel driver to configure the interface timings maintained by the hdmi driver. These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock to ensure they are called sequentially, this is similar to how hdmi enable and disable functions need locking. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface ↵Archit Taneja2012-08-153-28/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | timings The hdmi driver currently updates only the 'code' member of hdmi_config when the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver. The 'timing' field of hdmi_config is updated only when hdmi_power_on is called. It makes more sense to configure the whole hdmi_config field in the set_timing op called by the panel driver. This way, we don't need to call both functions to ensure that our hdmi_config is configured correctly. Also, we don't need to calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings in the panel's omap_dss_device struct. The default timings of the hdmi panel are represented in a cleaner form. Since the hdmi output is now configured by it's own copy of timings (in hdmi.ip_data.cfg), the panel driver needs to set it to a valid value before enabling hdmi output. We now call omapdss_hdmi_set_timing() before enabling hdmi output, this is done to atleast have the hdmi output configured to the panel's default timings if the DSS user didn't call panel driver's set_timings() op explicitly. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Update manager timings on a manual updateArchit Taneja2012-08-131-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | During a command mode update using DISPC video port, we may need to swap the connected overlay manager's width and height when 90 or 270 degree rotation is done via the panel by changing it's address mode. Call dss_mgr_set_timings() in update_screen_dispc() before starting the manager update. The new manager size is updated in the 'timings' field of DSI driver's private data via omapdss_dsi_set_size(). A panel driver is expected to call this when performing rotation. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Add function to set panel size for command mode panelsArchit Taneja2012-08-133-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DSI command mode panels don't need to configure a full set of timings to configure DSI, they only require the width and the height of the panel in pixels. Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is meant for video mode panels. When performing rotation via chaning the address mode of the panel, we would need to swap width and height when doing 90 or 270 rotation. Make sure that omapdss_dsi_set_size() makes the new width and height visible to DSI. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Maintain own copy of timings in driver dataArchit Taneja2012-08-132-22/+38
| | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the timings in omap_dss_device struct to configure the DISPC and DSI blocks accordingly. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own timings field. A DSI video mode panel driver is expected to call omapdss_dsi_set_timings() to set these timings before the panel is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI displays: Take care of panel timings in the driver itselfArchit Taneja2012-08-134-1/+5
| | | | | | | | | | | | | | | | | | | | The timings maintained in omap_dss_device(dssdev->panel.timings) should be maintained by the panel driver itself. It's the panel drivers responsibility to update it if a new set of timings is to be configured. The DPI interface driver shouldn't be responsible of updating the panel timings, it's responsible of maintianing it's own copy of timings. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI: Maintain our own timings field in driver dataArchit Taneja2012-08-139-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DPI driver currently relies on the timings in omap_dss_device struct to configure the DISPC accordingly. This makes the DPI interface driver dependent on the omap_dss_device struct. Make the DPI driver data maintain it's own timings field. The panel driver is expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set these timings before the panel is enabled. In the set_timings() op, we still ensure that the omap_dss_device timings (dssdev->panel.timings) are configured. This will later be configured only by the DPI panel drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Displays: Add locking in generic DPI panel driverArchit Taneja2012-08-131-7/+62
| | | | | | | | | | | | | | | | | | | | The generic DPI panel driver doesn't currently have locking to ensure that the display states and the driver data is maintained correctly. Add mutex locking to take care of this. Add a new get_timings driver op to override the default get_timings op. The new driver op contains locking to ensure the correct panel timings are seen when a DSS2 user calls device->driver->get_timings. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI: Add locking for DPI interfaceArchit Taneja2012-08-131-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The DPI interface driver currently relies on the panel driver to ensure calls like omapdss_dpi_display_enable() and omapdss_dpi_display_disable() are executed sequentially. Also, currently, there is no way to protect the DPI driver data. All DPI panel drivers don't ensure this, and in general, a DPI panel driver should use it's lock to that ensure it's own driver data and omap_dss_device states are taken care of, and not worry about the DPI interface. Add mutex locking in the DPI enable/disable/set_timings ops. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timingsArchit Taneja2012-08-132-3/+3
|/ | | | | | | | The function dss_mgr_set_timings is supposed to apply timings passed by an interface driver. It is not supposed to change the timings. Add const qualifier to the omap_video_timings pointer argument in dss_mgr_set_timings(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPFB: fix framebuffer console colorsGrazvydas Ignotas2012-08-101-1/+1
| | | | | | | | | | | | omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Improvements to DIGIT sync signal selectionRicardo Neri2012-08-101-2/+14
| | | | | | | | | | | | | | | DSS code wrongly assumes that VENC is always available as source for the external sync signal for the display controller DIGIT channel. One cannot blindly write/read the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this operation may not be valid. If the the sync source is not read correctly, the callers of dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance, video timings. Logic is added to correctly get the sync signal based on the available displays in the DIGIT channel. The source is set only if both VENC and HDMI are supported. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Use msleep instead of blocking mdelayJassi Brar2012-08-101-2/+2
| | | | | | | We have no reason to block in the error handler workqueue, so use msleep. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Disable PLL properly in case of error at power_onRicardo Neri2012-08-101-1/+2
| | | | | | | | Small patch to disable the PLL appropriately before runtime_put in case an error occurs while enabling the PHY. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge "Apply LCD manager related parameters" from ArchitTomi Valkeinen2012-06-2910-146/+271
|\ | | | | | | | | | | | | | | | | | | | | | | | | The LCD interface drivers(DPI, DSI, RFBI, SDI) do some direct DISPC register writes to configure LCD manager related fields. This series groups these fields into a single struct, and let's the interface driver apply these parameters. This allows us to: - Check the LCD manager related parameters before applying them. - Remove some omap_dss_device references as APPLY holds the applied parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: OVERLAY: Clean up replication checkingArchit Taneja2012-06-294-37/+16Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replication logic for an overlay depends on the color mode in which it is configured and the video port width of the manager it is connected to. video port width now held in dss_lcd_mgr_config in the manager's private data in APPLY. Use this instead of referring to the omap_dss_device connected to the manager. Replication is enabled in the case of TV manager, the video_port_width is set to a default value of 24 for TV manager. Make the replication checking an overlay function since it's more of an overlay characteristic than a display characteristic. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay managerArchit Taneja2012-06-291-4/+12
| | | | | | | | | | | | | | | | | | The RFBI driver uses a direct DISPC register write to enable the overlay manager. Replace this with dss_mgr_enable() which checks if the connected overlay and managers are correctly configured, and configure DSS for fifomerge. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DISPC: Remove a redundant functionArchit Taneja2012-06-291-16/+6Star
| | | | | | | | | | | | | | | | dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd() in dispc.c. Remove the function from dispc.c and replace it with the one in dss.h. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checksArchit Taneja2012-06-291-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APPLY needs to know at certain places whether an overlay manager is in manual or auto update mode. The caps of the connected omap_dss_device were used to check that. A LCD manager is in manual update if stallmode is enabled for that manager. TV managers for now always auto update. Return the value of stallmode parameter in the private data 'lcd_confg' in mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field will be false by default. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: MANAGER: Check LCD related overlay manager parametersArchit Taneja2012-06-293-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | The LCD related manager configurations are a part of the manager's private data in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function to check the validity of some of the configurations. To check some of the configurations, we require information of interface to which the manager output is connected. These can be added once interfaces are represented as an entity. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface ↵Archit Taneja2012-06-296-57/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers Replace the DISPC fuctions used to configure LCD channel related manager parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that the DISPC registers are written at the right time by using the shadow register programming model. The LCD manager configurations is stored as a private data of manager in APPLY. It is treated as an extra info as it's the panel drivers which trigger this apply via interface drivers, and not a DSS2 user like omapfb or omapdrm. Storing LCD manager related properties in APPLY also prevents the need to refer to the panel connected to the manager for information. This helps in making the DSS driver less dependent on panel. A helper function is added to check whether the manager is LCD or TV. The direct DISPC register writes are removed from the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by SDI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. Create function sdi_config_lcd_manager() which fills the mgr_config parameters and writes to the DISPC registers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-36/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by DSI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. The function dsi_configure_dispc_clocks() is now called in dsi_display_init_dispc(), this lets all the lcd manager related configurations happen in the same place. The DISPC_DIVISORo register was written in dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter in mgr_config. The clock_info is written later in dsi_display_init_dispc(). Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by RFBI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. Create function rfbi_config_lcd_manager() which fills up the mgr_config parameters and writes to the DISPC regs. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by DPI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk() and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in mgr_config. They are written later in dpi_config_lcd_manager. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Add struct to hold LCD overlay manager configurationArchit Taneja2012-06-291-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Create a struct dss_lcd_mgr_config which holds LCD overlay manager related parameters. These are currently partially contained in the omap_dss_device connected to the manager, and the rest are in the interface driver. The parameters are directly written to the DISPC registers in the interface drivers. These should eventually be applied at the correct time using the shadow register programming model. This struct would help in grouping these parameters so that they can be applied together. Signed-off-by: Archit Taneja <archit@ti.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-22 02:53:15 +0200