1. 29 12月, 2015 14 次提交
  2. 17 12月, 2015 2 次提交
    • T
      OMAPDSS: DISPC: always set ALIGN when available · e5f80917
      Tomi Valkeinen 提交于
      By default DISPC asserts hsync and vsync sequentially, i.e. there's
      first hsync and that is immediately followed by vsync. This is the only
      available behaviour on OMAP2/3, and default behaviour on OMAP4+.
      
      OMAP4+ has ALIGN bit in POL_FREQ register, which makes DISPC assert both
      syncs at the same time.
      
      It has been observed that some panels don't like sequential syncs (AM5
      EVM's panel). After studying the datasheets for multiple panels and
      encoders, and MIPI DPI spec, it looks like there is no standard way to
      handle this.
      
      Sometimes the datasheets don't mention the required syncs behaviour at
      all, sometimes the datasheets have images that hint towards simultaneous
      syncs, and sometimes it is explicitly mentioned that simultaneous syncs
      are needed. No panels or encoders requiring sequential sync was found.
      
      It thus seems to be safe to default to simultaneous syncs when the ALIGN
      bit is available. This fixed AM5 EVM's panel, and no side effects have
      been observed on other panels or encoders.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      e5f80917
    • D
      OMAPDSS: adopt pinctrl support · 5038bb8c
      Dave Gerlach 提交于
      Update omapdss driver to set the state of the pins to:
      - "default on resume
      - "sleep" on suspend
      
      By optionally putting the pins into sleep state in the suspend callback
      we can accomplish two things.
      - minimize current leakage from pins and thus save power,
      - prevent the IP from driving pins output in an uncontrolled manner,
      which may happen if the power domain drops the domain regulator.
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5038bb8c
  3. 28 10月, 2015 1 次提交
  4. 24 9月, 2015 3 次提交
    • J
      OMAPDSS: panel-sony-acx565akm: Export OF module alias information · 4bdb4629
      Javier Martinez Canillas 提交于
      Drivers needs to export the OF id table and this be built into
      the module or udev won't have the necessary information to autoload
      the driver module when the device is registered via OF.
      Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      4bdb4629
    • V
      fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface · ad38cc5f
      Vladimir Zapolskiy 提交于
      This change is needed to properly lock I2C bus driver, which serves DDC.
      
      Prior to this change i2c_put_adapter() is misused, which may lead to
      an overflow over zero of I2C bus driver user counter.
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ad38cc5f
    • J
      OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled · 8a9d4626
      Jyri Sarha 提交于
      Reconfigure and restart audio when display is enabled, if audio
      playback was active before. This is needed in a situation when an
      audio+video stream application opens the audio stream before the
      video. When video stream is opened the display mode may change and
      that aborts audio playback, because the display is momentarily
      turned off.
      
      The audio configuration is stored when it is successfully applied and
      a boolean is set when the audio playback is started and unset when
      stopped. This data is used to reconfigure the audio when display is
      re-enabled. The audio playback is aborted if the reconfiguration fails.
      
      A new spin lock is introduced in order to protect state variables
      related to audio playback status. This is needed for the transition
      from display enabled state (when audio start/stop commands can be
      written to HW) to display disabled state (when audio start/stop
      commands update only the hdmi.audio_playing variable) to always
      serialize correctly with the start/stop audio commands. The already
      existing mutex can not be used, because the audio start and stop
      commands are executed in atomic context.
      
      For example: when display is turned back on we take the spinlock and
      we can be sure that the audio start/stop status will not change while
      we update the HW according to hdmi.audio_playing state and set
      hdmi.display_enabled to true. After releasing the lock
      hdmi.display_enabled is true and all audio_start and audio_stop
      commands write their stuff directly to HW.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8a9d4626
  5. 11 9月, 2015 1 次提交
  6. 20 8月, 2015 1 次提交
  7. 10 8月, 2015 2 次提交
  8. 02 7月, 2015 1 次提交
    • T
      OMAPDSS: fix probing if rfbi device is enabled · 0438ec90
      Tomi Valkeinen 提交于
      After the commit 736e60dd ("OMAPDSS:
      componentize omapdss") the dss core device will wait until all the
      subdevices have been successfully probed. However, we don't have a
      working driver for RFBI, so if RFBI device exists, omapdss will never
      get probed.
      
      All the .dtsi files set RFBI as disabled, except am4372.dtsi. This
      causes omapdss probe to not finish on AM4 devices.
      
      This patch makes omapdss driver skip adding rfbi device as a
      subcomponent, solving the issue.
      
      This should be reverted when we have a working RFBI driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: NFelipe Balbi <balbi@ti.com>
      0438ec90
  9. 17 6月, 2015 15 次提交
    • T
      OMAPDSS: HDMI: wait for framedone when stopping video · a9fad688
      Tomi Valkeinen 提交于
      At the moment when HDMI video output is stopped, we just clear the
      enable bit and return. While it's unclear if this can cause any issues,
      I think it's still better to wait for FRAMEDONE interrupt after clearing
      the enable bit so that we're sure the HDMI IP has finished.
      
      As we don't have any ready-made irq handling for HDMI, and this only
      needs to be done when disabling the HDMI output, this patch implements a
      simple loop with sleep, polling the FRAMEDONE bit.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a9fad688
    • T
      OMAPDSS: HDMI4: fix error handling · 9bba13f0
      Tomi Valkeinen 提交于
      Error handling in hdmi_power_on_full() is not correct, and could leave
      resources unfreed.
      
      Fix this by arranging the error labels correctly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9bba13f0
    • T
      OMAPDSS: DISPC: scaler debug print · e4c5ae7f
      Tomi Valkeinen 提交于
      Improve the DISPC debug print for scaling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e4c5ae7f
    • T
      OMAPDSS: DISPC: do only y decimation on OMAP3 · 7059e3d8
      Tomi Valkeinen 提交于
      The current driver does both x and y decimation on OMAP3 DSS. Testing
      shows that x decimation rarely works, leading to underflows.
      
      The exact reason for this is unclear, as the underflows seem to happen
      even with low pixel clock rates, and I would presume that if the DSS can
      manage a display with 140MHz pixel clock, it could manage x decimation
      with factor 2 with a low pixel clock (~30MHz).
      
      So it is possible that there is a problem somewhere else, in memory
      management, or DSS DMA, or similar. I have not found anything that would
      help this.
      
      So, to fix the downscaling scaling, this patch removes x decimation for
      OMAP3. This will limit some of the more demanding downscaling scenarios,
      but one could argue that using DSS to downscale such a large amount is
      insane in the first place, as the produced image is rather bad quality.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7059e3d8
    • T
      OMAPDSS: DISPC: check if scaling setup failed · 3ce17b48
      Tomi Valkeinen 提交于
      The DISPC's scaling code seems to presume that decimation always
      succeeds, and so we always do find a suitable downscaling setup.
      However, this is not the case, and the algorithm can fail.
      
      When that happens, the code just proceeds with wrong results, causing
      issues later.
      
      Add the necessary checks to bail out if the scaling algorithm failed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3ce17b48
    • T
      OMAPDSS: DISPC: fix 64 bit issue in 5-tap · c582935c
      Tomi Valkeinen 提交于
      The DISPC driver uses 64 bit arithmetic to calculate the required clock
      rate for scaling. The code does not seem to work correctly, and instead
      calculates with 32 bit numbers, giving wrong result.
      
      Fix the code by typecasting values to u64 first, so that the
      calculations do happen in 64 bits.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c582935c
    • T
      OMAPDSS: DISPC: fix row_inc for OMAP3 · f2aee319
      Tomi Valkeinen 提交于
      pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On
      OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the
      line, after the last pixel, whereas on OMAP4+ it is.
      
      The driver currently works for OMAP4+, but does not handle OMAP2/3
      correctly, which leads to tilted image when row_inc is used.
      
      This patch adds a flag to DISPC driver so that the pixel_inc is added
      when required.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f2aee319
    • T
      OMAPDSS: DISPC: add check for scaling limits · ab6b2582
      Tomi Valkeinen 提交于
      On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After
      studying this, I found that sometimes the driver uses three-tap scaling
      with downscaling factor smaller than x0.5. This causes issues, as x0.5
      is the limit for three-tap scaling.
      
      The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for
      five-tap scaling, which allows scaling down to x0.25.
      
      This patch adds checks for both horizontal and vertical scaling. For
      horizontal the HW always uses 5 taps, so the limit is x0.25.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ab6b2582
    • T
      OMAPDSS: DISPC: fix check_horiz_timing_omap3 args · f5a73482
      Tomi Valkeinen 提交于
      After calculating the required decimation for scaling, the dispc driver
      checks once more if the resulting configuration is valid by calling
      check_horiz_timing_omap3().
      
      Earlier calls to this function have correctly used in_width and
      in_height as parameters, but the last call uses width and height. This
      causes the driver to possibly reject scaling that would work.
      
      This patch fixes the parameters.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f5a73482
    • T
      OMAPDSS: DISPC: fix predecimation for YUV modes · c4661b33
      Tomi Valkeinen 提交于
      DISPC needs even input buffer width for YUV modes. The DISPC driver
      doesn't check this at the moment (although omapdrm does), but worse,
      when DISPC driver does x predecimation the result may be uneven. This
      causes sometimes sync losts, underflows, or just visual errors.
      
      This patch makes DISPC driver return an error if the user gives uneven
      input width for a YUV buffer. It also makes the input width even in case
      of predecimation.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c4661b33
    • T
      OMAPDSS: DISPC: work-around for errata i631 · 3397cc6a
      Tomi Valkeinen 提交于
      Errata i631 description:
      
      "When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when
      fetching Chroma sampling."
      
      Workaround:
      
      "If YUV4:2:0-1D burst is required: Set
      DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and
      DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3"
      
      The description is somewhat confusing, but testing has shown that DSS
      fetches extra rows from memory when using NV12 format in 1D mode. If the
      memory after the framebuffer is inaccessible, this leads to OCP errors.
      
      The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only
      need to handle the ROTATION part.
      
      The issue exist on all OMAP4 and OMAP5 based DSS IPs.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3397cc6a
    • T
      OMAPDSS: simplify submodule reg/unreg code · ad4eaef7
      Tomi Valkeinen 提交于
      Now that we are using components in omapdss, there's no need for
      separate handling of dss and dispc driver init. Thus we can move the dss
      and dispc init and unit func pointers to the lists we use for the other
      dss submodules.
      
      We can now also handle errors returned by the registration functions
      properly: if registering a driver fails, we can stop processing and
      return the error.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      ad4eaef7
    • T
      OMAPDSS: componentize omapdss · 736e60dd
      Tomi Valkeinen 提交于
      omapdss kernel module contains drivers for multiple devices, one for
      each DSS submodule. The probing we have at the moment is a mess, and
      doesn't give us proper deferred probing nor ensure that all the devices
      are probed before omapfb/omapdrm start using omapdss.
      
      This patch solves the mess by using the component system for DSS
      submodules.
      
      The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
      venc) are the same: probe & remove functions are changed to bind &
      unbind, and new probe & remove functions are added which call
      component_add/del.
      
      The dss_core driver (dss.c) acts as a component master. Adding and
      matching the components is simple: all dss device's child devices are
      added as components.
      
      However, we do have some dependencies between the drivers. The order in
      which they should be probed is reflected by the list in core.c
      (dss_output_drv_reg_funcs). The drivers are registered in that order,
      which causes the components to be added in that order, which makes the
      components to be bound in that order. This feels a bit fragile, and we
      probably should improve the code to manage binds in random order.
      However, for now, this works fine.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      736e60dd
    • T
      OMAPDSS: reorder uninit calls · 606ae486
      Tomi Valkeinen 提交于
      We have a list of function pointers to dss submodule uninit functions.
      It makes sense to do the uninit in the reverse order to init, but that
      is not currently the case.
      
      This patch reorders the uninit calls to be the reverse of init order.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      606ae486
    • T
      OMAPDSS: remove uses of __init/__exit · ede92695
      Tomi Valkeinen 提交于
      The following patches will add component handling to omapdss, improving
      the handling of deferred probing. However, at the moment we're using
      quite a lot of __inits and __exits in the driver, which prevent normal
      dynamic probing and removal.
      
      This patch removes most of the uses of __init and __exit, so that we can
      register drivers after module init, and so that we can unregister
      drivers even if the module is built-in.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      ede92695