- 15 Mar, 2013 40 commits
-
-
Laurent Pinchart authored
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 <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org>
-
Laurent Pinchart authored
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 authored
Now that all PFC platform devices provide memory resources support for registers without an associated memory resource isn't used anymore. Drop it. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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:
-
Wei Yongjun authored
In case of error, the function pinctrl_register() returns NULL not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
Add memory resources for the pin control platform device to let the sh-pfc driver ioremap() registers properly instead of evily casting register physical addresses to virtual addresses. The memory resource address range has been extracted from the config and data registes lists in the sh-pfc driver. Signed-off-by: -
Laurent Pinchart authored
The sh-pfc driver exposes one fake group and function per GPIO pin. As the pinctrl and pinmux APIs are not used by any SuperH and SH Mobile board or driver, drop the fake groups and functions and replace them by a real pinctrl and pinmux implementation. Groups and functions must now be explicitly provided by PFC SoC-specific data. Signed-off-by:
-
Laurent Pinchart authored
The PFC GPIO API implementation moved to using port numbers. Replace all GPIO_PORTx enum usage with the corresponding port number. The GPIO_PORTx enum values are identical to the port number on this platform. Signed-off-by:
-
Laurent Pinchart authored
The PFC GPIO API implementation moved to using port numbers. Replace all GPIO_PORTx enum usage with the corresponding port number. The GPIO_PORTx enum values are identical to the port number on this platform. Signed-off-by:
-
Laurent Pinchart authored
The PFC GPIO API implementation moved to using port numbers. Replace all GPIO_PORTx enum usage with the corresponding port number. The GPIO_PORTx enum values are identical to the port number on this platform. Signed-off-by:
-
Laurent Pinchart authored
The PFC GPIO API implementation moved to using port numbers. Replace all GPIO_PORTx enum usage with the corresponding port number. The GPIO_PORTx enum values are identical to the port number on this platform. Signed-off-by:
-
Guennadi Liakhovetski authored
The SH73A0 SoC has sparse GPIO numbers. Declare the pin numbers ranges in the PFC SoC data and use the pin numbers in the GPIO API. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Laurent Pinchart authored
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 authored
Adding a GPIO range to a pinctrl device logically belongs to the GPIO driver. Switch to the right API. Signed-off-by:
-
Laurent Pinchart authored
This prepares support for sparse pin numbering. The function currently just performs and indexed lookup in the pins array. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
The macros are defined identically and used in two SoC-specific files, share them. Signed-off-by:
-
Laurent Pinchart authored
Instead of converting the GPIO number to an enum_id and looking up IRQ table entries by enum_id, replace the pinmux_irq enum_ids field with a gpios field and lookup entries using the GPIO number. Signed-off-by:
-
Laurent Pinchart authored
And drop the pinmux_flag_t typedef. Signed-off-by:
-
Laurent Pinchart authored
Register two GPIO chips, one for the real GPIOs and one for the function GPIOs. Signed-off-by:
-
Laurent Pinchart authored
Split the GPIOs table into a pins table for real GPIOs and a functions table for function GPIOs. Only register pins with the pinctrl core. The function GPIOs remain accessible as GPIOs. Signed-off-by:
-
Laurent Pinchart authored
The GPIO type is always PINMUX_TYPE_FUNCTION when freeing a function GPIO. Hardcode the type value. Signed-off-by:
-
Laurent Pinchart authored
As a step towards GPIO function removal, shorten the GPIO range registered with the pinctrl core. Function GPIOs are now handled in the GPIO handlers directly instead of going through the pinctrl API. Signed-off-by:
-
Laurent Pinchart authored
This ensures that the field is not modified, which is a prerequisite for the rest of the PFC refactoring work. Signed-off-by:
-
Laurent Pinchart authored
All function GPIO entries are initialized with the GPIO_FN macro that expands to the PINMUX_GPIO macro, used to initialize real GPIOs. Create a PINMUX_GPIO_FN macro that duplicates PINMUX_GPIO and sets flags to PINMUX_TYPE_FUNCTION and use it in GPIO_FN, and make PINMUX_GPIO set flags to PINMUX_TYPE_GPIO. This removes the need to initialize GPIO flags at runtime and thus simplifies the code, preparing for the GPIO and functions split. Signed-off-by:
-
Laurent Pinchart authored
The field is unused, remove it. Signed-off-by:
-
Laurent Pinchart authored
The data and mark ranges are only used to check whether a GPIO corresponds to a real pin or a function. As pins come first in the list of GPIOs and in the platform-specific GPIO enumerations, we can replace the data and mark ranges by a number of pins. Add an nr_pins field to struct sh_pfc_soc_info to store the number of pins implemented by the SoC, remove the data and mark range fields and introduce sh_pfc_gpio_is_pin() and sh_pfc_gpio_is_function() functions to replace range-based checks. Signed-off-by:
-
Laurent Pinchart authored
The SoC information first_gpio field is always equal to 0, and the last_gpio field is the index of the last entry in the pinmux_gpios array. Replace the first_gpio and last_gpio fields by a nr_gpios field, and initialize it to ARRAY_SIZE(pinmux_gpios). Signed-off-by:
-
