diff options
author | Archit Taneja <archit@ti.com> | 2012-09-26 13:30:37 +0200 |
---|---|---|
committer | Tomi Valkeinen <tomi.valkeinen@ti.com> | 2012-09-26 13:58:49 +0200 |
commit | 8ba85306ba0fd87a3c15a02fe83d817832705a7d (patch) | |
tree | 2e736e1cd5210f0705f863b6fdcfa24ff59650fb /drivers/video/da8xx-fb.c | |
parent | OMAPDSS: DISPC: Don't pass channel out when configuring overlays (diff) | |
download | linux-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/da8xx-fb.c')
0 files changed, 0 insertions, 0 deletions