1. 29 Jul, 2012 5 commits
  2. 25 Jul, 2012 2 commits
  3. 24 Jul, 2012 6 commits
  4. 19 Jul, 2012 9 commits
  5. 08 Jul, 2012 6 commits
    • Ondrej Zary's avatar
      s3fb: Add Virge/MX (86C260) · 6fcdbc0c
      Ondrej Zary authored
      Add support for Virge/MX (86C260) chip. Although this is a laptop chip,
      there's an AGP card with this chip too.
      
      Tested with AGP card, will probably not work correctly with laptops.
      DDC does not work on this card (even in DOS or Windows).
      Signed-off-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      6fcdbc0c
    • Emil Goode's avatar
      grvga: Fix error handling issues · 42eb317f
      Emil Goode authored
      This patch fixes two problems with the error handling in the
      grvga_probe function and simplifies it making the code
      easier to read.
      
      - If the call to grvga_parse_custom on line 370 fails we use
        the wrong label so that release_mem_region will be called
        without a call to request_mem_region being made.
      
      - If the call to ioremap on line 436 fails we should not try
        to call iounmap in the error handling code.
      
      This patch introduces the following changes:
      
      - Converts request_mem_region into its devm_ equivalent
        which simplifies the otherwise messy clean up code.
      
      - Changes the labels for correct error handling and their
        names to make the code easier to read.
      Signed-off-by: default avatarEmil Goode <emilgoode@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      42eb317f
    • Paul Parsons's avatar
      video: w100fb: Reduce sleep mode battery discharge · fb181559
      Paul Parsons authored
      In 2006 and 2007 the handhelds.org kernel w100fb driver was patched to
      reduce sleep mode battery discharge. Unfortunately those two patches
      never migrated to the mainline kernel.
      
      Fortunately the function affected - w100_suspend() - has not changed
      since; thus those patches still apply cleanly.
      
      Applying those patches to linux-3.4-rc3 running on an HP iPAQ hx4700
      reduces the sleep mode battery discharge from approximately 26 mA to
      approximately 11 mA.
      
      This patch combines those two patches into a single unified patch.
      Signed-off-by: default avatarPaul Parsons <lost.distance@yahoo.com>
      Cc: Matt Reimer <mreimer@sdgsystems.com>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      fb181559
    • Florian Tobias Schandinat's avatar
    • 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
    • Tomi Valkeinen's avatar
      OMAPDSS: Use PM notifiers for system suspend · 736f29cd
      Tomi Valkeinen authored
      The current way how omapdss handles system suspend and resume is that
      omapdss device (a platform device, which is not part of the device
      hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
      the suspend and resume callbacks from platform_driver to handle system
      suspend. It does this by disabling all enabled panels on suspend, and
      resuming the previously disabled panels on resume.
      
      This presents a few problems.
      
      One is that as omapdss device is not related to the panel devices or the
      DSS HW devices, there's no ordering in the suspend process. This means
      that suspend could be first ran for DSS HW devices and panels, and only
      then for omapdss device. Currently this is not a problem, as DSS HW
      devices and panels do not handle suspend.
      
      Another, more pressing problem, is that when suspending or resuming, the
      runtime PM functions return -EACCES as runtime PM is disabled during
      system suspend. This causes the driver to print warnings, and operations
      to fail as they think that they failed to bring up the HW.
      
      This patch changes the omapdss suspend handling to use PM notifiers,
      which are called before suspend and after resume. This way we have a
      normally functioning system when we are suspending and resuming the
      panels.
      
      This patch, I believe, creates a problem that somebody could enable or
      disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
      similarly the other way around in resume. I choose to ignore the problem
      for now, as it sounds rather unlikely, and if it happens, it's not
      fatal.
      
      In the long run the system suspend handling of omapdss and panels should
      be thought out properly. The current approach feels rather hacky.
      Perhaps the panel drivers should handle system suspend, or the users of
      omapdss (omapfb, omapdrm) should handle system suspend.
      
      Note that after this patch we could probably revert
      0eaf9f52 (OMAPDSS: use sync versions of
      pm_runtime_put). But as I said, this patch may be temporary, so let's
      leave the sync version still in place.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Tested-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Tested-by: default avatarJoe Woodward <jw@terrafix.co.uk>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      [fts: fixed 2 brace coding style issues]
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      736f29cd
  6. 29 Jun, 2012 12 commits
    • Tomi Valkeinen's avatar
      Merge "Apply LCD manager related parameters" from Archit · 974a6582
      Tomi Valkeinen authored
      The LCD interface drivers(DPI, DSI, RFBI, SDI) do some direct DISPC register
      writes to configure LCD manager related fields. This series groups these fields
      into a single struct, and let's the interface driver apply these parameters.
      
      This allows us to:
      
      - Check the LCD manager related parameters before applying them.
      - Remove some omap_dss_device references as APPLY holds the applied parameters.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      974a6582
    • Archit Taneja's avatar
      OMAPDSS: OVERLAY: Clean up replication checking · 6c6f510a
      Archit Taneja authored
      Replication logic for an overlay depends on the color mode in which it is
      configured and the video port width of the manager it is connected to.
      
      video port width now held in dss_lcd_mgr_config in the manager's private
      data in APPLY. Use this instead of referring to the omap_dss_device connected to
      the manager.
      
      Replication is enabled in the case of TV manager, the video_port_width is set to
      a default value of 24 for TV manager.
      
      Make the replication checking an overlay function since it's more of an overlay
      characteristic than a display characteristic.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6c6f510a
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager · c47cdb30
      Archit Taneja authored
      The RFBI driver uses a direct DISPC register write to enable the overlay
      manager. Replace this with dss_mgr_enable() which checks if the connected
      overlay and managers are correctly configured, and configure DSS for
      fifomerge.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c47cdb30
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove a redundant function · dd88b7a6
      Archit Taneja authored
      dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd()
      in dispc.c. Remove the function from dispc.c and replace it with the one in
      dss.h.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      dd88b7a6
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks · 75bac5d1
      Archit Taneja authored
      APPLY needs to know at certain places whether an overlay manager is in manual
      or auto update mode. The caps of the connected omap_dss_device were used to
      check that.
      
      A LCD manager is in manual update if stallmode is enabled for that manager. TV
      managers for now always auto update.
      
      Return the value of stallmode parameter in the private data 'lcd_confg' in
      mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field
      will be false by default.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      75bac5d1
    • Archit Taneja's avatar
      OMAPDSS: MANAGER: Check LCD related overlay manager parameters · 6e543595
      Archit Taneja authored
      The LCD related manager configurations are a part of the manager's private data
      in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
      to check the validity of some of the configurations.
      
      To check some of the configurations, we require information of interface to
      which the manager output is connected. These can be added once interfaces are
      represented as an entity.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6e543595
    • 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>
      f476ae9d
    • 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>
      37a57990
    • Archit Taneja's avatar
      OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 7d2572f8
      Archit Taneja authored
      Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by DSI.
      
      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.
      
      The function dsi_configure_dispc_clocks() is now called in
      dsi_display_init_dispc(), this lets all the lcd manager related configurations
      happen in the same place. The DISPC_DIVISORo register was written in
      dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter
      in mgr_config. The clock_info is written later in dsi_display_init_dispc().
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      7d2572f8
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters · bc2e60a6
      Archit Taneja authored
      Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by RFBI.
      
      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 rfbi_config_lcd_manager() which fills up the mgr_config
      parameters and writes to the DISPC regs.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      bc2e60a6
    • Archit Taneja's avatar
      OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 5cf9a264
      Archit Taneja authored
      Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by DPI.
      
      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.
      
      The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk()
      and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in
      mgr_config. They are written later in dpi_config_lcd_manager.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5cf9a264
    • Archit Taneja's avatar
      OMAPDSS: Add struct to hold LCD overlay manager configuration · c56fb3ef
      Archit Taneja authored
      Create a struct dss_lcd_mgr_config which holds LCD overlay manager related
      parameters. These are currently partially contained in the omap_dss_device
      connected to the manager, and the rest are in the interface driver.
      
      The parameters are directly written to the DISPC registers in the interface
      drivers. These should eventually be applied at the correct time using the
      shadow register programming model. This struct would help in grouping these
      parameters so that they can be applied together.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c56fb3ef