devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The correct header to include for clock handling is clk.h .
clk-provider.h should not be used in simple clock consumers.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current code use no locking at all, which is obviously not that
great and can lead to concurrency issues, especially with the newer SMP
SoCs from Allwinner.
Add some locking where it's needed.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
The current gpio_set function is ignoring the previous value set in the
GPIO value register, which leads in erasing the values already set for
the other GPIOs in the same bank when setting the value of a given GPIO.
Add the usual read/mask/write pattern to fix this brown paper bag bug.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
The current irq_set_type code doesn't read the current register value
before writing to it, leading to the older programmed values being
overwritten and everything but the latest value being reset.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Navigating through the source code is hard enough without having to
manually search for groups and functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The macros expand to irq_pin() calls and where most probably introduced
from a copy&paste of the sh7372 PFC data. Replace them with irq_pin().
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Magnus Damm <damm@opensource.se>
The mach/irqs.h header is included only to get the evt2irq macro
definition. The macro is defined in linux/sh_intc.h, include it directly
instead of the mach-specific header.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Magnus Damm <damm@opensource.se>
Pins with selectable functions but without a GPIO port can't be named
PORT_# or GP_#_#. Add a SH_PFC_PIN_NAMED macro to declare such pins in
the pinmux pins array, naming them with the PIN_ prefix followed by the
pin physical position.
In order to make sure not to register those pins as GPIOs, add a
SH_PFC_PIN_CFG_NO_GPIO pin flag to denote pins without a GPIO port.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Remove the manually specified ranges from PFC SoC data and compute the
ranges automatically. This prevents ranges from being out-of-sync with
pins definitions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The field contains the number of pins with an associated GPIO port. This
is currently equal to the total number of pins but will be modified when
adding support for pins without a GPIO port. Rename the field
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The PORT_1 macro invokes a macro passed as a parameter. Pass the pin
number down to that macro at the bottom of the call stack. This will be
used to compute the pin ranges automatically.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The PINMUX_GPIO macro takes a port name and a data mark, respectively of
the form GPIO_name and name_DATA. Modify the macro to take the name as a
single argument and derive the port name and data mark from it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Unlike all other PFC SoC data, the shx3 data prefix all static symbols
with shx3_. Remove the prefix to be consistent with the other source
files.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The SoC has a bank-style PFC. Replace the custom-defined macros with
common macros from sh-pfc.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The gpio_get_data_reg() and gpio_setup_data_reg() functions both take an
argument named gpio. The argument contains a GPIO offset for the first
function and a pin index for the second one. Rename them to offset and
idx respectively to match the rest of the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The typedef only conceals the real variable type without bringing any
additional value (see Documentation/CodingStyle, section 5.b). Moreover,
it polutes the pinmux namespace. Replace it with the integer type it
used to hide.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The GPIO driver uses an array of sh_pfc_gpio_pin structures to store
per-GPIO pin data. The array size is miscomputed at allocation time by
using the number of the last pin instead of the number of pins. When the
pin space contains holes this leads to memory overallocation. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The PFC SHX3 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SHX3 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The PFC SH7786 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SH7786 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The PFC SH7785 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SH7785 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The PFC SH7757 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SH7757 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The PFC SH7724 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SH7724 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The PFC SH7723 SoC data contains a input_pu range used to configure
pull-up resistors using the legacy non-pinconf API. That API has been
removed from the driver, the range is thus not used anymore. Remove it.
If required, configuring pull-up resistors for the SH7723 can be
implemented using the pinconf API, as done for the SH-Mobile, R-Mobile
and R-Car platforms.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
