1. 11 May, 2012 31 commits
    • Axel Castaneda Gonzalez's avatar
      OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop · 3df9fb5c
      Axel Castaneda Gonzalez authored
      Decouple the enable/disable operation of the HDMI audio wrapper from
      audio start/stop. Otherwise, an audio FIFO underflow may occur. The
      audio wrapper enablement must be done after configuration and
      before audio playback is started.
      Signed-off-by: default avatarAxel Castaneda Gonzalez <x0055901@ti.com>
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      3df9fb5c
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings · 7c92af16
      Ricardo Neri authored
      According to the most up-to-date documentation from Texas Instruments,
      the configuration of High Bitrate Audio is not possible. Also, it is
      not possible to set polarity of the I2S Word Select signal. This patch
      removes the invalid settings.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      7c92af16
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums · 199e7fd6
      Ricardo Neri authored
      Instead of having its own definitions for CEA-861 and IEC-60958, the HDMI
      driver should use those provided by ALSA. This patch removes the definitions
      that are already provided by ALSA.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      199e7fd6
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Remove ASoC codec · 7c3291f0
      Ricardo Neri authored
      Remove the ASoC OMAP HDMI audio codec. The goal of removing the codec
      is to, in subsequent patches, give way to the implementation of the HDMI
      audio support using the DSS device driver audio interface. This
      approach will expose the HDMI audio functionality to any interested entity.
      
      In a separate patch, ASoC will use this new approach to expose HDMI audio
      to ALSA.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      7c3291f0
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Split video_enable into video_enable/disable · c0456be3
      Ricardo Neri authored
      To improve readability, split the video_enable HDMI IP operation
      into two separate functions for enabling and disabling video.
      The video_enable function is also modified to return an error value.
      
      While there, update these operations for the OMAP4 IP accordingly.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      c0456be3
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Split audio_enable into audio_enable/disable · 027bdc85
      Ricardo Neri authored
      To improve readability, split the audio_enable HDMI IP operation
      into two separate functions for enabling and disabling audio.
      The audio_enable function is also modified to return an error value.
      
      While there, update these operations for the OMAP4 IP accordingly.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      027bdc85
    • Ricardo Neri's avatar
      OMAPDSS: Provide an interface for audio support · 9c0b8420
      Ricardo Neri authored
      There exist several display technologies and standards that support audio as
      well. Hence, it is relevant to update the DSS device driver to provide an audio
      interface that may be used by an audio driver or any other driver interested in
      the functionality.
      
      The audio_enable function is intended to prepare the relevant
      IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
      some IP, enabling companion chips, etc). It is intended to be called before
      audio_start. The audio_disable function performs the reverse operation and is
      intended to be called after audio_stop.
      
      While a given DSS device driver may support audio, it is possible that for
      certain configurations audio is not supported (e.g., an HDMI display using a
      VESA video timing). The audio_supported function is intended to query whether
      the current configuration of the display supports audio.
      
      The audio_config function is intended to configure all the relevant audio
      parameters of the display. In order to make the function independent of any
      specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
      is to contain all the required parameters for audio configuration. At the
      moment, such structure contains pointers to IEC-60958 channel status word and
      CEA-861 audio infoframe structures. This should be enough to support HDMI and
      DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
      structure may be extended in the future if required.
      
      The audio_enable/disable, audio_config and audio_supported functions could be
      implemented as functions that may sleep. Hence, they should not be called
      while holding a spinlock or a readlock.
      
      The audio_start/audio_stop function is intended to effectively start/stop audio
      playback after the configuration has taken place. These functions are designed
      to be used in an atomic context. Hence, audio_start should return quickly and be
      called only after all the needed resources for audio playback (audio FIFOs,
      DMA channels, companion chips, etc) have been enabled to begin data transfers.
      audio_stop is designed to only stop the audio transfers. The resources used
      for playback are released using audio_disable.
      
      A new enum omap_dss_audio_state is introduced to help the implementations of
      the interface to keep track of the audio state. The initial state is _DISABLED;
      then, the state transitions to _CONFIGURED, and then, when it is ready to
      play audio, to _ENABLED. The state _PLAYING is used when the audio is being
      rendered.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      9c0b8420
    • Tomi Valkeinen's avatar
      Merge branch 'dss-devtree-cleanup' · 38137c8f
      Tomi Valkeinen authored
      Merge OMAP DSS cleanups that restructure the omapdss driver to facilitate
      implementing device tree support in the future.
      38137c8f
    • Russ Dill's avatar
      OMAPDSS: TFP410: use gpio_set_value_cansleep · af461d64
      Russ Dill authored
      The Beagleboard xM gpio used for TFP410 powerdown is connected through
      an I2C attached chip which means setting the GPIO can sleep. Code that
      calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
      Signed-off-by: default avatarRuss Dill <Russ.Dill@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      af461d64
    • Tomi Valkeinen's avatar
      OMAPDSS: separate pdata based initialization · 38f3daf6
      Tomi Valkeinen authored
      Move the platform-data based display device initialization into a
      separate function, so that we may later add of-based initialization.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      38f3daf6
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: improve DSI module id handling · 11ee9606
      Tomi Valkeinen authored
      We currently use the id of the dsi platform device (dsidev->id) as the
      DSI hardware module ID. This works because we assign the ID manually in
      arch/arm/mach-omap2/display.c at boot time.
      
      However, with device tree the platform device IDs are automatically
      assigned to an arbitrary number, and we can't use it.
      
      Instead of using dsidev->id during operation, this patch stores the
      value of dsidev->id to a private field of the dsi driver at probe(). The
      future device tree code can thus set the private field with some other
      way.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      11ee9606
    • Tomi Valkeinen's avatar
      OMAPDSS: init omap_dss_devices internally · 9d8232a7
      Tomi Valkeinen authored
      Now that each output driver creates their own display devices, the
      output drivers can also initialize those devices.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      9d8232a7
    • Tomi Valkeinen's avatar
      OMAPDSS: interface drivers register their panel devices · 35deca3d
      Tomi Valkeinen authored
      Currently the higher level omapdss platform driver gets the list of
      displays in its platform data, and uses that list to create the
      omap_dss_device for each display.
      
      With DT, the logical way to do the above is to list the displays under
      each individual output, i.e. we'd have "dpi" node, under which we would
      have the display that uses DPI. In other words, each output driver
      handles the displays that use that particular output.
      
      To make the current code ready for DT, this patch modifies the output
      drivers so that each of them creates the display devices which use that
      output. However, instead of changing the platform data to suit this
      method, each output driver is passed the full list of displays, and the
      drivers pick the displays that are meant for them. This allows us to
      keep the old platform data, and thus we avoid the need to change the
      board files.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      35deca3d
    • Tomi Valkeinen's avatar
      OMAPDSS: change default_device handling · c018c673
      Tomi Valkeinen authored
      We currently have a two ways to set a "default panel device" for dss, to
      which the overlays are connected when the omapdss driver is loaded:
      
      - in textual format (name of the display) as cmdline parameter
      - as a pointer to the panel device from board file via pdata
      
      The current code handles this in a bit too complex way by using both of
      the above methods during runtime. However, with DT we don't have pdata
      anymore, so the code handling the second case won't work anymore. The
      current code has also the problem that it modifies the platform_data.
      
      This patch simplifies the code a bit by using the pointer method only
      inside the probe function, and stores the name of the panel device. This
      way we only need to handle the textual format during operation and also
      avoid modifying the platform_data.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      c018c673
    • Tomi Valkeinen's avatar
      OMAPFB: add __init & __exit · d64f14e1
      Tomi Valkeinen authored
      Change omapfb to use platform_driver_probe and add __init & __exit.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      d64f14e1
    • Tomi Valkeinen's avatar
      OMAPDSS: add __init & __exit · 6e7e8f06
      Tomi Valkeinen authored
      Now that we are using platform_driver_probe() we can add __inits and
      __exits all around.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6e7e8f06
    • Tomi Valkeinen's avatar
      OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi · 61055d4b
      Tomi Valkeinen authored
      Now that the core.c doesn't fail if output driver's init fails, we can
      change the uses of platform_driver_register to platform_driver_probe.
      This will allow us to use __init in the following patches.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      61055d4b
    • Tomi Valkeinen's avatar
      OMAPDSS: move the creation of debugfs files · e40402cf
      Tomi Valkeinen authored
      Instead of having an ugly #ifdef mess in the core.c for creating debugfs
      files, add a dss_debugfs_create_file() function that the dss drivers
      can use to create the debugfs files.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e40402cf
    • Tomi Valkeinen's avatar
      OMAPDSS: handle output-driver reg/unreg more dynamically · 461395c4
      Tomi Valkeinen authored
      Initialize and uninitialize the output drivers by using arrays of
      pointers to the init/uninit functions. This simplifies the code
      slightly.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      461395c4
    • Tomi Valkeinen's avatar
      OMAPDSS: remove uses of dss_runtime_get/put · 852f0838
      Tomi Valkeinen authored
      Now that the omapdss_core device is the parent for all other dss
      devices, we don't need to use the dss_runtime_get/put anymore. Instead,
      enabling omapdss_core will happen automatically when a child device is
      enabled.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      852f0838
    • Tomi Valkeinen's avatar
      OMAPDSS: create DPI & SDI drivers · a57dd4fe
      Tomi Valkeinen authored
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies the dpi.c and sdi.c to create drivers for the
      platform devices.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      a57dd4fe
    • Tomi Valkeinen's avatar
      OMAPDSS: create DPI & SDI devices · 53f576a8
      Tomi Valkeinen authored
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies arch/arm/mach-omap2/display.c to create platform
      devices for DPI and SDI, and later patches will implement driver for
      them.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      53f576a8
    • Tomi Valkeinen's avatar
      OMAPDSS: create custom pdevs for DSS omap_devices · 966eaed0
      Tomi Valkeinen authored
      Instead of using omap_device_build() to create the omap_devices for DSS
      hwmods, create them with a custom function. This will allow us to create
      a parent-child hierarchy for the devices so that the omapdss_core device
      is parent for the rest of the dss hwmod devices.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      966eaed0
    • Tomi Valkeinen's avatar
      OMAPDSS: use platform_driver_probe for core/dispc/dss · 11436e1d
      Tomi Valkeinen authored
      The platform devices for omapdss, dss and dispc drivers are always
      present, so we can use platform_driver_probe instead of
      platform_driver_register.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      11436e1d
    • Tomi Valkeinen's avatar
      OMAPDSS: remove return from platform_driver_unreg · 04c742c3
      Tomi Valkeinen authored
      For unknown reasons we seem to have a return in each of the omapdss's
      uninit functions, which is a void function.
      
      Remove the returns.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      04c742c3
    • Tomi Valkeinen's avatar
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      Tomi Valkeinen authored
      The omapdss pdata handling is a mess. This is more evident when trying
      to use device tree for DSS, as we don't have platform data anymore in
      that case. This patch cleans the pdata handling by:
      
      - Remove struct omap_display_platform_data. It was used just as a
        wrapper for struct omap_dss_board_info.
      - Pass the platform data only to omapdss device. The drivers for omap
        dss hwmods do not need the platform data. This should also work better
        for DT, as we can create omapdss device programmatically in generic omap
        boot code, and thus we can pass the pdata to it.
      - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
        that the dss hwmod drivers can call.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id · e23d83b0
      Tomi Valkeinen authored
      The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
      instance. However, there were a few places where dsidev->id was used
      instead of the function. Fix those places to use the function.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e23d83b0
    • Tomi Valkeinen's avatar
      OMAPDSS: TFP410: pdata rewrite · 958f2717
      Tomi Valkeinen authored
      To ease device tree adaptation in the future, rewrite TFP410 platform
      data handling to be done inside probe(), so that probe() is the only
      place where we need to handle the DT/pdata choice.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      958f2717
    • Tomi Valkeinen's avatar
      OMAPFB: fix parsing of vram parameter · 3a028bb9
      Tomi Valkeinen authored
      omapfb_parse_vram_param()'s check for end pointer returned from
      simple_strtoul() is wrong, causing the code to bug if the second or
      later vram parameters are non-parseable, for example
      "omapfb.vram=0:2M,:5M".
      
      However, even in that case the code will most likely bail out with
      -EINVAL in the following checks, so the bug is probably not a fatal one.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarHein Tibosch <hein_tibosch@yahoo.es>
      3a028bb9
    • Grazvydas Ignotas's avatar
      OMAPDSS: OMAPFB: always allow to configure overlay · b3e68d30
      Grazvydas Ignotas authored
      Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
      Instead of failing, allow it to configure the first overlay as if there
      was only one overlay, the remaining ones will have to be configured in
      other ways (sysfs).
      
      This allows overlay-controlling programs (like video players) to function
      properly when framebuffer is cloned to another display (like TV).
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b3e68d30
    • Grazvydas Ignotas's avatar
      OMAPDSS: VENC: allow switching venc output type at runtime · 0aca3c63
      Grazvydas Ignotas authored
      VENC output type (composite/svideo) doesn't have to be fixed by board
      wiring, it is possible to also provide composite signal through svideo
      luminance connector (software enabled), which is what pandora does.
      
      Having to recompile the kernel for users who have TV connector types
      that don't match default board setting is very inconvenient, especially
      for users of a consumer device, so add support for switching VENC output
      type at runtime over a new sysfs file output_type.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0aca3c63
  2. 10 May, 2012 1 commit
    • Tomi Valkeinen's avatar
      Merge branch 'for-l-o-3.5' · 9b71fb5c
      Tomi Valkeinen authored
      Conflicts:
      	drivers/video/omap2/displays/panel-taal.c
      
      Merge OMAP DSS related board file changes. The branch will also be
      merged through linux-omap tree to solve conflicts.
      9b71fb5c
  3. 09 May, 2012 8 commits
    • Tomi Valkeinen's avatar
      Merge branch 'archit/set-timing-work' · 1dfafbc6
      Tomi Valkeinen authored
      An overlay manager's timings (the manager size, and blanking parameters
      if an LCD manager) are DISPC shadow registers, and they should hence
      follow the correct programming model.
      
      This series makes the video timings an extra_info parameter in manager's
      private data. The interface drivers now apply the timings instead of
      directly writing to registers.
      
      This change also prevents the need to use display resolution for overlay
      checks, hence making some of the APPLY functions less dependent on the
      display. Some DISPC functions that needed display width can also use
      these privately stored timings.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1dfafbc6
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() · 81ab95b7
      Archit Taneja authored
      The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
      function dispc_mgr_get_device() to get the omap_dss_device pointer to which
      the manager is connected, the width of the panel is derived from that.
      
      The manager's timing is stored in it's private data in APPLY. This contains
      the latest timings applied to the manager. Pass these timings to
      dispc_ovl_setup() and use them in the above functions. Remove the function
      dispc_mgr_get_device() as it isn't used any more.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      81ab95b7
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() · 3fa03ba8
      Archit Taneja authored
      The pixel clock rate for the TV manager is calculated by checking the device
      type connected to the manager, and then requesting the VENC/HDMI interface for
      the pixel clock rate.
      
      Remove the use of omap_dss_device pointer from here by checking which interface
      generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      3fa03ba8
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer · b3d795ab
      Archit Taneja authored
      The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
      the pointer variable declaration and it's assignment.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      b3d795ab
    • Archit Taneja's avatar
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja authored
      The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
      set of timings. If the panel is disabled, they do not disable and re-enable
      the interface. Currently, the manager timings are applied in hdmi_power_on()
      and dpi_set_mode() respectively, 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 panel is disabled. Eventually, there should be
      one common place where the timings are applied independent of the state of the
      panel.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      fcc36619
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove display dependency from overlay and manager checks · 228b2134
      Archit Taneja authored
      In order to check the validity of overlay and manager info, there was a need to
      use the omap_dss_device struct to get the panel resolution. The manager's
      private data in APPLY now contains the manager timings. Hence, we don't need to
      rely on the display resolution any more.
      
      Pass the manager's timings in private data to dss_mgr_check(). Remove the need
      to pass omap_dss_device structs in the functions which check for the validity
      of overlay and manager parameters.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      228b2134
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Don't check manager settings if it is disabled · 5dd747e8
      Archit Taneja authored
      If a manager is disabled, there is no guarantee at any point in time that all
      it's parameters are configured. There is always a chance that some more
      parameters are yet to be configured by a user of DSS, or by DSS itself.
      
      However, when the manager is enabled, we can be certain that all the parameters
      have been configured, as we can't enable a manager with an incomplete
      configuration. Therefore, if a manager is disabled, don't check for the validity
      of it's parameters or the parameters of the overlays connected to it. Only check
      once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5dd747e8
    • Archit Taneja's avatar
      OMAPDSS: MANAGER: Create a function to check manager timings · b917fa39
      Archit Taneja authored
      Create a function dss_mgr_check_timings() which wraps around the function
      dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
      from interface drivers.
      
      dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
      takes the timings maintained in the omap_dss_device struct. This would be later
      replaced by the timings stored in the manager's private data.
      
      Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
      omap_video_timings pointer since these functions just check the timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      b917fa39