- 13 Aug, 2012 6 commits
-
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
- 10 Aug, 2012 4 commits
-
-
Grazvydas Ignotas authored
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>
-
Ricardo Neri authored
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>
-
Jassi Brar authored
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>
-
Ricardo Neri authored
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>
-
- 29 Jun, 2012 30 commits
-
-
Tomi Valkeinen authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
dipsc_mgr_set_clock div has an int return type to report errors or success. The function doesn't really check for errors and always returns 0. Change the return type to void. Checking for the correct DISPC clock divider ranges will be done when a DSS2 user does a manager apply. This support will be added later. Signed-off-by: Archit Taneja <archit@ti.com>
-
Chandrabhanu Mahapatra authored
The dispc_disable_outputs() function currently disables all LCD managers except LCD3. This patch adds disabling functionality for LCD3 manager thereby maintaining consistency of Display Subsystem for in case Display Controller is reset when LCD3 manager is in use. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
This series does the following things: - Remove passive matrix LCD support: There are no panel drivers with passive matrix LCD drivers in DSS2. There are no passive matrix panels even available to test with DSS. Since no one is using passive matrix panels, stop trying to support it. It cleans up the DSS driver. - Add some new fields to omap_video_timings: There were some standard panel timing fields missing from omap_video_timings. Namely Hsync/Vsync/DE levels and interlace. Add these to omap_video_timings to align it more with xorg modeline. Add some other OMAP DSS specific fields to omap_video_timings. - Remove some hacks done because omap_video_timings didn't have the above fields. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and VP_DE_POL in DSI_CTRL registers. This information is completely internal to DSS as logic levels for the above signals hold no meaning on the DSI bus. Hence a DSI panel driver should be totally oblivious of these fields. Fix the logic levels/polarities in the DISPC and DSI registers to a default value. This is done by overriding these fields in omap_video_timings struct filled by the panel driver for DISPC, and use the equivalent default values when programming DSI_CTRL registers. Also, remove the redundant polarity related fields in omap_dss_dsi_videomode_data. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings, omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync polarities and interlaced/progressive information. Remove hdmi_video_timings, and use omap_video_timings instead. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Use the interlace field in omap_video_timings to configure/retrieve corresponding fb mode flags in fb_var_screeninfo and fb_videomode. The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and FB_VMODE_NONINTERLACED. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Currently the interlace parameter passed to dispc_ovl_setup() is configured by checking the display type, and set to true if the display type is VENC. This isn't correct as other panels can take interlaced content too. The omap_video_timings struct in manager's private data contains the info whether the panel is in interlaced mode or not. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Add a parameter called interlace which tells whether the timings are in interlaced or progressive mode. This aligns the omap_video_timings struct with the Xorg modeline configuration. It also removes the hack needed to write to divide the manager height by 2 if the connected interface is VENC. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
omap_panel_config contains fields which are finally written to DISPC_POL_FREQo registers. These are now held by omap_video_timings and are set when the manager timings are applied. Remove the omap_panel_config enum, and remove all it's references from panel or interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable logic levels and data, hsync and vsync latching related info) to configure/retrieve corresponding sync flags in fb_var_screeninfo and fb_videomode. Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT. When converting fb mode to omap_video_timings, the fields which don't have an equivalent parameter in fb are kept as the original values if the panel driver has a get_timings op, else they are set to default values. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo. All these fields have been moved to omap_video_timings struct, and are now programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings are applied via dss_mgr_set_timings(). Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes, Hsync and Vsync signals(with respect to pixel clock) are newly added parameters in omap_video_timings. Program these in dispc_mgr_set_lcd_timings. These will be configured when the manager's timings are set via dss_mgr_set_timings(). Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
The display sysfs file for viewing/storing display timings is something which will be deprecated. The new omap_video_timings fields (hsync_level, vsync_level and others) are not configurable or viewable via this sysfs file. This prevents the need to make the input more configurable to take the new fields and at the same time work without these fields for backward compatibility. In display_timings_store, the omap_video_timings struct used to set the timings is initialized to the existing panel timings so that the new fields are taken in correctly. The other fields are taken from the user as before. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Some panel timing related fields are contained in omap_panel_config in the form of flags. The fields are: - Hsync logic level - Vsync logic level - Data driven on rising/falling edge of pixel clock - Output enable/Data enable logic level - HSYNC/VSYNC driven on rising/falling edge of pixel clock Out of these parameters, Hsync and Vsync logic levels are a part of the timings in the Xorg modeline configuration. So it makes sense to move the to omap_video_timings. The rest aren't a part of modeline, but it still makes sense to move these since they are related to panel timings. These fields stored in omap_panel_config in dssdev are configured for LCD panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers. Add the above fields in omap_video_timings. Represent their state via new enums. Add these parameters to the omap_video_timings instances in the panel drivers. Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in omap_panel_config for now. The struct will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Remove configuration of Ac-bias pins Ac-bias pins need to be configured only for passive matrix displays. Remove acbi and acb fields in omap_dss_device and their configuration in panel drivers. Don't program these fields in DISP_POL_FREQo register any more. The panel driver for sharp-ls037v7dw01, and the panel config for Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This is most likely carried over from the old omapfb driver which supported passive matrix displays. Cc: Thomas Weber <weber@corscience.de> Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Remove omap_lcd_display_type enum The enum omap_lcd_display_type is used to configure the lcd display type in DISPC. Remove this enum and always set display type to TFT by creating function dss_mgr_set_lcd_type_tft(). Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag. We don't support passive matrix displays any more. Remove this flag from all the panel drivers. Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
-
Archit Taneja authored
Remove clock constraints related to passive matrix displays. There is a constraint (pcd_min should be 3) for passive matrix displays. Remove this constraint in clock divider calculations as we won't support passive matrix displays any more. This cleans up the functions which calculate the clock dividers with DSI's PLL or DSS_FCLK as the clock source. Signed-off-by: Archit Taneja <archit@ti.com>
-