1. 07 Sep, 2016 1 commit
  2. 15 Jul, 2016 1 commit
  3. 06 Jun, 2016 1 commit
  4. 04 Jun, 2016 1 commit
    • mario.six@gdsys.cc's avatar
      dm: gpio: Add methods for open drain setting · 53ecdfb9
      mario.six@gdsys.cc authored
      Certain GPIO devices have the capability to switch their GPIOs into
      open-drain mode, that is, instead of actively driving the output
      (Push-pull output), the pin is connected to the collector (for a NPN
      transistor) or the drain (for a MOSFET) of a transistor, respectively.
      The pin then either forms an open circuit or a connection to ground,
      depending on the state of the transistor.
      This patch adds functions to the GPIO uclass to switch GPIOs to
      open-drain mode on devices that support it.
      Signed-off-by: default avatarMario Six <mario.six@gdsys.cc>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarYork Sun <york.sun@nxp.com>
  5. 17 May, 2016 1 commit
  6. 17 Mar, 2016 2 commits
  7. 08 Feb, 2016 1 commit
  8. 06 Feb, 2016 1 commit
  9. 21 Jan, 2016 1 commit
  10. 15 Dec, 2015 1 commit
    • York Sun's avatar
      Reserve secure memory · e8149522
      York Sun authored
      Secure memory is at the end of memory, separated and reserved
      from OS, tracked by gd->secure_ram. Secure memory can host
      MMU tables, security monitor, etc. This is different from PRAM
      used to reserve private memory. PRAM offers memory at the top
      of u-boot memory, not necessarily the real end of memory for
      systems with very large DDR. Using the end of memory simplifies
      MMU setup and avoid memory fragmentation.
      "bdinfo" command shows gd->secure_ram value if this memory is
      marked as secured.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
  11. 20 Nov, 2015 1 commit
    • Simon Glass's avatar
      console: Add a console buffer · 9854a874
      Simon Glass authored
      It is useful to be able to record console output and provide console input
      via a buffer. This provides sandbox with the ability to run a command and
      check its output. If the console is set to silent then no visible output
      is generated.
      This also provides a means to fix the problem where tests produce unwanted
      output, such as errors or warnings. This can be confusing. We can instead
      set the console to silent and record this output. It can be checked later
      in the test if required.
      It is possible that this may prove useful for non-test situations. For
      example the console output may be suppressed for normal operations, but
      recorded and stored for access by the OS. That feature is not implemented
      at present.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  12. 05 Nov, 2015 1 commit
  13. 04 Nov, 2015 1 commit
    • Simon Glass's avatar
      dm: spl: Support device tree when BSS is in a different section · 10172962
      Simon Glass authored
      At present in SPL we place the device tree immediately after BSS. This
      avoids needing to copy it out of the way before BSS can be used. However on
      some boards BSS is not placed with the image - e.g. it can be in RAM if
      Add an option to tell U-Boot that the device tree should be placed at the
      end of the image binary (_image_binary_end) instead of at the end of BSS.
      Note: A common reason to place BSS in RAM is to support the FAT filesystem.
      We should update the code so that it does not use so much BSS.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
  14. 22 Oct, 2015 1 commit
  15. 21 Oct, 2015 1 commit
    • Jagan Teki's avatar
      linux/bitops.h: GENMASK copy from linux · 89b5c81b
      Jagan Teki authored
      GENMASK is used to create a contiguous bitmask([hi:lo]).
      This patch is a copy from Linux, with below commit details
      "bitops: Fix shift overflow in GENMASK macros"
      (sha1: 00b4d9a14125f1e51874def2b9de6092e007412d)
      Cc: Tom Rini <trini@konsulko.com>
      Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
      Signed-off-by: default avatarJagan Teki <jteki@openedev.com>
  16. 17 Aug, 2015 1 commit
  17. 14 Aug, 2015 2 commits
  18. 05 Aug, 2015 2 commits
  19. 21 Jul, 2015 3 commits
  20. 15 Jul, 2015 1 commit
  21. 04 Jun, 2015 1 commit
  22. 15 May, 2015 1 commit
  23. 13 May, 2015 1 commit
  24. 06 Mar, 2015 2 commits
  25. 17 Feb, 2015 1 commit
  26. 30 Jan, 2015 5 commits
    • Martin Dorwig's avatar
      Export redesign · 49cad547
      Martin Dorwig authored
      this is an atempt to make the export of functions typesafe.
      I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
      The EXPORT_FUNC macro now has 3 fixed parameters and one
      variadic parameter
      The first is the name of the exported function,
      the rest of the parameters are used to format a functionpointer
      in the jumptable,
      the EXPORT_FUNC macros are expanded three times,
      1. to declare the members of the struct
      2. to initialize the structmember pointers
      3. to call the functions in stubs.c
      Signed-off-by: default avatarMartin Dorwig <dorwig@tetronik.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      (resending to the list since my tweaks are not quite trivial)
    • Simon Glass's avatar
      dm: gpio: Mark the old GPIO API deprecated · 5d1c17e9
      Simon Glass authored
      Add a deprecation notice to each function so that it is more obvious that we
      are moving GPIOs to driver model.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: gpio: Add better functions to request GPIOs · 3669e0e7
      Simon Glass authored
      At present U-Boot sort-of supports the standard way of reading GPIOs from
      device tree nodes, but the support is incomplete, a bit clunky and only
      works for GPIO bindings where #gpio-cells is 2.
      Add new functions to request GPIOs, taking full account of the device
      tree binding. These permit requesting a GPIO with a simple call like:
         gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN);
      This will request the GPIO, looking at the device's node which might be
      this, for example:
         cd-gpios = <&gpio TEGRA_GPIO(B, 3) GPIO_ACTIVE_LOW>;
      The GPIO will be set to input mode in this case and polarity will be
      honoured by the GPIO calls.
      It is also possible to request and free a list of GPIOs.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: gpio: Add a driver GPIO translation method · 0dac4d51
      Simon Glass authored
      Only the GPIO driver knows about the full GPIO device tree binding used by
      a device. Add a method to allow the driver to provide this information to the
      uclass, including the GPIO offset within the device and flags such as the
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: gpio: Add a native driver model API · ae7123f8
      Simon Glass authored
      So far driver model's GPIO uclass just implements the existing GPIO API.
      This has some limitations:
      - it requires manual device tree munging to support GPIOs in device tree
          (fdtdec_get_gpio() and friends)
      - it does not understand polarity
      - it is somewhat slower since we must scan for the GPIO device each time
      - Global GPIO numbering can change if other GPIO drivers are probed
      - it requires extra steps to set the GPIO direction and value
      The new functions have a dm_ prefix where necessary to avoid name conflicts
      but we can remove that when it is no-longer needed. The new struct gpio_desc
      holds all required information about the GPIO. For now this is intended to
      be stored by the client requesting the GPIO, but in future it might be
      brought into the uclass in some way.
      With these changes the old GPIO API still works, and uses the driver model
      API underneath.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  27. 28 Jan, 2015 1 commit
  28. 13 Jan, 2015 1 commit
    • Bin Meng's avatar
      pci: Make pci apis usable before relocation · 8f9052fd
      Bin Meng authored
      Introduce a gd->hose to save the pci hose in the early phase so that
      apis in drivers/pci/pci.c can be used before relocation. Architecture
      codes need assign a valid gd->hose in the early phase.
      Some variables are declared as static so change them to be either
      stack variable or global data member so that they can be used before
      relocation, except the 'indent' used by CONFIG_PCI_SCAN_SHOW which
      just affects some print format.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
  29. 21 Nov, 2014 2 commits
    • Simon Glass's avatar
      dm: Split the simple malloc() implementation into its own file · c9356be3
      Simon Glass authored
      The simple malloc() implementation is used when memory is tight. It provides
      a simple buffer with an incrementing pointer.
      At present the implementation is inside dlmalloc. Move it into its own file
      so that it is easier to find.
      Rather than using relocation as a signal that the full malloc() is
      available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the
      simple malloc() should no longer be used.
      In some cases, such as SPL, even the code space used by the full malloc() is
      wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple
      malloc. In this case the full malloc is not available at all. It saves about
      1KB of code space and about 0.5KB of data on Thumb 2.
      Acked-by: default avatarTom Rini <trini@ti.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: gpio: Add a function to read an ID from a list of GPIOs · e5901c94
      Simon Glass authored
      For board IDs a common approach is to set aside several GPIOs for use in
      determining the board ID. This can provide information about board features
      and the revision.
      Add a function that turns a list of GPIOs into an integer by assigning
      each GPIO to a single bit.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>