1. 08 9月, 2012 1 次提交
  2. 11 8月, 2012 1 次提交
  3. 15 5月, 2012 5 次提交
  4. 29 3月, 2012 8 次提交
    • Y
      tegra: i2c: Add I2C driver · 96a78ac0
      Yen Lin 提交于
      Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
      The driver requires CONFIG_OF_CONTROL to obtain its configuration
      from the device tree.
      
      (Simon Glass: sjg@chromium.org modified for upstream)
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Acked-by: NHeiko Schocher <hs@denx.de>
      Acked-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      96a78ac0
    • S
      fdt: Add function to allow aliases to refer to multiple nodes · c6782270
      Simon Glass 提交于
      Some devices can deal with multiple compatible properties. The devices
      need to know which nodes to bind to which features. For example an
      I2C driver which supports two different controller types will want to
      know which type it is dealing with in each case.
      
      The new fdtdec_add_aliases_for_id() function deals with this by allowing
      the driver to search for additional compatible nodes for a different ID.
      It can then detect the new ones and perform appropriate processing.
      
      Another option considered was to return a tuple (node offset, compat id)
      and have the function be passed a list of compatible IDs. This is more
      overhead for the common case though. We may add such a function later if
      more drivers in U-Boot require it.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      c6782270
    • S
      fdt: Avoid early panic() when there is no FDT present · 9a263e55
      Simon Glass 提交于
      CONFIG_OF_CONTROL requires a valid device tree. However, we cannot call
      panic() before the console is set up since the message does not appear,
      and we get a silent failure.
      
      Remove the panic from fdtdec_check_fdt() and provide a new function to
      prepare the fdt for use. This will be called after the console is ready.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      9a263e55
    • S
      tegra: usb: Add support for Tegra USB peripheral · 87f938c9
      Simon Glass 提交于
      This adds basic support for the Tegra2 USB controller. Board files should
      call board_usb_init() to set things up.
      
      Configuration is performed through the FDT, with aliases used to set the
      order of the ports, like this fragment:
      
              aliases {
      		/* This defines the order of our USB ports */
                      usb0 = "/usb@0xc5008000";
                      usb1 = "/usb@0xc5000000";
              };
      
      drivers/usb/host files ONLY: Acked-by: Remy Bohmer <linux@bohmer.net>
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      87f938c9
    • S
      fdt: Add basic support for decoding GPIO definitions · ed3ee5cd
      Simon Glass 提交于
      This adds some support into fdtdec for reading GPIO definitions from
      the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
      is of the form:
      
      gpio-function-name = <phandle gpio_num flags>;
      
      where:
      
      phandle is a pointer to the GPIO node
      gpio_num is the number of the GPIO (0 to 223)
      flags is a flag, as follows:
      
         bit    meaning
         0      0=polarity normal, 1=active low (inverted)
      
      An example is:
      
      enable-propounder-gpios = <&gpio 43 0>;
      
      which means that GPIO 43 is used to enable the propounder (setting the
      GPIO high), or that you can detect that the propounder is enabled by
      checking if the GPIO is high (the fdt does not indicate input/output).
      
      Two main functions are provided:
      
      fdtdec_decode_gpio() reads a GPIO property from an fdt node and decodes it
      into a structure.
      
      fdtdec_setup_gpio() sets up the GPIO by calling gpio_request for you.
      
      Both functions can cope with the property being missing, which is taken to
      mean that that GPIO function is not available or is not needed.
      
      [For reference, from Stephen Warren <swarren@nvidia.com>. It may be that
      we add this extra complexity later if needed:
      
      The correct way to parse such a GPIO property in general is:
      
      * Read the first cell.
      * Find the node referenced by the phandle (the controller).
      * Ensure property gpio-controller is present in the controller node.
      * Read property #gpio-cells from the controller node.
      * Extract #gpio-cells from the original property.
      * Keep processing more cells from the original property; there may be
      multiple GPIOs listed.
      
      According to the binding documentation in the Linux kernel, Samsung
      Exynos4 doesn't use this format, and while all other chips do have a
      flags cell, about 50% of the controllers indicate the cell is unused.
      ]
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      ed3ee5cd
    • S
      fdt: Add functions to access phandles, arrays and bools · d17da655
      Simon Glass 提交于
      Add a function to look up a property which is a phandle in a node, and
      another to read a fixed-length integer array from an fdt property.
      Also add a function to read boolean properties, although there is no
      actual boolean type in U-Boot.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Acked-by: NGerald Van Baren <vanbaren@cideas.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      d17da655
    • S
      fdt: Tidy up a few fdtdec problems · f88fe2de
      Simon Glass 提交于
      This fixes five trivial issues in fdtdec.c:
      1. fdtdec_get_is_enabled() doesn't really need a default value
      2. The fdt must be word-aligned, since otherwise it will fail on ARM
      3. The compat_names[] array is missing its first element. This is needed
      only because the first fdt_compat_id is defined to be invalid.
      4. Added a header prototype for fdtdec_next_compatible()
      5. Change fdtdec_next_alias() to only increment its 'upto' parameter
      on success, to make the display error messages in the caller easier.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Acked-by: NGerald Van Baren <vanbaren@cideas.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      f88fe2de
    • S
      fdt: Add fdtdec_find_aliases() to deal with alias nodes · a53f4a29
      Simon Glass 提交于
      Stephen Warren pointed out that we should use nodes whether or not they
      have an alias in the /aliases section. The aliases section specifies the
      order so far as it can, but is not essential. Operating without alisses
      is useful when the enumerated order of nodes does not matter (admittedly
      rare in U-Boot).
      
      This is considerably more complex, and it is important to keep this
      complexity out of driver code. This patch creates a function
      fdtdec_find_aliases() which returns an ordered list of node offsets
      for a particular compatible ID, taking account of alias nodes.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NTom Warren <twarren@nvidia.com>
      a53f4a29
  5. 27 10月, 2011 1 次提交
    • S
      fdt: add decode helper library · b5220bc6
      Simon Glass 提交于
      This library provides useful functions to drivers which want to use
      the fdt to control their operation. Functions are provided to:
      
      - look up and enumerate a device type (for example assigning i2c bus 0,
           i2c bus 1, etc.)
      - decode basic types from the fdt, like addresses and integers
      
      While this library is not strictly necessary, it helps to minimise the
      changes to a driver, in order to make it work under fdt control. Less
      code is required, and so the barrier to switch drivers over is lower.
      
      Additional functions to read arrays and GPIOs could be made available
      here also.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      b5220bc6