1. 26 Sep, 2012 31 commits
    • Archit Taneja's avatar
      OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode · 8ba85306
      Archit Taneja authored
      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: default avatarArchit Taneja <archit@ti.com>
      8ba85306
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Don't pass channel out when configuring overlays · 3e8a6ff2
      Archit Taneja authored
      dispc_ovl_setup_common() is to be used by both overlays and writeback. We pass
      channel out to figure out what manager the overlay is connected to, to determine
      the pixel clock rate. This is used to decide the scaling limitations for that
      overlay.
      
      writeback doesn't have a channel out, it has a channel in field which tells
      where writeback gets its input from. These are 2 different fields, and this
      prevents us reusing the overlay configuration code for writeback.
      
      To overcome this, we now pass omap_plane to overlay related functions rather
      than passing channel out. We create helper functions which can derive pclk/lclk
      from the omap_plane id.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      3e8a6ff2
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common · 84a880fd
      Archit Taneja authored
      Add a new static function called dispc_ovl_setup_common(). This function is used by
      dispc_ovl_setup() to configure the overlay registers. This split is done so that
      dispc_wb_setup() can reuse overlay register configuration related code.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      84a880fd
    • Archit Taneja's avatar
      OMAPDSS: OVERLAY: Add position and replication as overlay caps · d79db853
      Archit Taneja authored
      Add position and replication as overlay caps, and pass overlay caps as an
      argument to the corresponding functions. Adding position and replication to
      overlay caps seems a bit unnecessary, but it allows us to use the
      corresponding functions for writeback too.
      
      These caps will be set for all overlays, but not for writeback. This is done
      so writeback can reuse dispc_ovl_setup() to the maximum.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      d79db853
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions · 5b54ed3e
      Archit Taneja authored
      Currently, the functions below take the omap_plane parameter and derive the
      overlay caps within them. Pass the overlay caps as a parameter to the function
      to allow these to be used by writeback too.
      
      - dispc_ovl_set_zorder()
      - dispc_ovl_set_pre_mult_alpha()
      - dispc_ovl_setup_global_alpha()
      - dispc_ovl_calc_scaling()
      - dispc_ovl_setup()
      
      These functions will be used for writeback later, and the caps will help in
      deciding if they are to be used for writeback or not. This allows reuse of
      overlay caps for writeback.
      
      Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
      something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
      overlay caps for overlay like features of writeback too.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5b54ed3e
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes · 78b687fc
      Archit Taneja authored
      The DISPC pipeline register names in the TRM for setting the buffer size and
      the output size are a bit misleading, for example, there are different register
      names for setting the buffer size for VID and GFX pipes. Things get more
      confusing when considering writeback pipeline.
      
      Rename the functions so that they tell whether they are configuring the input
      to the scalar or the output. These will be extended later to support writeback
      registers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      78b687fc
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup() · 8eeb7019
      Archit Taneja authored
      The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
      DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
      was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
      this and const qualifier to the omap_overlay_info argument.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      8eeb7019
    • Archit Taneja's avatar
      OMAPDSS: Remove old way of setting manager and device links · 3c2995ac
      Archit Taneja authored
      Now that an omap_dss_output can be used to link between managers and devices, we
      can remove the old way of setting manager and device links. This involves
      removing the device and manager pointers from omap_overlay_manager and
      omap_dss_device respectively, and removing the set_device/unset_device ops from
      omap_overlay_manager.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      3c2995ac
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disable · 0f0e4e3c
      Archit Taneja authored
      An overlay isn't allowed to be enabled/disabled if it isn't connected to an
      omap_dss_device. This requirement isn't needed any more. An overlay can be
      enabled/disabled as long as it has an output connected to it. The output may
      not be connected to a device, but we can be assured that the connected
      manager's output is in use by an output interface.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      0f0e4e3c
    • Archit Taneja's avatar
      OMAPDSS: OVERLAY/MANAGER: Get device via output · 80d81d64
      Archit Taneja authored
      A manager is not connected to a device directly any more. It first connects
      to an output, and then to the display. Update overlay and manager get_device ops
      to return the device via the connected output.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      80d81d64
    • Archit Taneja's avatar
      OMAPDSS: MANAGER: Update display sysfs store · 947b2254
      Archit Taneja authored
      The display sysfs attribute's store function needs to be changed with the
      introduction of outputs.
      
      The DSS driver ensures that there is one display per output, and that a
      registered omap_dss_device will have an output connected to it. The display
      sysfs store function unsets the current output connected to the manager, and
      sets it with the output connected to the new display. If the new display doesn't
      have an output for some reason, we just bail out. The function doesn't set/unset
      output->device links. These remain the same as when the omap_dss_device was
      registered.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      947b2254
    • Archit Taneja's avatar
      OMAPFB: Change dssdev->manager references · 952cbaaa
      Archit Taneja authored
      To retrieve the manager pointer via a device, we need to now access it via the
      output to which the device is connected. Make this change in omapfb_ioctl()
      where the WAITFORVSYNC ioctl tries to access the manager's device.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      952cbaaa
    • Archit Taneja's avatar
      OMAPDSS: HDMI: Replace dssdev->manager with dssdev->output->manager references · cea87b92
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the HDMI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      cea87b92
    • Archit Taneja's avatar
      OMAPDSS: VENC: Replace dssdev->manager with dssdev->output->manager references · 8f1f736c
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the VENC output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      8f1f736c
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Replace dssdev->manager with dssdev->output->manager references · 1db39c0a
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the RFBI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      1db39c0a
    • Archit Taneja's avatar
      OMAPDSS: SDI: Replace dssdev->manager with dssdev->output->manager references · 7d6069e5
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the SDI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      7d6069e5
    • Archit Taneja's avatar
      OMAPDSS: DSI: Replace dssdev->manager with dssdev->output->manager references · eea8340a
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the DSI output, check whether the output entity connected to
      display is not NULL.
      
      In dsi_init_display(), the display won't be connected to the DSI output yet,
      that happens later in dss_recheck_connections() in the panel driver's probe. Get
      the dsidev platform device pointer using the DSI moudle number provided in the
      omap_dss_device struct.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      eea8340a
    • Archit Taneja's avatar
      OMAPDSS: DSI: Remove dsi_pdev_map global struct · 400e65d1
      Archit Taneja authored
      dsi_pdev_map is a struct visible globally in the DSI driver to get the platform
      device pointer of the DSI device corresponding to it's module ID. This was
      required because there was no clean way to derive the platform device from
      the DSI module instance number or from the connected panel.
      
      With the new output entity, it is possible to retrieve the platform device
      pointer if the omap_dss_output pointer is available. Modify the functions
      dsi_get_dsidev_from_dssdev() dsi_get_dsidev_from_id() so that they use output
      instead of dsi_pdev_map to retrieve the dsi platform device pointer.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      400e65d1
    • Archit Taneja's avatar
      OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager references · 5d512fcd
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the DPI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5d512fcd
    • Archit Taneja's avatar
      OMAPDSS: Create links between managers, outputs and devices · 32248276
      Archit Taneja authored
      Links between DSS entities are made in dss_init_connections() when a panel
      device is registered, and are removed in dss_uninit_connections() when the
      device is unregistered. Modify these functions to incorporate the addition of
      outputs.
      
      The fields in omap_dss_device struct gives information on which output and
      manager to connect to. The desired manager and output pointers are retrieved and
      prepared to form the desired links. The output is linked to the device, and then
      the manager to the output.
      
      A helper function omapdss_get_output_from_device() is created to retrieve the
      output from the display by checking it's type, and the module id in case of DSI.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      32248276
    • Archit Taneja's avatar
      OMAPDRM: Remove manager->device references · 23e2aa64
      Archit Taneja authored
      With the introduction of output entities, managers will now connect to outputs.
      Use the helper op for managers named get_device. This will abstract away the
      information on how to get the device from an overlay manager.
      
      Using the helper function will reduce the number of pointer dereferences a user
      of OMAPDSS needs to do and reduce risk of a NULL dereference.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      23e2aa64
    • Archit Taneja's avatar
      OMAPFB: remove manager->device references · 4249e61e
      Archit Taneja authored
      With the introduction of output entities, managers will now connect to outputs.
      Use the helper op for overlays named get_device. This will abstract away the
      information on how to get the device from an overlay.
      
      Using the helper function will reduce the number of pointer dereferences a user
      of OMAPDSS needs to do and reduce risk of a NULL dereference.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      4249e61e
    • Archit Taneja's avatar
      OMAP_VOUT: Remove manager->device references · d629f03f
      Archit Taneja authored
      With the introduction of output entities, managers will now connect to outputs.
      Use the helper op for overlays named get_device. This will abstract away the
      information on how to get the omap_dss_device pointer from an overlay.
      
      Using the helper function will reduce the number of pointer dereferences a user
      of OMAPDSS needs to do and reduce risk of a NULL dereference.
      
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      d629f03f
    • Archit Taneja's avatar
      OMAPDSS: Remove manager->device references · 794bc4ee
      Archit Taneja authored
      With the introduction of output entities, managers will now connect to outputs.
      Create helper ops for overlays and managers named get_device. This will abstract
      away the information on how to get the device from an overlay or an overlay
      manager. The get_device ops currently retrieve the output via a
      ovl->manager->device reference. This will be later replaced by
      ovl->manager->output->device references.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      794bc4ee
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager · 97f01b3a
      Archit Taneja authored
      Add set_output/unset_output ops for overlay managers, these form links between
      managers and outputs. Create a function in dss features which tell all the
      output instances that connect to a manager, use it when a manager tries to set
      an output. Add a constraint of not unsetting an output when the manager is
      enabled.
      
      Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
      now to not break things. Keep the dss feature function get_supported_displays
      as it's used in some places. These will be removed later.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      97f01b3a
    • Archit Taneja's avatar
      OMAPDSS: output: Add set/unset device ops for omap_dss_output · 6d71b923
      Archit Taneja authored
      An output entity represented by the struct omap_dss_output connects to a
      omap_dss_device entity. Add functions to set or unset an output's device. This
      is similar to how managers and devices were connected previously. An output can
      connect to a device without being connected to a manager. However, the output
      needs to eventually connect to a manager so that the connected panel can be
      enabled.
      
      Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
      breaking things. This will be removed later when outputs are supported
      completely.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6d71b923
    • Archit Taneja's avatar
      OMAPDSS: outputs: Create and register output instances · 81b87f51
      Archit Taneja authored
      Add output structs to output driver's private data. Register output instances by
      having an init function in the probes of the platform device drivers for
      different outputs. The *_init_output for each output registers the output and
      fill up the output's plaform device, type and id fields. The *_uninit_output
      functions unregister the output.
      
      In the probe of each interface driver, the output entities are initialized
      before the *_probe_pdata() functions intentionally. This is done to ensure that
      the output entity is prepared before the panels connected to the output are
      registered. We need the output entities to be ready because OMAPDSS will try
      to make connections between overlays, managers, outputs and devices during the
      panel's probe.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      81b87f51
    • Archit Taneja's avatar
      OMAPDSS: outputs: Create a new entity called outputs · 484dc404
      Archit Taneja authored
      The current OMAPDSS design contains 3 software entities: Overlays, Managers and
      Devices. These map to pipelines, overlay managers and the panels respectively in
      hardware. One or more overlays connect to a manager to represent a composition,
      the manager connects to a device(generally a display) to display the content.
      
      The part of DSS hardware which isn't represented by any of the above entities
      are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
      HDMI, VENC and so on. Currently, an overlay manager directly connects to the
      display, and the output to which it is actually connected is ignored. The panel
      driver of the display is responsible of calling output specific functions to
      configure the output.
      
      Adding outputs as a new software entity gives us the following benefits:
      
      - Have exact information on the possible connections between managers and
        outputs: A manager can't connect to each and every output, there only limited
        hardware links between a manager's video port and some of the outputs.
      
      - Remove hacks related to connecting managers and devices: Currently, default
        links between managers and devices are set in a not so clean way. Matching is
        done via comparing the device type, and the display types supported by the
        manager. This isn't sufficient to establish all the possible links between
        managers, outputs and devices in hardware.
      
      - Make panel drivers more generic: The DSS panel drivers currently call
        interface/output specific functions to configure the hardware IP. When making
        these calls, the driver isn't actually aware of the underlying output. The
        output driver extracts information from the panel's omap_dss_device pointer
        to figure out which interface it is connected to, and then configures the
        corresponding output block. An example of this is when a DSI panel calls
        dsi functions, the dsi driver figures out whether the panel is connected
        to DSI1 or DSI2. This isn't correct, and having output as entities will
        give the panel driver the exact information on which output to configure.
        Having outputs also gives the opportunity to make panel drivers generic
        across different platforms/SoCs, this is achieved as omap specific output
        calls can be replaced by ops of a particular output type.
      
      - Have more complex connections between managers, outputs and devices: OMAPDSS
        currently doesn't support use cases like 2 outputs connect to a single
        device. This can be achieved by extending properties of outputs to connect to
        more managers or devices.
      
      - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
        as compared to overlays, managers or devices.
      
      Add a new struct to represent outputs. An output struct holds pointers to the
      manager and device structs to which it is connected. Add functions which can
      register/unregister an output, or look for one. Create an enum which represent
      each output instance.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      484dc404
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions · fc22a843
      Archit Taneja authored
      The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
      is an enabled display connected to the manager before trying to see the state of
      the GO bit.
      
      The checks related to the display can be replaced by checking the state of the
      manager, i.e, whether the manager is enabled or not. This makes more sense than
      checking with the connected display as the GO bit behaviour is more connected
      with the manager state rather than the display state. A GO bit can only be set
      if the manager is enabled. If a manager isn't enabled, we can safely assume that
      the GO bit is not set.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      fc22a843
    • Archit Taneja's avatar
      OMAPDSS: DSI: Pass dsi platform device wherever possible · 9e7e9372
      Archit Taneja authored
      Many of the DSI functions receive the connected panel's omap_dss_device pointer
      as an argument. The platform device pointer is then derived via omap_dss_device
      pointers.
      
      Most of these functions don't really require omap_dss_device pointer anymore
      since we now keep copies of parameters in the driver data which were previously
      available only via omap_dss_device. Replace the arguments with platform device
      pointers for such functions.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      9e7e9372
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: fix tlpx_half reg field length · e84dc1cc
      Tomi Valkeinen authored
      tlpx_half bit field in DSI_DSIPHY_CFG1 is [20,16], not [22,16] as
      accessed in the code currently. Fix this.
      
      The bug should not have caused any problems on OMAP3/4, as the bits
      21,22 are unused. They are used on OMAP5, though.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e84dc1cc
  2. 25 Sep, 2012 4 commits
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Add predecimation limit for TILER based rotations · d557a9cf
      Chandrabhanu Mahapatra authored
      In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can
      be skipped as per the respective TRMs. The MBlockStride OCP signal, which is
      sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode TILER
      supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 or
      more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors.
      So, maximum vertical predecimation achievable is 2.
      Signed-off-by: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      d557a9cf
    • Tomi Valkeinen's avatar
      Merge OMAP5 DSS changes to omapdss · 406f7b8b
      Tomi Valkeinen authored
      This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI
      and DSI.
      
      * omap5-dss:
        OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
        OMAPDSS: DSI: Add code to disable PHY DCC
        OMAPDSS: DSI: Add new linebuffer size for OMAP5
        OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
        OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
        OMAPDSS: Add support for DPI source selection
        OMAPDSS: move dss feats to the end of dss.c
        OMAPDSS: Add basic omap5 features to dss and dispc
        OMAPDSS: DSI: improve DSI clock calcs for DISPC
      406f7b8b
    • Tomi Valkeinen's avatar
      Merge omapdss single-dssdev series · c0ca7c38
      Tomi Valkeinen authored
      This series contains patches that change how omapdss's panel devices
      (omap_dss_device) are initialized and registered. There are two patches that
      change behaviour, the rest are just cleanups:
      
      The patch "omap_dss_register_device() doesn't take display index" affects the
      number for the "displayX" sysfs files. This hopefully doesn't affect the
      userspace, as the number has never been a clear indication of what the
      particular display is.
      
      The patch "register only one display device per output" affects how panel
      devices are created. Currently we support multiple panels per output, i.e. you
      could have DVI and an LCD displays using the same DPI output, as long as the
      DVI and LCD are not used at the same time.
      
      This patch changes the omapdss driver to only register one display device per
      output. If there are multiple displays for the output, either the first one is
      picked or, if def_display has been defined in kernel parameters and the
      def_display is one of the displays for this output, the def_display is picked.
      See the patch for more information.
      
        OMAPDSS: alloc dssdevs dynamically
        OMAPDSS: cleanup dss_recheck_connections further
        OMAPDSS: cleanup dss_recheck_connections
        OMAPDSS: handle errors in dss_init_device
        OMAPDSS: explicitely initialize dssdev->channel for new displays
        OMAPDSS: register only one display device per output
        OMAPDSS: Add dss_get_default_display_name()
        OMAPDSS: omap_dss_register_device() doesn't take display index
      c0ca7c38
    • Raphaël Assénat's avatar
      OMAPDSS: Do not require a VDDS_DSI regulator on AM35xx · 524d9f48
      Raphaël Assénat authored
      On our AM3505 based board, dpi.c complains that there is no VDDS_DSI
      regulator and the framebuffer cannot be enabled. However, this check
      does not seem to apply to AM3505/17 chips.
      
      This patch adds new features list for AM35xxx, which is the same as for
      OMAP3 except the VDDS_DSI is removed.
      Signed-off-by: default avatarRaphael Assenat <raph@8d.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      524d9f48
  3. 24 Sep, 2012 5 commits