summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/dss/rfbi.c
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: RFBI: remove code related to old panel modelTomi Valkeinen2013-08-291-116/+19
| | | | | | | | | | Now that the old panel drivers have been removed, we can remove the old-model API and related code from the DSS encoder drivers. This patch removes the code from the RFBI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: public omapdss_register_output()Tomi Valkeinen2013-06-171-2/+2
| | | | | | | | | | | | | | | | | | | In order to allow multiple display block in a video pipeline, we need to give the drivers way to register themselves. For now we have the omapdss_register_display() which is used to register panels, and dss_register_output() which is used to register DSS encoders. This patch makes dss_register_output() public (with the name of omapdss_register_output), which can be used to register also external encoders. The distinction between register_output and register_display is that a "display" is an entity at the end of the videopipeline, and "output" is something inside the pipeline. The registration and naming will be made saner in the future, but the current names and functions are kept to minimize changes during the dss device model transition. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add THIS_MODULE owner to DSS outputsTomi Valkeinen2013-06-171-0/+1
| | | | | | | Setup the owner field for DSS output's omap_dss_device so that module refcounting works. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: combine omap_dss_output into omap_dss_deviceTomi Valkeinen2013-06-171-7/+7
| | | | | | | | | | | | | | | | | | | | We currently have omap_dss_device, which represents an external display device, sometimes an external encoder, sometimes a panel. Then we have omap_dss_output, which represents DSS's output encoder. In the future with new display device model, we construct a video pipeline from the display blocks. To accomplish this, all the blocks need to be presented by the same entity. Thus, this patch combines omap_dss_output into omap_dss_device. Some of the fields in omap_dss_output are already found in omap_dss_device, but some are not. This means we'll have DSS output specific fields in omap_dss_device, which is not very nice. However, it is easier to just keep those output specific fields there for now, and after transition to new display device model is made, they can be cleaned up easier than could be done now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove omap_dss_start/stop_device()Tomi Valkeinen2013-06-171-9/+0
| | | | | | | | | | | | | | | | | The omap_dss_start_device() and omap_dss_stop_device(), called by the DSS output drivers, are old relics. They originally did something totally else, but nowadays they increase the module ref count for panels that are enabled. This model is quite broken: the panel modules may be used even before they are enabled. For example, configuring the panel requires calls to functions located in the panel modules. In the following patches we try to improve the ref count management for the modules and display devices. The first step, however, is to remove the omap_dss_start/stop_device() totally. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove dssdev uses in trivial casesTomi Valkeinen2013-06-171-4/+4
| | | | | | | | | | | In the future the "dssdev" parameter passed to output drivers will change its meaning. Instead of being a pointer to the panel device, it's a pointer to the output instance. To make the transition easier, some of the uses for this dssdev parameter can be easily removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: only probe pdata if there's oneTomi Valkeinen2013-06-171-5/+6
| | | | | | | | | omapdss output drivers always read the platform data. This crashes when there's no platform data when using DT. Add a check to read the platform data only if it exists. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: RFBI: Add error handling for rfbi_probe_pdataTomi Valkeinen2013-05-021-7/+14
| | | | | | | | Add proper error handling for rfbi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the RFBI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: RFBI: use platform_driver_register()Tomi Valkeinen2013-05-021-6/+7
| | | | | | | Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add output->dispc_channelTomi Valkeinen2013-04-031-0/+1
| | | | | | | | | | | | | | | | | | The DISPC channel used for each output is currently passed in panel platform data from the board files. To simplify this, and to make the panel drivers less dependent on OMAP, this patch changes omapdss to resolve the channel independently. The channel is resolved based on the OMAP version and, in case of DSI, the DSI module id. This resolved channel is stored into a new field in output, dispc_channel. The few places where dssdev->channel was used are changed to use output->recommended_channel. After this patch, dssdev->channel is obsolete. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: add output->nameTomi Valkeinen2013-04-031-0/+1
| | | | | | | | Add name field to omapdss's outputs so that in the following patches panels refer to the output by their name. The name also helps debugging. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: manage framedone irq with mgr opsTomi Valkeinen2012-12-071-5/+7
| | | | | | | | | | | | | | Some of the output drivers need to handle FRAMEDONE interrupt from DISPC. This creates a direct dependency to dispc code, and we need to avoid this to make the compat code to work. Instead of the output drivers registering for dispc interrupts, we create new mgr-ops that are used to register a framedone handler. The code implementing the mgr-ops is responsible for calling the handler when DISPC FRAMEDONE interrupt happens. The compat layer is improved accordingly to do the call to the framedone handler. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: manage output-dssdev connection in output driversTomi Valkeinen2012-12-071-0/+9
| | | | | | | | | | | | | We currently attach an output to a dssdev in the initialization code for dssdevices in display.c. This works, but doesn't quite make sense: an output entity represents (surprisingly) an output of DSS, which is managed by an output driver. The output driver also handles adding new dssdev's for that particular output. It makes more sense to make the output-dssdev connection in the output driver. This is also in line with common display framework. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: export dss_get_def_display_name()Tomi Valkeinen2012-10-291-1/+1
| | | | | | | | 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: RFBI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja2012-09-261-6/+9
| | | | | | | | | | | With addition of output entities, a device connects to an output, and an output connects to overlay manager. Replace the dssdev->manager references with dssdev->output->manager to access the manager correctly. When enabling the RFBI output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: outputs: Create and register output instancesArchit Taneja2012-09-261-0/+26
| | | | | | | | | | | | | | | | | Add output structs to output driver's private data. Register output instances by having an init function in the probes of the platform device drivers for different outputs. The *_init_output for each output registers the output and fill up the output's plaform device, type and id fields. The *_uninit_output functions unregister the output. In the probe of each interface driver, the output entities are initialized before the *_probe_pdata() functions intentionally. This is done to ensure that the output entity is prepared before the panels connected to the output are registered. We need the output entities to be ready because OMAPDSS will try to make connections between overlays, managers, outputs and devices during the panel's probe. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: alloc dssdevs dynamicallyTomi Valkeinen2012-09-181-4/+13
| | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: register only one display device per outputTomi Valkeinen2012-09-181-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: omap_dss_register_device() doesn't take display indexTomi Valkeinen2012-09-181-1/+1
| | | | | | | | | | | | | | | | We used to have all the displays of the board in one list, and we made a "displayX" directory in the sysfs, where X was the index of the display in the list. This doesn't work anymore with device tree, as there's no single list to get the number from, and it doesn't work very well even with non-DT as we need to do some tricks to get the index nowadays. This patch changes omap_dss_register_device() so that it doesn't take disp_num as a parameter anymore, but uses a private increasing counter for the display number. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: fix use of dssdev->capsTomi Valkeinen2012-09-071-1/+0
| | | | | | | | | | | | | | | | | Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI: Maintain copy of operation mode in driver data) broke DSI for video mode displays. The commit changed the way dssdev->caps are initialized, and the result was that every DSI display is initialized with manual-update and tear-elim caps. The code that sets dssdev->caps is not very good, even when fixed. omapdss driver shouldn't be writing dssdev->caps at all. This patch fixes the problem with video mode displays by moving the initialization of dssdev->caps to the panel driver. The same change is done for RFBI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: RFBI: Maitain copy of rfbi timings in driver dataArchit Taneja2012-08-161-3/+9
| | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the rfbi specific timings requested by the panel driver. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own rfbi specific timings field. The panel driver is expected to call omapdss_rfbi_set_interface_timings() to configure the rfbi timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Maintain copy of number of data lines in driver dataArchit Taneja2012-08-161-3/+10
| | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to configure the number of data lines as specified by the panel. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format before enabling the interface or calling omap_rfbi_configure(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Maintain copy of pixel size in driver dataArchit Taneja2012-08-161-7/+13
| | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the desired pixel size of the panel. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own pixel format field. A panel driver is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format before enabling the interface or calling omap_rfbi_configure(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Add function to set panel sizeArchit Taneja2012-08-151-14/+33
| | | | | | | | | | | | RFBI drivers requires configuration of the update area. Since we don't support partial updates, the size to be configures is the panel size itself. Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the other fields are configured to an initial value when RFBI is enabled. A panel driver is expected to call omapdss_rfbi_set_size() configure the size of the panel. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Remove partial update supportArchit Taneja2012-08-151-58/+18
| | | | | | | | | | | | Partial update suppport was removed from DISPC and DSI sometime back. The RFBI driver still tries to support partial update without the underlying support in DISPC. Remove partial update support from RFBI, only support updates which span acros the whole panel size. This also helps in DSI and RFBI having similar update ops. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay managerArchit Taneja2012-06-291-4/+12
| | | | | | | | | The RFBI driver uses a direct DISPC register write to enable the overlay manager. Replace this with dss_mgr_enable() which checks if the connected overlay and managers are correctly configured, and configure DSS for fifomerge. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface ↵Archit Taneja2012-06-291-12/+1
| | | | | | | | | | | | | | | | | | | | | | drivers Replace the DISPC fuctions used to configure LCD channel related manager parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that the DISPC registers are written at the right time by using the shadow register programming model. The LCD manager configurations is stored as a private data of manager in APPLY. It is treated as an extra info as it's the panel drivers which trigger this apply via interface drivers, and not a DSS2 user like omapfb or omapdrm. Storing LCD manager related properties in APPLY also prevents the need to refer to the panel connected to the manager for information. This helps in making the DSS driver less dependent on panel. A helper function is added to check whether the manager is LCD or TV. The direct DISPC register writes are removed from the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-6/+28
| | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by RFBI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. Create function rfbi_config_lcd_manager() which fills up the mgr_config parameters and writes to the DISPC regs. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Remove passive matrix LCD support (part 3)Archit Taneja2012-06-291-2/+1
| | | | | | | | | | Remove omap_lcd_display_type enum The enum omap_lcd_display_type is used to configure the lcd display type in DISPC. Remove this enum and always set display type to TFT by creating function dss_mgr_set_lcd_type_tft(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=nTomi Valkeinen2012-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | If runtime PM is not enabled in the kernel config, pm_runtime_get_sync() will always return 1 and pm_runtime_put_sync() will always return -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to print a warning. One option would be to ignore errors returned by pm_runtime_put_sync() totally, as they only say that the call was unable to put the hardware into suspend mode. However, I chose to ignore the returned -ENOSYS explicitly, and print a warning for other errors, as I think we should get notified if the HW failed to go to suspend properly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Cc: Grazvydas Ignotas <notasas@gmail.com>
* OMAPDSS: separate pdata based initializationTomi Valkeinen2012-05-111-19/+26
| | | | | | | Move the platform-data based display device initialization into a separate function, so that we may later add of-based initialization. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: init omap_dss_devices internallyTomi Valkeinen2012-05-111-1/+7
| | | | | | | Now that each output driver creates their own display devices, the output drivers can also initialize those devices. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: interface drivers register their panel devicesTomi Valkeinen2012-05-111-1/+15
| | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: add __init & __exitTomi Valkeinen2012-05-111-5/+5
| | | | | | | 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>
* OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdiTomi Valkeinen2012-05-111-2/+1
| | | | | | | | Now that the core.c doesn't fail if output driver's init fails, we can change the uses of platform_driver_register to platform_driver_probe. This will allow us to use __init in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: move the creation of debugfs filesTomi Valkeinen2012-05-111-1/+3
| | | | | | | | 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>
* OMAPDSS: remove uses of dss_runtime_get/putTomi Valkeinen2012-05-111-11/+1
| | | | | | | | | Now that the omapdss_core device is the parent for all other dss devices, we don't need to use the dss_runtime_get/put anymore. Instead, enabling omapdss_core will happen automatically when a child device is enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove return from platform_driver_unregTomi Valkeinen2012-05-111-1/+1
| | | | | | | | | For unknown reasons we seem to have a return in each of the omapdss's uninit functions, which is a void function. Remove the returns. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Apply manager timings instead of direct DISPC writesArchit Taneja2012-05-091-2/+2
| | | | | | | | | | | Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the interface drivers. The latter function ensures that the timing related DISPC registers are configured according to the shadow register programming model. Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit is set by dss_mgr_set_timings(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: DISPC: Use a common function to set manager timingsArchit Taneja2012-04-231-2/+2
| | | | | | | | | | | | | | | | 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>
* OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd sizeArchit Taneja2012-04-231-2/+22
| | | | | | | | | | | | The RFBI driver uses dispc_mgr_set_lcd_size() to set the width and height of the LCD manager. Replace this to use dispc_mgr_set_lcd_timings(), pass dummy blanking parameters like done in the DSI driver. This prevents the need to export dispc_mgr_set_lcd_size(), and use a common function to set lcd timings. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: cleanup probe functionsTomi Valkeinen2012-02-211-18/+13
| | | | | | | | | | | | Now that dss is using devm_ functions for allocation in probe functions, small reordering of the allocations allows us to clean up the probe functions more. This patch moves "unmanaged" allocations after the managed ones, and uses plain returns instead of gotos where possible. This lets us remove a bunch of goto labels, simplifying the probe's error handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge commit 'v3.3-rc4'Tomi Valkeinen2012-02-211-1/+1
|\
| * OMAPDSS: use sync versions of pm_runtime_putTomi Valkeinen2012-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omapdss doesn't work properly on system suspend. The problem seems to be the fact that omapdss uses pm_runtime_put() functions when turning off the hardware, and when system suspend is in process only sync versions are allowed. Using non-sync versions normally and sync versions when suspending would need rather ugly hacks to convey the information of suspending/not-suspending to different functions. Optimally the driver wouldn't even need to care about this, and the PM layer would handle syncing when suspend is in process. This patch changes all omapdss's pm_runtime_put calls to pm_runtime_put_sync. This fixes the suspend problem, and probably the performance penalty of always using sync versions is negligible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Kevin Hilman <khilman@ti.com>
* | OMAPDSS: use devm_ functionsJulia Lawall2012-01-251-3/+2
|/ | | | | | | | | | The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove partial update from the overlay managerTomi Valkeinen2011-12-021-1/+0
| | | | | | | | | | | | | | | | | Partial update for manual update displays has never worked quite well: * The HW has limitations on the update area, and the x and width need to be even. * Showing a part of a scaled overlay causes artifacts. * Makes the management of dispc very complex Considering the above points and the fact that partial update is not used anywhere, this and the following patches remove the partial update support. This will greatly simplify the following re-write of the apply mechanism to get proper locking and additional features like fifo-merge. This patch removes the partial update from the manager.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: Add export.h for THIS_MODULE/EXPORT_SYMBOL to drivers/videoPaul Gortmaker2011-10-311-0/+1
| | | | | | | | | With module.h being implicitly everywhere via device.h, the absence of explicitly including something for EXPORT_SYMBOL went unnoticed. Since we are heading to fix things up and clean module.h from the device.h file, we need to explicitly include these files now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* OMAP: DSS2: Clean up stallmode and io pad mode selectionArchit Taneja2011-09-301-2/+2
| | | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: DISPC: rename manager related funcsTomi Valkeinen2011-09-301-6/+6
| | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: Remove support for non-DISPC overlaysTomi Valkeinen2011-09-301-20/+3
| | | | | | | | | | | | | | | | | | Remove support for non-DISPC overlays and overlay managers. The support to possibly have non-DISPC overlays and managers was made to make it possible to use CPU and/or sDMA to update RFBI or DSI command mode displays. It is ok to remove the support, because: - No one has used the feature. - Display update without DISPC is very slow, so it is debatable if the update would even be usable. - Removal cleans up code. - If such a feature is needed later, it is better implemented outside omapdss driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Archit Taneja <archit@ti.com>
OpenPOWER on IntegriCloud