1. 11 Feb, 2014 1 commit
  2. 13 Jan, 2014 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: don't print errors on -EPROBE_DEFER · 40359a9b
      Tomi Valkeinen authored
      Nowadays it's normal to get -EPROBE_DEFER from, e.g., regulator_get. As
      -EPROBE_DEFER is not really an error, and the driver will be probed fine
      a bit later, printing an error message will just confuse the user.
      This patch changes omapdss to print an error for regulator_gets only if
      the error code is something else than -EPROBE_DEFER.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  3. 18 Nov, 2013 2 commits
  4. 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
      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>
  5. 29 Aug, 2013 2 commits
  6. 17 Jun, 2013 9 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: SDI: Add ops · b1082dfd
      Tomi Valkeinen authored
      Add "ops" style method for using SDI functionality.
      Ops style calls will allow us to have arbitrarily long display
      pipelines, where each entity can call ops in the previous display
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • Tomi Valkeinen's avatar
      OMAPDSS: SDI: fix regulators for DT · 46c4b645
      Tomi Valkeinen authored
      SDI requires a regulator to operate. This regulator is, for some reason,
      currently attached to the virtual omapdss device, instead of the SDI
      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
      Fix the issue by acquiring the regulator in the SDI 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 SDI.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: SDI: clean up regulator init · d37801b3
      Tomi Valkeinen authored
      Clean up the SDI 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>
    • 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>
  7. 02 May, 2013 2 commits
  8. 03 Apr, 2013 3 commits
  9. 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>
  10. 29 Oct, 2012 1 commit
  11. 28 Sep, 2012 1 commit
  12. 26 Sep, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: SDI: Replace dssdev->manager with dssdev->output->manager references · 7d6069e5
      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 SDI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • 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>
  13. 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
      - Use dss_add_device to register the device.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • 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
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • 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>
  14. 07 Sep, 2012 1 commit
    • 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>
  15. 23 Aug, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: Fix SDI PLL locking · 35d67866
      Tomi Valkeinen authored
      Commit f476ae9d
       (OMAPDSS: APPLY: Remove
      DISPC writes to manager's lcd parameters in interface) broke the SDI
      output, as it causes the SDI PLL locking to fail.
      LCLK and PCLK divisors are located in shadow registers, and we normally
      write them to DISPC registers when enabling the output.  However, SDI
      uses pck-free as source clock for its PLL, and pck-free is affected by
      the divisors. And as we need the PLL before enabling the output, we need
      to write the divisors early.
      It seems just writing to the DISPC register is enough, and we don't need
      to care about the shadow register mechanism for pck-free. The exact
      reason for this is unknown.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
  16. 16 Aug, 2012 1 commit
    • Archit Taneja's avatar
      OMAPDSS: SDI: Maintain copy of data pairs in driver data · 889b4fd7
      Archit Taneja authored
      The SDI driver currently relies on the omap_dss_device struct to configure the
      number of data pairs as specified by the panel. This makes the SDI interface
      driver dependent on the omap_dss_device struct.
      Make the SDI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
      Even though we configure the number of data pairs here, this function would be
      finally mapped to a generic interface op called set_data_lines. The datapairs
      argument type has been changed from u8 to int at some places to be in sync with
      the 'set_data_lines' ops of other interfaces.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
  17. 15 Aug, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: SDI: Maintain our own timings field in driver data · 9b4a5716
      Archit Taneja authored
      The SDI driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC accordingly. This makes the SDI interface driver dependent
      on the omap_dss_device struct.
      Make the SDI driver data maintain it's own timings field. The panel driver is
      expected to call omapdss_sdi_set_timings() to set these timings before the panel
      is enabled.
      Make the SDI panel driver configure the new timings is the omap_dss_device
      struct(dssdev->panel.timings). The SDI driver is responsible for maintaining
      only it's own copy of timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: SDI: Create a function to set timings · c7833f7b
      Archit Taneja authored
      Create function omapdss_sdi_set_timings(). Configuring new timings is done the
      same way as before, SDI is disabled, and re-enabled with the new timings in
      dssdev. This just moves the code from the panel drivers to the SDI driver.
      The panel drivers shouldn't be aware of how SDI manages to configure a new set
      of timings. This should be taken care of by the SDI driver itself.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
  18. 29 Jun, 2012 6 commits
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers · f476ae9d
      Archit Taneja authored
      Replace the DISPC fuctions used to configure LCD channel related manager
      parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
      the DISPC registers are written at the right time by using the shadow register
      programming model.
      The LCD manager configurations is stored as a private data of manager in APPLY.
      It is treated as an extra info as it's the panel drivers which trigger this
      apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.
      Storing LCD manager related properties in APPLY also prevents the need to refer
      to the panel connected to the manager for information. This helps in making the
      DSS driver less dependent on panel.
      A helper function is added to check whether the manager is LCD or TV. The direct
      DISPC register writes are removed from the interface drivers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 37a57990
      Archit Taneja authored
      Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by SDI.
      Use these to write to the DISPC registers. These direct register writes would be
      later replaced by a function which applies the configuration using the shadow
      register programming model.
      Create function sdi_config_lcd_manager() which fills the mgr_config parameters
      and writes to the DISPC registers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() · f0d08f89
      Archit Taneja authored
      dipsc_mgr_set_clock div has an int return type to report errors or success.
      The function doesn't really check for errors and always returns 0. Change
      the return type to void.
      Checking for the correct DISPC clock divider ranges will be done when a DSS2
      user does a manager apply. This support will be added later.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: Remove omap_panel_config enum from omap_dss_device · 07fb51c6
      Archit Taneja authored
      omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
      registers. These are now held by omap_video_timings and are set when the manager
      timings are applied.
      Remove the omap_panel_config enum, and remove all it's references from panel or
      interface drivers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq() · 0e065c79
      Archit Taneja authored
      dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
      All these fields have been moved to omap_video_timings struct, and are now
      programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
      are applied via dss_mgr_set_timings().
      Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • Archit Taneja's avatar
      OMAPDSS: Add some new fields to omap_video_timings · a8d5e41c
      Archit Taneja authored
      Some panel timing related fields are contained in omap_panel_config in the form
      of flags. The fields are:
      - Hsync logic level
      - Vsync logic level
      - Data driven on rising/falling edge of pixel clock
      - Output enable/Data enable logic level
      - HSYNC/VSYNC driven on rising/falling edge of pixel clock
      Out of these parameters, Hsync and Vsync logic levels are a part of the timings
      in the Xorg modeline configuration. So it makes sense to move the to
      omap_video_timings. The rest aren't a part of modeline, but it still makes
      sense to move these since they are related to panel timings.
      These fields stored in omap_panel_config in dssdev are configured for LCD
      panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.
      Add the above fields in omap_video_timings. Represent their state via new enums.
      Add these parameters to the omap_video_timings instances in the panel drivers.
      Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
      omap_panel_config for now. The struct will be removed later.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>