summaryrefslogtreecommitdiff
path: root/drivers/video/omap2
AgeCommit message (Collapse)Author
2012-10-12Merge tag 'fbdev-updates-for-3.7' of git://github.com/schandinat/linux-2.6Linus Torvalds
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 ...
2012-10-09mm: kill vma flag VM_RESERVED and mm->reserved_vm counterKonstantin Khlebnikov
A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA, currently it lost original meaning but still has some effects: | effect | alternative flags -+------------------------+--------------------------------------------- 1| account as reserved_vm | VM_IO 2| skip in core dump | VM_IO, VM_DONTDUMP 3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP 4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP This patch removes reserved_vm counter from mm_struct. Seems like nobody cares about it, it does not exported into userspace directly, it only reduces total_vm showed in proc. Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP. remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP. remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP. [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup] Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Carsten Otte <cotte@de.ibm.com> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Eric Paris <eparis@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Jason Baron <jbaron@redhat.com> Cc: Kentaro Takeda <takedakn@nttdata.co.jp> Cc: Matt Helsley <matthltc@us.ibm.com> Cc: Nick Piggin <npiggin@kernel.dk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Robert Richter <robert.richter@amd.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Venkatesh Pallipadi <venki@google.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-02Merge branch 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds
Pull workqueue changes from Tejun Heo: "This is workqueue updates for v3.7-rc1. A lot of activities this round including considerable API and behavior cleanups. * delayed_work combines a timer and a work item. The handling of the timer part has always been a bit clunky leading to confusing cancelation API with weird corner-case behaviors. delayed_work is updated to use new IRQ safe timer and cancelation now works as expected. * Another deficiency of delayed_work was lack of the counterpart of mod_timer() which led to cancel+queue combinations or open-coded timer+work usages. mod_delayed_work[_on]() are added. These two delayed_work changes make delayed_work provide interface and behave like timer which is executed with process context. * A work item could be executed concurrently on multiple CPUs, which is rather unintuitive and made flush_work() behavior confusing and half-broken under certain circumstances. This problem doesn't exist for non-reentrant workqueues. While non-reentrancy check isn't free, the overhead is incurred only when a work item bounces across different CPUs and even in simulated pathological scenario the overhead isn't too high. All workqueues are made non-reentrant. This removes the distinction between flush_[delayed_]work() and flush_[delayed_]_work_sync(). The former is now as strong as the latter and the specified work item is guaranteed to have finished execution of any previous queueing on return. * In addition to the various bug fixes, Lai redid and simplified CPU hotplug handling significantly. * Joonsoo introduced system_highpri_wq and used it during CPU hotplug. There are two merge commits - one to pull in IRQ safe timer from tip/timers/core and the other to pull in CPU hotplug fixes from wq/for-3.6-fixes as Lai's hotplug restructuring depended on them." Fixed a number of trivial conflicts, but the more interesting conflicts were silent ones where the deprecated interfaces had been used by new code in the merge window, and thus didn't cause any real data conflicts. Tejun pointed out a few of them, I fixed a couple more. * 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits) workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending() workqueue: use cwq_set_max_active() helper for workqueue_set_max_active() workqueue: introduce cwq_set_max_active() helper for thaw_workqueues() workqueue: remove @delayed from cwq_dec_nr_in_flight() workqueue: fix possible stall on try_to_grab_pending() of a delayed work item workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback() workqueue: use __cpuinit instead of __devinit for cpu callbacks workqueue: rename manager_mutex to assoc_mutex workqueue: WORKER_REBIND is no longer necessary for idle rebinding workqueue: WORKER_REBIND is no longer necessary for busy rebinding workqueue: reimplement idle worker rebinding workqueue: deprecate __cancel_delayed_work() workqueue: reimplement cancel_delayed_work() using try_to_grab_pending() workqueue: use mod_delayed_work() instead of __cancel + queue workqueue: use irqsafe timer for delayed_work workqueue: clean up delayed_work initializers and add missing one workqueue: make deferrable delayed_work initializer names consistent workqueue: cosmetic whitespace updates for macro definitions workqueue: deprecate system_nrt[_freezable]_wq workqueue: deprecate flush[_delayed]_work_sync() ...
2012-09-28OMAPDSS: add missing include for string.hTomi Valkeinen
Both dpi.c and sdi.c use strcmp(), but do not include string.h. With some Kconfig options string.h is included implicitly, but with some other the compilation fails: drivers/video/omap2/dss/dpi.c:407:5: error: implicit declaration of function 'strcmp' Include string.h in both dpi.c and sdi.c Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-26OMAPDSS: DISPC: Configure color conversion coefficients for writebackArchit Taneja
Writeback pipeline receives RGB data from one of the overlays or one of the overlay managers. If the target color mode is YUV422 or NV12, we need to convert the RGB pixels to YUV. The scaler in WB then converts it to the target color mode. Hence, the color conversion coefficients that need to be programmed are the ones which convert a RGB24 pixel to YUV444. Program these coefficients for writeback pipeline. Rearrange the code a bit to configure different coefficients for overlays and writeback. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Add manager like functions for writebackArchit Taneja
Add functions to enable writeback, and set/check state of GO bit. These bits are identical in behaviour with the corresponding overlay manager bits. Configure them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to get the FRAMEDONE irq corresponding to writeback. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Configure writeback FIFOsArchit Taneja
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds. The most optimal configuration for writeback is to push out data to the interconnect the moment writeback pushes enough pixels in the FIFO to form a burst. This reduces the chance of writeback overflowing it's FIFO. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()Archit Taneja
Configure some of the writeback specific parameters in dispc_wb_setup(). The writeback parameters configured are: truncation: This needs to be set if the color depth input to writeback is more than the color depth of the color mode we want to store in memory. writeback mode: This configures whether we want to use writeback in mem to mem or capture mode. This information will be directly passed by APPLY later. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setupArchit Taneja
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info, the major difference is that there is no parameter which describes the input size to writeback, this is because this is always fixed, and decided by the connected overlay or overlay manager. One more difference is that screen_width is renamed to buf_width, to give the value of stride the writeback buffer has. Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like parameters. The parameters in dispc_ovl_setup_common() which do not hold for writeback are filled passed as zeroes or false, the code takes care of not configuring them as they won't possess the needed overlay caps. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Add function to set channel in for writebackArchit Taneja
Writeback can take input from either one of the overlays, or one of the overlay managers. Add an enum which represents the channel_in for writeback, and maps to the register field programming. Add a function to configure channel in for writeback. This will be used later in APPLY. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Don't set chroma resampling bit for writebackArchit Taneja
The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2. It isn't there because we don't upsample chroma like for video pipelines, we downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444 input. Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Downscale chroma if plane is writebackArchit Taneja
When converting YUYV444 content to YUV422 or NV12 formats through writeback pipeline, the scaler needs to downscale the chroma plane. Ensure that chroma is downscaled when the pipeline is writeback. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Configure input and output sizes for writebackArchit Taneja
Writeback uses the WB_PICTURE_SIZE register to define the size of the content written to memory, this is the output of the scaler. It uses the WB_SIZE register to define the size of the content coming from the overlay/manager to which it is connected, this is the input to the scaler. This naming is different as compared to overlays. Add checks for writeback in dispc_ovl_set_input_size() and dispc_ovl_set_output_size() to write to the correct registers. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Add writeback register offsets and dss features structsArchit Taneja
Since writeback has many overlay like properties, and most of it's registers are similar to that of overlays, it's possible to reuse most of the overlay related DISPC code for writeback when considering it as a plane. Writeback was added as a plane in the omap_plane field as OMAP_DSS_WB. Add the writeback register offsets in dispc.h, add minimal WB plane related info needed in dss_features. Add a function which returns the number of writeback pipelines an OMAP version has. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Allow both upscaling and downscaling of chromaArchit Taneja
In the function dispc_plane_set_scaling_uv(), create a parameter which tells if we want to upscale or downscale the chroma plane. Downscaling of chroma is required by writeback pipeline for converting the input YUV444 color format to YUV422 or NV12. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory modeArchit Taneja
The scalers of overlays and writeback do not have any constraints on downscale ratio when operating in memory to memory mode. This is because in memory to memory mode, we aren't connected to a display which needs data output at the rate of pixel clock. The scalers can perform as much downscaling as needed, the rate at which the scaler outputs is adjusted accordingly. Relax constraints related to downscaling based on whether the input overlays are connected to writeback in memory to memory mode. We pass a mem_to_mem boolean parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this will later be configured to the correct value based on whether the overlay is connected to writeback or not. Do the same later for writeback when writeback is configured. In the scaling calculation code, we calculate the minimum amount of core clock we need to achieve the required downscaling. If we are in memory to memory mode, we set this to a very small value(1 in this case), this value would always be lesser than the actual DISPC core clock value, and hence the scaling checks would succeed. We take care that pixel clock isn't calculated for writeback and the overlays connected to it when in memory to memory mode. A pixel clock in such cases doesn't make sense. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Don't pass channel out when configuring overlaysArchit Taneja
dispc_ovl_setup_common() is to be used by both overlays and writeback. We pass channel out to figure out what manager the overlay is connected to, to determine the pixel clock rate. This is used to decide the scaling limitations for that overlay. writeback doesn't have a channel out, it has a channel in field which tells where writeback gets its input from. These are 2 different fields, and this prevents us reusing the overlay configuration code for writeback. To overcome this, we now pass omap_plane to overlay related functions rather than passing channel out. We create helper functions which can derive pclk/lclk from the omap_plane id. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_commonArchit Taneja
Add a new static function called dispc_ovl_setup_common(). This function is used by dispc_ovl_setup() to configure the overlay registers. This split is done so that dispc_wb_setup() can reuse overlay register configuration related code. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: OVERLAY: Add position and replication as overlay capsArchit Taneja
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>
2012-09-26OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functionsArchit Taneja
Currently, the functions below take the omap_plane parameter and derive the overlay caps within them. Pass the overlay caps as a parameter to the function to allow these to be used by writeback too. - dispc_ovl_set_zorder() - dispc_ovl_set_pre_mult_alpha() - dispc_ovl_setup_global_alpha() - dispc_ovl_calc_scaling() - dispc_ovl_setup() These functions will be used for writeback later, and the caps will help in deciding if they are to be used for writeback or not. This allows reuse of overlay caps for writeback. Using omap_overlay_caps for writeback seems a bit incorrect, but caps is something already in use by users of OMAPDSS(omapfb/omap_vout), so we use overlay caps for overlay like features of writeback too. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Simplify function names for setting pipeline input and ↵Archit Taneja
output sizes The DISPC pipeline register names in the TRM for setting the buffer size and the output size are a bit misleading, for example, there are different register names for setting the buffer size for VID and GFX pipes. Things get more confusing when considering writeback pipeline. Rename the functions so that they tell whether they are configuring the input to the scalar or the output. These will be extended later to support writeback registers. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()Archit Taneja
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field was being changed in dispc_ovl_setup in the case of interlaced displays. Fix this and const qualifier to the omap_overlay_info argument. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: Remove old way of setting manager and device linksArchit Taneja
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>
2012-09-26OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disableArchit Taneja
An overlay isn't allowed to be enabled/disabled if it isn't connected to an omap_dss_device. This requirement isn't needed any more. An overlay can be enabled/disabled as long as it has an output connected to it. The output may not be connected to a device, but we can be assured that the connected manager's output is in use by an output interface. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: OVERLAY/MANAGER: Get device via outputArchit Taneja
A manager is not connected to a device directly any more. It first connects to an output, and then to the display. Update overlay and manager get_device ops to return the device via the connected output. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: MANAGER: Update display sysfs storeArchit Taneja
The display sysfs attribute's store function needs to be changed with the introduction of outputs. The DSS driver ensures that there is one display per output, and that a registered omap_dss_device will have an output connected to it. The display sysfs store function unsets the current output connected to the manager, and sets it with the output connected to the new display. If the new display doesn't have an output for some reason, we just bail out. The function doesn't set/unset output->device links. These remain the same as when the omap_dss_device was registered. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPFB: Change dssdev->manager referencesArchit Taneja
To retrieve the manager pointer via a device, we need to now access it via the output to which the device is connected. Make this change in omapfb_ioctl() where the WAITFORVSYNC ioctl tries to access the manager's device. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: HDMI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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 HDMI output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: VENC: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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 VENC output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: RFBI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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>
2012-09-26OMAPDSS: SDI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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 SDI output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DSI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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 DSI output, check whether the output entity connected to display is not NULL. In dsi_init_display(), the display won't be connected to the DSI output yet, that happens later in dss_recheck_connections() in the panel driver's probe. Get the dsidev platform device pointer using the DSI moudle number provided in the omap_dss_device struct. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DSI: Remove dsi_pdev_map global structArchit Taneja
dsi_pdev_map is a struct visible globally in the DSI driver to get the platform device pointer of the DSI device corresponding to it's module ID. This was required because there was no clean way to derive the platform device from the DSI module instance number or from the connected panel. With the new output entity, it is possible to retrieve the platform device pointer if the omap_dss_output pointer is available. Modify the functions dsi_get_dsidev_from_dssdev() dsi_get_dsidev_from_id() so that they use output instead of dsi_pdev_map to retrieve the dsi platform device pointer. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja
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 DPI output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: Create links between managers, outputs and devicesArchit Taneja
Links between DSS entities are made in dss_init_connections() when a panel device is registered, and are removed in dss_uninit_connections() when the device is unregistered. Modify these functions to incorporate the addition of outputs. The fields in omap_dss_device struct gives information on which output and manager to connect to. The desired manager and output pointers are retrieved and prepared to form the desired links. The output is linked to the device, and then the manager to the output. A helper function omapdss_get_output_from_device() is created to retrieve the output from the display by checking it's type, and the module id in case of DSI. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPFB: remove manager->device referencesArchit Taneja
With the introduction of output entities, managers will now connect to outputs. Use the helper op for overlays named get_device. This will abstract away the information on how to get the device from an overlay. Using the helper function will reduce the number of pointer dereferences a user of OMAPDSS needs to do and reduce risk of a NULL dereference. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: Remove manager->device referencesArchit Taneja
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>
2012-09-26OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_managerArchit Taneja
Add set_output/unset_output ops for overlay managers, these form links between managers and outputs. Create a function in dss features which tell all the output instances that connect to a manager, use it when a manager tries to set an output. Add a constraint of not unsetting an output when the manager is enabled. Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for now to not break things. Keep the dss feature function get_supported_displays as it's used in some places. These will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: output: Add set/unset device ops for omap_dss_outputArchit Taneja
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>
2012-09-26OMAPDSS: outputs: Create and register output instancesArchit Taneja
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>
2012-09-26OMAPDSS: outputs: Create a new entity called outputsArchit Taneja
The current OMAPDSS design contains 3 software entities: Overlays, Managers and Devices. These map to pipelines, overlay managers and the panels respectively in hardware. One or more overlays connect to a manager to represent a composition, the manager connects to a device(generally a display) to display the content. The part of DSS hardware which isn't represented by any of the above entities are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI, HDMI, VENC and so on. Currently, an overlay manager directly connects to the display, and the output to which it is actually connected is ignored. The panel driver of the display is responsible of calling output specific functions to configure the output. Adding outputs as a new software entity gives us the following benefits: - Have exact information on the possible connections between managers and outputs: A manager can't connect to each and every output, there only limited hardware links between a manager's video port and some of the outputs. - Remove hacks related to connecting managers and devices: Currently, default links between managers and devices are set in a not so clean way. Matching is done via comparing the device type, and the display types supported by the manager. This isn't sufficient to establish all the possible links between managers, outputs and devices in hardware. - Make panel drivers more generic: The DSS panel drivers currently call interface/output specific functions to configure the hardware IP. When making these calls, the driver isn't actually aware of the underlying output. The output driver extracts information from the panel's omap_dss_device pointer to figure out which interface it is connected to, and then configures the corresponding output block. An example of this is when a DSI panel calls dsi functions, the dsi driver figures out whether the panel is connected to DSI1 or DSI2. This isn't correct, and having output as entities will give the panel driver the exact information on which output to configure. Having outputs also gives the opportunity to make panel drivers generic across different platforms/SoCs, this is achieved as omap specific output calls can be replaced by ops of a particular output type. - Have more complex connections between managers, outputs and devices: OMAPDSS currently doesn't support use cases like 2 outputs connect to a single device. This can be achieved by extending properties of outputs to connect to more managers or devices. - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS as compared to overlays, managers or devices. Add a new struct to represent outputs. An output struct holds pointers to the manager and device structs to which it is connected. Add functions which can register/unregister an output, or look for one. Create an enum which represent each output instance. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functionsArchit Taneja
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there is an enabled display connected to the manager before trying to see the state of the GO bit. The checks related to the display can be replaced by checking the state of the manager, i.e, whether the manager is enabled or not. This makes more sense than checking with the connected display as the GO bit behaviour is more connected with the manager state rather than the display state. A GO bit can only be set if the manager is enabled. If a manager isn't enabled, we can safely assume that the GO bit is not set. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DSI: Pass dsi platform device wherever possibleArchit Taneja
Many of the DSI functions receive the connected panel's omap_dss_device pointer as an argument. The platform device pointer is then derived via omap_dss_device pointers. Most of these functions don't really require omap_dss_device pointer anymore since we now keep copies of parameters in the driver data which were previously available only via omap_dss_device. Replace the arguments with platform device pointers for such functions. Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26OMAPDSS: DSI: fix tlpx_half reg field lengthTomi Valkeinen
tlpx_half bit field in DSI_DSIPHY_CFG1 is [20,16], not [22,16] as accessed in the code currently. Fix this. The bug should not have caused any problems on OMAP3/4, as the bits 21,22 are unused. They are used on OMAP5, though. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-25OMAPDSS: DISPC: Add predecimation limit for TILER based rotationsChandrabhanu Mahapatra
In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can be skipped as per the respective TRMs. The MBlockStride OCP signal, which is sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode TILER supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 or more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors. So, maximum vertical predecimation achievable is 2. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-25Merge OMAP5 DSS changes to omapdssTomi Valkeinen
This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI and DSI. * omap5-dss: OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5 OMAPDSS: DSI: Add code to disable PHY DCC OMAPDSS: DSI: Add new linebuffer size for OMAP5 OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO OMAPDSS: Add support for DPI source selection OMAPDSS: move dss feats to the end of dss.c OMAPDSS: Add basic omap5 features to dss and dispc OMAPDSS: DSI: improve DSI clock calcs for DISPC
2012-09-25Merge omapdss single-dssdev seriesTomi Valkeinen
This series contains patches that change how omapdss's panel devices (omap_dss_device) are initialized and registered. There are two patches that change behaviour, the rest are just cleanups: The patch "omap_dss_register_device() doesn't take display index" affects the number for the "displayX" sysfs files. This hopefully doesn't affect the userspace, as the number has never been a clear indication of what the particular display is. The patch "register only one display device per output" affects how panel devices are created. Currently we support multiple panels per output, i.e. you could have DVI and an LCD displays using the same DPI output, as long as the DVI and LCD are not used at the same time. This patch changes the omapdss driver to only register one display device per output. If there are multiple displays for the output, either the first one is picked or, if def_display has been defined in kernel parameters and the def_display is one of the displays for this output, the def_display is picked. See the patch for more information. OMAPDSS: alloc dssdevs dynamically OMAPDSS: cleanup dss_recheck_connections further OMAPDSS: cleanup dss_recheck_connections OMAPDSS: handle errors in dss_init_device OMAPDSS: explicitely initialize dssdev->channel for new displays OMAPDSS: register only one display device per output OMAPDSS: Add dss_get_default_display_name() OMAPDSS: omap_dss_register_device() doesn't take display index
2012-09-25OMAPDSS: Do not require a VDDS_DSI regulator on AM35xxRaphaël Assénat
On our AM3505 based board, dpi.c complains that there is no VDDS_DSI regulator and the framebuffer cannot be enabled. However, this check does not seem to apply to AM3505/17 chips. This patch adds new features list for AM35xxx, which is the same as for OMAP3 except the VDDS_DSI is removed. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5Tomi Valkeinen
Change omapdss Kconfig file to make OMAP2_DSS_DSI depend on ARCH_OMAP5. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24OMAPDSS: DSI: Add code to disable PHY DCCTomi Valkeinen
OMAP5 DSI PHY has DCC (Duty Cycle Corrector) block, and by default DCC is enabled and thus the PLL clock is divided by 2 to get the DSI DDR clk. This divider has been 4 for all previous OMAPs, and changing it needs some reorganization of the code. The DCC can be disabled, and in that case the divider is back to the old 4. This patch adds dss feature for the DCC, and adds code to always disable the DCC. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>