aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpio/gpio-ich.c
AgeCommit message (Collapse)AuthorFilesLines
2013-08-16gpio: use dev_get_platdata()Jingoo Han1-1/+1
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-06-19gpio: ich: add GPO_BLINK supportVincent Donnefort1-1/+7
This patch makes sure blink hardware is disabled for selected GPIO. Blink hardware is controled by GPO_BLINK register and is available for GPIOs from 0 to 31. Signed-off-by: Vincent Donnefort <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-05-06Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds1-13/+4
Pull GPIO changes from Grant Likely: "The usual selection of bug fixes and driver updates for GPIO. Nothing really stands out except the addition of the GRGPIO driver and some enhacements to ACPI support" I'm pulling this despite the earlier mess. Let's hope it compiles these days. * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: (46 commits) gpio: grgpio: Add irq support gpio: grgpio: Add device driver for GRGPIO cores gpiolib-acpi: introduce acpi_get_gpio_by_index() helper GPIO: gpio-generic: remove kfree() from bgpio_remove call gpio / ACPI: Handle ACPI events in accordance with the spec gpio: lpc32xx: Fix off-by-one valid range checking for bank gpio: mcp23s08: convert driver to DT gpio/omap: force restore if context loss is not detectable gpio/omap: optimise interrupt service routine gpio/omap: remove extra context restores in *_runtime_resume() gpio/omap: free irq domain in probe() failure paths gpio: gpio-generic: Add 16 and 32 bit big endian byte order support gpio: samsung: Add terminating entry for exynos_pinctrl_ids gpio: mvebu: add dbg_show function MAX7301 GPIO: Do not force SPI speed when using OF Platform gpio: gpio-tps65910.c: fix checkpatch error gpio: gpio-timberdale.c: fix checkpatch error gpio: gpio-tc3589x.c: fix checkpatch errors gpio: gpio-stp-xway.c: fix checkpatch error gpio: gpio-sch.c: fix checkpatch error ...
2013-03-27gpio/gpio-ich: make ichx_gpio_check_available() return a pure boolean valueMika Westerberg1-1/+1
It is more readable for humans to use double-bang (!!) to convert the value to pure boolean before it is returned. Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-03-27gpio-ich: Check for pin availability at request timeJean Delvare1-12/+3
Stop checking for pin availability in direction and get functions. These functions can be called repeatedly, so checking every time is bad for performance. Now that requesting GPIO pins is no longer optional, checking for availability at pin request time is enough. Signed-off-by: Jean Delvare <[email protected]> Cc: Peter Tyser <[email protected]> Cc: Grant Likely <[email protected]> Cc: Linus Walleij <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-03-27gpio-ich: Fix value returned by ichx_gpio_requestJean Delvare1-1/+1
Per Documentation/gpio.txt, gpio_request callbacks should return 0 on success or a negative value on error. So it is not clear what was meant by letting ichx_gpio_request return 1 in some cases, nor how a caller would interpret it. Align the code with the comment above it and consider pins as available by default. Signed-off-by: Jean Delvare <[email protected]> Cc: Grant Likely <[email protected]> Acked-by: Peter Tyser <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-03-02gpio/gpio-ich: fix ichx_gpio_check_available() return what callers expectMika Westerberg1-2/+2
ichx_gpio_check_available() returns either 0 or -ENXIO depending on whether the given GPIO is available or not. However, callers of this function treat the return value as boolean: ... if (!ichx_gpio_check_available(gpio, nr)) return -ENXIO; which erroneusly fails when the GPIO is available and not vice versa. Fix this by making the function return boolean as expected by the callers. Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Grant Likely <[email protected]>
2012-12-19gpio/ich: Add missing spinlock initJean Delvare1-0/+1
As reported by CONFIG_DEBUG_SPINLOCK=y. Signed-off-by: Jean Delvare <[email protected]> Acked-by: Peter Tyser <[email protected]> Signed-off-by: Grant Likely <[email protected]>
2012-11-28gpio: remove use of __devexitBill Pemberton1-1/+1
CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton <[email protected]> Cc: Grant Likely <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: Peter Tyser <[email protected]> Acked-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-11-28gpio: remove use of __devinitBill Pemberton1-3/+3
CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <[email protected]> Cc: Grant Likely <[email protected]> Cc: Peter Tyser <[email protected]> Cc: Santosh Shilimkar <[email protected]> Cc: Kevin Hilman <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-11-28gpio: remove use of __devexit_pBill Pemberton1-1/+1
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton <[email protected]> Cc: Grant Likely <[email protected]> Cc: Peter Tyser <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-14gpio: gpio-ich: Share ownership of GPIO groupsJean Delvare1-10/+69
The ICH chips have their GPIO pins organized in 2 or 3 independent groups of 32 GPIO pins. It can happen that the ACPI BIOS wants to make use of pins in one group, preventing the OS to access these. This does not prevent the OS from accessing the other group(s). This is the case for example on my Asus Z8NA-D6 board. The ACPI BIOS wants to control GPIO 18 (group 1), while I (the OS) need to control GPIO 52 and 53 (group 2) for SMBus multiplexing. So instead of checking for ACPI resource conflict on the whole I/O range, check on a per-group basis, and consider it a success if at least one of the groups is available for the OS to use. Signed-off-by: Jean Delvare <[email protected]> Cc: Peter Tyser <[email protected]> Cc: Aaron Sierra <[email protected]> Cc: Grant Likely <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Samuel Ortiz <[email protected]>
2012-05-01gpio: Add support for Intel ICHx/3100/Series[56] GPIOPeter Tyser1-0/+419
This driver works on many Intel chipsets, including the ICH6, ICH7, ICH8, ICH9, ICH10, 3100, Series 5/3400 (Ibex Peak), Series 6/C200 (Cougar Point), and NM10 (Tiger Point). Additional Intel chipsets should be easily supported if needed, eg the ICH1-5, EP80579, etc. Tested on QM67 (Cougar Point), QM57 (Ibex Peak), 3100 (Whitmore Lake), and NM10 (Tiger Point). Includes work from Jean Delvare: - Resource leak removal during module load/unload - GPIO API bit value enforcement Also includes code cleanup from Guenter Roeck and Grant Likely. Signed-off-by: Peter Tyser <[email protected]> Signed-off-by: Aaron Sierra <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Samuel Ortiz <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.