summaryrefslogtreecommitdiffstats
path: root/drivers/video/sbuslib.c
diff options
context:
space:
mode:
authorArchit Taneja <archit@ti.com>2012-09-26 13:30:37 +0200
committerTomi Valkeinen <tomi.valkeinen@ti.com>2012-09-26 13:58:49 +0200
commit8ba85306ba0fd87a3c15a02fe83d817832705a7d (patch)
tree2e736e1cd5210f0705f863b6fdcfa24ff59650fb /drivers/video/sbuslib.c
parentOMAPDSS: DISPC: Don't pass channel out when configuring overlays (diff)
downloadlinux-8ba85306ba0fd87a3c15a02fe83d817832705a7d.tar.xz
linux-8ba85306ba0fd87a3c15a02fe83d817832705a7d.zip
OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode
The scalers of overlays and writeback do not have any constraints on downscale ratio when operating in memory to memory mode. This is because in memory to memory mode, we aren't connected to a display which needs data output at the rate of pixel clock. The scalers can perform as much downscaling as needed, the rate at which the scaler outputs is adjusted accordingly. Relax constraints related to downscaling based on whether the input overlays are connected to writeback in memory to memory mode. We pass a mem_to_mem boolean parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this will later be configured to the correct value based on whether the overlay is connected to writeback or not. Do the same later for writeback when writeback is configured. In the scaling calculation code, we calculate the minimum amount of core clock we need to achieve the required downscaling. If we are in memory to memory mode, we set this to a very small value(1 in this case), this value would always be lesser than the actual DISPC core clock value, and hence the scaling checks would succeed. We take care that pixel clock isn't calculated for writeback and the overlays connected to it when in memory to memory mode. A pixel clock in such cases doesn't make sense. Signed-off-by: Archit Taneja <archit@ti.com>
Diffstat (limited to 'drivers/video/sbuslib.c')
0 files changed, 0 insertions, 0 deletions