- 15 Mar, 2013 40 commits
-
-
Laurent Pinchart authored
When setting a pin direction verify that the requested direction is supported, and return an error if it isn't. This requires pin configuration information to be supplied by SoC data. The check is a no-op if the information is not supplied. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org>
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Set pin configuration type to - PINMUX_TYPE_NONE at initialization time and when disabling a function or freeing a GPIO - PINMUX_TYPE_FUNCTION when enabling a function - PINMUX_TYPE_INPUT or PINMUX_TYPE_OUTPUT when setting the GPIO direction Verify that the type is PINMUX_TYPE_NONE when enabling a function or requesting a GPIO and return -EBUSY if it isn't. Signed-off-by:
-
Laurent Pinchart authored
The sh_pfc_reconfig_pin() is only called from a single location. Merge it into its call site to make the code easier to follow. Signed-off-by:
-
Laurent Pinchart authored
The existing PFC pinconf implementation, tied to the PFC-specific pin types, isn't used by drivers or boards. Replace it with the generic pinconf types to implement bias (pull-up/down) setup. Other pin configuration options can be implemented later if needed. Signed-off-by:
-
Laurent Pinchart authored
Return proper error codes instead of -1, and propagate the error codes. Signed-off-by:
-
Laurent Pinchart authored
None of the SoC data need to be modified. Constify it. Signed-off-by:
-
Laurent Pinchart authored
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 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 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:
-
