Skip to content
Snippets Groups Projects
  1. May 15, 2015
  2. Apr 23, 2015
  3. Apr 22, 2015
  4. Feb 12, 2015
  5. Dec 30, 2014
    • Marek Vasut's avatar
      arm: mx6: gw_ventana: Define CONFIG_SYS_MALLOC_F_LEN · 7efefa9b
      Marek Vasut authored
      
      This board uses setup_i2c() in SPL. The setup_i2c() function internally
      calls gpio_request(), which in turn internally calls strdup(). The strdup()
      requires a running mallocator, so this patch makes the mallocator available.
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Nikita Kiryanov <nikita@compulab.co.il>
      Cc: Sean Cross <xobs@kosagi.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Tim Harvey <tharvey@gateworks.com>
      7efefa9b
  6. Sep 24, 2014
    • Nikita Kiryanov's avatar
      spi: mxc: fix sf probe when using mxc_spi · 155fa9af
      Nikita Kiryanov authored
      
      MXC SPI driver has a feature whereas a GPIO line can be used to force CS high
      across multiple transactions. This is set up by embedding the GPIO information
      in the CS value:
      
      cs = (cs | gpio << 8)
      
      This merge of cs and gpio data into one value breaks the sf probe command:
      if the use of gpio is required, invoking "sf probe <cs>" will not work, because
      the CS argument doesn't have the GPIO information in it. Instead, the user must
      use "sf probe <cs | gpio << 8>". For example, if bank 2 gpio 30 is used to force
      cs high on cs 0, bus 0, then instead of typing "sf probe 0" the user now must
      type "sf probe 15872".
      
      This is inconsistent with the description of the sf probe command, and forces
      the user to be aware of implementaiton details.
      
      Fix this by introducing a new board function: board_spi_cs_gpio(), which will
      accept a naked CS value, and provide the driver with the relevant GPIO, if one
      is necessary.
      
      Cc: Eric Nelson <eric.nelson@boundarydevices.com>
      Cc: Eric Benard <eric@eukrea.com>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Tim Harvey <tharvey@gateworks.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Tom Rini <trini@ti.com>
      Cc: Marek Vasut <marex@denx.de>
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarNikita Kiryanov <nikita@compulab.co.il>
      Reviewed-by: default avatarJagannadha Sutradharudu Teki <jaganna@xilinx.com>
      155fa9af
  7. Sep 09, 2014
  8. Aug 20, 2014
    • Tim Harvey's avatar
      imx: ventana: add econfig command · 9c0fe83e
      Tim Harvey authored
      
      The Gateworks Ventana EEPROM contains a set of configuration bits that
      affect the removal of device-tree nodes that support peripherals that do not
      exist on sub-loaded boards. This patch adds:
       - a structure to define a config bit name, dt node alias, bit position
       - an array of supported configuration items
       - an econfig command to get/set/list configuration bits
       - use of the array when adjusting the FDT prior to boot
      
      Signed-off-by: default avatarTim Harvey <tharvey@gateworks.com>
      9c0fe83e
  9. Jun 06, 2014
    • Tim Harvey's avatar
      imx: ventana: switch to SPL · 0cc11dea
      Tim Harvey authored
      
      Switch to an SPL image. The SPL for Ventana does the following:
       - setup i2c and read the factory programmed EEPROM to obtain DRAM config
         and model for board-specific calibration data
       - configure DRAM per CPU/size/layout/devices/calibration
       - load u-boot.img from NAND and jump to it
      
      This allows for a single SPL+u-boot.img to replace the previous multiple boa
      configurations.
      
      Cc: Stefan Roese <sr@denx.de>
      Cc: Otavio Salvador <otavio@ossystems.com.br>
      Cc: Andy Ng <andreas2025@gmail.com>
      Cc: Eric Nelson <eric.nelson@boundarydevices.com>
      Cc: Tapani Utriainen <tapani@technexion.com>
      Cc: Tom Rini <trini@ti.com>
      
      Signed-off-by: default avatarTim Harvey <tharvey@gateworks.com>
      0cc11dea
  10. Jun 01, 2014
    • Stephen Warren's avatar
      usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY · 77b83e6d
      Stephen Warren authored
      
      Now that we wait the correct specification-mandated time at the end of
      usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
      no purpose.
      
      For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
      so this change is safe.
      
      For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
      iff pgood_delay was at least 200ms. I'm not sure if this is the case or
      not, hence I've CC'd relevant people to test this change.
      
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Tim Harvey <tharvey@gateworks.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      77b83e6d
  11. May 09, 2014
  12. Mar 12, 2014
Loading