1. 03 4月, 2013 4 次提交
    • A
      OMAPDSS: picodlp panel: remove platform_enable/disable callbacks · b3fb8b98
      Archit Taneja 提交于
      The picodlp panel driver now manages the gpios required to configure the
      panel. This was previously done in omap_dss_device's platform_enable/disable
      callbacks defined in board files using this panel.
      
      All the board files using this panel now pass the gpio information as platform
      data via the panel_generic_dpi_data struct, which is needed by the panel driver
      to configure the gpios connected to the panel. Hence, the
      platform_enable/disable ops can be safely removed now.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      b3fb8b98
    • A
      OMAPDSS: picodlp panel: handle gpio data in panel driver · d52e2e75
      Archit Taneja 提交于
      The picodlp panel driver leaves gpio requests to the platform's board file.
      These should happen in the panel driver itself.
      
      A platform data struct called picodlp_panel_data already exists to hold gpio
      numbers and other platform data. Request all the gpios in the panel driver so
      that the board files which use the the panel don't need to do it.
      
      This will help in removing the need for the panel drivers to have platform
      related callbacks.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      d52e2e75
    • A
      OMAPDSS: picodlp: use devm_kzalloc for allocating driver data · e1b94f1d
      Archit Taneja 提交于
      Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp
      panel driver. This simplifies the driver's probe and remove functions.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      e1b94f1d
    • A
      OMAPDSS: panels: keep platform data of all panels in a single header · a0d8dde9
      Archit Taneja 提交于
      Structs for platform data of omapdss panels are found in headers in the
      'include/video/' path. Board files populate these structs with platform
      specific values, and the panel driver uses these to configure the panel.
      
      Currently, each panel has it's own header in the above path. Move all the
      omapdss panel platform data structs to a single header omap-panel-data.h.
      This is useful because:
      
      - All other omapdss panel drivers will be modified to use platform data. This
        would lead to a lot of panel headers usable only by omapdss. A lot of these
        platform data structs are trivial, and don't really need a separate header.
      - Platform data would be eventually removed, and platform information would be
        passed via device tree. Therefore, omapdss panel platform data structs are
        temporary, and will be easier to remove if they are all in the same header.
      - All board files will have to include the same header to configure a panel's
        platform data, that makes the board files more consistent.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      a0d8dde9
  2. 30 11月, 2012 1 次提交
  3. 24 10月, 2012 1 次提交
  4. 16 8月, 2012 1 次提交
    • A
      OMAPDSS: DPI: Maintain copy of number of data lines in driver data · c6b393d4
      Archit Taneja 提交于
      The DPI driver currently relies on the omap_dss_device struct to configure the
      number of data lines as specified by the panel. This makes the DPI interface
      driver dependent on the omap_dss_device struct.
      
      Make the DPI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_dpi_set_data_lines() before enabling the interface.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      c6b393d4
  5. 13 8月, 2012 1 次提交
    • A
      OMAPDSS: DPI: Maintain our own timings field in driver data · c499144c
      Archit Taneja 提交于
      The DPI driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC accordingly. This makes the DPI interface driver dependent
      on the omap_dss_device struct.
      
      Make the DPI driver data maintain it's own timings field. The panel driver is
      expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
      these timings before the panel is enabled.
      
      In the set_timings() op, we still ensure that the omap_dss_device timings
      (dssdev->panel.timings) are configured. This will later be configured only by
      the DPI panel drivers.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      c499144c
  6. 29 6月, 2012 4 次提交
    • A
      OMAPDSS: Remove omap_panel_config enum from omap_dss_device · 07fb51c6
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      07fb51c6
    • A
      OMAPDSS: Add some new fields to omap_video_timings · a8d5e41c
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      a8d5e41c
    • A
      OMAPDSS: Remove passive matrix LCD support (part 4) · a9105cb5
      Archit Taneja 提交于
      Remove configuration of Ac-bias pins
      
      Ac-bias pins need to be configured only for passive matrix displays. Remove
      acbi and acb fields in omap_dss_device and their configuration in panel
      drivers. Don't program these fields in DISP_POL_FREQo register any more.
      
      The panel driver for sharp-ls037v7dw01, and the panel config for
      Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This
      is most likely carried over from the old omapfb driver which supported passive
      matrix displays.
      
      Cc: Thomas Weber <weber@corscience.de>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      a9105cb5
    • A
      OMAPDSS: Remove passive matrix LCD support (part 2) · 5ae9eaa6
      Archit Taneja 提交于
      Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
      
      We don't support passive matrix displays any more. Remove this flag from all the
      panel drivers.
      
      Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      5ae9eaa6
  7. 04 10月, 2011 1 次提交
  8. 14 9月, 2011 2 次提交