AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-28 11:05:18 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
dba01625a3
linux_dsm_epyc7002/drivers/video/omap2/dss/dss.h

541 lines
17 KiB
C
Raw Normal View History

OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/*
* linux/drivers/video/omap2/dss/dss.h
*
* Copyright (C) 2009 Nokia Corporation
* Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
*
* Some code and ideas taken from drivers/video/omap/ driver
* by Imre Deak.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef __OMAP2_DSS_H
#define __OMAP2_DSS_H
OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function The printk in DSSDBG function definition is replaced with dynamic debug enabled pr_debug(). The use of dynamic debugging provides more flexibility as each debug statement can be enabled or disabled dynamically on basis of source filename, line number, module name etc., by writing to a control file in debugfs filesystem. For better understanding please refer to Documentation/dynamic-debug-howto.txt. The DSSDBGF() differs from DSSDBG() by providing function name. However, function name, line number, module name and thread ID can be printed through dynamic debug by setting appropriate flags 'f','l','m' and 't' in the debugfs control file. So, DSSDBGF instances are replaced with DSSDBG. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 18:42:58 +07:00
#ifdef pr_fmt
#undef pr_fmt
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
#endif
OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function The printk in DSSDBG function definition is replaced with dynamic debug enabled pr_debug(). The use of dynamic debugging provides more flexibility as each debug statement can be enabled or disabled dynamically on basis of source filename, line number, module name etc., by writing to a control file in debugfs filesystem. For better understanding please refer to Documentation/dynamic-debug-howto.txt. The DSSDBGF() differs from DSSDBG() by providing function name. However, function name, line number, module name and thread ID can be printed through dynamic debug by setting appropriate flags 'f','l','m' and 't' in the debugfs control file. So, DSSDBGF instances are replaced with DSSDBG. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 18:42:58 +07:00
#ifdef DSS_SUBSYS_NAME
#define pr_fmt(fmt) DSS_SUBSYS_NAME ": " fmt
#else
#define pr_fmt(fmt) fmt
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
#endif
OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function The printk in DSSDBG function definition is replaced with dynamic debug enabled pr_debug(). The use of dynamic debugging provides more flexibility as each debug statement can be enabled or disabled dynamically on basis of source filename, line number, module name etc., by writing to a control file in debugfs filesystem. For better understanding please refer to Documentation/dynamic-debug-howto.txt. The DSSDBGF() differs from DSSDBG() by providing function name. However, function name, line number, module name and thread ID can be printed through dynamic debug by setting appropriate flags 'f','l','m' and 't' in the debugfs control file. So, DSSDBGF instances are replaced with DSSDBG. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 18:42:58 +07:00
#define DSSDBG(format, ...) \
pr_debug(format, ## __VA_ARGS__)
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
#ifdef DSS_SUBSYS_NAME
#define DSSERR(format, ...) \
printk(KERN_ERR "omapdss " DSS_SUBSYS_NAME " error: " format, \
## __VA_ARGS__)
#else
#define DSSERR(format, ...) \
printk(KERN_ERR "omapdss error: " format, ## __VA_ARGS__)
#endif
#ifdef DSS_SUBSYS_NAME
#define DSSINFO(format, ...) \
printk(KERN_INFO "omapdss " DSS_SUBSYS_NAME ": " format, \
## __VA_ARGS__)
#else
#define DSSINFO(format, ...) \
printk(KERN_INFO "omapdss: " format, ## __VA_ARGS__)
#endif
#ifdef DSS_SUBSYS_NAME
#define DSSWARN(format, ...) \
printk(KERN_WARNING "omapdss " DSS_SUBSYS_NAME ": " format, \
## __VA_ARGS__)
#else
#define DSSWARN(format, ...) \
printk(KERN_WARNING "omapdss: " format, ## __VA_ARGS__)
#endif
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
number. For example 7:0 */
#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
#define FLD_GET(val, start, end) (((val) & FLD_MASK(start, end)) >> (end))
#define FLD_MOD(orig, val, start, end) \
(((orig) & ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
OMAP: DSS2: Clean up stallmode and io pad mode selection Split the function dispc_set_parallel_interface_mode() into 2 separate functions called dispc_mgr_set_io_pad_mode() and dispc_mgr_enable_stallmode(). The current function tries to set 2 different modes(io pad mode and stall mode) based on a parameter omap_parallel_interface_mode which loosely corresponds to the panel interface type. This isn't correct because a) these 2 modes are independent to some extent, b) we are currently configuring gpout0/gpout1 for DSI panels which is unnecessary, c) a DSI Video mode panel won't get configured correctly. Splitting the functions allows the interface driver to set these modes independently and hence allow more flexibility. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-22 19:11:57 +07:00
enum dss_io_pad_mode {
DSS_IO_PAD_MODE_RESET,
DSS_IO_PAD_MODE_RFBI,
DSS_IO_PAD_MODE_BYPASS,
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
};
OMAP4: DSS2: HDMI: Select between HDMI VENC clock source. Adding function to select between HDMI or VENC clock source. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-09 18:01:38 +07:00
enum dss_hdmi_venc_clk_source_select {
DSS_VENC_TV_CLK = 0,
DSS_HDMI_M_PCLK = 1,
};
OMAP: DSS2: DSI: Introduce generic write functions Intoduce enum "dss_dsi_content_type" to differentiate between DCS and generic content types. Introduce short and long packet write functions which use generic Processor-to-Peripheral transaction types. These are needed by some devices which may not support corresponding DCS commands. Create common write functions which allow code reuse between DCS and generic write functions. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-25 20:05:58 +07:00
enum dss_dsi_content_type {
DSS_DSI_CONTENT_DCS,
DSS_DSI_CONTENT_GENERIC,
};
OMAPDSS: DISPC: Add function to set channel in for writeback Writeback can take input from either one of the overlays, or one of the overlay managers. Add an enum which represents the channel_in for writeback, and maps to the register field programming. Add a function to configure channel in for writeback. This will be used later in APPLY. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-22 14:08:19 +07:00
enum dss_writeback_channel {
DSS_WB_LCD1_MGR = 0,
DSS_WB_LCD2_MGR = 1,
DSS_WB_TV_MGR = 2,
DSS_WB_OVL0 = 3,
DSS_WB_OVL1 = 4,
DSS_WB_OVL2 = 5,
DSS_WB_OVL3 = 6,
DSS_WB_LCD3_MGR = 7,
};
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct dss_clock_info {
/* rates that we get with dividers below */
unsigned long fck;
/* dividers */
u16 fck_div;
};
struct dispc_clock_info {
/* rates that we get with dividers below */
unsigned long lck;
unsigned long pck;
/* dividers */
u16 lck_div;
u16 pck_div;
};
struct dsi_clock_info {
/* rates that we get with dividers below */
unsigned long fint;
unsigned long clkin4ddr;
unsigned long clkin;
OMAP4: DSS2: Clock source changes for OMAP4 On OMAP3, the pixel clock for the LCD manager was derived through DISPC_FCLK as: Lcd Pixel clock = DISPC_FCLK / lcd / pcd Where lcd and pcd are divisors in the DISPC_DIVISOR register. On OMAP4, the pixel clocks for LCD1 and LCD2 managers are derived from 2 new clocks named LCD1_CLK and LCD2_CLK. The pixel clocks are calculated as: Lcd_o Pixel clock = LCDo_CLK / lcdo /pcdo, o = 1, 2 Where lcdo and pcdo registers are divisors in DISPC_DIVISORo registers. LCD1_CLK and LCD2_CLK can have DSS_FCLK, and the M4 divider clocks of DSI1 PLL and DSI2 PLL as clock sources respectively. Introduce functions to select and get the clock source for these new clocks. Modify DISPC functions get the correct lck and pck rates based on the clock source of these clocks. Since OMAP2/3 don't have these clocks, force OMAP2/3 to always have the LCD_CLK source as DSS_CLK_SRC_FCK by introducing a dss feature. Introduce clock source names for OMAP4 and some register field changes in DSS_CTRL on OMAP4. Currently, LCD2_CLK can only have DSS_FCLK as its clock source as DSI2 PLL functionality hasn't been introduced yet. BUG for now if DSI2 PLL is selected as clock. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-08 18:50:35 +07:00
unsigned long dsi_pll_hsdiv_dispc_clk; /* OMAP3: DSI1_PLL_CLK
* OMAP4: PLLx_CLK1 */
unsigned long dsi_pll_hsdiv_dsi_clk; /* OMAP3: DSI2_PLL_CLK
* OMAP4: PLLx_CLK2 */
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
unsigned long lp_clk;
/* dividers */
u16 regn;
u16 regm;
OMAP4: DSS2: Clock source changes for OMAP4 On OMAP3, the pixel clock for the LCD manager was derived through DISPC_FCLK as: Lcd Pixel clock = DISPC_FCLK / lcd / pcd Where lcd and pcd are divisors in the DISPC_DIVISOR register. On OMAP4, the pixel clocks for LCD1 and LCD2 managers are derived from 2 new clocks named LCD1_CLK and LCD2_CLK. The pixel clocks are calculated as: Lcd_o Pixel clock = LCDo_CLK / lcdo /pcdo, o = 1, 2 Where lcdo and pcdo registers are divisors in DISPC_DIVISORo registers. LCD1_CLK and LCD2_CLK can have DSS_FCLK, and the M4 divider clocks of DSI1 PLL and DSI2 PLL as clock sources respectively. Introduce functions to select and get the clock source for these new clocks. Modify DISPC functions get the correct lck and pck rates based on the clock source of these clocks. Since OMAP2/3 don't have these clocks, force OMAP2/3 to always have the LCD_CLK source as DSS_CLK_SRC_FCK by introducing a dss feature. Introduce clock source names for OMAP4 and some register field changes in DSS_CTRL on OMAP4. Currently, LCD2_CLK can only have DSS_FCLK as its clock source as DSI2 PLL functionality hasn't been introduced yet. BUG for now if DSI2 PLL is selected as clock. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-08 18:50:35 +07:00
u16 regm_dispc; /* OMAP3: REGM3
* OMAP4: REGM4 */
u16 regm_dsi; /* OMAP3: REGM4
* OMAP4: REGM5 */
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
u16 lp_clk_div;
};
OMAPDSS: Cleanup implementation of LCD channels The current implementation of LCD channels and managers consists of a number of if-else construct which has been replaced by a simpler interface. A constant structure mgr_desc has been created in Display Controller (DISPC) module. The mgr_desc contains for each channel its name, irqs and is initialized one time with all registers and their corresponding fields to be written to enable various features of Display Subsystem. This structure is later used by various functions of DISPC which simplifies the further implementation of LCD channels and its corresponding managers. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-06-21 12:37:44 +07:00
struct reg_field {
u16 reg;
u8 high;
u8 low;
};
OMAPDSS: Add struct to hold LCD overlay manager configuration 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>
2012-06-29 15:33:48 +07:00
struct dss_lcd_mgr_config {
enum dss_io_pad_mode io_pad_mode;
bool stallmode;
bool fifohandcheck;
struct dispc_clock_info clock_info;
int video_port_width;
int lcden_sig_polarity;
};
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct seq_file;
struct platform_device;
/* core */
OMAPDSS: register only one display device per output We have boards with multiple panel devices connected to the same physical output, of which only one panel can be enabled at one time. Examples of these are Overo, where you can use different daughter boards that have different LCDs, and 3430SDP which has an LCD and a DVI output and a physical switch to select the active display. These are supported by omapdss so that we add all the possible display devices at probe, but the displays are inactive until somebody enables one. At this point the panel driver starts using the DSS, thus reserving the physcal resource and excluding the other panels. This is problematic: - Panel drivers can't allocate their resources properly at probe(), because the resources can be shared with other panels. Thus they can be only reserved at enable time. - Managing this in omapdss is confusing. It's not natural to have child devices, which may not even exist (for example, a daughterboard that is not connected). Only some boards have multiple displays per output, and of those, only very few have possibility of switching the display during runtime. Because of the above points: - We don't want to make omapdss and all the panel drivers more complex just because some boards have complex setups. - Only few boards support runtime switching, and afaik even then it's not required. So we don't need to support runtime switching. Thus we'll change to a model where we will have only one display device per output and this cannot be (currently) changed at runtime. We'll still have the possibility to select the display from multiple options during boot with the default display option. This patch accomplishes the above by changing how the output drivers register the display device. Instead of registering all the devices given from the board file, we'll only register one. If the default display option is set, the output driver selects that display from its displays. If the default display is not set, or the default display is not one of the output's displays, the output driver selects the first display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-06 18:29:31 +07:00
const char *dss_get_default_display_name(void);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct bus_type *dss_get_bus(void);
OMAP: DSS2: enable VDDS_DSI when using DPI It looks like on OMAP3 some DSS pins need VDDS_DSI to function properly. This has not been confirmed from TI, but looking at figure 15-1 "Display subsystem highlight" from the TRM, some data pins come near the DSI and SDI blocks. This is not very hard evidence, but the fact remains that with the power on, pixels are ok, and with the power off, pixels are not ok. It may also be that VDDS_SDI is needed to power some pins, but as normally both VDDS_SDI and VDDS_DSI come from the same power source, this hasn't been shown. It seems that a single driver can only get a regulator once. This patch solves it by getting all the required regulators in one place, and from which the submodules then get the regulators they need. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-02-04 22:03:41 +07:00
struct regulator *dss_get_vdds_dsi(void);
struct regulator *dss_get_vdds_sdi(void);
OMAPDSS: clean up the omapdss platform data mess The omapdss pdata handling is a mess. This is more evident when trying to use device tree for DSS, as we don't have platform data anymore in that case. This patch cleans the pdata handling by: - Remove struct omap_display_platform_data. It was used just as a wrapper for struct omap_dss_board_info. - Pass the platform data only to omapdss device. The drivers for omap dss hwmods do not need the platform data. This should also work better for DT, as we can create omapdss device programmatically in generic omap boot code, and thus we can pass the pdata to it. - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads that the dss hwmod drivers can call. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-20 16:50:06 +07:00
int dss_get_ctx_loss_count(struct device *dev);
int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask);
void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask);
OMAPDSS: Ensure OPP100 when DSS is operational Most of the DSS clocks have restrictions on their frequency based on the OPP in use. For example, maximum frequency for a clock may be 180MHz in OPP100, but 90MHz in OPP50. This means that when a high enough pixel clock or function clock is required, we need to use OPP100. However, there's currently no way in the PM framework to make that kind of request. The closest we get is to ask for very high bus throughput from the PM framework, which should effectively force OPP100. This patch is a simple version for handling the problem. Instead of asking for OPP100 only when needed, this patch asks for OPP100 whenever DSS is active. This obviously is not an optimal solution for cases with small displays where OPP50 would work just fine. However, a proper solution is a complex one, and this patch is a short term solution for the problem. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Kevin Hilman <khilman@ti.com>
2012-03-08 17:52:38 +07:00
int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
OMAPDSS: move the creation of debugfs files Instead of having an ugly #ifdef mess in the core.c for creating debugfs files, add a dss_debugfs_create_file() function that the dss drivers can use to create the debugfs files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-02 23:01:07 +07:00
int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *));
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: alloc dssdevs dynamically We currently create omap_dss_devices statically in board files, and use those devices directly in the omapdss driver. This model prevents us from having the platform data (which the dssdevs in board files practically are) as read-only, and it's also different than what we will use with device tree. This patch changes the model to be in line with DT model: we allocate the dssdevs dynamically, and initialize them according to the data in the board file's dssdev (basically we memcopy the dssdev fields). The allocation and registration is done in the following steps in the output drivers: - Use dss_alloc_and_init_device to allocate and initialize the device. The function uses kalloc and device_initialize to accomplish this. - Call dss_copy_device_pdata to copy the data from the board file's dssdev - Use dss_add_device to register the device. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-10 17:58:29 +07:00
struct omap_dss_device *dss_alloc_and_init_device(struct device *parent);
int dss_add_device(struct omap_dss_device *dssdev);
void dss_unregister_device(struct omap_dss_device *dssdev);
void dss_unregister_child_devices(struct device *parent);
void dss_put_device(struct omap_dss_device *dssdev);
void dss_copy_device_pdata(struct omap_dss_device *dst,
const struct omap_dss_device *src);
OMAPDSS: interface drivers register their panel devices Currently the higher level omapdss platform driver gets the list of displays in its platform data, and uses that list to create the omap_dss_device for each display. With DT, the logical way to do the above is to list the displays under each individual output, i.e. we'd have "dpi" node, under which we would have the display that uses DPI. In other words, each output driver handles the displays that use that particular output. To make the current code ready for DT, this patch modifies the output drivers so that each of them creates the display devices which use that output. However, instead of changing the platform data to suit this method, each output driver is passed the full list of displays, and the drivers pick the displays that are meant for them. This allows us to keep the old platform data, and thus we avoid the need to change the board files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-01 20:45:53 +07:00
OMAPDSS: create apply.c Create a new file, apply.c, and move code about handling the apply-mechanism and configuration of the managers and overlays from manager.c to apply.c. Not all related code is moved in this patch, but only the core apply/configure functions. The later patches move rest of the code from overlay.c and manager.c, adding necessary locking at the same time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-04 14:48:54 +07:00
/* apply */
void dss_apply_init(void);
int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr);
int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl);
void dss_mgr_start_update(struct omap_overlay_manager *mgr);
int omap_dss_mgr_apply(struct omap_overlay_manager *mgr);
OMAPDSS: APPLY: move mgr funcs to apply.c apply.c will handle the management of dispc in the future patches. This patch moves overlay manager related functions to apply.c so that they will have access to the private data and functions of apply.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 17:15:18 +07:00
OMAPDSS: APPLY: add return value to dss_mgr_enable() Now that dss_mgr_enable() can fail due to checks, make it return the error value. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-21 18:34:48 +07:00
int dss_mgr_enable(struct omap_overlay_manager *mgr);
OMAPDSS: hide manager's enable/disable() omap_overlay_manager struct contains enable() and disable() functions. However, these are only meant to be used from inside omapdss, and thus it's bad to expose the functions. This patch adds dss_mgr_enable() and dss_mgr_disable() functions to apply.c, which handle enabling and disabling the output. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-04 15:22:46 +07:00
void dss_mgr_disable(struct omap_overlay_manager *mgr);
OMAPDSS: APPLY: move mgr funcs to apply.c apply.c will handle the management of dispc in the future patches. This patch moves overlay manager related functions to apply.c so that they will have access to the private data and functions of apply.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 17:15:18 +07:00
int dss_mgr_set_info(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info);
void dss_mgr_get_info(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info);
OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager Add set_output/unset_output ops for overlay managers, these form links between managers and outputs. Create a function in dss features which tell all the output instances that connect to a manager, use it when a manager tries to set an output. Add a constraint of not unsetting an output when the manager is enabled. Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for now to not break things. Keep the dss feature function get_supported_displays as it's used in some places. These will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 18:12:39 +07:00
int dss_mgr_set_output(struct omap_overlay_manager *mgr,
struct omap_dss_output *output);
int dss_mgr_unset_output(struct omap_overlay_manager *mgr);
OMAPDSS: APPLY: Add manager timings as extra_info in private data DISPC manager size and DISPC manager blanking parameters(for LCD managers) follow the shadow register programming model. Currently, they are programmed directly by the interface drivers. To configure manager timings using APPLY, there is a need to introduce extra info flags for managers, similar to what is done for overlays. This is needed because timings aren't a part of overlay_manager_info struct configured by a user of DSS, they are configured internally by the interface or panel drivers. Add dirty and shadow_dirty extra_info flags for managers, update these flags at the appropriate places. Rewrite the function extra_info_update_ongoing() slightly as checking for manager's extra_info flags can simplify the code a bit. Create function dss_mgr_set_timings() which applies the new manager timings to extra_info. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-26 21:01:22 +07:00
void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings 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>
2012-07-19 15:21:14 +07:00
const struct omap_video_timings *timings);
OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface 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>
2012-06-29 16:07:03 +07:00
void dss_mgr_set_lcd_config(struct omap_overlay_manager *mgr,
const struct dss_lcd_mgr_config *config);
OMAPDSS: APPLY: Remove display dependency from overlay and manager checks In order to check the validity of overlay and manager info, there was a need to use the omap_dss_device struct to get the panel resolution. The manager's private data in APPLY now contains the manager timings. Hence, we don't need to rely on the display resolution any more. Pass the manager's timings in private data to dss_mgr_check(). Remove the need to pass omap_dss_device structs in the functions which check for the validity of overlay and manager parameters. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-27 02:52:28 +07:00
const struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr);
OMAPDSS: create apply.c Create a new file, apply.c, and move code about handling the apply-mechanism and configuration of the managers and overlays from manager.c to apply.c. Not all related code is moved in this patch, but only the core apply/configure functions. The later patches move rest of the code from overlay.c and manager.c, adding necessary locking at the same time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-04 14:48:54 +07:00
OMAPDSS: APPLY: rewrite overlay enable/disable Overlays are currently enabled and disabled with a boolean in the struct omap_overlay_info. The overlay info is set with ovl->set_overlay_info(), and made into use with mgr->apply(). This doesn't work properly, as the enable/disable status may affect also other overlays, for example when using fifo-merge. Thus the enabling and disabling of the overlay needs to be done outside the normal overlay configuration. This patch achieves that by doing the following things: 1) Add function pointers to struct omap_overlay: enable(), disable() and is_enabled(). These are used to do the obvious. The functions may block. 2) Move the "enabled" field from struct omap_overlay to ovl_priv_data. 3) Add a new route for settings to be applied to the HW, called "extra_info". The status of the normal info and extra_info are tracked separately. The point here is to allow the normal info to be changed and applied in non-blocking matter, whereas the extra_info can only be changed when holding the mutex. This makes it possible to, for example, set the overlay enable flag, apply it, and wait until the HW has taken the flag into use. This is not possible if the enable flag would be in the normal info, as a new value for the flag could be set at any time from the users of omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 21:37:53 +07:00
bool dss_ovl_is_enabled(struct omap_overlay *ovl);
int dss_ovl_enable(struct omap_overlay *ovl);
int dss_ovl_disable(struct omap_overlay *ovl);
OMAPDSS: APPLY: move ovl funcs to apply.c apply.c will handle the management of dispc in the future patches. This patch moves overlay related functions to apply.c so that they will have access to the private data and functions of apply.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 17:11:11 +07:00
int dss_ovl_set_info(struct omap_overlay *ovl,
struct omap_overlay_info *info);
void dss_ovl_get_info(struct omap_overlay *ovl,
struct omap_overlay_info *info);
int dss_ovl_set_manager(struct omap_overlay *ovl,
struct omap_overlay_manager *mgr);
int dss_ovl_unset_manager(struct omap_overlay *ovl);
OMAPDSS: outputs: Create a new entity called outputs The current OMAPDSS design contains 3 software entities: Overlays, Managers and Devices. These map to pipelines, overlay managers and the panels respectively in hardware. One or more overlays connect to a manager to represent a composition, the manager connects to a device(generally a display) to display the content. The part of DSS hardware which isn't represented by any of the above entities are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI, HDMI, VENC and so on. Currently, an overlay manager directly connects to the display, and the output to which it is actually connected is ignored. The panel driver of the display is responsible of calling output specific functions to configure the output. Adding outputs as a new software entity gives us the following benefits: - Have exact information on the possible connections between managers and outputs: A manager can't connect to each and every output, there only limited hardware links between a manager's video port and some of the outputs. - Remove hacks related to connecting managers and devices: Currently, default links between managers and devices are set in a not so clean way. Matching is done via comparing the device type, and the display types supported by the manager. This isn't sufficient to establish all the possible links between managers, outputs and devices in hardware. - Make panel drivers more generic: The DSS panel drivers currently call interface/output specific functions to configure the hardware IP. When making these calls, the driver isn't actually aware of the underlying output. The output driver extracts information from the panel's omap_dss_device pointer to figure out which interface it is connected to, and then configures the corresponding output block. An example of this is when a DSI panel calls dsi functions, the dsi driver figures out whether the panel is connected to DSI1 or DSI2. This isn't correct, and having output as entities will give the panel driver the exact information on which output to configure. Having outputs also gives the opportunity to make panel drivers generic across different platforms/SoCs, this is achieved as omap specific output calls can be replaced by ops of a particular output type. - Have more complex connections between managers, outputs and devices: OMAPDSS currently doesn't support use cases like 2 outputs connect to a single device. This can be achieved by extending properties of outputs to connect to more managers or devices. - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS as compared to overlays, managers or devices. Add a new struct to represent outputs. An output struct holds pointers to the manager and device structs to which it is connected. Add functions which can register/unregister an output, or look for one. Create an enum which represent each output instance. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
/* output */
void dss_register_output(struct omap_dss_output *out);
void dss_unregister_output(struct omap_dss_output *out);
OMAPDSS: Create links between managers, outputs and devices Links between DSS entities are made in dss_init_connections() when a panel device is registered, and are removed in dss_uninit_connections() when the device is unregistered. Modify these functions to incorporate the addition of outputs. The fields in omap_dss_device struct gives information on which output and manager to connect to. The desired manager and output pointers are retrieved and prepared to form the desired links. The output is linked to the device, and then the manager to the output. A helper function omapdss_get_output_from_device() is created to retrieve the output from the display by checking it's type, and the module id in case of DSI. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-10 16:04:16 +07:00
struct omap_dss_output *omapdss_get_output_from_dssdev(struct omap_dss_device *dssdev);
OMAPDSS: outputs: Create a new entity called outputs The current OMAPDSS design contains 3 software entities: Overlays, Managers and Devices. These map to pipelines, overlay managers and the panels respectively in hardware. One or more overlays connect to a manager to represent a composition, the manager connects to a device(generally a display) to display the content. The part of DSS hardware which isn't represented by any of the above entities are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI, HDMI, VENC and so on. Currently, an overlay manager directly connects to the display, and the output to which it is actually connected is ignored. The panel driver of the display is responsible of calling output specific functions to configure the output. Adding outputs as a new software entity gives us the following benefits: - Have exact information on the possible connections between managers and outputs: A manager can't connect to each and every output, there only limited hardware links between a manager's video port and some of the outputs. - Remove hacks related to connecting managers and devices: Currently, default links between managers and devices are set in a not so clean way. Matching is done via comparing the device type, and the display types supported by the manager. This isn't sufficient to establish all the possible links between managers, outputs and devices in hardware. - Make panel drivers more generic: The DSS panel drivers currently call interface/output specific functions to configure the hardware IP. When making these calls, the driver isn't actually aware of the underlying output. The output driver extracts information from the panel's omap_dss_device pointer to figure out which interface it is connected to, and then configures the corresponding output block. An example of this is when a DSI panel calls dsi functions, the dsi driver figures out whether the panel is connected to DSI1 or DSI2. This isn't correct, and having output as entities will give the panel driver the exact information on which output to configure. Having outputs also gives the opportunity to make panel drivers generic across different platforms/SoCs, this is achieved as omap specific output calls can be replaced by ops of a particular output type. - Have more complex connections between managers, outputs and devices: OMAPDSS currently doesn't support use cases like 2 outputs connect to a single device. This can be achieved by extending properties of outputs to connect to more managers or devices. - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS as compared to overlays, managers or devices. Add a new struct to represent outputs. An output struct holds pointers to the manager and device structs to which it is connected. Add functions which can register/unregister an output, or look for one. Create an enum which represent each output instance. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* display */
int dss_suspend_all_devices(void);
int dss_resume_all_devices(void);
void dss_disable_all_devices(void);
OMAPDSS: handle errors in dss_init_device Add error handling to dss_init_device(), which has, for some reason, been missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 19:44:30 +07:00
int dss_init_device(struct platform_device *pdev,
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct omap_dss_device *dssdev);
void dss_uninit_device(struct platform_device *pdev,
struct omap_dss_device *dssdev);
/* manager */
int dss_init_overlay_managers(struct platform_device *pdev);
void dss_uninit_overlay_managers(struct platform_device *pdev);
OMAPDSS: APPLY: move simple_check functions The functions dss_ovl_simple_check() and dss_mgr_simple_check() are not really part of the apply mechanism, and can be moved to overlay.c and manager.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-12-13 18:18:52 +07:00
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
OMAPDSS: MANAGER: Create a function to check manager timings Create a function dss_mgr_check_timings() which wraps around the function dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions from interface drivers. dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently takes the timings maintained in the omap_dss_device struct. This would be later replaced by the timings stored in the manager's private data. Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const omap_video_timings pointer since these functions just check the timings. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-27 02:37:28 +07:00
int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
const struct omap_video_timings *timings);
OMAPDSS: APPLY: move check functions The functions dss_ovl_check, dss_mgr_check_zorder, dss_mgr_check in apply.c are not really part of the apply mechanism, and can be moved to overlay.c and manager.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-12-08 15:32:37 +07:00
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info,
OMAPDSS: APPLY: Remove display dependency from overlay and manager checks In order to check the validity of overlay and manager info, there was a need to use the omap_dss_device struct to get the panel resolution. The manager's private data in APPLY now contains the manager timings. Hence, we don't need to rely on the display resolution any more. Pass the manager's timings in private data to dss_mgr_check(). Remove the need to pass omap_dss_device structs in the functions which check for the validity of overlay and manager parameters. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-27 02:52:28 +07:00
const struct omap_video_timings *mgr_timings,
OMAPDSS: MANAGER: Check LCD related overlay manager parameters 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>
2012-05-23 18:31:35 +07:00
const struct dss_lcd_mgr_config *config,
OMAPDSS: APPLY: move check functions The functions dss_ovl_check, dss_mgr_check_zorder, dss_mgr_check in apply.c are not really part of the apply mechanism, and can be moved to overlay.c and manager.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-12-08 15:32:37 +07:00
struct omap_overlay_info **overlay_infos);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface 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>
2012-06-29 16:07:03 +07:00
static inline bool dss_mgr_is_lcd(enum omap_channel id)
{
if (id == OMAP_DSS_CHANNEL_LCD || id == OMAP_DSS_CHANNEL_LCD2 ||
id == OMAP_DSS_CHANNEL_LCD3)
return true;
else
return false;
}
OMAPDSS: split manager sysfs code Separate sysfs code for managers to a separate file. This is a bit cleaner, and will allow us later to easily switch off the sysfs support via Kconfig option. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-06 18:44:09 +07:00
int dss_manager_kobj_init(struct omap_overlay_manager *mgr,
struct platform_device *pdev);
void dss_manager_kobj_uninit(struct omap_overlay_manager *mgr);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* overlay */
void dss_init_overlays(struct platform_device *pdev);
void dss_uninit_overlays(struct platform_device *pdev);
void dss_overlay_setup_dispc_manager(struct omap_overlay_manager *mgr);
OMAPDSS: APPLY: move simple_check functions The functions dss_ovl_simple_check() and dss_mgr_simple_check() are not really part of the apply mechanism, and can be moved to overlay.c and manager.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-12-13 18:18:52 +07:00
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info);
OMAPDSS: APPLY: Remove display dependency from overlay and manager checks In order to check the validity of overlay and manager info, there was a need to use the omap_dss_device struct to get the panel resolution. The manager's private data in APPLY now contains the manager timings. Hence, we don't need to rely on the display resolution any more. Pass the manager's timings in private data to dss_mgr_check(). Remove the need to pass omap_dss_device structs in the functions which check for the validity of overlay and manager parameters. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-27 02:52:28 +07:00
int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
const struct omap_video_timings *mgr_timings);
OMAPDSS: OVERLAY: Clean up replication checking 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>
2012-06-25 16:28:48 +07:00
bool dss_ovl_use_replication(struct dss_lcd_mgr_config config,
enum omap_color_mode mode);
OMAPDSS: split overlay sysfs code Separate sysfs code for overlays to a separate file. This is a bit cleaner, and will allow us later to easily switch off the sysfs support via Kconfig option. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-06 18:40:00 +07:00
int dss_overlay_kobj_init(struct omap_overlay *ovl,
struct platform_device *pdev);
void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* DSS */
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int dss_init_platform_driver(void) __init;
OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver of DSS is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers. DSS platform driver is registered from inside omap_dss_probe, in the order desired. Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-01-24 13:21:57 +07:00
void dss_uninit_platform_driver(void);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: Add support for DPI source selection We can select the video source for DPI output as follows: OMAP2/3: always LCD1 OMAP4: LCD2 or DIGIT OMAP5: LCD1/LCD2/LCD3/DIGIT This patch adds support to select the source, and makes dpi.c call the function to set the source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Anders <x0132446@ti.com>
2012-09-21 16:09:54 +07:00
int dss_dpi_select_source(enum omap_channel channel);
OMAP4: DSS2: HDMI: Select between HDMI VENC clock source. Adding function to select between HDMI or VENC clock source. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-09 18:01:38 +07:00
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
OMAP: DSS2: add dss_get_hdmi_venc_clk_source() Add dss_get_hdmi_venc_clk_source(), which can be used to get the value programmed with dss_select_hdmi_venc_clk_source(). This can be used to find out if the digit output is going to VENC or HDMI. For OMAP2/3 dss_get_hdmi_venc_clk_source() always returns DSS_VENC_TV_CLK. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-31 18:33:31 +07:00
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
OMAP2PLUS: DSS2: Change enum "dss_clk_source" to "omap_dss_clk_source" Change enum dss_clk_source to omap_dss_clock_source and move it to 'plat/display.h'. Change the enum members to attach "OMAP_" in the beginning. These changes are done in order to specify the clock sources for DSS in the board file. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-12 15:22:23 +07:00
const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
OMAP2, 3: DSS2: Move clocks from core driver to dss driver All clock management is moved to dss platform driver. clk_get/put APIs use dss device instead of core platform device. Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So the device name is changed from omapdss to omapdss_dss in 2420, 2430, 3xxx clock database files. Now the core driver "omapdss" only takes care of panel registration with the custom bus. core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for clock management. DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC TODO: The clock content would be adapted to omap_hwmod in a seperate series. Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-01-24 13:21:58 +07:00
void dss_dump_clocks(struct seq_file *s);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: Create new debug config options The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for OMAPDSS. Both the config options are disabled by default and can be enabled independently of one another as per convenience. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-29 12:55:42 +07:00
#if defined(CONFIG_OMAP2_DSS_DEBUGFS)
OMAP2, 3: DSS2: Move clocks from core driver to dss driver All clock management is moved to dss platform driver. clk_get/put APIs use dss device instead of core platform device. Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So the device name is changed from omapdss to omapdss_dss in 2420, 2430, 3xxx clock database files. Now the core driver "omapdss" only takes care of panel registration with the custom bus. core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for clock management. DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC TODO: The clock content would be adapted to omap_hwmod in a seperate series. Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-01-24 13:21:58 +07:00
void dss_debug_dump_clocks(struct seq_file *s);
#endif
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: SDI: Maintain copy of data pairs in driver data 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>
2012-07-20 18:48:49 +07:00
void dss_sdi_init(int datapairs);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
int dss_sdi_enable(void);
void dss_sdi_disable(void);
OMAP2PLUS: DSS2: Change enum "dss_clk_source" to "omap_dss_clk_source" Change enum dss_clk_source to omap_dss_clock_source and move it to 'plat/display.h'. Change the enum members to attach "OMAP_" in the beginning. These changes are done in order to specify the clock sources for DSS in the board file. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-12 15:22:23 +07:00
void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src);
OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4 Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol engine and DISPC Functional clock. Do the following: - Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the dsi module number as an argument. - Create debugfs files for dsi2, split the corresponding debugfs functions. - Allow DPI to use these new clock sources. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:29 +07:00
void dss_select_dsi_clk_source(int dsi_module,
enum omap_dss_clk_source clk_src);
OMAP4: DSS2: Clock source changes for OMAP4 On OMAP3, the pixel clock for the LCD manager was derived through DISPC_FCLK as: Lcd Pixel clock = DISPC_FCLK / lcd / pcd Where lcd and pcd are divisors in the DISPC_DIVISOR register. On OMAP4, the pixel clocks for LCD1 and LCD2 managers are derived from 2 new clocks named LCD1_CLK and LCD2_CLK. The pixel clocks are calculated as: Lcd_o Pixel clock = LCDo_CLK / lcdo /pcdo, o = 1, 2 Where lcdo and pcdo registers are divisors in DISPC_DIVISORo registers. LCD1_CLK and LCD2_CLK can have DSS_FCLK, and the M4 divider clocks of DSI1 PLL and DSI2 PLL as clock sources respectively. Introduce functions to select and get the clock source for these new clocks. Modify DISPC functions get the correct lck and pck rates based on the clock source of these clocks. Since OMAP2/3 don't have these clocks, force OMAP2/3 to always have the LCD_CLK source as DSS_CLK_SRC_FCK by introducing a dss feature. Introduce clock source names for OMAP4 and some register field changes in DSS_CTRL on OMAP4. Currently, LCD2_CLK can only have DSS_FCLK as its clock source as DSI2 PLL functionality hasn't been introduced yet. BUG for now if DSI2 PLL is selected as clock. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-08 18:50:35 +07:00
void dss_select_lcd_clk_source(enum omap_channel channel,
OMAP2PLUS: DSS2: Change enum "dss_clk_source" to "omap_dss_clk_source" Change enum dss_clk_source to omap_dss_clock_source and move it to 'plat/display.h'. Change the enum members to attach "OMAP_" in the beginning. These changes are done in order to specify the clock sources for DSS in the board file. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-12 15:22:23 +07:00
enum omap_dss_clk_source clk_src);
enum omap_dss_clk_source dss_get_dispc_clk_source(void);
OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4 Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol engine and DISPC Functional clock. Do the following: - Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the dsi module number as an argument. - Create debugfs files for dsi2, split the corresponding debugfs functions. - Allow DPI to use these new clock sources. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:29 +07:00
enum omap_dss_clk_source dss_get_dsi_clk_source(int dsi_module);
OMAP2PLUS: DSS2: Change enum "dss_clk_source" to "omap_dss_clk_source" Change enum dss_clk_source to omap_dss_clock_source and move it to 'plat/display.h'. Change the enum members to attach "OMAP_" in the beginning. These changes are done in order to specify the clock sources for DSS in the board file. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-12 15:22:23 +07:00
enum omap_dss_clk_source dss_get_lcd_clk_source(enum omap_channel channel);
OMAP: DSS2: improve DSS clk src selection dss_select_clk_source() was rather confusing. Selecting the source with enums is much clearer. The clk source selection is also stored into memory, so that we know what is the selected source, even when clocks are off. This is important during setup, as we need to what clocks to turn on before the clocks are turned on. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-01-08 23:00:36 +07:00
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
void dss_set_venc_output(enum omap_dss_venc_type type);
void dss_set_dac_pwrdn_bgz(bool enable);
unsigned long dss_get_dpll4_rate(void);
int dss_set_clock_div(struct dss_clock_info *cinfo);
OMAPDSS: Remove passive matrix LCD support (part 1) 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>
2012-06-21 11:03:55 +07:00
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct dispc_clock_info *dispc_cinfo);
/* SDI */
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* DSI */
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#ifdef CONFIG_OMAP2_DSS_DSI
OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4 Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol engine and DISPC Functional clock. Do the following: - Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the dsi module number as an argument. - Create debugfs files for dsi2, split the corresponding debugfs functions. - Allow DPI to use these new clock sources. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:29 +07:00
struct dentry;
struct file_operations;
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int dsi_init_platform_driver(void) __init;
void dsi_uninit_platform_driver(void) __exit;
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAP: DSS2: Use PM runtime & HWMOD support Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-27 14:52:19 +07:00
int dsi_runtime_get(struct platform_device *dsidev);
void dsi_runtime_put(struct platform_device *dsidev);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
void dsi_dump_clocks(struct seq_file *s);
void dsi_irq_handler(void);
OMAP: DSS2: Create an enum for DSI pixel formats Currently, DSI pixel info is only represented by the pixel size in bits using the pixel_size parameter in omap_dss_device struct's ctrl member. This is not sufficient information for DSI video mode usage, as two of the supported formats(RGB666 loosely packed, and RGB888) have the same pixel container size, but different data_type values for the video mode packet header. Create enum "omap_dss_dsi_pixel_format" which describes the pixel data format the panel is configured for. Create helper function dsi_get_pixel_size() which returns the pixel size of the given pixel format. Modify functions omapdss_default_get_recommended_bpp() and dss_use_replication() to use dsi_get_pixel_size(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-08 20:12:16 +07:00
u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
unsigned long dsi_get_pll_hsdiv_dispc_rate(struct platform_device *dsidev);
int dsi_pll_set_clock_div(struct platform_device *dsidev,
struct dsi_clock_info *cinfo);
OMAPDSS: Remove passive matrix LCD support (part 1) 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>
2012-06-21 11:03:55 +07:00
int dsi_pll_calc_clock_div_pck(struct platform_device *dsidev,
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
unsigned long req_pck, struct dsi_clock_info *cinfo,
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
struct dispc_clock_info *dispc_cinfo);
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
bool enable_hsdiv);
void dsi_pll_uninit(struct platform_device *dsidev, bool disconnect_lanes);
void dsi_wait_pll_hsdiv_dispc_active(struct platform_device *dsidev);
void dsi_wait_pll_hsdiv_dsi_active(struct platform_device *dsidev);
struct platform_device *dsi_get_dsidev_from_id(int module);
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#else
OMAP: DSS2: Use PM runtime & HWMOD support Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-27 14:52:19 +07:00
static inline int dsi_runtime_get(struct platform_device *dsidev)
{
return 0;
}
static inline void dsi_runtime_put(struct platform_device *dsidev)
{
}
OMAP: DSS2: Create an enum for DSI pixel formats Currently, DSI pixel info is only represented by the pixel size in bits using the pixel_size parameter in omap_dss_device struct's ctrl member. This is not sufficient information for DSI video mode usage, as two of the supported formats(RGB666 loosely packed, and RGB888) have the same pixel container size, but different data_type values for the video mode packet header. Create enum "omap_dss_dsi_pixel_format" which describes the pixel data format the panel is configured for. Create helper function dsi_get_pixel_size() which returns the pixel size of the given pixel format. Modify functions omapdss_default_get_recommended_bpp() and dss_use_replication() to use dsi_get_pixel_size(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-08 20:12:16 +07:00
static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
{
WARN("%s: DSI not compiled in, returning pixel_size as 0\n", __func__);
return 0;
}
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
static inline unsigned long dsi_get_pll_hsdiv_dispc_rate(struct platform_device *dsidev)
OMAP2PLUS: DSS2: Cleanup clock source related code Clean up some of the DSS functions which select/get clock sources, use switch to select the clock source members since more clock sources will be introduced later on. Remove the use of macro CONFIG_OMAP2_DSS_DSI in dispc_fclk_rate, use a dummy inline for function for dsi_get_pll_hsdiv_dispc_rate() instead for code clarity. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-08 18:50:34 +07:00
{
WARN("%s: DSI not compiled in, returning rate as 0\n", __func__);
return 0;
}
OMAP: DSS2: Add missing dummy functions dpi.c does not compile if DSI is not compiled in. Add the missing dummy functions so that dpi.c compiles. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-30 19:38:15 +07:00
static inline int dsi_pll_set_clock_div(struct platform_device *dsidev,
struct dsi_clock_info *cinfo)
{
WARN("%s: DSI not compiled in\n", __func__);
return -ENODEV;
}
static inline int dsi_pll_calc_clock_div_pck(struct platform_device *dsidev,
OMAPDSS: Remove passive matrix LCD support (part 1) 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>
2012-06-21 11:03:55 +07:00
unsigned long req_pck,
OMAP: DSS2: Add missing dummy functions dpi.c does not compile if DSI is not compiled in. Add the missing dummy functions so that dpi.c compiles. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-04-30 19:38:15 +07:00
struct dsi_clock_info *dsi_cinfo,
struct dispc_clock_info *dispc_cinfo)
{
WARN("%s: DSI not compiled in\n", __func__);
return -ENODEV;
}
static inline int dsi_pll_init(struct platform_device *dsidev,
bool enable_hsclk, bool enable_hsdiv)
{
WARN("%s: DSI not compiled in\n", __func__);
return -ENODEV;
}
static inline void dsi_pll_uninit(struct platform_device *dsidev,
bool disconnect_lanes)
{
}
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
static inline void dsi_wait_pll_hsdiv_dispc_active(struct platform_device *dsidev)
OMAP: DSS2: DSI: Wait for DSI PLL clocks to be active before selecting them The TRM tells us to wait for the DSI PLL derived clocks to become active before selecting them for use. I didn't actually have any issues which this would fix but according to the TRM it seems to be the right thing to do. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-06-09 19:28:12 +07:00
{
}
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
static inline void dsi_wait_pll_hsdiv_dsi_active(struct platform_device *dsidev)
OMAP: DSS2: DSI: Wait for DSI PLL clocks to be active before selecting them The TRM tells us to wait for the DSI PLL derived clocks to become active before selecting them for use. I didn't actually have any issues which this would fix but according to the TRM it seems to be the right thing to do. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-06-09 19:28:12 +07:00
{
}
OMAP: DSS2: Pass platform_device as an argument in dsi functions The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12 18:56:26 +07:00
static inline struct platform_device *dsi_get_dsidev_from_id(int module)
{
WARN("%s: DSI not compiled in, returning platform device as NULL\n",
__func__);
return NULL;
}
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#endif
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* DPI */
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int dpi_init_platform_driver(void) __init;
void dpi_uninit_platform_driver(void) __exit;
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* DISPC */
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int dispc_init_platform_driver(void) __init;
void dispc_uninit_platform_driver(void) __exit;
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
void dispc_dump_clocks(struct seq_file *s);
OMAP: DSS2: Use PM runtime & HWMOD support Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-27 14:52:19 +07:00
int dispc_runtime_get(void);
void dispc_runtime_put(void);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
void dispc_enable_sidle(void);
void dispc_disable_sidle(void);
void dispc_lcd_enable_signal(bool enable);
void dispc_pck_free_enable(bool enable);
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
void dispc_enable_fifomerge(bool enable);
void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
OMAPDSS: DISPC: Clean up manager timing/size functions Clean up the DISPC manager timings related function by: - Create a common function to set size for LCD and TV. - Create a common function to check timings for LCD and TV. - Add dss params to get the range of manager size. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-16 14:23:44 +07:00
bool dispc_mgr_timings_ok(enum omap_channel channel,
OMAPDSS: MANAGER: Create a function to check manager timings Create a function dss_mgr_check_timings() which wraps around the function dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions from interface drivers. dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently takes the timings maintained in the omap_dss_device struct. This would be later replaced by the timings stored in the manager's private data. Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const omap_video_timings pointer since these functions just check the timings. Signed-off-by: Archit Taneja <archit@ti.com>
2012-04-27 02:37:28 +07:00
const struct omap_video_timings *timings);
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
unsigned long dispc_fclk_rate(void);
OMAPDSS: Remove passive matrix LCD support (part 1) 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>
2012-06-21 11:03:55 +07:00
void dispc_find_clk_divs(unsigned long req_pck, unsigned long fck,
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
struct dispc_clock_info *cinfo);
int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
struct dispc_clock_info *cinfo);
OMAPDSS: DISPC: make dispc_ovl_set_fifo_threshold() public Make dispc_ovl_set_fifo_threshold() public so that later patches can handle overlay fifo configuration. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-10-31 13:58:52 +07:00
void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
OMAPDSS: DISPC: move fifo threhold calc to dispc.c Move fifo threshold calculation into dispc.c, as the thresholds are really dispc internal thing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-01-13 18:17:01 +07:00
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays There is a problem related to DSS FIFO thresholds and power management on OMAP3. It seems that when the full PM hits in, we get underflows. The core reason is unknown, but after experiments it looks like only particular FIFO thresholds work correctly. This bug is related to an earlier patch, which added special FIFO threshold configuration for OMAP3, because DSI command mode output didn't work with the normal threshold configuration. However, as the above work-around worked fine for other output types also, we currently always configure thresholds in this special way on OMAP3. In theory there should be negligible difference with this special way and the standard way. The first paragraph explains what happens in practice. This patch changes the driver to use the special threshold configuration only when the output is a manual update display on OMAP3. This does include RFBI displays also, and although it hasn't been tested (no boards using RFBI) I suspect the similar behaviour is present there also, as the DISPC side should work similarly for DSI command mode and RFBI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Joe Woodward <jw@terrafix.co.uk>
2012-05-15 19:31:01 +07:00
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
bool manual_update);
OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup() The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field was being changed in dispc_ovl_setup in the case of interlaced displays. Fix this and const qualifier to the omap_overlay_info argument. Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-22 14:03:49 +07:00
int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode The scalers of overlays and writeback do not have any constraints on downscale ratio when operating in memory to memory mode. This is because in memory to memory mode, we aren't connected to a display which needs data output at the rate of pixel clock. The scalers can perform as much downscaling as needed, the rate at which the scaler outputs is adjusted accordingly. Relax constraints related to downscaling based on whether the input overlays are connected to writeback in memory to memory mode. We pass a mem_to_mem boolean parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this will later be configured to the correct value based on whether the overlay is connected to writeback or not. Do the same later for writeback when writeback is configured. In the scaling calculation code, we calculate the minimum amount of core clock we need to achieve the required downscaling. If we are in memory to memory mode, we set this to a very small value(1 in this case), this value would always be lesser than the actual DISPC core clock value, and hence the scaling checks would succeed. We take care that pixel clock isn't calculated for writeback and the overlays connected to it when in memory to memory mode. A pixel clock in such cases doesn't make sense. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 18:30:37 +07:00
bool replication, const struct omap_video_timings *mgr_timings,
bool mem_to_mem);
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
int dispc_ovl_enable(enum omap_plane plane, bool enable);
OMAPDSS: DISPC: make dispc_ovl_set_channel_out() public Make dispc_ovl_set_channel_out() public so that later patches can handle changing overlay's manager. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-10-28 19:26:26 +07:00
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
OMAPDSS: DISPC: Add dispc_mgr_get_vsync_irq() Add dispc_mgr_get_vsync_irq() which returns the irq number for vsync on the given channel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-07 20:50:09 +07:00
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel);
OMAPDSS: DISPC: add dispc_mgr_get_framedone_irq Add dispc_mgr_get_framedone_irq() which returns the irq number for FRAMEDONE for the given channel. Note that the function returns always 0 for DIGIT channel, even if OMAP4 does have FRAMEDONE_TV interrupt. The reason for this is that this function is currently used only to track manual updates, and thus FRAMEDONE_TV is not needed. If there's need in the future to also get the FRAMEDONE_TV this needs revisiting. However, as FRAMEDONE_TV doesn't exist on OMAP2/3, the use of this function for that purpose needs some extra code to handle the OMAP2/3 case. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-18 20:39:52 +07:00
u32 dispc_mgr_get_framedone_irq(enum omap_channel channel);
OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq() Add function that returns the sync lost irq mask for the given channel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-17 14:38:52 +07:00
u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel);
OMAP: DSS2: DISPC: rename manager related funcs Rename dispc's manager related functions as follows: - Remove prepending underscores, which were originally used to inform that the clocks needs to be enabled. This meaning is no longer valid. - Prepend the functions with dispc_mgr_* - Remove "channel" from the name, e.g. dispc_enable_channel -> dispc_mgr_enable The idea is to group manager related functions so that it can be deduced from the function name that it writes to manager spesific registers. All dispc_mgr_* functions have enum omap_channel as the first parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:45:15 +07:00
bool dispc_mgr_go_busy(enum omap_channel channel);
void dispc_mgr_go(enum omap_channel channel);
OMAPDSS: DISPC: add missing prototype dispc_mgr_is_enabled() was missing a prototype in dss.h Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 15:56:11 +07:00
bool dispc_mgr_is_enabled(enum omap_channel channel);
OMAPDSS: DISPC: cleanup lcd/digit enable/disable We currently have a single function to enable and disable the manager output for LCD and DIGIT. The functions are a bit complex, as handling both enable and disable require some extra steps to ensure that the output is enabled or disabled properly without errors before exiting the function. The code can be made simpler to understand by splitting the functions into separate enable and disable functions. We'll also clean up the comments and some parameter names at the same time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-10 16:48:31 +07:00
void dispc_mgr_enable(enum omap_channel channel);
void dispc_mgr_disable(enum omap_channel channel);
OMAP: DSS2: DISPC: rename manager related funcs Rename dispc's manager related functions as follows: - Remove prepending underscores, which were originally used to inform that the clocks needs to be enabled. This meaning is no longer valid. - Prepend the functions with dispc_mgr_* - Remove "channel" from the name, e.g. dispc_enable_channel -> dispc_mgr_enable The idea is to group manager related functions so that it can be deduced from the function name that it writes to manager spesific registers. All dispc_mgr_* functions have enum omap_channel as the first parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:45:15 +07:00
bool dispc_mgr_is_channel_enabled(enum omap_channel channel);
OMAPDSS: combine LCD related config into one func Dispc has a bunch of functions used to configure output related parameters: - dispc_mgr_set_io_pad_mode - dispc_mgr_enable_stallmode - dispc_mgr_enable_fifohandcheck - dispc_mgr_set_clock_div - dispc_mgr_set_tft_data_lines - dispc_lcd_enable_signal_polarity - dispc_mgr_set_lcd_type_tft These are all called together, and the configuration values are taken from struct dss_lcd_mgr_config. Instead of exposing those individual dispc functions, create a new one, dispc_mgr_set_lcd_config(), which is used to configure the above parameters from values in struct dss_lcd_mgr_config. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-12 17:30:39 +07:00
void dispc_mgr_set_lcd_config(enum omap_channel channel,
const struct dss_lcd_mgr_config *config);
OMAPDSS: DISPC: Use a common function to set manager timings Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV manager's timings is set by dispc_set_digit_size(). Use a common function called dispc_mgr_set_timings() which sets timings for both type of managers. We finally want the interface drivers to use an overlay manager function to configure it's timings, having a common DISPC function would make things cleaner. For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for TV manager, it sets only the TV size since blanking values don't exist for TV. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-16 14:23:43 +07:00
void dispc_mgr_set_timings(enum omap_channel channel,
OMAPDSS: DISPC: constify function parameters Add consts to dispc function parameters which do not modify the passed structs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-03 14:09:11 +07:00
const struct omap_video_timings *timings);
OMAP: DSS2: reorganize functions in dss.h Group dispc's overlay and manager related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:49:15 +07:00
unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
OMAPDSS: DISPC: Correct DISPC functional clock usage DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC. DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC divisor LCD. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 13:46:50 +07:00
unsigned long dispc_core_clk_rate(void);
OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() 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>
2012-06-29 15:30:54 +07:00
void dispc_mgr_set_clock_div(enum omap_channel channel,
OMAPDSS: DISPC: constify function parameters Add consts to dispc function parameters which do not modify the passed structs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-03 14:09:11 +07:00
const struct dispc_clock_info *cinfo);
OMAP: DSS2: DISPC: rename manager related funcs Rename dispc's manager related functions as follows: - Remove prepending underscores, which were originally used to inform that the clocks needs to be enabled. This meaning is no longer valid. - Prepend the functions with dispc_mgr_* - Remove "channel" from the name, e.g. dispc_enable_channel -> dispc_mgr_enable The idea is to group manager related functions so that it can be deduced from the function name that it writes to manager spesific registers. All dispc_mgr_* functions have enum omap_channel as the first parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-16 17:45:15 +07:00
int dispc_mgr_get_clock_div(enum omap_channel channel,
OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument The following dispc functions are also changed to incorporate channel as an argument: -dispc_lclk_rate() -dispc_pclk_rate() -dispc_set_pol_freq() -dispc_set_clock_div() -dispc_get_clock_div() Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Mukund Mittal <mmittal@ti.com> Signed-off-by: Samreen <samreen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> [tomi.valkeinen@nokia.com: fixed trivial compile error] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-12-02 18:27:11 +07:00
struct dispc_clock_info *cinfo);
OMAPDSS: setup manager with dispc_mgr_setup() Change manager configuration to be similar to overlay configuration by creating dispc_mgr_setup() which takes omap_overlay_manager_info as parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-04 23:14:20 +07:00
void dispc_mgr_setup(enum omap_channel channel,
OMAPDSS: DISPC: constify function parameters Add consts to dispc function parameters which do not modify the passed structs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-03 14:09:11 +07:00
const struct omap_overlay_manager_info *info);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAPDSS: DISPC: Add manager like functions for writeback Add functions to enable writeback, and set/check state of GO bit. These bits are identical in behaviour with the corresponding overlay manager bits. Configure them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to get the FRAMEDONE irq corresponding to writeback. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-22 14:09:33 +07:00
u32 dispc_wb_get_framedone_irq(void);
bool dispc_wb_go_busy(void);
void dispc_wb_go(void);
void dispc_wb_enable(bool enable);
bool dispc_wb_is_enabled(void);
OMAPDSS: DISPC: Add function to set channel in for writeback Writeback can take input from either one of the overlays, or one of the overlay managers. Add an enum which represents the channel_in for writeback, and maps to the register field programming. Add a function to configure channel in for writeback. This will be used later in APPLY. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-22 14:08:19 +07:00
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup Create struct omap_dss_writeback_info, this is similar to omap_overlay_info, the major difference is that there is no parameter which describes the input size to writeback, this is because this is always fixed, and decided by the connected overlay or overlay manager. One more difference is that screen_width is renamed to buf_width, to give the value of stride the writeback buffer has. Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like parameters. The parameters in dispc_ovl_setup_common() which do not hold for writeback are filled passed as zeroes or false, the code takes care of not configuring them as they won't possess the needed overlay caps. Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-31 14:02:52 +07:00
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup() Configure some of the writeback specific parameters in dispc_wb_setup(). The writeback parameters configured are: truncation: This needs to be set if the color depth input to writeback is more than the color depth of the color mode we want to store in memory. writeback mode: This configures whether we want to use writeback in mem to mem or capture mode. This information will be directly passed by APPLY later. Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-24 18:29:26 +07:00
bool mem_to_mem, const struct omap_video_timings *timings);
OMAPDSS: DISPC: Add function to set channel in for writeback Writeback can take input from either one of the overlays, or one of the overlay managers. Add an enum which represents the channel_in for writeback, and maps to the register field programming. Add a function to configure channel in for writeback. This will be used later in APPLY. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-22 14:08:19 +07:00
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* VENC */
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#ifdef CONFIG_OMAP2_DSS_VENC
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int venc_init_platform_driver(void) __init;
void venc_uninit_platform_driver(void) __exit;
OMAPDSS: DISPC: Get correct pixel clock for TV manager dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-13 19:58:41 +07:00
unsigned long venc_get_pixel_clock(void);
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#else
OMAPDSS: DISPC: Get correct pixel clock for TV manager dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-13 19:58:41 +07:00
static inline unsigned long venc_get_pixel_clock(void)
{
WARN("%s: VENC not compiled in, returning pclk as 0\n", __func__);
return 0;
}
OMAP: DSS2: omap_dss_probe() conditional compilation cleanup Move a number of #ifdefs from code into dss.h and elsewhere, and conditionally define no-op static inline functions, cleaning up the code. This style is according to Documentation/SubmittingPatches. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-05-07 16:58:41 +07:00
#endif
OMAPDSS: VENC: Split VENC into interface and panel driver 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>
2012-07-06 22:22:37 +07:00
int omapdss_venc_display_enable(struct omap_dss_device *dssdev);
void omapdss_venc_display_disable(struct omap_dss_device *dssdev);
void omapdss_venc_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_venc_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
OMAPDSS: VENC: Maintain copy of venc type in driver data 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>
2012-08-16 13:25:15 +07:00
void omapdss_venc_set_type(struct omap_dss_device *dssdev,
enum omap_dss_venc_type type);
OMAPDSS: VENC: Maintian copy of video output polarity info in private data 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>
2012-08-16 13:26:31 +07:00
void omapdss_venc_invert_vid_out_polarity(struct omap_dss_device *dssdev,
bool invert_polarity);
OMAPDSS: VENC: Split VENC into interface and panel driver 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>
2012-07-06 22:22:37 +07:00
int venc_panel_init(void);
void venc_panel_exit(void);
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS Adding the hdmi interface driver(hdmi.c) to the dss driver. It configures the audio and video portion of HDMI based on functionality called by the panel driver. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Yong Zhi <y-zhi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-12 13:34:27 +07:00
/* HDMI */
#ifdef CONFIG_OMAP4_DSS_HDMI
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int hdmi_init_platform_driver(void) __init;
void hdmi_uninit_platform_driver(void) __exit;
OMAPDSS: DISPC: Get correct pixel clock for TV manager dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-13 19:58:41 +07:00
unsigned long hdmi_get_pixel_clock(void);
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS Adding the hdmi interface driver(hdmi.c) to the dss driver. It configures the audio and video portion of HDMI based on functionality called by the panel driver. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Yong Zhi <y-zhi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-12 13:34:27 +07:00
#else
OMAPDSS: DISPC: Get correct pixel clock for TV manager dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-13 19:58:41 +07:00
static inline unsigned long hdmi_get_pixel_clock(void)
{
WARN("%s: HDMI not compiled in, returning pclk as 0\n", __func__);
return 0;
}
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS Adding the hdmi interface driver(hdmi.c) to the dss driver. It configures the audio and video portion of HDMI based on functionality called by the panel driver. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Yong Zhi <y-zhi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-12 13:34:27 +07:00
#endif
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev);
void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev);
OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface 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>
2012-08-08 18:20:42 +07:00
void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS Adding the hdmi interface driver(hdmi.c) to the dss driver. It configures the audio and video portion of HDMI based on functionality called by the panel driver. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Yong Zhi <y-zhi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-12 13:34:27 +07:00
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
OMAP: DSS2: HDMI: implement read_edid() Implement read_edid() for HDMI by implementing necessary functions to hdmi.c and to hdmi_omap4_panel.c. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-25 21:12:56 +07:00
int omapdss_hdmi_read_edid(u8 *buf, int len);
OMAP: DSS2: HDMI: implement detect() Implement detect() by checking the hot plug detect status. The implementation is not very good, as it always turns on the HDMI output to get the detection working. HDMI driver needs improvements so that we could enable only core parts of it. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-29 22:10:20 +07:00
bool omapdss_hdmi_detect(void);
OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller to manage the enable and disable requests and synchronize audio and video. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-10 17:18:48 +07:00
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
OMAPDSS: HDMI: Implement DSS driver interface for audio Implement the DSS device driver audio support interface in the HDMI panel driver and generic driver. The implementation relies on the IP-specific functions that are defined at DSS probe time. A mixed locking strategy is used. The panel's mutex is used when the state of the panel is queried as required by the audio functions. The audio state is protected using a spinlock as users of DSS HDMI audio functionality might start/stop audio while holding a spinlock. The mutex and the spinlock are held and released as needed by each individual function to protect the panel state and the audio state. Although the panel's audio_start functions does not check whether the panel is active, the audio _ENABLED state can be reached only from audio_enable, which does check the state of the panel. Also, if the panel is ever disabled, the audio state will transition to _DISABLED. Transitions are always protected by the audio lock. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
2012-05-10 09:09:50 +07:00
#ifdef CONFIG_OMAP4_DSS_HDMI_AUDIO
int hdmi_audio_enable(void);
void hdmi_audio_disable(void);
int hdmi_audio_start(void);
void hdmi_audio_stop(void);
bool hdmi_mode_has_audio(void);
int hdmi_audio_config(struct omap_dss_audio *audio);
#endif
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS Adding the hdmi interface driver(hdmi.c) to the dss driver. It configures the audio and video portion of HDMI based on functionality called by the panel driver. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Yong Zhi <y-zhi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-12 13:34:27 +07:00
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
/* RFBI */
OMAPDSS: add __init & __exit Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-17 22:41:13 +07:00
int rfbi_init_platform_driver(void) __init;
void rfbi_uninit_platform_driver(void) __exit;
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
OMAP: DSS2: Collect interrupt statistics Collect interrupt statistics, printable via debugfs: debugfs/omapdss/dispc_irq debugfs/omapdss/dsi_irq The counters are reset when printed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-12-17 19:35:21 +07:00
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
static inline void dss_collect_irq_stats(u32 irqstatus, unsigned *irq_arr)
{
int b;
for (b = 0; b < 32; ++b) {
if (irqstatus & (1 << b))
irq_arr[b]++;
}
}
#endif
OMAP: DSS2: Display Subsystem Driver core The core files of DSS2. DSS2 commits are split a bit artificially to make the individual commits smaller, and DSS2 doesn't compile properly without the rest of the core commits. This shouldn't be a problem, as no configuration uses DSS2 yet. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-11-03 16:23:50 +07:00
#endif
Reference in New Issue Copy Permalink