summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for ↵Archit Taneja2012-11-121-5/+13
| | | | | | | | | | | | | | | | | | | | | | writeback When calculating row and pixel increments for graphics and video pipes, we need to consider the dimensions of the input frame to know how to read from the buffer. Hence, we need to calculate these parameters from the input to the pipeline. For writeback, the row and pixel increments need to be calculated based on the output of the writeback pipeline, i.e, the dimensions of the frame after scaling. Ensure that dispc driver uses values of out_width and out_height when calling calc_dma/calc_tiler_rotation_offset. For graphics and video pipes, the original code passed the original height as frame_height to calc_dma_rotation_offset, and not the predecimated height. This is left as it is for now. We need to figure out why pre decimated height isn't needed. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Don't allow predecimation for writebackArchit Taneja2012-11-121-3/+8
| | | | | | | | | Since writeback writes to a buffer instead of reading from one, predecimation doesn't make sense for it. Configure the width and height predecimation limits to 1 if the plane is writeback. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipelineArchit Taneja2012-11-121-4/+6
| | | | | | | | | | | | | | | | | dispc_ovl_calc_scaling_44xx() doesn't work correctly for writeback. There are two issues with it: - the function tries to calculate pixel clock for the input plane using dispc_plane_pclk_rate(), calling this with writeback as input plane results in a BUG(), this function shouldn't be called for writeback at all. Fix this by calculating pixel clock only when we are not in mem to mem mode. - the maximum input_width is the product of the downscale ratio supported and the and the given output_width. This was calculated incorrectly by dividing output_width with maxdownscale. Fix this. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HACK: look for regulators with omap4 namesTomi Valkeinen2012-11-072-0/+12
| | | | | | | | | | | | | | Normally the omapdss driver gets the regulators using the regulator names assigned for omapdss. However, in an effort to get a minimal DSS support for DT enabled kernel on selected boards, we will add omapdss devices and platform data the old way even for DT kernel. This causes the problem that omapdss cannot find the regulators using omapdss's regulator names. This patch creates a temporary workaround for DSI and HDMI by trying to get the regulators also using native OMAP4 regulator names. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Remove __exit macro from hdmi_uninit_displayRicardo Neri2012-11-071-1/+1
| | | | | | | | | | | This function is now used in the driver init path to handle probe errors properly. Thus, it may be possible to use this function outside the exit path. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: fix sparse warningTomi Valkeinen2012-11-071-1/+1
| | | | | | | | | | Fix sparse warning: drivers/video/omap2/dss/dispc.c:3320:6: warning: symbol 'dispc_dump_irqs' was not declared. Should it be static? Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
* OMAPDSS: HDMI: Create platform device for audio supportRicardo Neri2012-11-061-0/+62
| | | | | | | | | | | | | | | Creating the accessory devices, such as audio, from the HDMI driver allows to regard HDMI as a single entity with audio an display functionality. This intends to follow the design of drivers such as MFD, in which a single entity handles the creation of the accessory devices. Such devices are then used by domain-specific drivers; audio in this case. Also, this is in line with the DT implementation of HDMI, in which we will have a single node to describe this feature of the OMAP SoC. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Add op to get audio DMA port address offsetRicardo Neri2012-11-063-0/+13
| | | | | | | | | It could be possible that the DMA port differs accross diferent HDMI IPs. Thus, add an IP-specific function to obtain the address offset and size of the DMA data port. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Uninit display on device add errorRicardo Neri2012-11-061-0/+1
| | | | | | | The display must be uninitialized in order to free the requested GPIOs. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Handle panel init error at probeRicardo Neri2012-11-061-3/+11
| | | | | | | | | Do not blindly assume that the panel could be initialized. While there, group mutex initialization at a single place. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Make panel return dssdev register errorsRicardo Neri2012-11-061-3/+1
| | | | | | | Do not assume blindly that the DSS driver was registered successfully. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Convert to devm_request_and_ioremapRicardo Neri2012-11-061-4/+2
| | | | | | | | Using devm_request_and_ioremap provides better memory handling and improves readability. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Rename resource variable at probe.Ricardo Neri2012-11-061-5/+4
| | | | | | | Minor cleanup to give to the resource variable a more proper name. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: Fix the usage of wait_for_completion_timeoutChuansheng Liu2012-11-061-2/+0
| | | | | | | | | | The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Fix the usage of wait_for_completion_timeoutChuansheng Liu2012-11-061-3/+0
| | | | | | | | | | The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: fix DS variable nameTomi Valkeinen2012-11-051-5/+5
| | | | | | | | | check_horiz_timing_omap3() has a variable named 'DS'. i386 uses DS name for something else, causing a compilation error. As 'DS' is not a very good local variable name in the first place, let's change it to 'ds', fixing the issue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge branch '3.8/dsi-pll-work'Tomi Valkeinen2012-11-056-50/+151
|\ | | | | | | Merge omapdss patches to enable using DSI PLL for DPI output.
| * OMAPDSS: DPI: always use DSI PLL if availableTomi Valkeinen2012-11-051-27/+37
| | | | | | | | | | | | | | | | | | | | We currently get the decision whether to use PRCM or DSI PLL clock for DPI from the board file. This is not a good way to handle it, and it won't work with device tree. This patch changes DPI to always use DSI PLL if it's available. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DPI: verify if DSI PLL is operationalTomi Valkeinen2012-11-051-0/+27
| | | | | | | | | | | | | | | | | | | | | | The SoCs that have DSI module should have a working DSI PLL. However, some rare boards have not connected the powers to the DSI PLL. This patch adds a function that tries to power up the DSI PLL, and reports if that doesn't succeed. DPI uses this function to fall back to PRCM clocks if DSI PLL doesn't work. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pllTomi Valkeinen2012-11-051-6/+6
| | | | | | | | | | | | | | Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we can just check if dpi.dsidev != NULL. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: hide dss_select_dispc_clk_source()Tomi Valkeinen2012-11-055-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dss.c currently exposes functions to configure the dispc source clock and lcd source clock. There are configured separately from the output drivers. However, there is no safe way for the output drivers to handle dispc clock, as it's shared between the outputs. Thus, if, say, the DSI driver sets up DSI PLL and configures both the dispc and lcd clock sources to that DSI PLL, the resulting dispc clock could be too low for, say, HDMI. Thus the output drivers should really only be concerned about the lcd clock, which is what the output drivers actually use. There's lot to do to clean up the dss clock handling, but this patch takes one step forward and removes the use of dss_select_dispc_clk_source() from the output drivers. After this patch, the output drivers only configure the lcd source clock. On omap4+ the dispc src clock is never changed from the default PRCM source. On omap3, where the dispc and lcd clocks are actually the same, setting the lcd clock source sets the dispc clock source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: setup default dss fckTomi Valkeinen2012-11-051-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't currently set the dss fck when starting up. This is not a problem, as we setup the fck later when configuring the pixel clocks. Or this is how it was for omap2, for the rest of the omaps this may not be so. For DSI, HDMI and also for DPI when using DSI PLL, we don't need to change the dss fck, and thus it may be left unconfigured. Usually the dss fck is already setup fine by default, but we can't trust this. This patch sets the dss fck to maximum at probe time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: add dss_calc_clock_rates() backTomi Valkeinen2012-11-052-0/+24
| | | | | | | | | | | | | | dss_calc_clock_rates() was removed earlier as it was not used, but it is needed for DSI PLL calculations, so this patch adds it back. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DSI: workaround for HSDiv problemTomi Valkeinen2012-11-051-0/+6
| | | | | | | | | | | | | | | | | | It looks like on many OMAP versions powers for both HSClk and HSDiv to be enabled to have a functional HSDiv. This patch fixes the issue by forcing both powers on. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DSI: skip odd dividers when pck >= 100MHzTomi Valkeinen2012-11-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI PLL and HSDivider can be used to generate the pixel clock for LCD overlay manager, which then goes to DPI output. On the DPI output pin the voltage of the signal is shifted from the OMAP's internal minimal voltage to 1.8V range. The shifting is not instant, and the higher the clock frequency, the less time there is to shift the signal to nominal voltage. If the HSDivider's divider is greater than one and odd, the resulting pixel clock does not have 50% duty cycle. For example, with a divider of 3, the duty cycle is 33%. When combining high frequency (in the area of 140MHz+) and non-50% duty cycle, it has been observed the the shifter does not have enough time to shift the voltage enough, and this leads to bad signal which is rejected by monitors. As a workaround this patch makes the divider calculation skip all odd dividers when the required pixel clock is over 100MHz. The limit of 100MHz is a guesstimate. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: fix DPI & DSI init orderTomi Valkeinen2012-11-051-6/+6
|/ | | | | | | | | | | | | | | DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver is added first, which causes DPI initialization to fail when it tries to get the DSI PLL. This patch changes the init order to fix this. A better solution would be to separate DSI PLL and DSI drivers. They have dependencies, though, but we could still have DSI PLL as an independent entity that we could initialize before any of the output drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge branch '3.8/misc-2'Tomi Valkeinen2012-11-0527-664/+315
|\ | | | | | | Merge omapdss miscellaneous patches.
| * OMAPDSS: split hdmi muxing functionTomi Valkeinen2012-10-291-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | Split the omap4_hdmi_mux_pads() function into two parts, one handles the tpd12s015 gpio muxing, the other handles the hdmi pins. This is clearer, as hdmi and tpd12s015 are separate devices, and it also allows us to mux those separately with DT. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ricardo Neri <ricardo.neri@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
| * OMAPDSS: DISPC: remove dssdev depependency from error handlerTomi Valkeinen2012-10-291-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dispc error handler tries to "fix" issues by disabling and enabling panel. This is problematic, as we're trying to remove the dependency from omapdss to the omap_dss_devices. It's also racy, and doesn't really fix anything. This patch removes the use of omap_dss_device from the error handler, and just disables and enables the associated overlay manager. This should produce similar results as the previous solution, without using dssdev. However, the error handling is still horrible. But the problem boils down to one question, to which I don't have a clear answer: what to do when a HW error happens? Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DISPC: fix loop in error handlerTomi Valkeinen2012-10-291-2/+3
| | | | | | | | | | | | | | | | The dispc's error handler has a loop inside another loop, and both use the same loop variable. This is clearly wrong, and this patch makes a new variable for the inner loop. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: fix DSI2 PLL clk namesTomi Valkeinen2012-10-291-0/+2
| | | | | | | | | | | | | | dss_generic_clk_source_names is missing the names for clocks from DSI2 PLL. Add them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPFB: improve mode selection from EDIDTomi Valkeinen2012-10-291-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current omapfb code goes over all the modes found from the monitors EDID data, and searches for a mode that is compatible with the DSS hardware and has the highest x-res. While this works ok as such, it proves problematic when using DSI PLL for pixel clock. Calculating DSI PLL dividers is not the fastest of the operations, and while doing it for one mode is usually ok, doing it for 20 modes is noticable. Also, the first mode given in the EDID data should be the native mode of the monitor, and thus also the best mode, so if that can be used, no need to look further. This patch changes the code to use the first mode that is compatible with the DSS hardware. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPFB: remove use of extended edid blockTomi Valkeinen2012-10-291-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | It seems that using the second EDID block causes more problems than is of any help. The first mode in the extended block will get FB_MODE_IS_FIRST set, which will override the first mode from the first EDID block, thus making the default videomode selection not to work properly. This patch removes the use of the extended edid block for now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI: make hdmi pclk check more permissiveTomi Valkeinen2012-10-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hdmi driver tries to find the given video timings from its static list of timings, to find the required ID for the mode. The check tries to find exact match for the pixel clock, among other checks. with omapfb driver there can be some amount of error in the give pixel clock, as the pixel clock is converted between Hz and ps, thus the hdmi's check fails to find the mode. This patch makes the check more allowing, by rounding the pixel clocks to nearest MHz. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ricardo Neri <ricardo.neri@ti.com>
| * OMAPDSS: HDMI: add 1920x1200 video modeTomi Valkeinen2012-10-291-0/+6
| | | | | | | | | | | | | | Add 1920x1200 video mode to hdmi driver's static modelist. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ricardo Neri <ricardo.neri@ti.com>
| * OMAPDSS: HDMI: use core power on/off with edid & detectTomi Valkeinen2012-10-293-4/+41
| | | | | | | | | | | | | | | | | | This patch makes use of the hdmi_power_[on|off]_core() functions added in the previous patch. The functions are used when reading EDID or detecting if a monitor is connected. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ricardo Neri <ricardo.neri@ti.com>
| * OMAPDSS: HDMI: split power_on/off to two partsTomi Valkeinen2012-10-291-29/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's currently just one power-on function for HDMI, which enables the IP and the video output. When reading EDID or detecting if a monitor is connected, we don't need the video output. Enabling the video output for these operations is not a big problem in itself, but the quick enable/disable cycles caused by the operations seem to cause sync lost errors from time to time. Also, this makes it possible to read the EDID before the full video path has been set up. This patch splits the hdmi_power_on into two parts, hdmi_power_on_core and hdmi_power_on_full. The "full" version does what hdmi_power_on does currently, and hdmi_power_on_core only enables the core IP. Similar changes are made for power_off. Note that these don't allow the HDMI IP to be first enabled, and later enable the video output, but the HDMI IP will first need to be powered off before calling the full version. So this is rather limited implementation, but it fills the needs for reading EDID. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ricardo Neri <ricardo.neri@ti.com>
| * OMAPDSS: DISPC: Add IRQ enable/status helpersTomi Valkeinen2012-10-292-12/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DISPC irqs need to be handled from the compat layer and also in the future by the omapdrm. To make this possible, this patchs adds a set of helper functions, so that the irqs can be managed without direct register reads/writes. The following functions are added, and all the current direct reg reads/writes are changed to use these. u32 dispc_read_irqstatus(void); void dispc_clear_irqstatus(u32 mask); u32 dispc_read_irqenable(void); void dispc_write_irqenable(u32 mask); Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: add dispc_ovl_enabled()Tomi Valkeinen2012-10-292-0/+6
| | | | | | | | | | | | | | Add new dispc function, dispc_ovl_enabled(). This returns if the overlay enable bit is set in the registers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DISPC: make _enable_mgr_out public as "dispc_mgr_enable"Tomi Valkeinen2012-10-292-5/+6
| | | | | | | | | | | | | | | | | | We need a low level manager-enable function for omapdrm. We have that function as dispc internal func, _enable_mgr_out(). This patch exposes that function, and renames it to dispc_mgr_enable(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DISPC: rename dispc_mgr_enable/disable to _syncTomi Valkeinen2012-10-293-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | The current dispc_mgr_enable/disable function are blocking, and do a bit too much for omapdrm. We'll expose new enable & disable functions that will just set the bits in the registers in the following patches. This patch renames the current functions to *_sync, to make it clear that they are blocking, and also to free up the dispc_mgr_enable/disable names for these new functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DISPC: use dss_feat_get_num_ovls()Tomi Valkeinen2012-10-291-2/+2
| | | | | | | | | | | | | | | | | | Use dss_feat_get_num_ovls() in dispc.c instead of omap_dss_get_num_overlays() to remove the dependency to overlay.c. Note that we still have uses of omap_dss_get_num_overlays() in dispc.c, but these will be moved out in the future patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: remove initial display code from omapdssTomi Valkeinen2012-10-292-82/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently omapdss driver sets up the initial connections between overlays, overlay manager and a panel, based on default display parameter coming from the board file or via module parameters. This is unnecessary, as it's the higher level component that should decide what display to use and how. This patch removes the code from omapdss, and implements similar code to omapfb. The def_disp module parameter and the default display platform_data parameter are kept in omapdss, but omapdss doesn't do anything with them. It will just return the default display name with dss_get_default_display_name() call, which omapfb uses. This is done to keep the backward compatibility. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: export dss_get_def_display_name()Tomi Valkeinen2012-10-2910-9/+10
| | | | | | | | | | | | | | | | Export dss_get_def_display_name() with the name of omapdss_get_def_display_name() so that omapfb can use it after the next patch which moves default display handling to omapfb. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT outputTomi Valkeinen2012-10-241-24/+25
| | | | | | | | | | | | | | | | dispc_mgr_lclk_rate() cannot currently be called with DIGIT channel parameter, even if dispc_ovl_lclk_rate() can. Fix this by making dispc_mgr_lclk_rate() handle DIGIT channel also. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: remove dispc_irq_handler declarationTomi Valkeinen2012-10-241-1/+0
| | | | | | | | | | | | | | dss.h contains dispc_irq_handler declaration, even if the function is dispc.c internal. Remove the declaration. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: get the dss version from core pdevTomi Valkeinen2012-10-245-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | The output drivers get the omapdss hw version from the platform data for their respective output device. This doesn't work with DT, as there's no platform data for them. Add a new function, omapdss_get_version(), which returns the dss version from the core device, which will have platform data on DT also. The function is exported so that users of omapdss can also use it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: remove omap_dss_device's suspend/resumeTomi Valkeinen2012-10-2415-452/+16
| | | | | | | | | | | | | | | | | | | | The panel drivers contain enable, disable, suspend and resume calls. The suspend and resume are effectively identical to disable and enable. This patch removes panel suspend and enable code from omapdss and the panel drivers, and replaces their use with enable and disable. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs()Wei Yongjun2012-10-221-1/+3
| | | | | | | | | | | | | | | | | | Add the missing unlock on the error handling path in function hdmi_dump_regs(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Remove acb and acbi fields from omap_dss_deviceArchit Taneja2012-10-221-4/+0
|/ | | | | | | | | acbi and acb fields were meant for passive matrix panels which omapdss doesn't support any longer. Remove these fields from omap_dss_device struct. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 18:27:08 +0100