An error occurred fetching the project authors.
  1. 29 Aug, 2013 1 commit
  2. 17 Jun, 2013 9 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: AnalogTV: Add ops · fb8efa49
      Tomi Valkeinen authored
      Add "ops" style method for using analog TV functionality.
      
      Ops style calls will allow us to have arbitrarily long display
      pipelines, where each entity can call ops in the previous display
      entity.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      fb8efa49
    • Tomi Valkeinen's avatar
      OMAPDSS: public omapdss_register_output() · 5d47dbc8
      Tomi Valkeinen authored
      In order to allow multiple display block in a video pipeline, we need to
      give the drivers way to register themselves. For now we have
      the omapdss_register_display() which is used to register panels, and
      dss_register_output() which is used to register DSS encoders.
      
      This patch makes dss_register_output() public (with the name of
      omapdss_register_output), which can be used to register also external
      encoders. The distinction between register_output and register_display
      is that a "display" is an entity at the end of the videopipeline, and
      "output" is something inside the pipeline.
      
      The registration and naming will be made saner in the future, but the
      current names and functions are kept to minimize changes during the dss
      device model transition.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5d47dbc8
    • Tomi Valkeinen's avatar
      OMAPDSS: remove dispc's dependency to VENC/HDMI · 5391e87d
      Tomi Valkeinen authored
      DISPC needs to know the clock rate for DIGIT (i.e. TV) channel, and this
      clock is provided by either VENC or HDMI modules. Currently DISPC will
      call a function in VENC/HDMI, asking what the clock rate is. This means
      we have a fixed dependency from DISPC to both VENC and HDMI.
      
      To have a more generic approach, and in particular to allow adding OMAP5
      HDMI driver, we need to remove this dependency. This patch makes
      VENC/HDMI inform DISPC when the their clock changes, thus reversing the
      dependency and removing the issue.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5391e87d
    • Tomi Valkeinen's avatar
      OMAPDSS: add THIS_MODULE owner to DSS outputs · b7328e14
      Tomi Valkeinen authored
      Setup the owner field for DSS output's omap_dss_device so that module
      refcounting works.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b7328e14
    • Tomi Valkeinen's avatar
      OMAPDSS: combine omap_dss_output into omap_dss_device · 1f68d9c4
      Tomi Valkeinen authored
      We currently have omap_dss_device, which represents an external display
      device, sometimes an external encoder, sometimes a panel. Then we have
      omap_dss_output, which represents DSS's output encoder.
      
      In the future with new display device model, we construct a video
      pipeline from the display blocks. To accomplish this, all the blocks
      need to be presented by the same entity.
      
      Thus, this patch combines omap_dss_output into omap_dss_device. Some of
      the fields in omap_dss_output are already found in omap_dss_device, but
      some are not. This means we'll have DSS output specific fields in
      omap_dss_device, which is not very nice. However, it is easier to just
      keep those output specific fields there for now, and after transition to
      new display device model is made, they can be cleaned up easier than
      could be done now.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1f68d9c4
    • Tomi Valkeinen's avatar
      OMAPDSS: remove omap_dss_start/stop_device() · d3923933
      Tomi Valkeinen authored
      The omap_dss_start_device() and omap_dss_stop_device(), called by the
      DSS output drivers, are old relics. They originally did something
      totally else, but nowadays they increase the module ref count for panels
      that are enabled.
      
      This model is quite broken: the panel modules may be used even before
      they are enabled. For example, configuring the panel requires calls to
      functions located in the panel modules.
      
      In the following patches we try to improve the ref count management for
      the modules and display devices. The first step, however, is to remove
      the omap_dss_start/stop_device() totally.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      d3923933
    • Tomi Valkeinen's avatar
      OMAPDSS: remove dssdev uses in trivial cases · 7ae9a71e
      Tomi Valkeinen authored
      In the future the "dssdev" parameter passed to output drivers will
      change its meaning. Instead of being a pointer to the panel device, it's
      a pointer to the output instance.
      
      To make the transition easier, some of the uses for this dssdev
      parameter can be easily removed.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      7ae9a71e
    • Tomi Valkeinen's avatar
      OMAPDSS: VENC: clean up regulator init · 7e436bb2
      Tomi Valkeinen authored
      Clean up the VENC driver's regulator init to remove the (unused)
      omap_dss_device parameter, renaming the function to a more sensible
      name, and making the code slightly clearer.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      7e436bb2
    • Tomi Valkeinen's avatar
      OMAPDSS: only probe pdata if there's one · c6ca5b22
      Tomi Valkeinen authored
      omapdss output drivers always read the platform data. This crashes when
      there's no platform data when using DT.
      
      Add a check to read the platform data only if it exists.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      c6ca5b22
  3. 02 May, 2013 2 commits
  4. 10 Apr, 2013 1 commit
  5. 03 Apr, 2013 3 commits
  6. 07 Dec, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: manage output-dssdev connection in output drivers · 486c0e17
      Tomi Valkeinen authored
      We currently attach an output to a dssdev in the initialization code for
      dssdevices in display.c. This works, but doesn't quite make sense: an
      output entity represents (surprisingly) an output of DSS, which is
      managed by an output driver. The output driver also handles adding new
      dssdev's for that particular output.
      
      It makes more sense to make the output-dssdev connection in the output
      driver. This is also in line with common display framework.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      486c0e17
  7. 29 Oct, 2012 1 commit
  8. 26 Sep, 2012 2 commits
    • 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: 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
  9. 18 Sep, 2012 4 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: alloc dssdevs dynamically · 5274484b
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5274484b
    • Tomi Valkeinen's avatar
      OMAPDSS: explicitely initialize dssdev->channel for new displays · bcb226a9
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      bcb226a9
    • Tomi Valkeinen's avatar
      OMAPDSS: register only one display device per output · 1521653c
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1521653c
    • Tomi Valkeinen's avatar
      OMAPDSS: omap_dss_register_device() doesn't take display index · 8768a52f
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8768a52f
  10. 07 Sep, 2012 2 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: fix set_timings · b82fe7f0
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b82fe7f0
    • Tomi Valkeinen's avatar
      OMAPDSS: remove unnecessary includes · fe6a4662
      Tomi Valkeinen authored
      Remove unnecessary includes from omapdss.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      fe6a4662
  11. 22 Aug, 2012 1 commit
  12. 16 Aug, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintian copy of video output polarity info in private data · 89e71956
      Archit Taneja authored
      The VENC driver currently relies on the omap_dss_device struct to configure the
      video output polarity. This makes the VENC interface driver dependent on the
      omap_dss_device struct.
      
      Make the VENC driver data maintain it's own polarity field. A panel driver
      is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the
      interface.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      89e71956
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintain copy of venc type in driver data · febe2905
      Archit Taneja authored
      The VENC driver currently relies on the omap_dss_device struct to configure the
      venc type. This makes the VENC interface driver dependent on the omap_dss_device
      struct.
      
      Make the VENC driver data maintain it's own 'venc type' field. A panel driver
      is expected to call omapdss_venc_set_type() before enabling the interface or
      changing the type via display sysfs attributes.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      febe2905
  13. 15 Aug, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintain our own timings field in driver data · a5abf472
      Archit Taneja authored
      The VENC driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC and VENC blocks accordingly. This makes the VENC interface
      driver dependent on the omap_dss_device struct.
      
      Make the VENC driver data maintain it's own timings field. The panel driver is
      expected to call omapdss_venc_set_timings() to set these timings before the
      panel is enabled. Call omapdss_venc_set_timings() before enabling
      venc output, this is done to atleast have the venc output configured to the
      panel's default timings if the DSS user didn't explicitly call the venc panel
      driver's set_timings op.
      
      Make the VENC panel driver configure the new timings is the omap_dss_device
      struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
      only it's own copy of timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      a5abf472
    • Archit Taneja's avatar
      OMAPDSS: VENC: Split VENC into interface and panel driver · 156fd99e
      Archit Taneja authored
      The current venc.c driver contains both the interface and panel driver code.
      This makes the driver hard to read, and difficult to understand the work split
      between the interface and panel driver and the how the locking works.
      
      This also makes it easier to clearly define the VENC interface ops called by the
      panel driver.
      
      Split venc.c into venc.c and venc_panel.c representing the interface and panel
      driver respectively. This split is done along the lines of the HDMI interface
      and panel drivers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      156fd99e
  14. 08 Jul, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 373b4365
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      373b4365
  15. 29 Jun, 2012 3 commits
    • Archit Taneja's avatar
      OMAPDSS: Add interlace parameter to omap_video_timings · 23c8f88e
      Archit Taneja authored
      Add a parameter called interlace which tells whether the timings are in
      interlaced or progressive mode. This aligns the omap_video_timings struct with
      the Xorg modeline configuration.
      
      It also removes the hack needed to write to divide the manager height by 2 if
      the connected interface is VENC.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      23c8f88e
    • Tomi Valkeinen's avatar
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 5be3aebd
      Tomi Valkeinen authored
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      5be3aebd
    • Rajendra Nayak's avatar
      OMAPDSS: add clk_prepare_enable and clk_disable_unprepare · f11766d1
      Rajendra Nayak authored
      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: default avatarRajendra 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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      f11766d1
  16. 22 May, 2012 3 commits
    • 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
    • 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
  17. 11 May, 2012 2 commits