- 10 May, 2012 1 commit
-
-
Guennadi Liakhovetski authored
This removes a repeated word and a repeated and incomplete line from two pinctrl headers. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 07 May, 2012 1 commit
-
-
Stephen Warren authored
Additionally print which pin the request failed for, which entity already claimed it, and what entity was trying to claim it. Remove duplicate device name from a debug message. Clean up some indentation. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
- 01 May, 2012 5 commits
-
-
Shawn Guo authored
Add pinctrl support for Freescale MXS SoCs, i.MX23 and i.MX28. The driver supports device tree probe only. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Dong Aisheng authored
Acked-by:
Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by:
-
Dong Aisheng authored
The driver has mux and config support while the gpio is still not supported. For select input setting, the driver will handle it internally and do not need user to take care of it. The pinctrl-imx core driver will parse the dts file and dynamically create the pinmux functions and groups. Each IMX SoC pinctrl driver should register pins with a pin register map including mux register and config register and select input map to core for proper operations. Acked-by:
-
Dong Aisheng authored
Currently most code to get child count in kernel are almost same, add a helper to implement this function for dt to use. Cc: Grant Likely <grant.likely@secretlab.ca> Acked-by:
Rob Herring <rob.herring@calxeda.com> Acked-by:
-
Dong Aisheng authored
As pinctrl handles, it may be possible the pinctrl gpio ranges are still not got registered when user call pinctrl_gpio_request. Thus, add defer support for it too. Signed-off-by:
-
- 26 Apr, 2012 4 commits
-
-
Dong Aisheng authored
Add a interface pinctrl_provide_dummies for platform to indicate whether it needs use pinctrl dummy state. ChangeLog v3->v4: * remove dummy gpio support in pinctrl subsystem. Let gpio driver decide whether it wants to use pinctrl gpio mux function. ChangeLog v2->v3: * Also changed the missed pinctrl gpio APIs in v1. ChangeLog v1->v2: * Based on sascha's suggestion, drop using kconfig since it will hide pinctrl errors on all other boards. See: https://lkml.org/lkml/2012/4/18/282 It seemed both Linus and Stephen agreed with this way, so i'm ok with it too. * Add dummy gpio support. pinctrl gpio in the same situation as state. * Patch name changed. Original is pinctrl: handle dummy state in core. * Split removing old dt dummy interface into a separate patch Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
-
John Crispin authored
There are a few places in the api where the code simply returns -EINVAL when it finds an error. An example is pinmux_map_to_setting() which now reports an error if we try to match a group with a function that it does not support. The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the same style and is located inside the according functions and not the calling code. When the map is found in the DT but the default state can not be selected we get an error to know that the code at least tried. The patch also removes a stray word from one comment and a "->" from another for the sake of consistency. Finally we replace a few pr_err/debug() calls with dev_err/dbg(). Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting inside pinmux_map_to_setting(). Signed-off-by:
John Crispin <blogic@openwrt.org> Acked-by:
-
Stephen Warren authored
Signed-off-by:
-
Stephen Warren authored
pinctrl_register_map() was returning early if pinmux_validate_map() or pinconf_validate_map() failed, but was not actually returning the error code. Signed-off-by:
-
- 25 Apr, 2012 1 commit
-
-
Linus Walleij authored
This comment was referring to an older PINMUX define, it should be PINCTRL now. Reported-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by:
-
- 24 Apr, 2012 1 commit
-
-
John Crispin authored
pinmux_map_to_setting() uses setting->data.mux.func/group to store the return code of pinmux_func_name_to_selector/pinctrl_get_group_selector(). However, struct pinctrl_setting_mux defines these elements as unsigned, resulting in all error codes getting lost. The conditionals following the assignments will always evaluate to false thus breaking the error paths. This bug can be triggered by loading a pinmux group map from the devicetree with an invalid function/group string. Signed-off-by:
-
- 18 Apr, 2012 24 commits
-
-
Dong Aisheng authored
Pin name is more useful to users. After change, when cat pingroups in sysfs, it becomes: root@freescale /sys/kernel/debug/pinctrl/20e0000.iomuxc$ cat pingroups registered pin groups: group: uart4grp-1 pin 219 (MX6Q_PAD_KEY_ROW0) pin 218 (MX6Q_PAD_KEY_COL0) group: usdhc4grp-1 pin 305 (MX6Q_PAD_SD4_CMD) pin 306 (MX6Q_PAD_SD4_CLK) pin 315 (MX6Q_PAD_SD4_DAT0) pin 316 (MX6Q_PAD_SD4_DAT1) pin 317 (MX6Q_PAD_SD4_DAT2) pin 318 (MX6Q_PAD_SD4_DAT3) pin 319 (MX6Q_PAD_SD4_DAT4) pin 320 (MX6Q_PAD_SD4_DAT5) pin 321 (MX6Q_PAD_SD4_DAT6) pin 322 (MX6Q_PAD_SD4_DAT7) Acked-by:
-
Dong Aisheng authored
Pin name is more useful to users. Acked-by:
-
Stephen Warren authored
These functions allow the driver core to automatically clean up any allocations made by drivers, thus leading to simplified drivers. Signed-off-by:
-
Dong Aisheng authored
Signed-off-by:
-
Viresh Kumar authored
When we compile pinctrl layer for platforms without CONFIG_PINCONF, we get following compilation errors: drivers/built-in.o: In function `pinctrl_show': linux-2.6/drivers/pinctrl/core.c:1116: undefined reference to `pinconf_show_setting' drivers/built-in.o: In function `pinctrl_maps_show': linux-2.6/drivers/pinctrl/core.c:1071: undefined reference to `pinconf_show_map' drivers/built-in.o: In function `pinctrl_init_device_debugfs': linux-2.6/drivers/pinctrl/core.c:1224: undefined reference to `pinconf_init_device_debugfs' make[1]: *** [.tmp_vmlinux1] Error 1 This patch fixes this. Signed-off-by:
Viresh Kumar <viresh.kumar@st.com> Signed-off-by:
-
Stephen Warren authored
Add a pinconf op so that pin controller drivers can decode their pin config settings for debugfs. Signed-off-by:
-
Stephen Warren authored
Only provide prototypes for pin{mux,conf}.c debugfs-related functions when both CONFIG_PIN* /and/ CONFIG_DEBUG_FS are enabled, otherwise provide static inlines. Signed-off-by: -
Linus Walleij authored
With the finalization of the external driver API and the device tree support, this subsystem is now mature and can be promoted to non-experimental status. Acked-by:
-
Stephen Warren authored
Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow complete specification of the desired pinmux configuration using device tree. Signed-off-by:
-
Stephen Warren authored
Define a new binding for the Tegra pin controller, which is capable of defining all aspects of desired pin multiplexing and pin configuration. This is all based on the new common pinctrl bindings. Add Tegra30 binding based on Tegra20 binding. Add some basic stuff that was missing before: * How many and what reg property entries must be provided. * An example. Signed-off-by:
-
Stephen Warren authored
This places the file in the new location for all pin controller bindings. Also, rename the file using the full compatible value for easier avoidance of conflicts between multiple bindings. Signed-off-by:
-
Stephen Warren authored
The core pin controller bindings define: * The fact that pin controllers expose pin configurations as nodes in device tree. * That the bindings for those pin configuration nodes is defined by the individual pin controller drivers. * A standardized set of properties for client devices to define numbered or named pin configuration states, each referring to some number of the afore-mentioned pin configuration nodes. * That the bindings for the client devices determines the set of numbered or named states that must exist. Signed-off-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Simon Glass <sjg@chromium.org> Acked-by:
-
Stephen Warren authored
This patch adds macros of_property_for_each_u32() and of_property_for_each_string(), which iterate over an array of values within a device-tree property. Usage is for example: struct property *prop; const __be32 *p; u32 u; of_property_for_each_u32(np, "propname", prop, p, u) printk("U32 value: %x\n", u); struct property *prop; const char *s; of_property_for_each_string(np, "propname", prop, s) printk("String value: %s\n", s); Based on work by Rob Herring <robherring2@gmail.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: -
Linus Walleij authored
If drivers try to obtain pinctrl handles for a pin controller that has not yet registered to the subsystem, we need to be able to back out and retry with deferred probing. So let's return -EPROBE_DEFER whenever this location fails. Also downgrade the errors to info, maybe we will even set them to debug once the deferred probing is commonplace. Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
-
Dong Aisheng authored
This patch can avoid kernel oops in case the mux or config function is not supported by driver. Acked-by:
-
Dong Aisheng authored
Do not use get_functions_count before checking. Acked-by:
-
Viresh Kumar authored
Most of the SoC drivers implement list_groups() and list_functions() routines for pinctrl and pinmux. These routines continue returning zero until the selector argument is greater than total count of available groups or functions. This patch replaces these list_*() routines with get_*_count() routines, which returns the number of available selection for SoC driver. pinctrl layer will use this value to check the range it can choose. This patch fixes all user drivers for this change. There are other routines in user drivers, which have checks to check validity of selector passed to them. It is also no more required and hence removed. Documentation updated as well. Acked-by:
-
Uwe Kleine-König authored
As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Viresh Kumar authored
Missed one group from the documentation when proofreading. Signed-off-by:
-
Stephen Warren authored
pinctrl/devicetree.c won't compile when !CONFIG_PINCTRL, since the pinctrl headers don't declare some types when !PINCTRL. Make sure pinctrl/Makefile only attempts to compile devicetree.c when OF && PINCTRL. Acked-by:
-
Stephen Warren authored
During pinctrl_get(), if the client device has a device tree node, look for the common pinctrl properties there. If found, parse the referenced device tree nodes, with the help of the pinctrl drivers, and generate mapping table entries from them. During pinctrl_put(), free any results of device tree parsing. Acked-by:
-
Stephen Warren authored
Most code assumes that the pinctrl ops are present. Validate this when registering a pinctrl driver. Remove the one place in the code that was checking whether one of these non-optional ops was present. Signed-off-by:
-
Stephen Warren authored
Macros in <linux/pinctrl/machine.h> call ARRAY_SIZE(), the definition of which eventually calls BUILD_BUG_ON_ZERO(), which is defined in <linux/bug.h>. Include that so that every .c file using the pinctrl macros doesn't have to do that itself. Signed-off-by:
-
Dong Aisheng authored
The pinctrl_register_mappings is defined in core.c, so change the dependent macro from CONFIG_MUX to CONFIG_PINCTRL. The compile error message is: drivers/pinctrl/core.c:886: error: redefinition of 'pinctrl_register_mappings' include/linux/pinctrl/machine.h:160: note: previous definition of 'pinctrl_register_mappings' was here make[2]: *** [drivers/pinctrl/core.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 Acked-by:
-
- 16 Apr, 2012 3 commits
-
-
Linus Torvalds authored
-
git://git.linaro.org/people/rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: "Nothing too disasterous, the biggest thing being the removal of the regulator support for vcore in the AMBA driver; only one SoC was using this and it got broken during the last merge window, which then started causing problems for other people. Mutual agreement was reached for it to be removed." * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7386/1: jump_label: fixup for rename to static_key ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus ARM: 7383/1: nommu: populate vectors page from paging_init ARM: 7381/1: nommu: fix typo in mm/Kconfig ARM: 7380/1: DT: do not add a zero-sized memory property ARM: 7379/1: DT: fix atags_to_fdt() second call site ARM: 7366/3: amba: Remove AMBA level regulator support ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
-
Linus Torvalds authored
The 'max' range needs to be unsigned, since the size of the user address space is bigger than 2GB. We know that 'count' is positive in 'long' (that is checked in the caller), so we will truncate 'max' down to something that fits in a signed long, but before we actually do that, that comparison needs to be done in unsigned. Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of 'strncpy_from_user()' and speed it up"). On x86-64 you can't trigger this, since the user address space is much smaller than 63 bits, and on x86-32 it works in practice, since you would seldom hit the strncpy limits anyway. I had actually tested the corner-cases, I had only tested them on x86-64. Besides, I had only worried about the case of a pointer *close* to the end of the address space, rather than really far away from it ;) This also changes the "we hit the user-specified maximum" to return 'res', for the trivial reason that gcc seems to generate better code that way. 'res' and 'count' are the same in that case, so it really doesn't matter which one we return. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
