21 Jun, 2016
1 commit
-
This allows to remove the .remove() callback, and all functions and data
it needed for its own bookkeeping.Suggested-by: Laxman Dewangan
Signed-off-by: Geert Uytterhoeven
Acked-by: Linus Walleij
11 May, 2016
1 commit
-
Currrently the gpio_chip.to_irq() callback returns -ENOSYS on error,
which causes bad interactions with the serial_mctrl_gpio helpers.mctrl_gpio_init() returns -ENOSYS if GPIOLIB is not enabled, which is
intended to be ignored by its callers. However, ignoring -ENOSYS when it
was caused by a gpiod_to_irq() failure will lead to a crash later:Unable to handle kernel paging request at virtual address ffffffde
...
PC is at mctrl_gpio_set+0x14/0x78Fix this by returning zero instead, like gpiochip_to_irq() does.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Walleij
05 Jan, 2016
1 commit
-
This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Signed-off-by: Linus Walleij
19 Nov, 2015
1 commit
-
The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:@@
struct gpio_chip *var;
@@
-var->dev
+var->parentand:
@@
struct gpio_chip var;
@@
-var.dev
+var.parentand:
@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parentPlus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.Cc: Haavard Skinnemoen
Cc: Rafał Miłecki
Cc: Richard Purdie
Cc: Mauro Carvalho Chehab
Cc: Alek Du
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Dmitry Torokhov
Acked-by: Greg Kroah-Hartman
Acked-by: Lee Jones
Acked-by: Jiri Kosina
Acked-by: Hans-Christian Egtvedt
Acked-by: Jacek Anaszewski
Signed-off-by: Linus Walleij
02 Oct, 2015
5 commits
-
Now that all ARM-based Renesas SoCs use multiplatform kernels only the
hardcoded IRQ numbers can be dropped as they're dynamically allocated.Signed-off-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven -
Shmobile is all multiplatform these days, so get rid of the reference to
CONFIG_ARCH_SHMOBILE_LEGACY.Move the legacy code to do the non-DT mapping between GPIOs and pins
inside the existing #ifdef CONFIG_SUPERH section.Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Acked-by: Linus Walleij -
Legacy function GPIOs are no longer used on ARM since commit
a27c5cd1a08cc95c ("sh-pfc: sh73a0: Remove function GPIOs").
Extract its setup code into a separate function, and make all function
GPIO related code and data depend on CONFIG_SUPERH.Signed-off-by: Geert Uytterhoeven
Acked-by: Linus Walleij
Acked-by: Laurent Pinchart -
gpio_chip.free() is optional, and can just be left unimplemented.
Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Acked-by: Linus Walleij -
On platforms where the PFC/GPIO controller is instantiated from DT, the
mapping between GPIOs and pins is set up using the "gpio-ranges"
property in DT.Hence stop setting up the mapping from C code on DT platforms.
This code is still used for SH or ARM-legacy platforms.Signed-off-by: Geert Uytterhoeven
Acked-by: Linus Walleij
Acked-by: Laurent Pinchart
18 Mar, 2015
4 commits
-
Currently all PFC registers lie in low 32-bit address space. Hence use
u32 instead of unsigned long to store PFC register addresses in pinctrl
tables. All calculations of virtual addresses use a phys_addr_t
intermediate, so we know where to add an offset if the 32-bit assumption
ever becomes false.While this doesn't impact 32-bit builds, it would save ca. 7 KiB on a
64-bit shmobile_defconfig kernel.Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij -
All other loops over sh_pfc_soc_info.data_regs[] use
pinmux_data_reg.regwidth as the sentinel, which is safer as zero is
never a valid regwidth value (reg could be zero if we start using it to
store an offset).Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij -
As register and field widths and offsets are in the range 1..32, use
unsigned int (mostly replacing unsigned long) to store them in local
variables and for passing them around.Move to one variable per line, move variables to the beginning of the
block where they are used, and drop superfluous initializations while we
are at it.Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij -
As PFC registers are either 8, 16, or 32 bits wide, use u32 (mostly
replacing unsigned long) to store (parts of) register values and masks.Switch the shadow register operations from {set,clear}_bit() to plain C
bit operations, as the former can operate on long data only.Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij
22 Jul, 2014
1 commit
-
Signed-off-by: abdoulaye berthe
Signed-off-by: Linus Walleij
20 Dec, 2013
1 commit
-
The arrays are never modified, make them const.
Signed-off-by: Laurent Pinchart
Signed-off-by: Linus Walleij
13 Dec, 2013
4 commits
-
On non-DT platforms IRQ controllers associated with the GPIOs have a
fixed IRQ base value known at compile time. The sh-pfc driver translates
GPIO number to IRQ numbers using a hardcoded table. This mechanism
breaks on DT platforms, as the IRQ base values are dynamic in that case.Fix this by specifying IRQs associated with GPIOs in IRQ resources,
populated automatically from the device tree. When IRQ resources are
specified the driver requires one IRQ resource per GPIO able to generate
an interrupt, and uses the translation table to compute the IRQ resource
offset instead of the IRQ number.Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
Acked-by: Magnus Damm
Signed-off-by: Linus Walleij -
There's more than one window, name the field windows.
Signed-off-by: Laurent Pinchart
Acked-by: Magnus Damm
Signed-off-by: Linus Walleij -
0 is a valid GPIO value, use -1 to terminate the gpios array in IRQ
lists.Signed-off-by: Laurent Pinchart
Acked-by: Magnus Damm
Signed-off-by: Linus Walleij -
Some indices take positive values only, make them unsigned.
Signed-off-by: Laurent Pinchart
Acked-by: Magnus Damm
Signed-off-by: Linus Walleij
29 Jul, 2013
5 commits
-
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
Tested-by: Yusuke Goda -
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
Tested-by: Yusuke Goda -
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
Tested-by: Yusuke Goda -
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
Tested-by: Yusuke Goda -
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
Tested-by: Yusuke Goda
03 Apr, 2013
3 commits
-
Boards/platforms that register dedicated GPIO devices will not supply a
memory resource for GPIOs. Try to locate the GPIO memory resource at
initialization time, and skip registration of the gpiochip if the
resource can't be found.This is a temporary modification to ease the transition to separate GPIO
drivers. It should be reverted when all boards and platforms will have
been moved.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
Signed-off-by: Simon Horman -
When implemented as a separate IP block, GPIOs should be handled by a
separate driver. To make this possible GPIO support needs to be optional
in the sh-pfc driver.If no GPIO data registers are supplied in the SoC information structure
skip registration of the gpiochip.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
Signed-off-by: Simon Horman -
The target is to get rid of function GPIOs completely. To reach this,
make function GPIOs support optional by skipping the function GPIO chip
registration if no function GPIOS are defined in SoC data.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
Signed-off-by: Simon Horman
15 Mar, 2013
13 commits
-
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
Return proper error codes instead of -1, and propagate the error codes.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
None of the SoC data need to be modified. Constify it.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The purpose of the dry-run is to ensure that a pin about to be
configured isn't in use. However, the current implementation is a no-op.
This proves that the dry-run isn't essential. Remove it.Freeing configuration then becomes a no-op as well. Remove it.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The sh_pfc_pin structure supplied in SoC data contains information about
pin configuration and name. It's abused to store GPIO data registers
information and pin config type. Move those fields out of the
pinmux_data_reg structure into the new sh_pfc_gpio_pin and
sh_pfc_pin_config structures.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The pinmux_data_reg structure supplied in SoC data contains information
about data registers. It's abused to store per-device mapped iomem and
shadow values. Move those fields out of the pinmux_data_reg structure
into the per-device sh_pfc_chip structure.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
All data registers are located in the same memory resource. Locate the
mapped resource at initializat time and use it directly instead of
computing a mapped address for each register. This gets rid of the
mapped_reg field of the pinmux_data_reg structure.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
Move the sh_pfc_setup_data_regs(), sh_pfc_setup_data_reg(),
sh_pfc_get_data_reg(), sh_pfc_read_bit() and sh_pfc_write_bit()
function to gpio.c as they belong to the GPIO implementation. Inline
sh_pfc_read_bit() and sh_pfc_write_bit() in their only call location.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The PFC driver assumes that the value of the GPIO_PORTxxx enumeration
names are equal to the port number. This isn't true when the port number
space is sparse, as with the SH73A0.Fix the issue by adding support for pin numbers ranges specified through
SoC data. When no range is specified the driver considers that the PFC
implements a single contiguous range for all pins.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
Adding a GPIO range to a pinctrl device logically belongs to the GPIO
driver. Switch to the right API.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
This prepares support for sparse pin numbering. The function currently
just performs and indexed lookup in the pins array.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The function is guaranteed to be called with a gpio number smaller than
nr_pins. The condition can the be simplified, and the function inlined.Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij -
The PFC core exposes a sh_pfc_config_gpio() function that configures
pinmuxing for a given GPIO (either a real GPIO or a function GPIO).
Handling of real and function GPIOs belong to the GPIO layer, move the
GPIO number to mark translation to the caller and rename the function to
sh_pfc_config_mux().Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij