1. 26 10月, 2012 1 次提交
  2. 26 9月, 2012 2 次提交
    • A
      OMAPDSS: HDMI: Replace dssdev->manager with dssdev->output->manager references · cea87b92
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      cea87b92
    • A
      OMAPDSS: outputs: Create and register output instances · 81b87f51
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      81b87f51
  3. 18 9月, 2012 4 次提交
    • T
      OMAPDSS: alloc dssdevs dynamically · 5274484b
      Tomi Valkeinen 提交于
      We currently create omap_dss_devices statically in board files, and use
      those devices directly in the omapdss driver. This model prevents us
      from having the platform data (which the dssdevs in board files
      practically are) as read-only, and it's also different than what we will
      use with device tree.
      
      This patch changes the model to be in line with DT model: we allocate
      the dssdevs dynamically, and initialize them according to the data in
      the board file's dssdev (basically we memcopy the dssdev fields).
      
      The allocation and registration is done in the following steps in the
      output drivers:
      
      - Use dss_alloc_and_init_device to allocate and initialize the device.
        The function uses kalloc and device_initialize to accomplish this.
      - Call dss_copy_device_pdata to copy the data from the board file's
        dssdev
      - Use dss_add_device to register the device.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5274484b
    • T
      OMAPDSS: explicitely initialize dssdev->channel for new displays · bcb226a9
      Tomi Valkeinen 提交于
      HDMI and VENC outputs always use the DIGIT output from DISPC. The dssdev
      struct contains "channel" field which is used to specify the DISPC
      output for the display, but this was not used for HDMI and VENC.
      
      This patch fills the channel field explicitely for HDMI and VENC
      displays so that we can always rely on the channel field.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bcb226a9
    • T
      OMAPDSS: register only one display device per output · 1521653c
      Tomi Valkeinen 提交于
      We have boards with multiple panel devices connected to the same
      physical output, of which only one panel can be enabled at one time.
      Examples of these are Overo, where you can use different daughter boards
      that have different LCDs, and 3430SDP which has an LCD and a DVI output
      and a physical switch to select the active display.
      
      These are supported by omapdss so that we add all the possible display
      devices at probe, but the displays are inactive until somebody enables
      one. At this point the panel driver starts using the DSS, thus reserving
      the physcal resource and excluding the other panels.
      
      This is problematic:
      - Panel drivers can't allocate their resources properly at probe(),
        because the resources can be shared with other panels. Thus they can
        be only reserved at enable time.
      - Managing this in omapdss is confusing. It's not natural to have
        child devices, which may not even exist (for example, a daughterboard
        that is not connected).
      
      Only some boards have multiple displays per output, and of those, only
      very few have possibility of switching the display during runtime.
      Because of the above points:
      - We don't want to make omapdss and all the panel drivers more complex
        just because some boards have complex setups.
      - Only few boards support runtime switching, and afaik even then it's
        not required. So we don't need to support runtime switching.
      
      Thus we'll change to a model where we will have only one display device
      per output and this cannot be (currently) changed at runtime. We'll
      still have the possibility to select the display from multiple options
      during boot with the default display option.
      
      This patch accomplishes the above by changing how the output drivers
      register the display device. Instead of registering all the devices
      given from the board file, we'll only register one. If the default
      display option is set, the output driver selects that display from its
      displays. If the default display is not set, or the default display is
      not one of the output's displays, the output driver selects the first
      display.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      1521653c
    • T
      OMAPDSS: omap_dss_register_device() doesn't take display index · 8768a52f
      Tomi Valkeinen 提交于
      We used to have all the displays of the board in one list, and we made a
      "displayX" directory in the sysfs, where X was the index of the display
      in the list.
      
      This doesn't work anymore with device tree, as there's no single list to
      get the number from, and it doesn't work very well even with non-DT as
      we need to do some tricks to get the index nowadays.
      
      This patch changes omap_dss_register_device() so that it doesn't take
      disp_num as a parameter anymore, but uses a private increasing counter
      for the display number.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8768a52f
  4. 08 9月, 2012 4 次提交
    • T
      OMAPDSS: fix set_timings · b82fe7f0
      Tomi Valkeinen 提交于
      set_timings function of DSS's output drivers are not consistent. Some of
      them disable the output, set the timings, and re-enable the output. Some
      set the timings on the fly, while the output is enabled. And some just
      store the given timings, so that they will be taken into use next time
      the output is enabled.
      
      We require the DISPC output to be disabled when changing the timings,
      and so we can change all the output drivers' set_timings to just store
      the given timings.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b82fe7f0
    • T
      OMAPDSS: HDMI: use vdda_hdmi_dac · 17486943
      Tomi Valkeinen 提交于
      The HDMI driver requires vdda_hdmi_dac power for operation, but does not
      enable it. This has worked because the regulator has been always
      enabled.
      
      But this may not always be the case, as I encountered when implementing
      HDMI device tree support.
      
      This patch changes the HDMI driver to use the vdda_hdmi_dac.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      17486943
    • T
      OMAPDSS: HDMI: Add delay to wait for 5V power · a84b2065
      Tomi Valkeinen 提交于
      TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the
      5V power output to reach 90% of the voltage. This patch adds the delay
      to the driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a84b2065
    • T
      OMAPDSS: HDMI: Move GPIO handling to HDMI driver · cca35017
      Tomi Valkeinen 提交于
      We currently manage HDMI GPIOs in the board files via
      platform_enable/disable calls. This won't work with device tree, and in
      any case the correct place to manage the GPIOs is in the HDMI driver.
      
      This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
      handling is moved to the common hdmi.c file, and this probably needs to
      be revisited when adding OMAP5 HDMI support to see if the GPIO handling
      needs to be moved to IP specific files.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      cca35017
  5. 15 8月, 2012 2 次提交
    • A
      OMAPDSS: HDMI: Add locking for hdmi interface set timing functions · ed1aa900
      Archit Taneja 提交于
      The hdmi interface driver exposes functions to the hdmi panel driver to
      configure the interface timings maintained by the hdmi driver.
      
      These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
      to ensure they are called sequentially, this is similar to how hdmi enable and
      disable functions need locking.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      ed1aa900
    • A
      OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings · 7849398f
      Archit Taneja 提交于
      The hdmi driver currently updates only the 'code' member of hdmi_config when
      the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
      The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
      It makes more sense to configure the whole hdmi_config field in the set_timing
      op called by the panel driver. This way, we don't need to call both functions
      to ensure that our hdmi_config is configured correctly. Also, we don't need to
      calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings
      in the panel's omap_dss_device struct.
      
      The default timings of the hdmi panel are represented in a cleaner form. Since
      the hdmi output is now configured by it's own copy of timings (in
      hdmi.ip_data.cfg), the panel driver needs to set it to a valid value before
      enabling hdmi output. We now call omapdss_hdmi_set_timing() before enabling
      hdmi output, this is done to atleast have the hdmi output configured to the
      panel's default timings if the DSS user didn't call panel driver's set_timings()
      op explicitly.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      7849398f
  6. 10 8月, 2012 1 次提交
  7. 08 7月, 2012 1 次提交
    • T
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 373b4365
      Tomi Valkeinen 提交于
      If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
      will always return 1 and pm_runtime_put_sync() will always return
      -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
      driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
      print a warning.
      
      One option would be to ignore errors returned by pm_runtime_put_sync()
      totally, as they only say that the call was unable to put the hardware
      into suspend mode.
      
      However, I chose to ignore the returned -ENOSYS explicitly, and print a
      warning for other errors, as I think we should get notified if the HW
      failed to go to suspend properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      373b4365
  8. 29 6月, 2012 4 次提交
    • A
      OMAPDSS: HDMI: Remove custom hdmi_video_timings struct · cc937e5e
      Archit Taneja 提交于
      The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings,
      omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync
      polarities and interlaced/progressive information.
      
      Remove hdmi_video_timings, and use omap_video_timings instead.
      
      Cc: Mythri P K <mythripk@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      cc937e5e
    • J
      OMAPDSS: HDMI: Replace spinlock with mutex in hdmi_check_hpd_state · 3a5383a2
      Jassi Brar 提交于
      State change of HDMI PHY could potentially take many millisecs, we can do
      better by protecting things in hdmi_set_phy_pwr() with a mutex rather than
      a spin_lock_irqsave.
      Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3a5383a2
    • T
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 5be3aebd
      Tomi Valkeinen 提交于
      If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
      will always return 1 and pm_runtime_put_sync() will always return
      -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
      driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
      print a warning.
      
      One option would be to ignore errors returned by pm_runtime_put_sync()
      totally, as they only say that the call was unable to put the hardware
      into suspend mode.
      
      However, I chose to ignore the returned -ENOSYS explicitly, and print a
      warning for other errors, as I think we should get notified if the HW
      failed to go to suspend properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      5be3aebd
    • R
      OMAPDSS: add clk_prepare_enable and clk_disable_unprepare · f11766d1
      Rajendra Nayak 提交于
      In preparation of OMAP moving to Common Clk Framework(CCF) change
      clk_enable() and clk_disable() calls to clk_prepare_enable() and
      clk_disable_unprepare() in omapdss. This can be safely done, as omapdss
      never enables or disables clocks in atomic context.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: <linux-fbdev@vger.kernel.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      [tomi.valkeinen@ti.com: updated patch description]
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f11766d1
  9. 11 5月, 2012 15 次提交
    • R
      OMAPDSS: HDMI: Implement DSS driver interface for audio · f3a97491
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      f3a97491
    • R
      OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation · 25a65359
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      25a65359
    • R
      OMAPDSS: HDMI: Relocate N/CTS calculation · 35547626
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      35547626
    • R
      OMAPDSS: HDMI: Remove ASoC codec · 7c3291f0
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      7c3291f0
    • R
      OMAPDSS: HDMI: Split video_enable into video_enable/disable · c0456be3
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      c0456be3
    • R
      OMAPDSS: HDMI: Split audio_enable into audio_enable/disable · 027bdc85
      Ricardo Neri 提交于
      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: NRicardo Neri <ricardo.neri@ti.com>
      027bdc85
    • T
      OMAPDSS: separate pdata based initialization · 38f3daf6
      Tomi Valkeinen 提交于
      Move the platform-data based display device initialization into a
      separate function, so that we may later add of-based initialization.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      38f3daf6
    • T
      OMAPDSS: init omap_dss_devices internally · 9d8232a7
      Tomi Valkeinen 提交于
      Now that each output driver creates their own display devices, the
      output drivers can also initialize those devices.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9d8232a7
    • T
      OMAPDSS: interface drivers register their panel devices · 35deca3d
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      35deca3d
    • T
      OMAPDSS: add __init & __exit · 6e7e8f06
      Tomi Valkeinen 提交于
      Now that we are using platform_driver_probe() we can add __inits and
      __exits all around.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6e7e8f06
    • T
      OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi · 61055d4b
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      61055d4b
    • T
      OMAPDSS: move the creation of debugfs files · e40402cf
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e40402cf
    • T
      OMAPDSS: remove uses of dss_runtime_get/put · 852f0838
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      852f0838
    • T
      OMAPDSS: remove return from platform_driver_unreg · 04c742c3
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      04c742c3
    • T
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
  10. 09 5月, 2012 2 次提交
    • A
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      fcc36619
    • A
      OMAPDSS: Apply manager timings instead of direct DISPC writes · 41721163
      Archit Taneja 提交于
      Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
      interface drivers. The latter function ensures that the timing related DISPC
      registers are configured according to the shadow register programming model.
      
      Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
      is set by dss_mgr_set_timings().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      41721163
  11. 23 4月, 2012 1 次提交
    • A
      OMAPDSS: DISPC: Use a common function to set manager timings · c51d921a
      Archit Taneja 提交于
      Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV
      manager's timings is set by dispc_set_digit_size(). Use a common function called
      dispc_mgr_set_timings() which sets timings for both type of managers.
      
      We finally want the interface drivers to use an overlay manager function to
      configure it's timings, having a common DISPC function would make things
      cleaner.
      
      For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for
      TV manager, it sets only the TV size since blanking values don't exist for TV.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c51d921a
  12. 06 3月, 2012 1 次提交
    • M
      OMAPDSS: HDMI: Add M2 divider while calculating clkout · dd2116a3
      Mythri P K 提交于
      While calculating regm and regmf value add using M2 divider in
      the equation.
      Formula for calculating:
      Output clock on digital core domain:
      	CLKOUT = (M / (N+1))*CLKINP*(1/M2)
      Internal oscillator output clock on internal LDO domain:
      	CLKDCOLDO = (M / (N+1))*CLKINP
      The current code when allows variable M2 values as input
      ignores using M2 divider values in calculation of regm and regmf.
      so fix it by using M2 in calculation although the default value for
      M2 is 1.
      Signed-off-by: NMythri P K <mythripk@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      dd2116a3
  13. 23 2月, 2012 1 次提交
    • A
      OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled · a247ce78
      Archit Taneja 提交于
      For DSS clock domain to transition from idle to active state. It's necessary
      to enable the optional clock DSS_FCLK before we enable the module using the
      MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
      
      This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
      to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
      called for hdmi's platform device.
      
      Since the clock domain failed to change it's state to active, the hwmod code
      disables any clocks it had enabled before for this hwmod. This led to the clock
      'dss_48mhz_clk' gettind disabled.
      
      When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
      correctly enables the DSS clock domain this time. However, the clock
      'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
      disabled previously, the driver fails when it tries to enable HDMI's PHY.
      
      Fix this for now by ensuring that dss_runtime_get() is called before we call
      pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
      be to modify the DSS related hwmod's mainclks, and also some changes in how
      opt clocks are handled in the DSS driver.
      
      This fixes the issue of HDMI not working when it's the default display. The
      issue is not seen if any other display is already enabled as the first display
      would have correctly enabled the DSS clockdomain.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a247ce78
  14. 21 2月, 2012 1 次提交