summaryrefslogtreecommitdiffstats
path: root/include/video
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'fbdev-updates-for-3.7' of git://github.com/schandinat/linux-2.6Linus Torvalds2012-10-122-19/+626
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull fbdev updates from Florian Tobias Schandinat: "This includes: - large updates for OMAP - basic OMAP5 DSS support for DPI and DSI outputs - large cleanups and restructuring - some update to Exynos and da8xx-fb - removal of the pnx4008 driver (arch removed) - various other small patches" Fix up some trivial conflicts (mostly just include line changes, but also some due to the renaming of the deferred work functions by Tejun). * tag 'fbdev-updates-for-3.7' of git://github.com/schandinat/linux-2.6: (193 commits) gbefb: fix compile error video: mark nuc900fb_map_video_memory as __devinit video/mx3fb: set .owner to prevent module unloading while being used video: exynos_dp: use clk_prepare_enable and clk_disable_unprepare drivers/video/exynos/exynos_mipi_dsi.c: fix error return code drivers/video/savage/savagefb_driver.c: fix error return code video: s3c-fb: use clk_prepare_enable and clk_disable_unprepare da8xx-fb: save and restore LCDC context across suspend/resume cycle da8xx-fb: add pm_runtime support video/udlfb: fix line counting in fb_write OMAPDSS: add missing include for string.h OMAPDSS: DISPC: Configure color conversion coefficients for writeback OMAPDSS: DISPC: Add manager like functions for writeback OMAPDSS: DISPC: Configure writeback FIFOs OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup() OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup OMAPDSS: DISPC: Add function to set channel in for writeback OMAPDSS: DISPC: Don't set chroma resampling bit for writeback OMAPDSS: DISPC: Downscale chroma if plane is writeback OMAPDSS: DISPC: Configure input and output sizes for writeback ...
| * Merge tag 'omapdss-for-3.7' of git://gitorious.org/linux-omap-dss2/linux ↵Florian Tobias Schandinat2012-10-101-19/+93
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into fbdev-next Omapdss driver changes for the 3.7 merge window. Notable changes: * Basic writeback support for DISPC level. Writeback is not yet usable, though, as we need higher level code to actually expose the writeback feature to userspace. * Rewriting the omapdss output drivers. We're trying to remove the hard links between the omapdss and the panels, and this rewrite work moves us closer to that goal. * Cleanup and restructuring patches that have been made while working on device tree support for omapdss. Device tree support is still some way ahead, but these patches are good cleanups in themselves. * Basic OMAP5 DSS support for DPI and DSI outputs. * Workaround for the problem that GFX overlay's fifo is too small for high resolution scenarios, causing underflows. * Cleanups that remove dependencies to omap platform code.
| | * OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setupArchit Taneja2012-09-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * OMAPDSS: OVERLAY: Add position and replication as overlay capsArchit Taneja2012-09-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add position and replication as overlay caps, and pass overlay caps as an argument to the corresponding functions. Adding position and replication to overlay caps seems a bit unnecessary, but it allows us to use the corresponding functions for writeback too. These caps will be set for all overlays, but not for writeback. This is done so writeback can reuse dispc_ovl_setup() to the maximum. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove old way of setting manager and device linksArchit Taneja2012-09-261-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that an omap_dss_output can be used to link between managers and devices, we can remove the old way of setting manager and device links. This involves removing the device and manager pointers from omap_overlay_manager and omap_dss_device respectively, and removing the set_device/unset_device ops from omap_overlay_manager. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove manager->device referencesArchit Taneja2012-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of output entities, managers will now connect to outputs. Create helper ops for overlays and managers named get_device. This will abstract away the information on how to get the device from an overlay or an overlay manager. The get_device ops currently retrieve the output via a ovl->manager->device reference. This will be later replaced by ovl->manager->output->device references. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_managerArchit Taneja2012-09-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * OMAPDSS: output: Add set/unset device ops for omap_dss_outputArchit Taneja2012-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An output entity represented by the struct omap_dss_output connects to a omap_dss_device entity. Add functions to set or unset an output's device. This is similar to how managers and devices were connected previously. An output can connect to a device without being connected to a manager. However, the output needs to eventually connect to a manager so that the connected panel can be enabled. Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent breaking things. This will be removed later when outputs are supported completely. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: outputs: Create a new entity called outputsArchit Taneja2012-09-261-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * OMAPDSS: Use WB fifo for GFX overlayTomi Valkeinen2012-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4's GFX overlay has smaller fifo than the rest of the overlays (including writeback "overlay"). This seems to be the reason for underflows in some more demanding scenarios. We can avoid the problems by using the WB fifo for GFX overlay, and vice versa. WB usage is not supported yet, but when it will, it should perform just fine with smaller fifo as there are no hard realtime constraints with WB. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: DSI: calculate dsi clockTomi Valkeinen2012-09-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the way to configure clocks related to DSI (both DSI and DISPC clocks) happens via omapdss platform data. The reason for this is that configuring the DSS clocks is a very complex problem, and it's impossible for the SW to know requirements about things like interference. However, for general cases it should be fine to calculate the dividers for clocks in the SW. The calculated clocks are probably not perfect, but should work. This patch adds support to calculate the dividers when using DSI command mode panels. The panel gives the required DDR clock rate and LP clock rate, and the DSI driver configures itself and DISPC accordingly. This patch is somewhat ugly, though. The code does its job by modifying the platform data where the clock dividers would be if the board file gave them. This is not how it's going to be in the future, but allows us to have quite simple patch and keep the backward compatibility. It also allows the developer to still give the exact dividers from the board file when there's need for that, as long as the panel driver does not override them. There are also other areas for improvement. For example, it would be better if the panel driver could ask for a DSI clock in a certain range, as, at least command mode panels, the panel can work fine with many different clock speeds. While the patch is not perfect, it allows us to remove the hardcoded clock dividers from the board file, making it easier to bring up a new panel and to use device tree from omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: HDMI: Move GPIO handling to HDMI driverTomi Valkeinen2012-09-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently manage HDMI GPIOs in the board files via platform_enable/disable calls. This won't work with device tree, and in any case the correct place to manage the GPIOs is in the HDMI driver. This patch moves the handling of the GPIOs to the HDMI driver. The GPIO handling is moved to the common hdmi.c file, and this probably needs to be revisited when adding OMAP5 HDMI support to see if the GPIO handling needs to be moved to IP specific files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
| | * Merge tag 'v3.6-rc4'Tomi Valkeinen2012-09-033-20/+61
| | |\ | | | | | | | | | | | | Merge 3.6-rc4 to get latest OMAP and device tree fixes.
| | * | OMAPDSS: Correct DISPC_IRQ bit definitions for LCD3Chandrabhanu Mahapatra2012-08-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3, DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3 which were incorrectly set in previous LCD3 patches have been corrected here. Reported-by: Mark Tyler <mark.tyler@ti.com> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: RFBI: Maitain copy of rfbi timings in driver dataArchit Taneja2012-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the rfbi specific timings requested by the panel driver. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own rfbi specific timings field. The panel driver is expected to call omapdss_rfbi_set_interface_timings() to configure the rfbi timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Maintain copy of video mode timings in driver dataArchit Taneja2012-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to receive the video mode timings requested by the panel driver. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own video mode timings field. The panel driver is expected to call omapdss_dsi_set_videomode_timings() to configure the video mode timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timingsArchit Taneja2012-08-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct omap_dss_dsi_videomode_data holds fields which need to be configured for DSI to operate in video mode. Rename the struct to dsi_videomode_timings. One reason to do this is because most of the fields in the struct are timings related. The other reason is to create a generic op for output specific timings. This generic op can be considered as a way to set custom or private timings for the output. In the case of OMAP, DSI and RFBI require some more timings apart from the relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings can be considered as these output specific timings respectively. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Maintain copy of operation mode in driver dataArchit Taneja2012-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to know the mode of operation of the DSI protocol(command or video mode). This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own operation mode field. The panel driver is expected to call omapdss_dsi_set_operation_mode() before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: SDI: Maintain copy of data pairs in driver dataArchit Taneja2012-08-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SDI driver currently relies on the omap_dss_device struct to configure the number of data pairs as specified by the panel. This makes the SDI interface driver dependent on the omap_dss_device struct. Make the SDI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_sdi_set_datapairs() before enabling the interface. Even though we configure the number of data pairs here, this function would be finally mapped to a generic interface op called set_data_lines. The datapairs argument type has been changed from u8 to int at some places to be in sync with the 'set_data_lines' ops of other interfaces. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DPI: Maintain copy of number of data lines in driver dataArchit Taneja2012-08-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DPI driver currently relies on the omap_dss_device struct to configure the number of data lines as specified by the panel. This makes the DPI interface driver dependent on the omap_dss_device struct. Make the DPI driver data maintain it's own data lines field. A panel driver is expected to call omapdss_dpi_set_data_lines() before enabling the interface. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: RFBI: Maintain copy of number of data lines in driver dataArchit Taneja2012-08-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the desired pixel size of the panel. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own pixel format field. A panel driver is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format before enabling the interface or calling omap_rfbi_configure(). Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Maintain copy of pixel format in driver dataArchit Taneja2012-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to receive the desired pixel format of the panel. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own pixel format field. The panel driver is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: RFBI: Add function to set panel sizeArchit Taneja2012-08-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: SDI: Create a function to set timingsArchit Taneja2012-08-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create function omapdss_sdi_set_timings(). Configuring new timings is done the same way as before, SDI is disabled, and re-enabled with the new timings in dssdev. This just moves the code from the panel drivers to the SDI driver. The panel drivers shouldn't be aware of how SDI manages to configure a new set of timings. This should be taken care of by the SDI driver itself. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Add function to set panel size for command mode panelsArchit Taneja2012-08-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSI command mode panels don't need to configure a full set of timings to configure DSI, they only require the width and the height of the panel in pixels. Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is meant for video mode panels. When performing rotation via chaning the address mode of the panel, we would need to swap width and height when doing 90 or 270 rotation. Make sure that omapdss_dsi_set_size() makes the new width and height visible to DSI. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DSI: Maintain own copy of timings in driver dataArchit Taneja2012-08-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the timings in omap_dss_device struct to configure the DISPC and DSI blocks accordingly. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own timings field. A DSI video mode panel driver is expected to call omapdss_dsi_set_timings() to set these timings before the panel is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| | * | OMAPDSS: DPI: Maintain our own timings field in driver dataArchit Taneja2012-08-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DPI driver currently relies on the timings in omap_dss_device struct to configure the DISPC accordingly. This makes the DPI interface driver dependent on the omap_dss_device struct. Make the DPI driver data maintain it's own timings field. The panel driver is expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set these timings before the panel is enabled. In the set_timings() op, we still ensure that the omap_dss_device timings (dssdev->panel.timings) are configured. This will later be configured only by the DPI panel drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | include/video: Add register offsets for FIMD version 8Leela Krishna Amudala2012-08-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FIMD version 8 has VIDTCON and VIDCON registers at different offsets from the previous versions. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
| * | | include/video: move fimd register headers from platform to include/videoLeela Krishna Amudala2012-08-081-0/+526
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | This patch moves the contents from regs-fb-v4.h and regs-fb.h to include/video/samsung_fimd.h. Also updates the header inclusion in machine files and driver files accordingly. Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* | | ARM: clps711x: Remove board support for CEIVAAlexander Shiyan2012-09-281-64/+0
|/ / | | | | | | | | | | | | | | | | The current kernel does not fit in the CEIVA ROM. Also, some functional has already been removed due migrate from 2.6 to 3.0, and it seems that no one uses this platform. So, remove support for this board and modules specific only to this board. Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
* | video: da8xx-fb: configure FIFO threshold to reduce underflow errorsManjunathappa, Prakash2012-07-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch works around the below silicon errata: During LCDC initialization, there is the potential for a FIFO underflow condition to occur. A FIFO underflow condition occurs when the input FIFO is completely empty and the LCDC raster controller logic that drives data to the output pins attempts to fetch data from the FIFO. When a FIFO underflow condition occurs, incorrect data will be driven out on the LCDC data pins. Software should poll the FUF bit field in the LCD_STAT register to check if an error condition has occurred or service the interrupt if FUF_EN is enabled when FUF occurs. If the FUF bit field has been set to 1, this will indicate an underflow condition has occurred and then the software should execute a reset of the LCDC via the LPSC. This problem may occur if the LCDC FIFO threshold size (LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset. Increasing the FIFO threshold size will reduce or eliminate underflows. Setting the threshold size to 256 double words or larger is recommended. Above issue is described in section 2.1.3 of silicon errata http://www.ti.com/lit/er/sprz313e/sprz313e.pdf Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* | Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into ↵Florian Tobias Schandinat2012-07-251-25/+26
|\ \ | |/ | | | | | | | | | | | | fbdev-next Conflicts: drivers/video/omap2/dss/core.c drivers/video/omap2/dss/dispc.c
| * OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSIArchit Taneja2012-06-291-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and VP_DE_POL in DSI_CTRL registers. This information is completely internal to DSS as logic levels for the above signals hold no meaning on the DSI bus. Hence a DSI panel driver should be totally oblivious of these fields. Fix the logic levels/polarities in the DISPC and DSI registers to a default value. This is done by overriding these fields in omap_video_timings struct filled by the panel driver for DISPC, and use the equivalent default values when programming DSI_CTRL registers. Also, remove the redundant polarity related fields in omap_dss_dsi_videomode_data. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Add interlace parameter to omap_video_timingsArchit Taneja2012-06-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | Add a parameter called interlace which tells whether the timings are in interlaced or progressive mode. This aligns the omap_video_timings struct with the Xorg modeline configuration. It also removes the hack needed to write to divide the manager height by 2 if the connected interface is VENC. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Remove omap_panel_config enum from omap_dss_deviceArchit Taneja2012-06-291-11/+0
| | | | | | | | | | | | | | | | | | | | | | omap_panel_config contains fields which are finally written to DISPC_POL_FREQo registers. These are now held by omap_video_timings and are set when the manager timings are applied. Remove the omap_panel_config enum, and remove all it's references from panel or interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Add some new fields to omap_video_timingsArchit Taneja2012-06-291-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some panel timing related fields are contained in omap_panel_config in the form of flags. The fields are: - Hsync logic level - Vsync logic level - Data driven on rising/falling edge of pixel clock - Output enable/Data enable logic level - HSYNC/VSYNC driven on rising/falling edge of pixel clock Out of these parameters, Hsync and Vsync logic levels are a part of the timings in the Xorg modeline configuration. So it makes sense to move the to omap_video_timings. The rest aren't a part of modeline, but it still makes sense to move these since they are related to panel timings. These fields stored in omap_panel_config in dssdev are configured for LCD panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers. Add the above fields in omap_video_timings. Represent their state via new enums. Add these parameters to the omap_video_timings instances in the panel drivers. Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in omap_panel_config for now. The struct will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Remove passive matrix LCD support (part 3)Archit Taneja2012-06-291-5/+0
| | | | | | | | | | | | | | | | | | | | 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: Remove passive matrix LCD support (part 2)Archit Taneja2012-06-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag. We don't support passive matrix displays any more. Remove this flag from all the panel drivers. Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: Add LCD3 overlay manager and Clock and IRQ supportChandrabhanu Mahapatra2012-06-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for LCD3 manager has been added into the manager module. LCD3 panel has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and LCD2 panels. These registers control the Display Controller (DISPC) module for LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can be connected through parallel output interface using DISPC and RFBI or DPI. For serial interface DSS uses DSI. The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL register which has been enabled. The clock switch chooses between DSS_CLK and DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3, DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have been added specific to the new manager. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: Add support for LCD3 channelChandrabhanu Mahapatra2012-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel with its own dedicated overlay manager. The current patch adds LCD3 channel and basic register support for LCD3 channel. It adds register addresses for various Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H, DISPC_DIVISORo, etc. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: remove enum omap_dss_overlay_managersTomi Valkeinen2012-06-281-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | We have two almost the same enums: omap_channel and omap_dss_overlay_managers. omap_channel is used almost everywhere, and omap_channel assigns explicit values to the enum values which are needed for proper operation. omap_dss_overlay_managers is only used in one place, so it's easy to remove it, which is what this patch does. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | sh_mobile_meram: Add direct MERAM allocation APILaurent Pinchart2012-07-191-0/+16
| | | | | | | | | | | | | | The API can be used to allocate and free MERAM blocks directly, without going through ICBs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* | sh_mobile_meram: Use direct function calls for the public APILaurent Pinchart2012-07-191-15/+35
| | | | | | | | | | | | | | There's no reason to use abstract operation pointers to implement the MERAM API. Replace them by direct function calls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* | sh_mobile_meram: Rename operations to cache_[alloc|free|update]Laurent Pinchart2012-07-191-13/+8
| | | | | | | | | | | | | | | | The MERAM operations meram_register, meram_unregister and meram_update handle LCDC cache. In preparation for "raw" MERAM allocation, rename them to more appropriate names. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* | fbdev: sh_mobile_lcdc: Implement overlays supportLaurent Pinchart2012-06-201-0/+7
|/ | | | Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6Linus Torvalds2012-06-015-9/+159
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull fbdev updates from Florian Tobias Schandinat: - driver for AUO-K1900 and AUO-K1901 epaper controller - large updates for OMAP (e.g. decouple HDMI audio and video) - some updates for Exynos and SH Mobile - various other small fixes and cleanups * tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits) video: bfin_adv7393fb: Fix cleanup code video: exynos_dp: reduce delay time when configuring video setting video: exynos_dp: move sw reset prioir to enabling sw defined function video: exynos_dp: use devm_ functions fb: handle NULL pointers in framebuffer release OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request OMAPDSS: Apply VENC timings even if panel is disabled OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC OMAPDSS: DISPC: Support rotation through TILER OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n OMAPFB: remove compiler warnings when CONFIG_BUG=n OMAPDSS: remove compiler warnings when CONFIG_BUG=n OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods OMAPDSS: DISPC: Update Accumulator configuration for chroma plane drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers video: exynos mipi dsi: support reverse panel type video: exynos mipi dsi: Properly interpret the interrupt source flags video: exynos mipi dsi: Avoid races in probe() ...
| * Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-nextFlorian Tobias Schandinat2012-05-273-28/+68
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Omapdss driver changes for 3.5 merge window. Lots of normal development commits, but perhaps most notable changes are: * HDMI rework to properly decouple the HDMI audio part from the HDMI video part. * Restructure omapdss core driver so that it's possible to implement device tree support. This included changing how platform data is passed to the drivers, changing display device registration and improving the panel driver's ability to configure the underlying video output interface. * Basic support for DSI packet interleaving
| | * OMAPDSS: DISPC: Support rotation through TILERChandrabhanu Mahapatra2012-05-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner. Physical memory can be mapped to a portion of OMAP's system address space called TILER address space. The TILER address space is split into 8 views. Each view represents a rotated or mirrored form of the mapped physical memory. When a DISPC overlay's base address is programmed to one of these views, the TILER fetches the pixels according to the orientation of the view. A view is further split into 4 containers, each container holds elements of a particular size. Rotation can be achieved at the granularity of elements in the container. For more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM. Rotation type TILER has been added which is used to exploit the capabilities of these 8 views for performing various rotations. When fetching from addresses mapped to TILER space, the DISPC DMA can fetch pixels in either 1D or 2D bursts. The fetch depends on which TILER container we are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts, and page mode sized containers require 1D bursts. The DSS2 user is expected to provide the Tiler address of the view that it is interested in. This is passed to the paddr and p_uv_addr parameters in omap_overlay_info. It is also expected to provide the stride value based on the view's orientation and container type, this should be passed to the screen_width parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is used to calculate the required row_inc for DISPC. x_predecim and y_predecim are also used to calculate row_inc and pix_inc thereby adding predecimation support for TILER. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud