15 Nov, 2018

1 commit

  • When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
    bound before relocation. However due to a bug in the DM core,
    the flag only takes effect when devices are statically declared
    via U_BOOT_DEVICE(). This bug has been fixed recently by commit
    "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
    lists_bind_fdt()", but with the fix, it has a side effect that
    all existing drivers that declared DM_FLAG_PRE_RELOC flag will
    be bound before relocation now. This may expose potential boot
    failure on some boards due to insufficient memory during the
    pre-relocation stage.

    To mitigate this potential impact, the following changes are
    implemented:

    - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
    only supports configuration from device tree (OF_CONTROL)
    - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
    is statically declared via U_BOOT_DEVICE()
    - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
    drivers that support both statically declared devices and
    configuration from device tree

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass
    Reviewed-by: Patrick Delaunay

    Bin Meng
     

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
     

28 Apr, 2018

1 commit


29 Jul, 2017

1 commit


01 Jun, 2017

2 commits

  • Move the main part of the GPIO request function into a separate function
    so that it can be used by the live tree function when added. Update the
    xlate method to use a node reference.

    Update all GPIO drivers to handle the modified xlate() method.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • These support the flat device tree. We want to use the dev_read_..()
    prefix for functions that support both flat tree and live tree. So rename
    the existing functions to avoid confusion.

    In the end we will have:

    1. dev_read_addr...() - works on devices, supports flat/live tree
    2. devfdt_get_addr...() - current functions, flat tree only
    3. of_get_address() etc. - new functions, live tree only

    All drivers will be written to use 1. That function will in turn call
    either 2 or 3 depending on whether the flat or live tree is in use.

    Note this involves changing some dead code - the imx_lpi2c.c file.

    Signed-off-by: Simon Glass

    Simon Glass
     

08 Feb, 2017

1 commit

  • At present devices use a simple integer offset to record the device tree
    node associated with the device. In preparation for supporting a live
    device tree, which uses a node pointer instead, refactor existing code to
    access this field through an inline function.

    Signed-off-by: Simon Glass

    Simon Glass
     

17 Feb, 2016

1 commit

  • The tegra GPIO controller has two ways of reading the value of a GPIO. It
    can supply the 'input' value (which is the value read from the pin) and the
    'output' value (which is the value being driven from the pin. With a GPIO
    set to output mode, the 'input' value is always low which is not very
    useful.

    This has the unfortunate result that setting a GPIO high still leaves it
    showing as low in the 'gpio status' command.

    Adjust the driver to check which direction the GPIO is set to, then read
    the value from the appropriate register: 'input' for input GPIOs, 'output'
    for output GPIOs.

    Signed-off-by: Simon Glass
    Reviewed-by: Joe Hershberger
    Signed-off-by: Tom Warren

    Simon Glass
     

03 Oct, 2015

4 commits

  • In order to make it clear what the parameters to set_config() and
    set_direction() mean, and similarly for the return values from the
    respective get_*(), define named constants for these values.

    Disassembly shows no diff in the generated code, except that the
    order of the code in the branches of tegra_gpio_get_function() gets
    modified without affecting behaviour.

    Suggested-by: Tom Warren
    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • These enum values aren't used anywhere. Remove them.

    Signed-off-by: Stephen Warren
    Reviewed-by: Simon Glass
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • Tegra's GPIO driver currently enables pins as GPIO as soon as they're
    requested. This is not safe, since the desired direction and output value
    are not yet known. This could cause a glitch on the output pins between
    gpio_request() and gpio_direction_*(), depending on what values happen to
    be in the GPIO controller's in/out and out-value registers vs. the final
    desired configuration.

    To solve this, defer enabling pins as GPIOs until some gpio_direction_*()
    is invoked, and the desired configuration is explicitly programmed.

    In theory this change could cause regressions, if code exists that claims
    a GPIO, never explicitly sets a direction, and then gets/sets the GPIO
    value based on that assumption. However, I've read through all the Tegra-
    related board files and device drivers that touch GPIOs and I do not see
    such buggy code anywhere.

    Signed-off-by: Stephen Warren
    Reviewed-by: Simon Glass
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • Tegra's gpio_config_table() currently uses common GPIO APIs. These used
    to work without requesting the GPIO, but since commit 2fccd2d96bad "tegra:
    Convert tegra GPIO driver to use driver model" no longer do so. This
    prevents any of the GPIO initialization table from being applied to HW.
    Fix gpio_config_table() to directly program the HW to solve this.

    Fixes: 2fccd2d96bad ("tegra: Convert tegra GPIO driver to use driver model")
    Signed-off-by: Stephen Warren
    Reviewed-by: Simon Glass
    Signed-off-by: Tom Warren

    Stephen Warren
     

31 Aug, 2015

1 commit

  • This is a convenient way for a driver to get the hardware address of a
    device, when regmap or syscon are not being used. Change existing callers
    to use it as an example to others.

    Signed-off-by: Simon Glass
    Reviewed-by: Joe Hershberger
    Acked-by: Stephen Warren

    Simon Glass
     

17 Apr, 2015

1 commit


05 Mar, 2015

1 commit


30 Jan, 2015

1 commit


24 Oct, 2014

1 commit


23 Oct, 2014

1 commit

  • Fix Tegra GPIO driver to not crash resp. misbehave upon requesting
    GPIOs with an empty aka NULL label. As the driver uses exclusively the
    label to check for reservation status actually supplying one is
    mandatory!

    This fixes a regression introduced by commit:

    2fccd2d96badcdf6165658a99771a4c475586279
    tegra: Convert tegra GPIO driver to use driver model

    Signed-off-by: Marcel Ziswiler
    Acked-by: Simon Glass
    Signed-off-by: Tom Warren

    Marcel Ziswiler
     

11 Sep, 2014

1 commit

  • This is an implementation of GPIOs for Tegra that uses driver model. It has
    been tested on trimslice and also using the new iotrace feature.

    The implementation uses a top-level GPIO device (which has no actual GPIOS).
    Under this all the banks are created as separate GPIO devices.

    The GPIOs are named as per the Tegra datasheet/header files: A0..A7, B0..B7,
    ..., Z0..Z7, AA0..AA7, etc.

    Since driver model is not yet available before relocation, or in SPL, a
    special function is provided for seaboard's SPL code.

    Signed-off-by: Simon Glass

    Simon Glass
     

14 May, 2014

1 commit

  • The HW-defined procedure for booting Tegra requires that some pins be
    set up as GPIOs immediately at boot in order to avoid glitches on those
    pins, when the pinmux is programmed. Add a feature to the GPIO driver
    which executes a GPIO configuration table. Board files will use this to
    implement the correct HW initialization procedure.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     

24 Jul, 2013

1 commit


16 Oct, 2012

1 commit

  • The move is pretty straight-forward. ap20.h and tegra20.h were renamed to ap.h and tegra.h.
    Some files remain in arch-tegra20 but 'include' a file in 'arch-tegra' with #defines & structs
    that will be common between T20 and T30 HW. HW-specific #defines, etc. stay in the 'arch-tegra20'
    'root' file.

    All boards build OK w/MAKEALL -s tegra20. Checkpatch.pl runs clean. Seaboard works OK.

    Signed-off-by: Tom Warren

    Tom Warren
     

11 Sep, 2012

1 commit


01 Sep, 2012

1 commit

  • This is make naming consistent with the kernel and devicetree and in
    preparation of pulling out the common tegra20 code.

    Signed-off-by: Allen Martin
    Acked-by: Stephen Warren
    Tested-by: Thierry Reding
    Signed-off-by: Tom Warren

    Allen Martin
     

07 Jul, 2012

1 commit