1. 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
  2. 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
  3. 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
  4. 11 May, 2012 29 commits
    • Tomi Valkeinen's avatar
      Merge branch 'omapdss-hdmi-audio' · 037983e6
      Tomi Valkeinen authored
      Merge OMAP DSS HDMI audio patches from Ricardo Neri
      037983e6
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Implement DSS driver interface for audio · f3a97491
      Ricardo Neri authored
      Implement the DSS device driver audio support interface in the HDMI
      panel driver and generic driver. The implementation relies on the
      IP-specific functions that are defined at DSS probe time.
      
      A mixed locking strategy is used. The panel's mutex is used when
      the state of the panel is queried as required by the audio functions.
      The audio state is protected using a spinlock as users of DSS HDMI
      audio functionality might start/stop audio while holding a spinlock.
      The mutex and the spinlock are held and released as needed by each
      individual function to protect the panel state and the audio state.
      
      Although the panel's audio_start functions does not check whether
      the panel is active, the audio _ENABLED state can be reached only
      from audio_enable, which does check the state of the panel. Also,
      if the panel is ever disabled, the audio state will transition
      to _DISABLED. Transitions are always protected by the audio lock.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      f3a97491
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex · b7dea05a
      Ricardo Neri authored
      As the hdmi_lock mutex is inside the hdmi struct, rename to simply
      "lock". This is only a change in the name. There are not changes
      in functionality.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      b7dea05a
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order · 24ccfc55
      Ricardo Neri authored
      As of today, the only know user of the DSS HDMI audio support is
      ASoC. Hence, it makes sense to remap the speaker order to match
      the ALSA speaker order. In the future, a dynamic mapping mechanism
      may be implemented.
      
      Remapping is needed as the HDMI speaker order is FL/FR/LFE/C/RL/RR/
      RLC-FLC/RRC-FLC while the ALSA order is FL/FR/RL/RR/C/LFE/SL/SR.
      Refer to CEA-861 Section 6.6.2 for further details.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      24ccfc55
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Add an audio configuration function · 6ec355d6
      Ricardo Neri authored
      The generic HDMI driver does not need to know about the specific
      settings of a given IP. Hence, it just passes the audio configuration
      and the IP library parses such configuration and sets the IP
      accordingly. This patch introduces an IP-specific audio configuration
      function.
      
      Also, this patch implements the audio config function for OMAP4. The
      DMA, format and core config functions are no longer exposed to the
      generic HDMI driver as they are IP-specific.
      
      The audio configuration function caters for 16-bit through 24-bit
      audio samples with sample rates from 32kHz and up to 192kHz as well
      as up to 8 audio channels.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      6ec355d6
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation · 25a65359
      Ricardo Neri authored
      Add support for more sample rates when calculating N and CTS. This
      covers all the audio sample rates that an HDMI source is allowed
      to transmit according to the HDMI 1.4a specification.
      
      Also, reorganize the logic for the calculation when using deep color.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      25a65359
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Relocate N/CTS calculation · 35547626
      Ricardo Neri authored
      The N and CTS parameters are relevant to all HDMI implementations and
      not specific to a given IP. Hence, the calculation is relocated
      into the generic HDMI driver.
      
      Also, deep color is not queried but it is still considered in the
      calculation of N. This is to be changed when deep color functionality is
      implemented in the driver.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      35547626
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio · c1164ed8
      Ricardo Neri authored
      Utilize a snd_aes_iec958 struct to write the parameters of the IEC-60958
      channel status word into the HDMI IP registers. Hence, the user of the
      driver has full control of what parameters are written in the word.
      
      Also, some of the parameters of the I2S structure have been removed
      as they are actually IEC-60958 parameters.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      c1164ed8
    • Ricardo Neri's avatar
      OMAPDSS: HDMI: Decouple HDMI audio from ASoC · 7e151f7f
      Ricardo Neri authored
      Instead of having OMAPDSS HDMI audio functionality depending on the
      ASoC HDMI audio driver, use a new config option so that
      potential users, including ASoC, may select if needed.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      7e151f7f
    • 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