Skip to content
Snippets Groups Projects
  • Simon Glass's avatar
    ed3ee5cd
    fdt: Add basic support for decoding GPIO definitions · ed3ee5cd
    Simon Glass authored
    
    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: default avatarSimon Glass <sjg@chromium.org>
    Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
    ed3ee5cd
    History
    fdt: Add basic support for decoding GPIO definitions
    Simon Glass authored
    
    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: default avatarSimon Glass <sjg@chromium.org>
    Signed-off-by: default avatarTom Warren <twarren@nvidia.com>