1. 08 Jul, 2012 2 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 373b4365
      Tomi Valkeinen authored
      If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
      will always return 1 and pm_runtime_put_sync() will always return
      -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
      driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
      print a warning.
      
      One option would be to ignore errors returned by pm_runtime_put_sync()
      totally, as they only say that the call was unable to put the hardware
      into suspend mode.
      
      However, I chose to ignore the returned -ENOSYS explicitly, and print a
      warning for other errors, as I think we should get notified if the HW
      failed to go to suspend properly.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      373b4365
    • Tomi Valkeinen's avatar
      OMAPDSS: Use PM notifiers for system suspend · 736f29cd
      Tomi Valkeinen authored
      The current way how omapdss handles system suspend and resume is that
      omapdss device (a platform device, which is not part of the device
      hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
      the suspend and resume callbacks from platform_driver to handle system
      suspend. It does this by disabling all enabled panels on suspend, and
      resuming the previously disabled panels on resume.
      
      This presents a few problems.
      
      One is that as omapdss device is not related to the panel devices or the
      DSS HW devices, there's no ordering in the suspend process. This means
      that suspend could be first ran for DSS HW devices and panels, and only
      then for omapdss device. Currently this is not a problem, as DSS HW
      devices and panels do not handle suspend.
      
      Another, more pressing problem, is that when suspending or resuming, the
      runtime PM functions return -EACCES as runtime PM is disabled during
      system suspend. This causes the driver to print warnings, and operations
      to fail as they think that they failed to bring up the HW.
      
      This patch changes the omapdss suspend handling to use PM notifiers,
      which are called before suspend and after resume. This way we have a
      normally functioning system when we are suspending and resuming the
      panels.
      
      This patch, I believe, creates a problem that somebody could enable or
      disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
      similarly the other way around in resume. I choose to ignore the problem
      for now, as it sounds rather unlikely, and if it happens, it's not
      fatal.
      
      In the long run the system suspend handling of omapdss and panels should
      be thought out properly. The current approach feels rather hacky.
      Perhaps the panel drivers should handle system suspend, or the users of
      omapdss (omapfb, omapdrm) should handle system suspend.
      
      Note that after this patch we could probably revert
      0eaf9f52 (OMAPDSS: use sync versions of
      pm_runtime_put). But as I said, this patch may be temporary, so let's
      leave the sync version still in place.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Tested-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Tested-by: default avatarJoe Woodward <jw@terrafix.co.uk>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      [fts: fixed 2 brace coding style issues]
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      736f29cd
  2. 13 Jun, 2012 2 commits
  3. 09 Jun, 2012 5 commits
  4. 05 Jun, 2012 3 commits
    • Emil Goode's avatar
      video: bfin_adv7393fb: Convert to kstrtouint_from_user · 5c888aa4
      Emil Goode authored
      This patch removes a call to the deprecated simple_strtoul function
      and simplifies the code by replacing two function calls with one
      call to kstrtouint_from_user.
      
      -Simplify the adv7393_write_proc function by replacing the
       simple_strtoul and copy_from_user calls with one call
       to kstrtouint_from_user.
      
      -Change the count parameter from unsigned long to size_t as
       this is the type that the kstrtouint_from_user function expects.
       (size_t is what will be passed to the adv7393_write_proc function
       by the proc write handler function proc_file_write anyway)
      Signed-off-by: default avatarEmil Goode <emilgoode@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      5c888aa4
    • Florian Tobias Schandinat's avatar
      Merge tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux into fbdev-for-linus · 70b6eaee
      Florian Tobias Schandinat authored
      Small fixes for omapdss driver. Most importantly, fixes a build problem when
      debugfs or omapdss debug support is turned off, and fixes a suspend related
      crash.
      70b6eaee
    • Tomi Valkeinen's avatar
      OMAPDSS: fix registration of DPI and SDI devices · c3a21fc7
      Tomi Valkeinen authored
      The omapdss arch initialization code registers all the output devices as
      omap_devices. However, DPI and SDI are not proper omap_devices, as they
      do not have any corresponding HWMOD. This leads to crashes or problems
      when the platform code tries to use omap_device functions for DPI and
      SDI devices.
      
      One such crash was reported by John Stultz <johnstul@us.ibm.com>:
      
      [   18.756835] Unable to handle kernel NULL pointer dereference at
      virtual addr8
      [   18.765319] pgd = ea6b8000
      [   18.768188] [00000018] *pgd=aa942831, *pte=00000000, *ppte=00000000
      [   18.774749] Internal error: Oops: 17 [#1] SMP ARM
      [   18.779663] Modules linked in:
      [   18.782836] CPU: 0    Not tainted  (3.5.0-rc1-dirty #456)
      [   18.788482] PC is at _od_resume_noirq+0x1c/0x78
      [   18.793212] LR is at _od_resume_noirq+0x6c/0x78
      [   18.797943] pc : [<c00307ec>]    lr : [<c003083c>]    psr: 20000113
      [   18.797943] sp : ec3abe80  ip : ec3abdb8  fp : 00000006
      [   18.809936] r10: ec1148b8  r9 : c08a48f0  r8 : c00307d0
      [   18.815368] r7 : 00000000  r6 : 00000000  r5 : ec114800  r4 :
      ec114808
      [   18.822174] r3 : 00000000  r2 : 00000000  r1 : ec154fe8  r0 :
      00000006
      [   18.829010] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
      Segment user
      [   18.836456] Control: 10c5387d  Table: aa6b804a  DAC: 00000015
      [   18.842437] Process sh (pid: 1139, stack limit = 0xec3aa2f0)
      [   18.848358] Stack: (0xec3abe80 to 0xec3ac000)
      
      DPI and SDI can be plain platform_devices. This patch changes the
      registration from omap_device_register() to platform_device_add().
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarJohn Stultz <johnstul@us.ibm.com>
      Tested-by: default avatarJean Pihet <jean.pihet@newoldbits.com>
      c3a21fc7
  5. 04 Jun, 2012 4 commits
    • Archit Taneja's avatar
      OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters · 2e063c30
      Archit Taneja authored
      In function dsi_compute_interleave_lp(), the escape clock/LP clock time period
      is calculated incorrectly. The escape clock/LP clock is calculated as:
      
      LP Clock(Hz) = DSI_FCLK(Hz) / lp_clk_div
      
      Since we are calculating the time period of LP clock, the LP clock divider
      should be multiplied with the time period of DSI_FCLK.
      
      Calculating incorrect value of txclkesc results in incorrect calculation of LP
      interleaving parameters, it also creates a possibility of a divide by zero
      error.
      Reported-by: default avatarSureshkumar Manimuthu <mail2msuresh@ti.com>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2e063c30
    • Tomi Valkeinen's avatar
      OMAPDSS: fix bogus WARN_ON in dss_runtime_put() · 5025ce07
      Tomi Valkeinen authored
      pm_runtime_put_sync() in dss_runtime_put() returns -EBUSY when any child
      of dss is still enabled. This happens, for example, when a display
      output is enabled and one dumps the clocks via debugfs. This causes
      dss_runtime_get & put to be called.
      
      While I couldn't find anything about this in the documentation and it
      wasn't immediately clear from runtime_pm code, it looks to me that
      pm_runtime_put_sync() returns -EBUSY to inform that things went fine,
      but the device could not be turned off as there are still child devices
      that are enabled. This is not a problem.
      
      This patch skips the WARN_ON if pm_runtime_put_sync() returns -EBUSY.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5025ce07
    • Tomi Valkeinen's avatar
      OMAPDSS: Taal: fix compilation warning · d1700f92
      Tomi Valkeinen authored
      This patch fixes a warning:
      
      drivers/video/omap2/displays/panel-taal.c: In function
      ‘taal_num_errors_show’:
      drivers/video/omap2/displays/panel-taal.c:529: warning: ‘errors’ may be
      used uninitialized in this function
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      d1700f92
    • Tomi Valkeinen's avatar
      OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled · 0e9a126e
      Tomi Valkeinen authored
      If CONFIG_DEBUG_FS or CONFIG_OMAP2_DSS_DEBUG_SUPPORT is disabled, the
      build fails:
      
      drivers/video/omap2/dss/core.c:197:50: error: static declaration of
      'dss_debugfs_create_file' follows non-static declaration
      drivers/video/omap2/dss/dss.h:166:5: note: previous declaration of
      'dss_debugfs_create_file' was here
      
      This patch fixes the dummy dss_debugfs_create_file() so that the driver
      builds.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0e9a126e
  6. 29 May, 2012 5 commits
  7. 27 May, 2012 1 commit
    • Florian Tobias Schandinat's avatar
      Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-next · d85d135d
      Florian Tobias Schandinat authored
      Omapdss driver changes for 3.5 merge window.
      
      Lots of normal development commits, but perhaps most notable changes are:
      
      * HDMI rework to properly decouple the HDMI audio part from the HDMI video part.
      * Restructure omapdss core driver so that it's possible to implement device
        tree support. This included changing how platform data is passed to the
        drivers, changing display device registration and improving the panel driver's
        ability to configure the underlying video output interface.
      * Basic support for DSI packet interleaving
      d85d135d
  8. 22 May, 2012 9 commits
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request · e92a5b28
      Ricardo Neri authored
      genirq requires that the IRQ requests that do not provided a handler to
      use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
      is reenabled while the interrupt is still asserted. While this situation may
      not happen in edge type interrupts, genirq still requires to use IRQF_ONESHOT.
      
      Also, remove the IRQF_DISABLED as the flag is now a NOOP and has been
      deprecated.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e92a5b28
    • Archit Taneja's avatar
      OMAPDSS: Apply VENC timings even if panel is disabled · c808ab9c
      Archit Taneja authored
      The VENC interfaces uses it's venc_set_timing() function to take in a new set
      of timings. If the panel is disabled, it does not disable and re-enable the
      interface. Currently, the manager timings are applied in venc_power_on(), these
      are not called by set_timings if the panel is disabled. When checking overlay
      and manager data, the DSS driver uses the last applied manager timings, and not
      the timings held by omap_dss_device struct. Hence, there is a need to apply the
      new manager timings even if the panel is disabled.
      
      Apply the manager timings if the VENC panel is disabled.
      
      This is similar to the commit below which fixed the same issue for HDMI/DPI
      interfaces:
      
      fcc36619Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      c808ab9c
    • Archit Taneja's avatar
      OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC · 2aefad49
      Archit Taneja authored
      DSS2 driver uses the timings in manager's private data to check the validity of
      overlay and manager infos written by the user. For VENC interface, we divide the
      Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the
      content is interlaced. However, the height of the manager/display with respect
      to the content shown through VENC still remains the same.
      
      The VENC driver divides the y_res parameter in omap_video_timings by half, and
      then applies the configuration. This leads to manager's private data storing
      the wrong Y resolution. Hence, overlay related checks fail.
      
      Ensure that manager's private data stores the original timings, and the Y
      resolution is halved only when we write to the DISPC register. This is a hack,
      the proper solution would be to pass some sort of interlace parameter which
      makes the call whether we should divide y_res or not.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2aefad49
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Support rotation through TILER · 65e006ff
      Chandrabhanu Mahapatra authored
      TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
      Physical memory can be mapped to a portion of OMAP's system address space called
      TILER address space. The TILER address space is split into 8 views. Each view
      represents a rotated or mirrored form of the mapped physical memory. When a
      DISPC overlay's base address is programmed to one of these views, the TILER
      fetches the pixels according to the orientation of the view. A view is further
      split into 4 containers, each container holds elements of a particular size.
      Rotation can be achieved at the granularity of elements in the container. For
      more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
      Rotation type TILER has been added which is used to exploit the capabilities of
      these 8 views for performing various rotations.
      
      When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
      pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
      are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
      and page mode sized containers require 1D bursts.
      
      The DSS2 user is expected to provide the Tiler address of the view that it is
      interested in. This is passed to the paddr and p_uv_addr parameters in
      omap_overlay_info. It is also expected to provide the stride value based on the
      view's orientation and container type, this should be passed to the screen_width
      parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
      used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
      also used to calculate row_inc and pix_inc thereby adding predecimation support
      for TILER.
      Signed-off-by: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      65e006ff
    • Tomi Valkeinen's avatar
      OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n · 3cb6a1b9
      Tomi Valkeinen authored
      If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
      places in code expect the execution to stop, and this causes compiler
      warnings about uninitialized variables and returning from a non-void
      function without a return value.
      
      This patch fixes the warnings by initializing the variables and
      returning properly after BUG() lines. However, the behaviour is still
      undefined after the BUG, but this is the choice the user makes when
      using CONFIG_BUG=n.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      3cb6a1b9
    • Tomi Valkeinen's avatar
      OMAPFB: remove compiler warnings when CONFIG_BUG=n · 4a75cb85
      Tomi Valkeinen authored
      If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
      places in code expect the execution to stop, and this causes compiler
      warnings about uninitialized variables and returning from a non-void
      function without a return value.
      
      This patch fixes the warnings by initializing the variables and
      returning properly after BUG() lines. However, the behaviour is still
      undefined after the BUG, but this is the choice the user makes when
      using CONFIG_BUG=n.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      4a75cb85
    • Tomi Valkeinen's avatar
      OMAPDSS: remove compiler warnings when CONFIG_BUG=n · c6eee968
      Tomi Valkeinen authored
      If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
      places in code expect the execution to stop, and this causes compiler
      warnings about uninitialized variables and returning from a non-void
      function without a return value.
      
      This patch fixes the warnings by initializing the variables and
      returning properly after BUG() lines. However, the behaviour is still
      undefined after the BUG, but this is the choice the user makes when
      using CONFIG_BUG=n.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      c6eee968
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv · 36377357
      Tomi Valkeinen authored
      Commit 05dd0f53 ("OMAPDSS: DISPC: Update
      Accumulator configuration for chroma plane") adds
      dispc_ovl_set_accu_uv() function that sets the accu, but the function
      only handles YUV and NV12 modes, and BUGs otherwise.
      
      The patch also adds a call to the function, but unfortunately the place
      of call was such that the mode could be other than YUV or NV12, thus
      crashing the driver.
      
      This patchs moves the call to a slightly later spot, at which point only
      YUV and NV12 modes are handled.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
      36377357
    • Tomi Valkeinen's avatar
      OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays · 3568f2a4
      Tomi Valkeinen authored
      There is a problem related to DSS FIFO thresholds and power management
      on OMAP3. It seems that when the full PM hits in, we get underflows. The
      core reason is unknown, but after experiments it looks like only
      particular FIFO thresholds work correctly.
      
      This bug is related to an earlier patch, which added special FIFO
      threshold configuration for OMAP3, because DSI command mode output
      didn't work with the normal threshold configuration.
      
      However, as the above work-around worked fine for other output types
      also, we currently always configure thresholds in this special way on
      OMAP3. In theory there should be negligible difference with this special
      way and the standard way. The first paragraph explains what happens in
      practice.
      
      This patch changes the driver to use the special threshold configuration
      only when the output is a manual update display on OMAP3. This does
      include RFBI displays also, and although it hasn't been tested (no
      boards using RFBI) I suspect the similar behaviour is present there
      also, as the DISPC side should work similarly for DSI command mode and
      RFBI.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Joe Woodward <jw@terrafix.co.uk>
      3568f2a4
  9. 21 May, 2012 1 commit
    • Archit Taneja's avatar
      OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods · 6f28c296
      Archit Taneja authored
      DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
      BLLP blanking intervals in a video mode stream. This is useful as a user may
      want to read or change the configuration of a panel without stopping the video
      stream.
      
      On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
      the DSI HW takes care of interleaving this data during the one of the blanking
      intervals. The DSI HW needs to be programmed with the maximum amount of data
      that can be interleaved in a particular blanking period. A blanking period
      cannot be used to send command mode data for it's complete duration, there is
      some amount of time required for the DSI data and clock lanes to transition
      to the desired LP or HS state.
      
      Based on the state of the lanes at the beginning and end of the blanking period,
      we have different scenarios, with each scenario having a different value of time
      required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
      OMAP TRM for more info on the scenarios and the equations to calculate the time
      required for HS or LP transitions.
      
      We use the scenarios which takes the maximum time for HS or LP transition, this
      gives us the minimum amount of time that can be used to interleave command mode
      data. The amount of data that can be sent during this minimum time is calculated
      for command mode packets both in LP and HS. These are written to the registers
      DSI_VM_TIMING4 to DSI_VM_TIMING6.
      
      The calculations don't take into account the time required of transmitting BTA
      when doing a DSI read, or verifying if a DSI write went through correctly. Until
      these latencies aren't considered, the behaviour of DSI is unpredictable when
      a BTA is interleaved during a blanking period. Enhancement of these calculations
      is a TODO item.
      
      The calculations are derived from DSI parameter calculation tools written by
      Sebastien Fagard <s-fagard@ti.com>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6f28c296
  10. 15 May, 2012 1 commit
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Update Accumulator configuration for chroma plane · 05dd0f53
      Chandrabhanu Mahapatra authored
      DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
      with horizontal and vertical bit fields. The bit fields can take values in the
      range of -1024 to 1023. Based on bit field values DISPC decides on which one out
      of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
      output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
      are used.
      
      The current accumulator values in DISPC scaling logic for chroma plane takes
      default values for all color modes and rotation types. So, the horizontal and
      vertical up and downsampling accumulator bit field values have been updated for
      better performance.
      Signed-off-by: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      05dd0f53
  11. 13 May, 2012 7 commits