- 12 Mar, 2014 14 commits
-
-
Stephen Warren authored
The per-SoC data structures for Tegra pinctrl stored some information in a redundant way. Specifically, the list of groups that each function could be muxed onto was stored once explicitly, and also as part of the definition of each group. Eliminate this redundancy, and calculate each function's list of valid groups at pinctrl probe time. This removes thousands of lines of code from the pinctrl driver and ~16K from the vmlinux binary size, and adds only about 500uS to the boot process (on Tegra30; newer SoCs will likely be faster still). Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Stephen Warren authored
The Tegra20/30 pinctrl drivers currently initializes at arch_initcall, whereas Tegra114/124 pinctrl drivers initialize at module_init time. Convert Tegra20/30 to work the same way as the other drivers. Signed-off-by:
-
Maxime COQUELIN authored
This patch replaces the raw values with ARRAY_SIZE for assigning the ninput_delays and noutput_delays fields of STiH416's st_pctl_data struct. Acked-by:
Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by:
Maxime Coquelin <maxime.coquelin@st.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Giuseppe Cavallaro authored
This patch adds the initial support for pinctrl based on H407 SoC. Acked-by:
Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by:
-
Giuseppe Cavallaro authored
This patch adds a new logic inside the st pinctrl to manage an unsupported scenario: some sysconfig are not available! This is the case of STiH407 where, although documented, the following registers from SYSCFG_FLASH have been removed from the SoC. SYSTEM_CONFIG3040 Output Enable pad control for all PIO Alternate Functions and SYSTEM_ CONFIG3050 Pull Up pad control for all PIO Alternate Functions Without managing this condition an imprecise external abort will be detect. To do this the patch also reviews the st_parse_syscfgs and other routines to manipulate the registers only if actually available. In any case, for example the st_parse_syscfgs detected an error condition but no action was made in the st_pctl_probe_dt. Acked-by:
-
Stephen Boyd authored
We don't need to check for a negative reg here because reg is always the same and is always non-negative. Also, collapse the switch statement down for the duplicate cases. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Stephen Boyd authored
All these functions are limited in what they can pass as the gpio or irq number to whatever is setup during probe. Remove the checks. Signed-off-by:
-
Stephen Boyd authored
We don't need to waste space with these lookup tables, just do the math directly. Signed-off-by:
-
Stephen Boyd authored
This driver doesn't rely on any functionality living in drivers/of/irq.c to compile. Drop this dependency. Signed-off-by:
-
Stephen Boyd authored
These includes are unused or can be handled via forward declarations. Remove them. Signed-off-by:
-
Stephen Boyd authored
Fail the probe and print a warning if SoC specific drivers have more GPIOs than there can be accounted for in the static bitmaps. This should avoid silent corruption/failures in the future. Signed-off-by:
-
Stephen Boyd authored
If a driver calls enable_irq_wake() on a gpio turned interrupt from the msm pinctrl driver we'll get a lockdep warning like so: ============================================= [ INFO: possible recursive locking detected ] 3.14.0-rc3 #2 Not tainted --------------------------------------------- modprobe/52 is trying to acquire lock: (&irq_desc_lock_class){-.....}, at: [<c026aea0>] __irq_get_desc_lock+0x48/0x88 but task is already holding lock: (&irq_desc_lock_class){-.....}, at: [<c026aea0>] __irq_get_desc_lock+0x48/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by modprobe/52: #0: (&__lockdep_no_validate__){......}, at: [<c04f2864>] __driver_attach+0x48/0x98 #1: (&__lockdep_no_validate__){......}, at: [<c04f2874>] __driver_attach+0x58/0x98 #2: (&irq_desc_lock_class){-.....}, at: [<c026aea0>] __irq_get_desc_lock+0x48/0x88 #3: (&(&pctrl->lock)->rlock){......}, at: [<c04bb4b8>] msm_gpio_irq_set_wake+0x20/0xa8 Silence it by putting the gpios into their own lock class. Signed-off-by: -
Sebastian Hesselbarth authored
Pinctrl will WARN on missing DT resources, which is a little bit too noisy. Use dev_warn with FW_BUG instead. Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Josh Cartwright authored
Currently, the wake_irqs bitmap is used to track whether there are any gpio's which are configured as wake irqs, and uses this to determine whether or not to call enable_irq_wake()/disable_irq_wake() on the summary interrupt. However, the genirq core already handles this case, by maintaining a 'wake_count' per irq_desc, and only calling into the controlling irq_chip when wake_count transitions 0 <-> 1. Drop this bitmap, and unconditionally call irq_set_irq_wake() on the summary interrupt. Signed-off-by:
Josh Cartwright <joshc@codeaurora.org> Acked-by:
-
- 11 Mar, 2014 2 commits
-
-
Chew, Kean Ho authored
The requested gpio pin must has the func_pin_mux field set to GPIO function by BIOS/FW in advanced. Else, the gpio pin request would fail. This is to ensure that we do not expose any gpio pins which shall be used for alternate functions, for eg: wakeup pin, I/O interfaces for LPSS, etc. Signed-off-by:
Chew, Kean Ho <kean.ho.chew@intel.com> Signed-off-by:
Chew, Chiau Ee <chiau.ee.chew@intel.com> Reviewed-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Stephen Warren authored
drive_dev3_pins in pinctrl-tegra114.c wasn't used; delete it. pinctrl-tegra124.c had quite a few typos. Fix those. pinctrl-tegra124.c had a few mismatches between the *_groups[] ararys and the function lists in tegra124_groups[]. Fix those. Signed-off-by:
-
- 07 Mar, 2014 1 commit
-
-
Stephen Boyd authored
The compatible string doesn't have an x in it. Fix it. Also remove the "qcom" prefix from pins and functions as this binding uses the generic pinctrl bindings for the pins and functions. Signed-off-by:
-
- 05 Mar, 2014 2 commits
-
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@linux-m68k.org> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
- 03 Mar, 2014 2 commits
-
-
Linus Walleij authored
-
git://git.infradead.org/linux-mvebuLinus Walleij authored
mvebu pinctrl changes for v3.15 - various cleanup and refactorization - add drivers for the Armada 375, 380, and 385 SoCs - prepare dove for SoC code moving into mach-mvebu - DT documentation updates
-
- 01 Mar, 2014 3 commits
-
-
Jason Cooper authored
Sign for-mvebu/pinctrl-3xx
-
Jason Cooper authored
-
Jason Cooper authored
Sign for-mvebu/pinctrl-cleanup
-
- 25 Feb, 2014 16 commits
-
-
Sebastian Hesselbarth authored
Now that we have a regmap for global registers, get rid of the last remaining hardcoded physical addresses. While at it, also remove DOVE_ prefix from those macros. Signed-off-by:
-
Sebastian Hesselbarth authored
Now that we have ioremapped pmu_mpp registers, get rid of hardcoded physical addresses. While at it, also remove DOVE_ prefix from those macros. Signed-off-by:
-
Sebastian Hesselbarth authored
Now that we have an ioremapped mpp4 register, get rid of hardcoded physical addresses. While at it, also remove DOVE_ prefix from those macros. Signed-off-by:
-
Sebastian Hesselbarth authored
Now that we have ioremapped mpp base registers, get rid of hardcoded physical addresses. While at it, also remove DOVE_ prefix from those macros. Signed-off-by:
-
Sebastian Hesselbarth authored
Dove pinctrl uses some global config registers to control pins. This patch requests a syscon regmap for those registers. As this changes DT to driver requirements, fallback to a self-registered regmap with hardcoded resources, if the corresponding syscon DT node is missing. Also, WARN about old DT binding usage to encourage users to update their DTBs. Signed-off-by:
-
Sebastian Hesselbarth authored
Dove pinctrl also requires additional registers to control all pins. This patch requests resources for mpp4 and pmu-mpp register ranges. As this changes DT to driver requirements, fallback to hardcoded resources, if the corresponding DT regs have not been set. Also, WARN about old DT binding usage to encourage users to update their DTBs. Signed-off-by:
-
Sebastian Hesselbarth authored
Dove pinctrl binding now requires three different reg properties. This updates corresponding binding and example accordingly. While at it, also document reg property as required for the other MVEBU SoC pinctrl nodes. Signed-off-by: -
Sebastian Hesselbarth authored
Marvell Dove SoC binding was not documented, yet. Add the documentation and also describe Global Configuration register node in it. Signed-off-by: -
Thomas Petazzoni authored
The Marvell Armada 380/385 are new ARM SoCs from Marvell, part of the mvebu family, but using a Cortex-A9 CPU core. In terms of pin-muxing, it is similar to Armada 370 and XP for the register layout, only different in the number of available pins and their functions. Therefore, we simply use the existing drivers/pinctrl/mvebu/ infrastructure, with no other changes that the list of pins and corresponding functions. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
The Marvell Armada 375 is a new ARM SoC from Marvell, part of the mvebu family, but using a Cortex-A9 CPU core. In terms of pin-muxing, it is similar to Armada 370 and XP for the register layout, only different in the number of available pins and their functions. Therefore, we simply use the existing drivers/pinctrl/mvebu/ infrastructure, with no other changes that the list of pins and corresponding functions. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Sebastian Hesselbarth authored
Dove has pins that can be switched between normal and pmu functions. Rework pmu_mpp callbacks to reuse default mpp ctrl helpers. Signed-off-by: -
Sebastian Hesselbarth authored
Passing a NULL name for pin ranges will auto-generate standard names for each pin. With common pinctrl driver now checking NULL name correctly, consolidate mpp pins 0-15. Signed-off-by: -
Thomas Petazzoni authored
Now that each per-SoC pinctrl driver must implement its own get/set functions, there is no point in keeping the MPP_REG_CTRL macro, whose purpose was to let the core pinctrl mvebu driver use default get/set functions. While at it also update the comment about mvebu_mpp_ctrl. Signed-off-by:
-
Sebastian Hesselbarth authored
With every SoC always providing its own get/set callbacks, we can now remove the generic ones, remove the obsolete base address, and always use the provided callbacks. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
-
Sebastian Hesselbarth authored
The way that mvebu pinctrl is designed, requesting mpp registers in common pinctrl driver does not allow SoC specific drivers to access this resource. Move resource allocation in each SoC pinctrl driver and enable already provided mpp_{set,get} callbacks. Signed-off-by: -
Sebastian Hesselbarth authored
We want to get rid of passing register addresses to common pinctrl driver, so provide set/get callbacks that use generic mpp pins helper and will be used later. Signed-off-by:
-
