Skip to content

L
linux
Switch branch/tag
  1. 20 Jan, 2014 1 commit
  3. 17 Jan, 2014 24 commits
  5. 14 Jan, 2014 1 commit
    • Ivaylo Dimitrov's avatar
      OMAPDSS: DISPC: Fix 34xx overlay scaling calculation · e4998634
      Ivaylo Dimitrov authored 
      commit 7faa9233 OMAPDSS: DISPC: Handle
synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
on OMAP3. However, it misses the logic found in Nokia kernels that is
needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
well as the logic to fallback to 3 taps if 5 taps clock results in too
tight horizontal timings. Without that patch "horizontal timing too tight"
errors are seen when a video with resolution above 640x350 is tried to be
played. The patch is a forward-ported logic found in Nokia N900 and N9/50
kernels.
Signed-off-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e4998634
  7. 13 Jan, 2014 13 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: panel-acx565akm: clean-up locking · 0eb0dafb
      Tomi Valkeinen authored 
      The locking in the acx565akm panel driver was getting too complex. Clean
it up by making new functions, acx565akm_bl_get_intensity_locked and
acx565akm_bl_update_status_locked, which are called by the backlight
subsystem. This way the non-locked versions can be called by the panel's
other funcs, simplifying the lock management.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0eb0dafb
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Preload more data in pipeline DMAs for OMAP4+ SoCs · 8bc65552
      Archit Taneja authored 
      DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
region before the start of each frame. The preload ensures the pipeline doesn't
underflow when the active region of the display starts.

DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
should be preloaded for each pipeline. Calculating a precise preload value
would be a complex function of the pixel clock of the connected display, the
vertical blanking duration and the interconnect traffic at that instance. If
the register is left untouched, a default value is preloaded.

We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use cases
with many other initiators active, and in situations where memory access isn't
very efficient(like accessing Tiler mapped buffers and EMIF configured in
non-interleaved more). The cause of the underflow is because the default preload
value isn't sufficient for the DMA to reach a steady state. We configure the
PRELOAD register such that the pipelines preload data up to the high threshold
of the FIFO.

Preloading lot of data for older SoCs can have a negative impact. Due to slower
interconnects, it's possible that the DISPC DMA cannot preload up to the high
threshold within the vertical blanking region of the panel. We leave the PRELOAD
registers to their reset values since we haven't faced underflows with these
SoCs because of low value of PRELOAD.
Signed-off-by: default avatarArchit Taneja <archit@ti.com>
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8bc65552
    • Tomi Valkeinen's avatar
      OMAPFB: disable overlays on driver removal · b52a6e7f
      Tomi Valkeinen authored 
      When omapfb module is removed, the driver will turn off all the displays
it manages. However, it leaves the overlays enabled. While the overlays
are obviously disabled as the displays are disabled, it causes issues
when the driver module is loaded again, as at that point the overlays
are still enabled on the hardware level. The result is that even if the
SW thinks overlays are disabled, they are actually enabled.

Fix this by making sure the overlays are disabled at module removal.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b52a6e7f
    • Tomi Valkeinen's avatar
      OMAPDSS: don't print errors on -EPROBE_DEFER · 40359a9b
      Tomi Valkeinen authored 
      Nowadays it's normal to get -EPROBE_DEFER from, e.g., regulator_get. As
-EPROBE_DEFER is not really an error, and the driver will be probed fine
a bit later, printing an error message will just confuse the user.

This patch changes omapdss to print an error for regulator_gets only if
the error code is something else than -EPROBE_DEFER.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      40359a9b
    • Tomi Valkeinen's avatar
      OMAPFB: give informative print when probe succeeds · ab7bf423
      Tomi Valkeinen authored 
      It is quite common to have omapfb probe deferred because of a missing
resource, and to get omapfb probed succesfully a bit later. This works
fine. However, omapfb does not give any print on a successful probe, so
if the omapfb is actually never probed again after deferral, this is not
shown in the log.

To help debugging, add a simple print from omapfb at the end of its
probe, saying which display it is using and in which resolution.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      ab7bf423
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: rename resource names · 77601507
      Tomi Valkeinen authored 
      The HDMI driver tries to get the needed memory resources by name and by
ID. Resources by name are not currently defined, and will be used with
DT boot.

The resource names used in the driver are not quite perfect, and as they
are not used yet, we can change them. This patch removes the unneeded
"hdmi_" prefix from the names, and simplifies the names (e.g. hdmi_txphy
-> phy).
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      77601507
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: split DSI memory map to smaller blocks · 68104467
      Tomi Valkeinen authored 
      DSI contains three separate blocks: protocol engine, PHY and PLL. At the
moment, all these are memory mapped in one big chunk. We need to split
that memory map into smaller pieces so that we can add proper 'reg'
properties into the DT data for each block.

This patch changes the driver to map the blocks separately. It first
tries to get the memory resource using name, used when booting with DT,
and if that fails, it gets the memory resource by ID, in which case the
driver gets the big chunk from platform data. That big chunk is then
split into the smaller blocks manually.

After DSS DT code has been merged and the old platform code removed, we
can clean up the memory resource management.

Instead of changing the driver in all the places where a register is
read or written, this patch takes a shortcut: it adds an additional
number to the struct which represents the register index. This number is
used to decide which base address to use. In the future we should
consider other approaches.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      68104467
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: add missing core irq · 6873efe1
      Tomi Valkeinen authored 
      HDMI_IRQ_CORE was not defined in the hdmi.h.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6873efe1
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: fix HDMI_WP_CLK name · 42116517
      Tomi Valkeinen authored 
      HDMI_WP_CLK was wrongly defined as HDMI_WP_WP_CLK. Fix that.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      42116517
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: fix hdmi_wait_for_bit_change · 91b53e6a
      Tomi Valkeinen authored 
      hdmi_wait_for_bit_change() has two issues:

The register index was passed as u16, even if the register index may be
u32. Fix the index to u32.

The function was copied from wait_for_bit_change() which waits for a
single bit to change, but the hdmi version was changed to wait for a bit
field. This change was not done correctly.

The function is supposed to return the (last) value of the bit field,
but it returned !val in case of timeout. This was correct for the single
bit version, but not for the hdmi version. Fix the function to return
the actual value in the register.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      91b53e6a
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: fix context restore · be07dcd7
      Tomi Valkeinen authored 
      DISPC_MSTANDBY_CTRL register is used in the driver, but it's not
restored in dispc_restore_context(), causing problems after resume.

Instead of adding DISPC_MSTANDBY_CTRL to dispc_restore_context(), let's
call _omap_dispc_initial_config() as the first thing in
dispc_runtime_resume(). This will initialize the DISPC core registers
properly, and will avoid similar issues in the future.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      be07dcd7
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI4: remove useless func calls · f4f49c48
      Tomi Valkeinen authored 
      For some reason the hdmi driver first turns off the video output when
it's about to enable the video output. This serves no purpose, and can
be removed.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      f4f49c48
    • Archit Taneja's avatar
      OMAPDSS: HDMI4: Accept non-standard timings · 1e676248
      Archit Taneja authored 
      The hdmi4 driver currently rejects any timing which is not from the CEA or VESA
standards. This leads hdmi rejecting any non-standard mode. A non standard
timing may not have a valid code corresponding to it. In such cases, the HDMI
spec suggests to set the code to 0.

Modify the driver to check if the timings fall within the range of the DISPC
TV overlay manager, and remove the check for an invalid code. Add a debug print
specifying the mode and code in hdmi_display_set_timing.
Signed-off-by: default avatarArchit Taneja <archit@ti.com>
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1e676248
  9. 30 Dec, 2013 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: fix fifosize · 558c73e2
      Tomi Valkeinen authored 
      DSI has separate TX and RX fifos. However, the current code only has one
field where the fifo size is stored, and the code for both TX and RX
config write to the same field. This has not caused issues, as we've
been using the same fifo sizes.

Fix this bug by creating separate fields for TX and RX fifo sizes.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      558c73e2
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7