1. 21 Jul, 2015 1 commit
    • Masahiro Yamada's avatar
      dm: change dm_warn() message into debug() in uclass_add() · 643e6902
      Masahiro Yamada authored
      The command "dm uclass" tries to display all the UClasses, but
      some of them might be disabled by Kconfig.
      The function do_dm_dump_uclass() iterates over all the UClass IDs
      and calls uclass_get() for each of them.  Then, it displays annoying
      message "Cannot find uclass for id ..." every time it fails to get
      the UClass.
      As a result, we get much noisier log for the "dm uclass" command.
        => dm uclass
        uclass 0: root
        - * root_driver @ bfb54028, seq 0, (req -1)
        Cannot find uclass for id 1: please add the UCLASS_DRIVER() ...
        Cannot find uclass for id 2: please add the UCLASS_DRIVER() ...
        Cannot find uclass for id 3: please add the UCLASS_DRIVER() ...
        Cannot find uclass for id 4: please add the UCLASS_DRIVER() ...
        Cannot find uclass for id 5: please add the UCLASS_DRIVER() ...
        Cannot find uclass for id 6: please add the UCLASS_DRIVER() ...
      This commit suppresses these warnings.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
  2. 28 Apr, 2015 1 commit
    • Simon Glass's avatar
      dm: core: Correct bug introduced in uclass_first/next_device() · f66529f9
      Simon Glass authored
      These functions now rely on uclass_find_first/next_device() and assume that
      they will either return failure (-ve error code) or a device. In fact,
      coming to the end of a list is not considered failure and they return 0
      in that case.
      The logic to deal with this was replaced in commit acb9ca2a with just using
      uclass_get_device_tail(). Add back the missing logic. This bug was
      caught by unit tests but since they were broken for other reasons at the
      time, this was not noticed.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  3. 23 Apr, 2015 1 commit
  4. 22 Apr, 2015 5 commits
  5. 17 Apr, 2015 1 commit
    • Simon Glass's avatar
      dm: core: Add a uclass pre_probe() method for devices · 02c07b37
      Simon Glass authored
      Some uclasses want to set up a device before it is probed. Add a method
      for this.
      An example is with PCI, where a PCI uclass wants to set up its private
      data for later use. This allows the device's uclass() method to make calls
      whcih use that data (for example, read PCI memory regions from device
      tree, set up bus numbers).
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  6. 30 Jan, 2015 2 commits
  7. 22 Oct, 2014 1 commit
  8. 23 Jul, 2014 4 commits
    • Simon Glass's avatar
      dm: Avoid accessing uclasses before they are ready · c910e2e2
      Simon Glass authored
      Don't allow access to uclasses before they have been initialised.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: Allow a device to be found by its FDT offset · f4cdead2
      Simon Glass authored
      Each device that was bound from a device tree has an node that caused it to
      be bound. Add functions that find and return a device based on a device tree
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: Introduce device sequence numbering · 5a66a8ff
      Simon Glass authored
      In U-Boot it is pretty common to number devices from 0 and access them
      on the command line using this numbering. While it may come to pass that
      we will move away from this numbering, the possibility seems remote at
      Given that devices within a uclass will have an implied numbering, it
      makes sense to build this into driver model as a core feature. The cost
      is fairly small in terms of code and data space.
      With each uclass having numbered devices we can ask for SPI port 0 or
      serial port 1 and receive a single device.
      Devices typically request a sequence number using aliases in the device
      tree. These are resolved when the device is probed, to deal with conflicts.
      Sequence numbers need not be sequential and holes are permitted.
      At present there is no support for sequence numbers using static platform
      data. It could easily be added to 'struct driver_info' if needed, but it
      seems better to add features as we find a use for them, and the use of -1
      to mean 'no sequence' makes the default value somewhat painful.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: Move uclass error checking/probing into a function · 9ca296a1
      Simon Glass authored
      Several functions will use this same pattern, so bring it into a function.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  9. 20 Jun, 2014 1 commit
  10. 27 May, 2014 1 commit
    • Heiko Schocher's avatar
      dm: rename device struct to udevice · 54c5d08a
      Heiko Schocher authored
      using UBI and DM together leads in compiler error, as
      both define a "struct device", so rename "struct device"
      in include/dm/device.h to "struct udevice", as we use
      linux code (MTD/UBI/UBIFS some USB code,...) and cannot
      change the linux "struct device"
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Marek Vasut <marex@denx.de>
  11. 04 Mar, 2014 1 commit