1. 18 Nov, 2013 2 commits
  2. 30 Aug, 2013 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: rename omap_dss_device's 'device' field to 'dst' · 9560dc10
      Tomi Valkeinen authored
      
      
      In the old panel device model we had omap_dss_output entities,
      representing the encoders in the DSS block. This entity had "device"
      field, which pointed to the panel that was using the omap_dss_output.
      
      With the new panel device model, the omap_dss_output is integrated into
      omap_dss_device, which now represents a "display entity". Thus the "device"
      field, now in omap_dss_device, points to the next entity in the display
      entity-chain.
      
      This patch renames the "device" field to "dst", which much better tells
      what the field points to.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: default avatarArchit Taneja <archit@ti.com>
      9560dc10
  3. 29 Aug, 2013 2 commits
  4. 26 Jun, 2013 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: Fix wrong pixel clock limit · 72e5512a
      Tomi Valkeinen authored
      
      
      DPI is supposed to skip odd dividers in the clock path when the pixel
      clock is higher than 100MHz. The code, however, defines the pixel clock
      limit as 1MHz. This causes the driver to skip valid clock dividers,
      possibly making the pixel clock to be further away from the requested
      one than necessary.
      
      Fix the clock limit to 100MHz.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: NeilBrown <neilb@suse.de>
      72e5512a
  5. 17 Jun, 2013 8 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: Add ops · 0b24edb1
      Tomi Valkeinen authored
      
      
      Add "ops" style method for using DPI 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>
      0b24edb1
    • 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: 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: DPI: fix regulators for DT · 00df43b8
      Tomi Valkeinen authored
      
      
      On some platforms DPI requires a regulator to be enabled to power up the
      output pins. This regulator is, for some reason, currently attached to
      the virtual omapdss device, instead of the DPI device. This does not
      work for DT, as the regulator mappings need to be described in the DT
      data, and the virtual omapdss device is not present there.
      
      Fix the issue by acquiring the regulator in the DPI device. To retain
      compatibility with the current board files, the old method of getting
      the regulator is kept. The old method can be removed when the board
      files have been changed to pass the regulator to DPI.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      00df43b8
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: cleanup pll & regulator init · 2795f646
      Tomi Valkeinen authored
      
      
      Split regulator and DSI PLL init code to their own functions for
      clarity.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2795f646
    • 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
  6. 02 May, 2013 2 commits
  7. 11 Apr, 2013 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: widen the pck search when using dss fck · 2c6360fb
      Tomi Valkeinen authored
      
      
      When not using DSI PLL to generate the pixel clock, but DSS FCK, the
      possible pixel clock rates are rather limited. DSS FCK is currently used
      on OMAP2 and OMAP3.
      
      When using Beagleboard with a monitor that supports high resolutions,
      the clock rates do not match (at least for me) for the monitor's pixel
      clocks within the current threshold in the code, which is +/- 1MHz.
      
      This patch widens the search up to +/- 15MHz. The search is done in
      steps, i.e. it first tries to find a rather exact clock, than a bit less
      exact, etc. so this should not change the cases where a clock was
      already found.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2c6360fb
  8. 03 Apr, 2013 5 commits
  9. 13 Dec, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: fix TV-out issue with DSI PLL · bd0f5cc3
      Tomi Valkeinen authored
      Commit 0e8276ef
      
       (OMAPDSS: DPI: always
      use DSI PLL if available) made dpi.c use DSI PLL for its clock. This
      works fine, for DPI, but has a nasty side effect on OMAP3:
      
      On OMAP3 the same clock is used for DISPC fclk and LCD output. Thus,
      after the above patch, DSI PLL is used for DISPC and LCD output. If
      TV-out is used, the TV-out needs DISPC. And if DPI is turned off, the
      DSI PLL is also turned off, disabling DISPC.
      
      For this to work, we'd need proper DSS internal clock handling, with
      refcounts, which is a non-trivial project.
      
      This patch fixes the issue for now by disabling the use of DSI PLL for
      DPI on OMAP3.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      bd0f5cc3
  10. 07 Dec, 2012 2 commits
  11. 27 Nov, 2012 1 commit
  12. 05 Nov, 2012 4 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: always use DSI PLL if available · 0e8276ef
      Tomi Valkeinen authored
      
      
      We currently get the decision whether to use PRCM or DSI PLL clock for
      DPI from the board file. This is not a good way to handle it, and it
      won't work with device tree.
      
      This patch changes DPI to always use DSI PLL if it's available.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0e8276ef
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: verify if DSI PLL is operational · 6061675b
      Tomi Valkeinen authored
      
      
      The SoCs that have DSI module should have a working DSI PLL. However,
      some rare boards have not connected the powers to the DSI PLL.
      
      This patch adds a function that tries to power up the DSI PLL, and
      reports if that doesn't succeed. DPI uses this function to fall back to
      PRCM clocks if DSI PLL doesn't work.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6061675b
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll · 8a3db406
      Tomi Valkeinen authored
      
      
      Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
      can just check if dpi.dsidev != NULL.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8a3db406
    • Tomi Valkeinen's avatar
      OMAPDSS: hide dss_select_dispc_clk_source() · a5b8399f
      Tomi Valkeinen authored
      
      
      dss.c currently exposes functions to configure the dispc source clock
      and lcd source clock. There are configured separately from the output
      drivers.
      
      However, there is no safe way for the output drivers to handle dispc
      clock, as it's shared between the outputs. Thus, if, say, the DSI driver
      sets up DSI PLL and configures both the dispc and lcd clock sources to
      that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
      
      Thus the output drivers should really only be concerned about the lcd
      clock, which is what the output drivers actually use. There's lot to do
      to clean up the dss clock handling, but this patch takes one step
      forward and removes the use of dss_select_dispc_clk_source() from the
      output drivers.
      
      After this patch, the output drivers only configure the lcd source
      clock. On omap4+ the dispc src clock is never changed from the default
      PRCM source. On omap3, where the dispc and lcd clocks are actually the
      same, setting the lcd clock source sets the dispc clock source.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      a5b8399f
  13. 29 Oct, 2012 1 commit
  14. 28 Sep, 2012 1 commit
  15. 26 Sep, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager references · 5d512fcd
      Archit Taneja authored
      
      
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      
      When enabling the DPI output, check whether the output entity connected to
      display is not NULL.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5d512fcd
    • Archit Taneja's avatar
      OMAPDSS: 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
  16. 24 Sep, 2012 1 commit
  17. 18 Sep, 2012 3 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: 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
  18. 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