On 07/18/2013 09:23 PM, Shawn Guo wrote:
On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
...
You're spending an awful lot of energy arguing over this, but nobody
has actually shown data of how much deferral is happening -- and that
it's a real problem. Until someone does so
On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 19 July 2013 11:59 AM, Greg KH wrote:
On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Friday 19 July 2013 11:13 AM, Greg KH wrote:
On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay
On 07/19/2013 10:24 AM, Sourav Poddar wrote:
This patch disabled I2C/SPI/UART device initially(status = disabled).
This devices will only be probed, if the devices are
present in the dts file(status = okay).
interrupts = 0 72 0x4;
ti,hwmods =
On 07/18/2013 03:21 PM, Guenter Roeck wrote:
On Thu, Jul 18, 2013 at 11:18:05AM -0600, Stephen Warren wrote:
On 07/18/2013 07:53 AM, Eduardo Valentin wrote:
Hello Guenter,
On 17-07-2013 18:09, Guenter Roeck wrote:
On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
wrote:
Hello all
On 07/19/2013 07:38 AM, Eduardo Valentin wrote:
On 18-07-2013 17:11, Guenter Roeck wrote:
On Thu, Jul 18, 2013 at 09:53:05AM -0400, Eduardo Valentin
wrote:
Hello Guenter,
On 17-07-2013 18:09, Guenter Roeck wrote:
On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
wrote:
Hello
On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
Hello,
Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT.
The series,
Reviewed-by: Stephen Warren swar...@nvidia.com
I'm (very very) slightly hesitant about patch 3/4, since it's moving
towards all PWMs
On 07/18/2013 05:57 AM, Philipp Zabel wrote:
If the requested reset controller is not yet available, have reset_control_get
and device_reset return -EPROBE_DEFER so the driver can decide to request
probe deferral.
Reviewed-by: Stephen Warren swar...@nvidia.com
On 07/18/2013 07:53 AM, Eduardo Valentin wrote:
Hello Guenter,
On 17-07-2013 18:09, Guenter Roeck wrote:
On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
wrote:
Hello all,
As you noticed, I am working in a way to represent thermal
data using device tree [1]. Essentially, this
On 07/18/2013 10:07 AM, Christian Ruppert wrote:
...
Well, perhaps my definition of inside/outside pins was not quite
clear: The pin groups define the set of (kernel internal) pin numbers of
outside pins which are used by pin controller to map a given
interface. Inside pins are not numbered
On 07/17/2013 06:26 AM, Dan Carpenter wrote:
xspi-irq is unsigned int so it's never less than zero. I have added
a cast.
Um. Doesn't this just hide a warning, not solve the problem? If the
value can't be negative, so the if condition never fires, then the cast
won't change that...
On 07/16/2013 09:02 PM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.
Deferred probe /is/ the approach for assuring correct dependencies
between drivers. It works
On 07/17/2013 05:00 AM, Laurent Pinchart wrote:
On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
...
But then there's a problem where people assume that the common flags are
always available, and somewhere they aren't... Care is needed in the
choice of which common flags to define
On 07/17/2013 03:38 PM, Pavel Machek wrote:
On Wed 2013-07-17 10:57:08, Stephen Warren wrote:
On 07/16/2013 09:02 PM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach
On 07/15/2013 10:10 PM, Shawn Guo wrote:
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are mostly probed at module_init time
. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Stephen Warren swar...@nvidia.com
I see this patch is very useful, as GPIOs are widely used to reset
components/devices on board
On 07/16/2013 03:59 AM, Philipp Zabel wrote:
...
Deferred probing is fine, but it'd be nice to keep the probe deferral
loops to a minimum where possible and/or reasonable.
I agree, but manually selecting initcalls for drivers is not the
solution. See my other email.
...@pengutronix.de
Reviewed-by: Stephen Warren swar...@nvidia.com
---
Changes since v8, as suggested by Shawn:
- added support for I2C gpios via gpio_set_value_cansleep
- switched from module_init to arch_initcall to avoid unnecessary
probe deferral of subsys_initcall drivers like gpio
On 07/16/2013 02:47 AM, Christian Ruppert wrote:
On Wed, Jul 10, 2013 at 01:27:52PM -0600, Stephen Warren wrote:
On 07/08/2013 07:02 AM, Christian Ruppert wrote:
...
OK, a small drawing of our hardware should make this clear, let's take
an imaginary example of one port with 10 pins, one i2c
On 07/15/2013 05:02 PM, Stephen Warren wrote:
On 07/15/2013 01:34 PM, Rob Herring wrote:
On 07/15/2013 01:40 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Won't this break compatibility with older kernel
On 07/16/2013 07:50 PM, Rob Herring wrote:
On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/15/2013 05:02 PM, Stephen Warren wrote:
On 07/15/2013 01:34 PM, Rob Herring wrote:
On 07/15/2013 01:40 PM, Stephen Warren wrote:
From: Stephen Warren swar
From: Stephen Warren swar...@nvidia.com
This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/of/base.c | 67
From: Stephen Warren swar...@nvidia.com
This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS
From: Stephen Warren swar...@nvidia.com
Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/gpio/gpiolib-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
From: Stephen Warren swar...@nvidia.com
Commit bd69f73 of: Create function for counting number of phandles in
a property renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
This should presumably be applied along with the previous changes
v2: Squash spear
On 07/15/2013 01:34 PM, Rob Herring wrote:
On 07/15/2013 01:40 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Won't this break compatibility with older kernel? It is one thing to
deprecate, but removal
signal can be configured via device tree.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Stephen Warren swar...@nvidia.com
I see this patch is very useful, as GPIOs are widely used to reset
components/devices on board. But I do not find the patch in v3.11-rc1.
What's your plan
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources
On 07/12/2013 05:01 AM, Laurent Pinchart wrote:
Hi,
On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
On 07/11/2013 01:32 PM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04
On 07/12/2013 11:24 AM, Thierry Reding wrote:
On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
[...]
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update
include
Is there a (possibly just proposed) mechanism in place to allow *.dts
from multiple Linux architectures to share common *.dtsi files?
As an example, consider two SoCs that are identical except for the CPU
complex. One uses an ARMv7 CPU (DTs in arch/arm/boot/dts/) and the other
uses some ARMv8 CPU
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
de0eaed..be09be4 100644 ---
On 07/11/2013 01:32 PM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
wrote: [...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb
On 07/08/2013 07:02 AM, Christian Ruppert wrote:
...
OK, a small drawing of our hardware should make this clear, let's take
an imaginary example of one port with 10 pins, one i2c interface, one
spi interface and one GPIO bank:
| mux N-1|
++
On 07/09/2013 01:05 AM, Sascha Hauer wrote:
On Fri, Jul 05, 2013 at 04:43:38PM +0800, Huang Shijie wrote:
If we set the uart compatible in the dts file like this:
--
compatible = fsl,imx6q-uart, fsl,imx21-uart;
On 07/09/2013 06:03 AM, Rob Herring wrote:
On Tue, Jul 9, 2013 at 3:10 AM, Huang Shijie b32...@freescale.com wrote:
于 2013年07月09日 15:51, Sascha Hauer 写道:
On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
于 2013年07月09日 15:05, Sascha Hauer 写道:
Why don't you set the matching order
On 07/09/2013 12:20 PM, Jason Cooper wrote:
Bjorn,
On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges
On 07/04/2013 10:56 AM, Daniel Mack wrote:
...
The built-in support for attaching a DTB to the zImage does not suffice
here, because we have one image for all models, and also, we couldn't do
a 'per-board-revision' selection that way either.
...
As a solution, I'm thinking of a small framework
On 07/05/2013 03:49 AM, Christian Ruppert wrote:
On Wed, Jun 26, 2013 at 11:40:42AM -0600, Stephen Warren wrote:
On 06/26/2013 05:50 AM, Christian Ruppert wrote:
On Wed, Jun 19, 2013 at 04:35:14PM -0600, Stephen Warren wrote:
On 06/18/2013 03:29 AM, Christian Ruppert wrote:
[...]
+Example
On 06/29/2013 10:22 AM, Marc Dietrich wrote:
On Friday 28 June 2013 09:13:38 Stephen Warren wrote:
On 06/27/2013 12:26 PM, Marc Dietrich wrote:
...
I'm puzzling for some time now to find a binding for a mfd device. So
let's
start with something I think I have learned already, let's describe
On 06/28/2013 01:52 AM, Gerhard Sittig wrote:
[ late reply, just catching up with the backlog ]
On Mon, Jun 24, 2013 at 17:26 -0600, Stephen Warren wrote:
[ ... sparse matrices, not all columns/rows populated ... ]
On some Tegra boards, there end up
being rather tri-angular keymaps
On 06/28/2013 02:24 AM, Gerhard Sittig wrote:
On Mon, Jun 24, 2013 at 16:00 -0600, Stephen Warren wrote:
On 06/22/2013 03:23 AM, Gerhard Sittig wrote:
...
So the direction to go is
- move the Linux driver specific discussion to
Documentation/input/ including potential hardware setups
On 06/28/2013 02:33 AM, Gerhard Sittig wrote:
On Mon, Jun 24, 2013 at 17:14 -0600, Stephen Warren wrote:
[ active low pins, individually for sets or even single pins ]
Can't you add this enhancement as follows:
Update the driver to look at the per-pin GPIO flags in all cases.
Presumably
On 06/27/2013 12:26 PM, Marc Dietrich wrote:
Hi,
(CC'ing linux-tegra)
I'm puzzling for some time now to find a binding for a mfd device. So let's
start with something I think I have learned already, let's describe the
hardware.
Here the problem starts, because the nvec (nvidia
On 06/26/2013 05:42 AM, Christian Ruppert wrote:
On Wed, Jun 19, 2013 at 12:15:13PM -0600, Stephen Warren wrote:
On 06/19/2013 06:03 AM, Linus Walleij wrote:
On Tue, Jun 18, 2013 at 11:29 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
This patch adds the infrastructure required
On 06/26/2013 05:46 AM, Christian Ruppert wrote:
On Wed, Jun 19, 2013 at 04:27:44PM -0600, Stephen Warren wrote:
On 06/18/2013 03:29 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree
On 06/26/2013 05:50 AM, Christian Ruppert wrote:
On Wed, Jun 19, 2013 at 04:35:14PM -0600, Stephen Warren wrote:
On 06/18/2013 03:29 AM, Christian Ruppert wrote:
The pinmux driver of the Abilis Systems TB10x platform based on ARC700 CPUs.
Used to control the pinmux and is a prerequisite
On 06/25/2013 05:45 AM, Grant Likely wrote:
On Mon, Jun 24, 2013 at 5:33 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
Hi all,
I am dealing with a lingering problem related to init and probing of platform
devices early (before initcalls) in the kernel boot process. The problem,
On 06/25/2013 08:32 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
The Linux pinctrl subsystem specifically doesn't provide mutual
exclusion between mux function and GPIO usage within
On 06/25/2013 08:27 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
When I pushed for the concept of groups, I intended it to mean precisely
one single thing. The points below describe this.
1) A pin is a single pin/ball/pad
On 06/25/2013 09:28 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
And finally, I don't really like using pin groups for the purpose of
defining these mappings, since I intended them to purely represent the
mapping from register
On 06/25/2013 05:59 AM, Christian Ruppert wrote:
On Fri, Jun 21, 2013 at 03:17:33PM -0600, Stephen Warren wrote:
...
To define some terminology, let's call a set of pins affected by the
same register / bit field a port.
Well, the terminology group already exists for this really, but I
suppose
On 06/25/2013 09:39 AM, Linus Walleij wrote:
On Tue, Jun 25, 2013 at 3:50 PM, James Hogan james.ho...@imgtec.com wrote:
On 25/06/13 14:32, Linus Walleij wrote:
Patches adding it back in with SI measures will be welcomed!
Okay.
So the most descriptive documentation I can find for the slew
On 06/25/2013 08:57 AM, James Hogan wrote:
On 25/06/13 14:22, Linus Walleij wrote:
Can't we just try to come up with a patch that nails down the meaning of
slew rate in some meaningful manner then?
So according to:
http://en.wikipedia.org/wiki/Slew_rate
a proper expression for slew rate
On 06/22/2013 12:23 PM, Jon Loeliger wrote:
Great! I didn't see any objections, and the week is basically over.
Are we good for a release today?
Hear Ye! Hear Ye!
With a Mandate from the Masses for a tagged release,
your wish has finally been granted!
Excellent! Thank you very much. I
On 06/22/2013 03:23 AM, Gerhard Sittig wrote:
...
On Fri, Jun 21, 2013 at 15:31 -0600, Stephen Warren wrote:
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
update the device tree binding documentation for the GPIO matrix keypad
driver: mention the driver's selecting all columns at once, reword
On 06/22/2013 03:36 AM, Gerhard Sittig wrote:
On Fri, Jun 21, 2013 at 15:34 -0600, Stephen Warren wrote:
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
extend the device tree adjustable hardware configuration:
- allow for differing polarity of the row and column GPIO pins
- optionally fully
On 06/22/2013 03:50 AM, Gerhard Sittig wrote:
...
The patch set doesn't introduce that behaviour, but merely
describes it in more detail. It doesn't even introduce the
interrupt discussion into the binding document in a strict sense,
but expands on it in the hope for improved usability of
On 06/22/2013 04:00 AM, Gerhard Sittig wrote:
On Fri, Jun 21, 2013 at 15:41 -0600, Stephen Warren wrote:
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
On 06/22/2013 04:17 AM, Gerhard Sittig wrote:
On Fri, Jun 21, 2013 at 16:00 -0600, Stephen Warren wrote:
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
querying keyboards isn't a time critical task and does not depend on
exact timing in the microseconds order -- the timeouts and delays
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Hello Stephen,
On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
update the device tree binding documentation for the GPIO matrix keypad
driver: mention the driver's selecting all columns at once, reword the
delay descriptions, add the missing active low GPIO pin level property
diff --git
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
extend the device tree adjustable hardware configuration:
- allow for differing polarity of the row and column GPIO pins
- optionally fully drive column output pins instead of the former
unconditional open collector emulation approach
diff
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
detecting changes in the key press status may not work reliably in
interrupt driven mode (see the documentation part of the change for
details)
add support to poll the matrix in software for reliable operation in the
presence of multi key press
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
+The driver assumes that all interconnections of the matrix can potentially
+contain a button, and will
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
introduce support to optionally run a binary column address bit pattern
on column GPIO pins in contrast to the formerly assumed one-out-of-N approach
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
querying keyboards isn't a time critical task and does not depend on
exact timing in the microseconds order -- the timeouts and delays are
arbitrary choices or educated guesses at best anyway
diff --git
On 06/17/2013 05:42 PM, David Gibson wrote:
On Mon, Jun 17, 2013 at 03:28:22PM -0600, Stephen Warren wrote:
On 06/15/2013 09:32 AM, Jon Loeliger wrote:
Hrm. We should make a new release. But I don't think we
should bump the version without actuall rolling a release.
..and are we ready
On 06/13/2013 02:59 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.
Rob, Grant, are you OK
c58299aa87544a590c62bda0bf52b69fa56cb8d5 (kbuild: create an
include chroot for DT bindings) merged in v3.10-rc1.
Reviewed-by: Stephen Warren swar...@nvidia.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree
On 06/18/2013 11:57 PM, Keerthy wrote:
From: J Keerthy j-keer...@ti.com
Check if irq value obtained is valid. If it is not valid
then skip the irq request step and go ahead with the probe.
Reviewed-by: Stephen Warren swar...@nvidia.com
On 06/19/2013 06:03 AM, Linus Walleij wrote:
On Tue, Jun 18, 2013 at 11:29 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges
On 06/15/2013 02:16 PM, Heiko Stübner wrote:
Am Samstag, 15. Juni 2013, 21:56:05 schrieb Linus Walleij:
On Fri, Jun 14, 2013 at 12:39 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
mmcif_pins: mmcif {
mux {
On 06/11/2013 04:03 PM, Laurent Pinchart wrote:
Document DT properties for the generic pinctrl parameters and add a
parser function.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+== Generic
On 06/18/2013 03:29 AM, Christian Ruppert wrote:
The pinmux driver of the Abilis Systems TB10x platform based on ARC700 CPUs.
Used to control the pinmux and is a prerequisite for the GPIO driver.
diff --git a/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt
On 06/18/2013 03:29 AM, Christian Ruppert wrote:
The GPIO driver for the Abilis Systems TB10x series of SOCs based on ARC700
CPUs. It supports GPIO control and GPIO interrupt generation. This driver
works in conjunction with the TB10x pinctrl driver.
Just one comment on the binding (I didn't
On 05/22/2013 01:56 AM, Linus Walleij wrote:
On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
linus.wall...@linaro.org wrote:
This tries to address an issue found when writing an MFD driver
for the Nomadik STw481x PMICs: as the platform is using device
tree exclusively I want to specify the
On 06/17/2013 10:33 AM, Linus Walleij wrote:
On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren swar...@wwwdotorg.org wrote:
This has just shown up in next-20130617, and breaks at least the
TPS65910 and TPS62360 drivers, since they assume that the id parameter
passed to probe is non-NULL
On 06/15/2013 09:32 AM, Jon Loeliger wrote:
Hrm. We should make a new release. But I don't think we should bump
the version without actuall rolling a release.
..and are we ready to do so?
I don't see anyone saying no...
How about if nobody objects, a release is made by the end of the
On 06/17/2013 04:15 PM, Grant Likely wrote:
On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
This has just shown up in next-20130617, and breaks at least the
TPS65910 and TPS62360
On 06/14/2013 02:27 AM, Alexandre Courbot wrote:
On Fri, Jun 14, 2013 at 4:19 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Add basic support for booting secondary processors on Tegra devices
using the Trusted Foundations secure monitor
On 06/14/2013 02:54 AM, Alexandre Courbot wrote:
On Fri, Jun 14, 2013 at 4:23 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Use a firmware operation to set the CPU reset handler and only resort to
doing it ourselves if there is none defined
On 06/14/2013 07:12 PM, David Gibson wrote:
On Tue, Jun 11, 2013 at 11:11:25AM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Many useful new features have been added to dtc since the last
release. Projects that use dtc wish to test the version number to
determine
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Add basic support for booting secondary processors on Tegra devices
using the Trusted Foundations secure monitor.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/devicetree/bindings/arm/tegra.txt| 11 +
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Not all Tegra devices need to set the CPU reset handler in the same way.
s/need/can/ ?
In particular, devices using a TrustZone secure monitor cannot set the
reset handler directly and need to do it through a firmware operation.
This patch
From: Stephen Warren swar...@nvidia.com
The gpio-ranges properties in vf610.dtsi were written according to an
older version of the GPIO bindings. Unfortunately, these were changed
incompatibly in commit 86853c8 gpio: add gpio offset in gpio range
cells property. This patch adds the missing
From: Stephen Warren swar...@nvidia.com
Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/gpio/gpiolib-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
Assuming the previous patches are accepted, I assume this should be
applied or squashed into the branch where vf610.dtsi was added
From: Stephen Warren swar...@nvidia.com
Commit bd69f73 of: Create function for counting number of phandles in
a property renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing gpio-ranges property already
allows non-linear ranges to be
On 06/13/2013 03:48 PM, Grant Likely wrote:
This patch merely updates the generated dtc parser and lexer files to
the output generated by Bison 2.5. The previous versions were generated
from version 2.4.1. The only reason for this commit is to minimize the
diff on the next commit which fixes a
On 06/13/2013 04:52 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-06-13 at 23:22 +0100, Grant Likely wrote:
Grant Likely (2):
dtc: Update generated files to output from Bison 2.5
dtc: ensure #line directives don't consume data from the next
Question. Are those fixes also in
On 06/11/2013 05:33 PM, Scott Wood wrote:
I get the following lockdump output on p2020rdb using
v3.10-rc5-43-g34376a5. While it's not particularly polite for the
esdhc driver to be calling OF functions while holding another lock which
can be acquired from interrupt context, why is
On 06/12/2013 02:19 AM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Reviewed-by: Stephen Warren swar...@nvidia.com
diff --git a/arch/arm/boot/dts
On 06/12/2013 06:30 AM, Thierry Reding wrote:
On Mon, Apr 15, 2013 at 12:28:12PM -0600, Stephen Warren wrote:
On 04/03/2013 08:45 AM, Thierry Reding wrote:
Move the PCIe driver from arch/arm/mach-tegra into the
drivers/pci/host directory. The motivation is to collect
various host controller
From: Stephen Warren swar...@nvidia.com
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part
On 06/12/2013 10:46 AM, Mark Brown wrote:
On Tue, Jun 11, 2013 at 02:40:40PM -0600, Stephen Warren wrote:
+- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's
LDO1_EN pin.
Why gpios and not gpio?
For some reason, GPIO properties have always been named gpios rather
than gpio, even
1 - 100 of 1676 matches
Mail list logo
