1. 11 Feb, 2014 2 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: fix fck field types · c56812fc
      Tomi Valkeinen authored
      'fck' field in dpi and sdi clock calculation struct is 'unsigned long
      long', even though it should be 'unsigned long'. This hasn't caused any
      issues so far.
      Fix the field's type.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: decimation rounding fix · eec77da2
      Tomi Valkeinen authored
      The driver uses DIV_ROUND_UP when calculating decimated width & height.
      For example, when decimating with 3, the width is calculated as:
        width = DIV_ROUND_UP(width, decim_x);
      This yields bad results for some values. For example, 800/3=266.666...,
      which is rounded to 267. When the input width is set to 267, and pixel
      increment is set to 3, this causes the dispc to read a line of 801
      pixels, i.e. it reads a wrong pixel at the end of the line.
      Even more pressing, the above rounding causes a BUG() in pixinc(), as
      the value of 801 is used to calculate row increment, leading to a bad
      value being passed to pixinc().
      This patch fixes the decimation by removing the DIV_ROUND_UP()s when
      calculating width and height for decimation.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  2. 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
      Signed-off-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  3. 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
  4. 09 Jan, 2014 1 commit
    • Tomi Valkeinen's avatar
      drm/omap: fix (un)registering irqs inside an irq handler · 6da9f891
      Tomi Valkeinen authored
      omapdrm (un)registers irqs inside an irq handler. The problem is that
      the (un)register function uses dispc_runtime_get/put() to enable the
      clocks, and those functions are not irq safe by default.
      This was kind of fixed in 48664b21
      (OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
      runtime calls irq-safe.
      However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
      dss, always enabled, effectively preventing PM for the whole DSS module.
      This patch makes omapdrm behave better by adding new irq (un)register
      functions that do not use dispc_runtime_get/put, and using those
      functions in interrupt context. Thus we can make dispc again
      non-irq-safe, allowing proper PM.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Rob Clark <robdclark@gmail.com>
  5. 30 Dec, 2013 6 commits
    • 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>
    • Tomi Valkeinen's avatar
      OMAPDSS: rename display-sysfs 'name' entry · 303e4697
      Tomi Valkeinen authored
      omapdss in compat mode creates some sysfs files into the device's sysfs
      directory, including a 'name' file. This works fine for
      platform_devices, but breaks with i2c or spi devices, as those already
      have a 'name' file.
      Fix this by renaming the omapdss's 'name' file to 'display_name'.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: Add MFLAG defines · 29fceeeb
      Tomi Valkeinen authored
      OMAP5 has MFLAG feature in DISPC. Add the register definition and dump
      it. The register is not used yet, though.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: apply fixes · 7a53df2c
      Tomi Valkeinen authored
      When omapfb does ovl->get_overlay_info, ovl->set_overlay_info, the set
      function may fail even if the info has not been changed. This is because
      omapdss doesn't initialize the info, but expect the caller to set valid
      Normally that is the case, but there is at least one corner case: if
      omapfb has not allocated memory for the overlay yet, and the user uses
      ioctl to disable the overlay to make sure it's disabled. In this case
      get_overlay_info returns invalid data, but the user is only interested
      in setting the overlay to disabled, not configuring it, and
      set_overlay_info fails.
      The issue is made possible by the omapfb's setup_plane ioctl, which
      groups overlay configuration and overlay enable/disable bit into the
      same struct. Thus, when you are disabling an overlay, you are also
      configuring it.
      This is a bit counter intuitive, so I think it's better to initialize
      the info to some valid values.
      The fields requiring initialization are color_mode and rotation_type,
      and also we need to remove the check for (paddr == 0), as paddr is 0 for
      unallocated overlay (but it's still fine to disable the overlay).
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: fix debug prints · ac9f2421
      Tomi Valkeinen authored
      Fix debug prints all over omapdss:
      * add missing linefeeds
      * change pr_err/pr_debug to DSSERR/DSSDBG
      * add missing DSS_SUBSYS_NAMEs
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: fix missing EXPORT_SYMBOL()s · 8ee5c842
      Tomi Valkeinen authored
      Functions dispc_ovl_set_fifo_threshold and
      dispc_ovl_compute_fifo_thresholds need to be exported. Add the
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  6. 26 Nov, 2013 1 commit
    • Aaro Koskinen's avatar
      ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance · c37dd677
      Aaro Koskinen authored
      When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig
      (LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled,
      the following BUG is seen during the boot:
      [    7.302154] =====================================
      [    7.307128] [ BUG: bad unlock balance detected! ]
      [    7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7b
       #3 Not tainted
      [    7.318450] -------------------------------------
      [    7.323425] kworker/u2:1/12 is trying to release lock (&ddata->mutex) at:
      [    7.330657] [<c031b760>] acx565akm_enable+0x12c/0x18c
      [    7.335998] but there are no more locks to release!
      Fix by removing double unlock and handling the locking completely inside
      acx565akm_panel_power_on() when doing the power on.
      Reported-by: default avatarEduardo Valentin <eduardo.valentin@ti.com>
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  7. 18 Nov, 2013 7 commits
  8. 15 Nov, 2013 1 commit
  9. 31 Oct, 2013 1 commit
  10. 30 Oct, 2013 1 commit
  11. 29 Oct, 2013 2 commits
  12. 18 Oct, 2013 1 commit
  13. 09 Oct, 2013 3 commits