OpenCloudOS-Kernel/drivers/pinctrl/aspeed/pinctrl-aspeed.c

659 lines
16 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2016 IBM Corp.
*/
#include <linux/mfd/syscon.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/string.h>
#include "../core.h"
#include "pinctrl-aspeed.h"
int aspeed_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
return pdata->pinmux.ngroups;
}
const char *aspeed_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
unsigned int group)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
return pdata->pinmux.groups[group].name;
}
int aspeed_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
unsigned int group, const unsigned int **pins,
unsigned int *npins)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
*pins = &pdata->pinmux.groups[group].pins[0];
*npins = pdata->pinmux.groups[group].npins;
return 0;
}
void aspeed_pinctrl_pin_dbg_show(struct pinctrl_dev *pctldev,
struct seq_file *s, unsigned int offset)
{
seq_printf(s, " %s", dev_name(pctldev->dev));
}
int aspeed_pinmux_get_fn_count(struct pinctrl_dev *pctldev)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
return pdata->pinmux.nfunctions;
}
const char *aspeed_pinmux_get_fn_name(struct pinctrl_dev *pctldev,
unsigned int function)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
return pdata->pinmux.functions[function].name;
}
int aspeed_pinmux_get_fn_groups(struct pinctrl_dev *pctldev,
unsigned int function,
const char * const **groups,
unsigned int * const num_groups)
{
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
*groups = pdata->pinmux.functions[function].groups;
*num_groups = pdata->pinmux.functions[function].ngroups;
return 0;
}
pinctrl: aspeed-g5: Delay acquisition of regmaps While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-24 16:01:55 +08:00
static int aspeed_sig_expr_enable(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr)
{
int ret;
pr_debug("Enabling signal %s for %s\n", expr->signal,
expr->function);
ret = aspeed_sig_expr_eval(ctx, expr, true);
if (ret < 0)
return ret;
if (!ret)
return aspeed_sig_expr_set(ctx, expr, true);
pinctrl: aspeed: "Not enabled" is a significant mux state Consider a scenario with one pin P that has two signals A and B, where A is defined to be higher priority than B: That is, if the mux IP is in a state that would consider both A and B to be active on P, then A will be the active signal. To instead configure B as the active signal we must configure the mux so that A is inactive. The mux state for signals can be described by logical operations on one or more bits from one or more registers (a "signal expression"), which in some cases leads to aliased mux states for a particular signal. Further, signals described by multi-bit bitfields often do not only need to record the states that would make them active (the "enable" expressions), but also the states that makes them inactive (the "disable" expressions). All of this combined leads to four possible states for a signal: 1. A signal is active with respect to an "enable" expression 2. A signal is not active with respect to an "enable" expression 3. A signal is inactive with respect to a "disable" expression 4. A signal is not inactive with respect to a "disable" expression In the case of P, if we are looking to activate B without explicitly having configured A it's enough to consider A inactive if all of A's "enable" signal expressions evaluate to "not active". If any evaluate to "active" then the corresponding "disable" states must be applied so it becomes inactive. For example, on the AST2400 the pins composing GPIO bank H provide signals ROMD8 through ROMD15 (high priority) and those for UART6 (low priority). The mux states for ROMD8 through ROMD15 are aliased, i.e. there are two mux states that result in the respective signals being configured: A. SCU90[6]=1 B. Strap[4,1:0]=100 Further, the second mux state is a 3-bit bitfield that explicitly defines the enabled state but the disabled state is implicit, i.e. if Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not considered active. This requires the mux function evaluation logic to use approach 2. above, however the existing code was using approach 3. The problem was brought to light on the Palmetto machines where the strap register value is 0x120ce416, and prevented GPIO requests in bank H from succeeding despite the hardware being in a position to allow them. Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-09-27 22:50:13 +08:00
return 0;
}
pinctrl: aspeed-g5: Delay acquisition of regmaps While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-24 16:01:55 +08:00
static int aspeed_sig_expr_disable(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr)
{
int ret;
pr_debug("Disabling signal %s for %s\n", expr->signal,
expr->function);
ret = aspeed_sig_expr_eval(ctx, expr, true);
if (ret < 0)
return ret;
if (ret)
return aspeed_sig_expr_set(ctx, expr, false);
pinctrl: aspeed: "Not enabled" is a significant mux state Consider a scenario with one pin P that has two signals A and B, where A is defined to be higher priority than B: That is, if the mux IP is in a state that would consider both A and B to be active on P, then A will be the active signal. To instead configure B as the active signal we must configure the mux so that A is inactive. The mux state for signals can be described by logical operations on one or more bits from one or more registers (a "signal expression"), which in some cases leads to aliased mux states for a particular signal. Further, signals described by multi-bit bitfields often do not only need to record the states that would make them active (the "enable" expressions), but also the states that makes them inactive (the "disable" expressions). All of this combined leads to four possible states for a signal: 1. A signal is active with respect to an "enable" expression 2. A signal is not active with respect to an "enable" expression 3. A signal is inactive with respect to a "disable" expression 4. A signal is not inactive with respect to a "disable" expression In the case of P, if we are looking to activate B without explicitly having configured A it's enough to consider A inactive if all of A's "enable" signal expressions evaluate to "not active". If any evaluate to "active" then the corresponding "disable" states must be applied so it becomes inactive. For example, on the AST2400 the pins composing GPIO bank H provide signals ROMD8 through ROMD15 (high priority) and those for UART6 (low priority). The mux states for ROMD8 through ROMD15 are aliased, i.e. there are two mux states that result in the respective signals being configured: A. SCU90[6]=1 B. Strap[4,1:0]=100 Further, the second mux state is a 3-bit bitfield that explicitly defines the enabled state but the disabled state is implicit, i.e. if Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not considered active. This requires the mux function evaluation logic to use approach 2. above, however the existing code was using approach 3. The problem was brought to light on the Palmetto machines where the strap register value is 0x120ce416, and prevented GPIO requests in bank H from succeeding despite the hardware being in a position to allow them. Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-09-27 22:50:13 +08:00
return 0;
}
/**
* aspeed_disable_sig() - Disable a signal on a pin by disabling all provided
* signal expressions.
*
* @ctx: The pinmux context
* @exprs: The list of signal expressions (from a priority level on a pin)
*
* Return: 0 if all expressions are disabled, otherwise a negative error code
*/
pinctrl: aspeed-g5: Delay acquisition of regmaps While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-24 16:01:55 +08:00
static int aspeed_disable_sig(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr **exprs)
{
int ret = 0;
if (!exprs)
return true;
while (*exprs && !ret) {
ret = aspeed_sig_expr_disable(ctx, *exprs);
exprs++;
}
return ret;
}
/**
* aspeed_find_expr_by_name - Search for the signal expression needed to
* enable the pin's signal for the requested function.
*
* @exprs: List of signal expressions (haystack)
* @name: The name of the requested function (needle)
*
* Return: A pointer to the signal expression whose function tag matches the
* provided name, otherwise NULL.
*
*/
static const struct aspeed_sig_expr *aspeed_find_expr_by_name(
const struct aspeed_sig_expr **exprs, const char *name)
{
while (*exprs) {
if (strcmp((*exprs)->function, name) == 0)
return *exprs;
exprs++;
}
return NULL;
}
static char *get_defined_attribute(const struct aspeed_pin_desc *pdesc,
const char *(*get)(
const struct aspeed_sig_expr *))
{
char *found = NULL;
size_t len = 0;
const struct aspeed_sig_expr ***prios, **funcs, *expr;
prios = pdesc->prios;
while ((funcs = *prios)) {
while ((expr = *funcs)) {
const char *str = get(expr);
size_t delta = strlen(str) + 2;
char *expanded;
expanded = krealloc(found, len + delta + 1, GFP_KERNEL);
if (!expanded) {
kfree(found);
return expanded;
}
found = expanded;
found[len] = '\0';
len += delta;
strcat(found, str);
strcat(found, ", ");
funcs++;
}
prios++;
}
if (len < 2) {
kfree(found);
return NULL;
}
found[len - 2] = '\0';
return found;
}
static const char *aspeed_sig_expr_function(const struct aspeed_sig_expr *expr)
{
return expr->function;
}
static char *get_defined_functions(const struct aspeed_pin_desc *pdesc)
{
return get_defined_attribute(pdesc, aspeed_sig_expr_function);
}
static const char *aspeed_sig_expr_signal(const struct aspeed_sig_expr *expr)
{
return expr->signal;
}
static char *get_defined_signals(const struct aspeed_pin_desc *pdesc)
{
return get_defined_attribute(pdesc, aspeed_sig_expr_signal);
}
int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
unsigned int group)
{
int i;
int ret;
pinctrl: aspeed-g5: Delay acquisition of regmaps While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-24 16:01:55 +08:00
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
const struct aspeed_pin_group *pgroup = &pdata->pinmux.groups[group];
const struct aspeed_pin_function *pfunc =
&pdata->pinmux.functions[function];
for (i = 0; i < pgroup->npins; i++) {
int pin = pgroup->pins[i];
const struct aspeed_pin_desc *pdesc = pdata->pins[pin].drv_data;
const struct aspeed_sig_expr *expr = NULL;
const struct aspeed_sig_expr **funcs;
const struct aspeed_sig_expr ***prios;
pr_debug("Muxing pin %s for %s\n", pdesc->name, pfunc->name);
if (!pdesc)
return -EINVAL;
prios = pdesc->prios;
if (!prios)
continue;
/* Disable functions at a higher priority than that requested */
while ((funcs = *prios)) {
expr = aspeed_find_expr_by_name(funcs, pfunc->name);
if (expr)
break;
ret = aspeed_disable_sig(&pdata->pinmux, funcs);
if (ret)
return ret;
prios++;
}
if (!expr) {
char *functions = get_defined_functions(pdesc);
char *signals = get_defined_signals(pdesc);
pr_warn("No function %s found on pin %s (%d). Found signal(s) %s for function(s) %s\n",
pfunc->name, pdesc->name, pin, signals,
functions);
kfree(signals);
kfree(functions);
return -ENXIO;
}
ret = aspeed_sig_expr_enable(&pdata->pinmux, expr);
if (ret)
return ret;
pr_debug("Muxed pin %s as %s for %s\n", pdesc->name, expr->signal,
expr->function);
}
return 0;
}
static bool aspeed_expr_is_gpio(const struct aspeed_sig_expr *expr)
{
/*
pinctrl: aspeed: Fix GPIO requests on pass-through banks Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Billy Tsai <billy_tsai@aspeedtech.com> Cc: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-26 14:33:37 +08:00
* We need to differentiate between GPIO and non-GPIO signals to
* implement the gpio_request_enable() interface. For better or worse
* the ASPEED pinctrl driver uses the expression names to determine
* whether an expression will mux a pin for GPIO.
*
pinctrl: aspeed: Fix GPIO requests on pass-through banks Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Billy Tsai <billy_tsai@aspeedtech.com> Cc: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-26 14:33:37 +08:00
* Generally we have the following - A GPIO such as B1 has:
*
* - expr->signal set to "GPIOB1"
* - expr->function set to "GPIOB1"
*
* Using this fact we can determine whether the provided expression is
* a GPIO expression by testing the signal name for the string prefix
* "GPIO".
*
* However, some GPIOs are input-only, and the ASPEED datasheets name
* them differently. An input-only GPIO such as T0 has:
*
* - expr->signal set to "GPIT0"
* - expr->function set to "GPIT0"
*
* It's tempting to generalise the prefix test from "GPIO" to "GPI" to
* account for both GPIOs and GPIs, but in doing so we run aground on
* another feature:
*
* Some pins in the ASPEED BMC SoCs have a "pass-through" GPIO
* function where the input state of one pin is replicated as the
* output state of another (as if they were shorted together - a mux
* configuration that is typically enabled by hardware strapping).
* This feature allows the BMC to pass e.g. power button state through
* to the host while the BMC is yet to boot, but take control of the
* button state once the BMC has booted by muxing each pin as a
* separate, pin-specific GPIO.
*
* Conceptually this pass-through mode is a form of GPIO and is named
* as such in the datasheets, e.g. "GPID0". This naming similarity
* trips us up with the simple GPI-prefixed-signal-name scheme
* discussed above, as the pass-through configuration is not what we
* want when muxing a pin as GPIO for the GPIO subsystem.
*
* On e.g. the AST2400, a pass-through function "GPID0" is grouped on
* balls A18 and D16, where we have:
*
* For ball A18:
* - expr->signal set to "GPID0IN"
* - expr->function set to "GPID0"
*
* For ball D16:
* - expr->signal set to "GPID0OUT"
* - expr->function set to "GPID0"
*
* By contrast, the pin-specific GPIO expressions for the same pins are
* as follows:
*
* For ball A18:
* - expr->signal looks like "GPIOD0"
* - expr->function looks like "GPIOD0"
*
* For ball D16:
* - expr->signal looks like "GPIOD1"
* - expr->function looks like "GPIOD1"
*
* Testing both the signal _and_ function names gives us the means
* differentiate the pass-through GPIO pinmux configuration from the
* pin-specific configuration that the GPIO subsystem is after: An
* expression is a pin-specific (non-pass-through) GPIO configuration
* if the signal prefix is "GPI" and the signal name matches the
* function name.
*/
pinctrl: aspeed: Fix GPIO requests on pass-through banks Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Billy Tsai <billy_tsai@aspeedtech.com> Cc: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-26 14:33:37 +08:00
return !strncmp(expr->signal, "GPI", 3) &&
!strcmp(expr->signal, expr->function);
}
static bool aspeed_gpio_in_exprs(const struct aspeed_sig_expr **exprs)
{
if (!exprs)
return false;
while (*exprs) {
if (aspeed_expr_is_gpio(*exprs))
return true;
exprs++;
}
return false;
}
int aspeed_gpio_request_enable(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned int offset)
{
int ret;
pinctrl: aspeed-g5: Delay acquisition of regmaps While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-24 16:01:55 +08:00
struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
const struct aspeed_pin_desc *pdesc = pdata->pins[offset].drv_data;
const struct aspeed_sig_expr ***prios, **funcs, *expr;
if (!pdesc)
return -EINVAL;
prios = pdesc->prios;
if (!prios)
return -ENXIO;
pr_debug("Muxing pin %s for GPIO\n", pdesc->name);
/* Disable any functions of higher priority than GPIO */
while ((funcs = *prios)) {
if (aspeed_gpio_in_exprs(funcs))
break;
ret = aspeed_disable_sig(&pdata->pinmux, funcs);
if (ret)
return ret;
prios++;
}
if (!funcs) {
char *signals = get_defined_signals(pdesc);
pr_warn("No GPIO signal type found on pin %s (%d). Found: %s\n",
pdesc->name, offset, signals);
kfree(signals);
return -ENXIO;
}
expr = *funcs;
/*
* Disabling all higher-priority expressions is enough to enable the
* lowest-priority signal type. As such it has no associated
* expression.
*/
if (!expr) {
pr_debug("Muxed pin %s as GPIO\n", pdesc->name);
return 0;
}
/*
* If GPIO is not the lowest priority signal type, assume there is only
* one expression defined to enable the GPIO function
*/
ret = aspeed_sig_expr_enable(&pdata->pinmux, expr);
if (ret)
return ret;
pr_debug("Muxed pin %s as %s\n", pdesc->name, expr->signal);
return 0;
}
int aspeed_pinctrl_probe(struct platform_device *pdev,
struct pinctrl_desc *pdesc,
struct aspeed_pinctrl_data *pdata)
{
struct device *parent;
struct pinctrl_dev *pctl;
parent = pdev->dev.parent;
if (!parent) {
dev_err(&pdev->dev, "No parent for syscon pincontroller\n");
return -ENODEV;
}
pdata->scu = syscon_node_to_regmap(parent->of_node);
if (IS_ERR(pdata->scu)) {
dev_err(&pdev->dev, "No regmap for syscon pincontroller parent\n");
return PTR_ERR(pdata->scu);
}
pdata->pinmux.maps[ASPEED_IP_SCU] = pdata->scu;
pctl = pinctrl_register(pdesc, &pdev->dev, pdata);
if (IS_ERR(pctl)) {
dev_err(&pdev->dev, "Failed to register pinctrl\n");
return PTR_ERR(pctl);
}
platform_set_drvdata(pdev, pdata);
return 0;
}
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
static inline bool pin_in_config_range(unsigned int offset,
const struct aspeed_pin_config *config)
{
return offset >= config->pins[0] && offset <= config->pins[1];
}
static inline const struct aspeed_pin_config *find_pinconf_config(
const struct aspeed_pinctrl_data *pdata,
unsigned int offset,
enum pin_config_param param)
{
unsigned int i;
for (i = 0; i < pdata->nconfigs; i++) {
if (param == pdata->configs[i].param &&
pin_in_config_range(offset, &pdata->configs[i]))
return &pdata->configs[i];
}
return NULL;
}
enum aspeed_pin_config_map_type { MAP_TYPE_ARG, MAP_TYPE_VAL };
static const struct aspeed_pin_config_map *find_pinconf_map(
const struct aspeed_pinctrl_data *pdata,
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
enum pin_config_param param,
enum aspeed_pin_config_map_type type,
s64 value)
{
int i;
for (i = 0; i < pdata->nconfmaps; i++) {
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
const struct aspeed_pin_config_map *elem;
bool match;
elem = &pdata->confmaps[i];
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
switch (type) {
case MAP_TYPE_ARG:
match = (elem->arg == -1 || elem->arg == value);
break;
case MAP_TYPE_VAL:
match = (elem->val == value);
break;
}
if (param == elem->param && match)
return elem;
}
return NULL;
}
int aspeed_pin_config_get(struct pinctrl_dev *pctldev, unsigned int offset,
unsigned long *config)
{
const enum pin_config_param param = pinconf_to_config_param(*config);
const struct aspeed_pin_config_map *pmap;
const struct aspeed_pinctrl_data *pdata;
const struct aspeed_pin_config *pconf;
unsigned int val;
int rc = 0;
u32 arg;
pdata = pinctrl_dev_get_drvdata(pctldev);
pconf = find_pinconf_config(pdata, offset, param);
if (!pconf)
return -ENOTSUPP;
rc = regmap_read(pdata->scu, pconf->reg, &val);
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
if (rc < 0)
return rc;
pmap = find_pinconf_map(pdata, param, MAP_TYPE_VAL,
(val & pconf->mask) >> __ffs(pconf->mask));
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
if (!pmap)
return -EINVAL;
if (param == PIN_CONFIG_DRIVE_STRENGTH)
arg = (u32) pmap->arg;
else if (param == PIN_CONFIG_BIAS_PULL_DOWN)
arg = !!pmap->arg;
else
arg = 1;
if (!arg)
return -EINVAL;
*config = pinconf_to_config_packed(param, arg);
return 0;
}
int aspeed_pin_config_set(struct pinctrl_dev *pctldev, unsigned int offset,
unsigned long *configs, unsigned int num_configs)
{
const struct aspeed_pinctrl_data *pdata;
unsigned int i;
int rc = 0;
pdata = pinctrl_dev_get_drvdata(pctldev);
for (i = 0; i < num_configs; i++) {
const struct aspeed_pin_config_map *pmap;
const struct aspeed_pin_config *pconf;
enum pin_config_param param;
unsigned int val;
u32 arg;
param = pinconf_to_config_param(configs[i]);
arg = pinconf_to_config_argument(configs[i]);
pconf = find_pinconf_config(pdata, offset, param);
if (!pconf)
return -ENOTSUPP;
pmap = find_pinconf_map(pdata, param, MAP_TYPE_ARG, arg);
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
if (WARN_ON(!pmap))
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
return -EINVAL;
val = pmap->val << __ffs(pconf->mask);
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
rc = regmap_update_bits(pdata->scu, pconf->reg,
pconf->mask, val);
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
if (rc < 0)
return rc;
pr_debug("%s: Set SCU%02X[0x%08X]=0x%X for param %d(=%d) on pin %d\n",
__func__, pconf->reg, pconf->mask,
val, param, arg, offset);
pinctrl: aspeed: Add core pinconf support Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07 20:57:11 +08:00
}
return 0;
}
int aspeed_pin_config_group_get(struct pinctrl_dev *pctldev,
unsigned int selector,
unsigned long *config)
{
const unsigned int *pins;
unsigned int npins;
int rc;
rc = aspeed_pinctrl_get_group_pins(pctldev, selector, &pins, &npins);
if (rc < 0)
return rc;
if (!npins)
return -ENODEV;
rc = aspeed_pin_config_get(pctldev, pins[0], config);
return rc;
}
int aspeed_pin_config_group_set(struct pinctrl_dev *pctldev,
unsigned int selector,
unsigned long *configs,
unsigned int num_configs)
{
const unsigned int *pins;
unsigned int npins;
int rc;
int i;
pr_debug("%s: Fetching pins for group selector %d\n",
__func__, selector);
rc = aspeed_pinctrl_get_group_pins(pctldev, selector, &pins, &npins);
if (rc < 0)
return rc;
for (i = 0; i < npins; i++) {
rc = aspeed_pin_config_set(pctldev, pins[i], configs,
num_configs);
if (rc < 0)
return rc;
}
return 0;
}