07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

01 Jun, 2017

3 commits


04 Jun, 2016

1 commit

  • 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: Mario Six
    Reviewed-by: Simon Glass
    Reviewed-by: York Sun

    mario.six@gdsys.cc
     

17 May, 2016

1 commit

  • Many drivers use a common form of offset + flags for device
    tree nodes. e.g.:

    This patch adds a common implementation of this type of parsing
    and calls it when a gpio driver doesn't supply its' own xlate
    routine.

    This will allow removal of the driver-specific versions in a
    handful of drivers and simplify the addition of new drivers.

    Signed-off-by: Eric Nelson
    Reviewed-by: Stephen Warren
    Acked-by: Simon Glass

    Eric Nelson
     

17 Mar, 2016

2 commits


22 Jul, 2015

2 commits


04 Jun, 2015

1 commit


15 May, 2015

1 commit


14 May, 2015

1 commit


30 Jan, 2015

4 commits

  • Add a deprecation notice to each function so that it is more obvious that we
    are moving GPIOs to driver model.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • 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 = ;

    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: Simon Glass

    Simon Glass
     
  • 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
    polarity.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • 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: Simon Glass

    Simon Glass
     

21 Nov, 2014

1 commit


27 Oct, 2014

1 commit


26 Oct, 2014

1 commit


24 Oct, 2014

5 commits


23 Oct, 2014

1 commit


01 Sep, 2014

1 commit

  • The GPIO list is very long in many cases and most of them are not used.
    By default, show only the GPIOs that are in use, and provide a flag to show
    all of them. This makes the 'gpio status' command much more pleasant.

    In order to do this, driver model now exposes a method for obtaining the
    'function' of a GPIO, which describes whether it is an input or output, for
    example. Implementation of this method is optional.

    Signed-off-by: Simon Glass

    Simon Glass
     

27 May, 2014

1 commit

  • 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: Heiko Schocher
    Cc: Simon Glass
    Cc: Marek Vasut

    Heiko Schocher
     

05 Mar, 2014

1 commit

  • Add driver model support for GPIOs. Since existing GPIO drivers do not use
    driver model, this feature must be enabled by CONFIG_DM_GPIO. After all
    GPO drivers are converted over we can perhaps remove this config.

    Tests are provided for the sandbox implementation, and are a sufficient
    sanity check for basic operation.

    The GPIO uclass understands the concept of named banks of GPIOs, with each
    GPIO device providing a single bank. Within each bank the GPIOs are numbered
    using an offset from 0 to n-1. For example a bank named 'b' with 20
    offsets will provide GPIOs named b0 to b19.

    Anonymous GPIO banks are also supported, and are just numbered without any
    prefix.

    Each time a GPIO driver is added to the uclass, the GPIOs are renumbered
    accordinging, so there is always a global GPIO numbering order.

    Signed-off-by: Simon Glass
    Signed-off-by: Marek Vasut
    Signed-off-by: Pavel Herrmann
    Signed-off-by: Viktor Křivák
    Signed-off-by: Tomas Hlavacek

    Simon Glass
     

24 Jul, 2013

1 commit


12 Dec, 2012

1 commit


22 Sep, 2012

1 commit


10 Jan, 2012

1 commit


18 Oct, 2011

1 commit