On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote:
On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
[...]
At least for DT enabled platforms, we could force no irq to be 0 in
the DT irq code. Searching the dts files, I
On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
[...]
Unfortunately, NO_IRQ is often not spelled NO_IRQ. It looks like the
assumption
irq 0 === no irq may be quite a lot more widespread than NO_IRQ
=== no irq.
Since there's no specific thing we can grep for
On Tue, Dec 06, 2011 at 11:26:43AM +0800, Shawn Guo wrote:
On Mon, Dec 05, 2011 at 07:09:47PM +, Mark Brown wrote:
That doesn't answer the question - I've still no idea how the binding is
supposed to map the nodes contained within regulators onto the physical
regulators.
And here it
On Fri, Dec 02, 2011 at 03:08:37PM -0700, Stephen Warren wrote:
wm8903_platform_data.gpio_cfg[] was intended to be interpreted as follows:
0: Don't touch this GPIO's configuration register
1..7fff: Write that value to the GPIO's configuration register
8000:Write zero to the GPIO's
Otherwise, it feels like we might need a strategy for migrating pretty
much everything if we don't want to end up in a mess.
You really do anyway - lots of generic driver code knows !dev-irq is a
valid test. That covers things like 8250 based UART hardware, network phy
layer code and vast
On Tue, Dec 06, 2011 at 09:37:09AM +, Dave Martin wrote:
To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially? (i.e., we remap HW irq 0, if there is one,
to some other random number but have a 1:1 mapping for everything else).
Even better.
On Tue, Dec 06, 2011 at 09:30:00AM +, Dave Martin wrote:
Do we expect there to be any platform drivers which are shared between
legacy platforms and newer DT-ised platforms?
Those drivers would be pain points since they would need to understand
both conventions.
So far as I can see,
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used. Let's be crystal clear: even x86
uses IRQ0. It happens to be the PIC timer, and that gets claimed
On Tue, Dec 06, 2011 at 12:00:12PM +0100, Geert Uytterhoeven wrote:
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used. Let's be crystal clear: even
Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.
The ISA bus space is non-discoverable so that doesn't make any sense.
But.. let's make one thing
It's shown in /proc/interrupts due to a bug in show_interrupts().
The (gmail damaged) patch below fixes this bug.
We get API breakage then. Which is a pain of course because debug tools
and the like which think IRQ 0 is timer ticks are somewhat broken.
On Tue, Dec 06, 2011 at 11:05:54AM +, Alan Cox wrote:
Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.
The ISA bus space is non-discoverable so
can we sinply introduce a macro irq_is_valid
See the 2005, 2006 and 2008 discussion.
if (!dev-irq)
is the proper test.
The = is just a temporary thing while ARM gets its publically visible
house in order so it can be done without breakage.
Alan
On Tue, Dec 06, 2011 at 10:46:54AM +, Russell King - ARM Linux wrote:
On Tue, Dec 06, 2011 at 09:37:09AM +, Dave Martin wrote:
To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially? (i.e., we remap HW irq 0, if there is one,
to some
On Tue, Dec 06, 2011 at 11:37:35AM +, Dave Martin wrote:
1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
for the no-interrupt case. Code which receives irq numbers directly
from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
needs to
However, I have suggested in the past that new platforms _should_ avoid
not just IRQ0 but IRQ0-15 (for a completely different reason to that of
'IRQ0 means no IRQ'.) But such comments just get ignored, so I just
don't see the point in doing anything about this. If people experience
On Tue, Dec 06, 2011 at 11:49:52AM +, Russell King - ARM Linux wrote:
On Tue, Dec 06, 2011 at 11:37:35AM +, Dave Martin wrote:
1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
for the no-interrupt case. Code which receives irq numbers directly
from
It adds device tree probe support for mc13xxx mfd driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Samuel Ortiz sa...@linux.intel.com
---
Changes since v2:
* Add some note on how driver matches regulator device and the node
in binding document
Since it's a small change, I only
Hi,
I'm working on adding support for a device which is booted from a device tree
only. Currently this gets me to a login prompt on a serial console and the
device is basically functional. However, the device also has a display with a
backlight that is controlled via a PWM (supplied by the SoC).
Hello again,
Here goes the fourth version of the series, hopefully something that
could be merged for 3.3 (all Revieved-by-s and Acked-by-s welcomed!)
Changes since v3:
* The core tile support has been renamed (no real code change)
to support for platforms based on a processor and the DTBs
Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to versatile_secondary_startup().
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/mach-realview/platsmp.c |3 +--
arch/arm/mach-vexpress/platsmp.c |4 +---
arch/arm/plat-versatile/headsmp.S |
This patch gets rid of the MMIO_P2V and __MMIO_P2V macros,
defining constant virtual base for motherboard and tile
peripherals instead.
Additionally, in preparation for the new motherboard memory
map, the motherboard peripherals are using base pointers
calculated in runtime, instead of
This patch provides hooks for DT-based tile machine implementations
and adds Flattened Device Tree description for the motherboard.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
Documentation/devicetree/bindings/arm/vexpress.txt | 118
arch/arm/boot/dts/vexpress-v2m.dtsi
This patch adds support for RS1 memory map based Versatile Express
motherboard.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 196 +
arch/arm/mach-vexpress/include/mach/debug-macro.S | 37 -
This patch adds Flattened Device Trees based support for ARM Ltd.
Versatile Express platforms based on Cortex-A5 and Cortex-A9
processors.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 131
This patch adds Flattened Device Trees based support for ARM Ltd.
Versatile Express platforms based on Cortex-A7 and Cortex-A15
processors.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 138 +++
Hi Tony,
This is a trivial cleanup series the removed some useless stuff inside
DTS and force DT by default in an omap2plus_config build.
Patches are based 3.2-rc4 and are available here:
git://gitorious.org/omap-pm/linux.git for_3.3/1_dt_base
Regards,
Benoit
Benoit Cousson (3):
ARM:
devicetree will become the mandatory boot method for OMAP2+.
In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF,
select USE_OF by default for every OMAP2+ systems.
Select as well the APPENDED_DTB and ATAG_DTB_COMPAT to allow legacy
boot loader to keep working properly.
Enable
Since 3.2, the CONFIG_ARM_ATAG_DTB_COMPAT config allows
an old bootloader to still use ATAG to provide cmdline.
Remove chosen/bootargs from the DTS board files.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
The file contains a mix of #ifdef and #if defined().
Replace the #if... by #ifdef.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Benoit,
On 12/06/2011 10:49 AM, Benoit Cousson wrote:
Since 3.2, the CONFIG_ARM_ATAG_DTB_COMPAT config allows
an old bootloader to still use ATAG to provide cmdline.
Remove chosen/bootargs from the DTS board files.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely
On 12/06/2011 09:07 AM, Thierry Reding wrote:
Hi,
I'm working on adding support for a device which is booted from a device tree
only. Currently this gets me to a login prompt on a serial console and the
device is basically functional. However, the device also has a display with a
backlight
Stephen Warren wrote at Friday, December 02, 2011 3:09 PM:
Document the device tree binding for the WM8903 codec, and modify the
driver to extract platform data from the device tree, if present.
Mark,
I just realized that when I was re-organizing all the WM8903 patches, I
dropped the part that
On 12/06/2011 12:22 PM, Stephen Warren wrote:
Stephen Warren wrote at Friday, December 02, 2011 3:09 PM:
Document the device tree binding for the WM8903 codec, and modify the
driver to extract platform data from the device tree, if present.
Mark,
I just realized that when I was
On Tue, 6 Dec 2011, Dave Martin wrote:
On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
No need to convert everything.
First move is to make irq=0 meaning no IRQ. That means making things
like:
if (irq 0)
if (irq = 0)
into
if (irq = 0)
On 12/06/2011 05:49 AM, Russell King - ARM Linux wrote:
On Tue, Dec 06, 2011 at 11:37:35AM +, Dave Martin wrote:
1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
for the no-interrupt case. Code which receives irq numbers directly
from the OF framework and
On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
Not for any device driver, though.
It's used entirely internally, and it doesn't even use
request_irq(). It uses the magic internal setup_irq() and never
*ever* exposes irq0 as anything that a driver can see.
That's what
Rob Herring wrote at Tuesday, December 06, 2011 12:07 PM:
On 12/06/2011 12:22 PM, Stephen Warren wrote:
Stephen Warren wrote at Friday, December 02, 2011 3:09 PM:
Document the device tree binding for the WM8903 codec, and modify the
driver to extract platform data from the device tree, if
On 12/06/2011 02:09 PM, Stephen Warren wrote:
Rob Herring wrote at Tuesday, December 06, 2011 12:07 PM:
On 12/06/2011 12:22 PM, Stephen Warren wrote:
Stephen Warren wrote at Friday, December 02, 2011 3:09 PM:
Document the device tree binding for the WM8903 codec, and modify the
driver to
On 12/05/2011 05:55 PM, Simon Glass wrote:
On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds peripheral IDs and timing information to the USB part of the
device tree for U-Boot.
The peripheral IDs provide easy access
Hello Linus,
On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used. Let's be crystal
Hi Stephen,
On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/05/2011 05:55 PM, Simon Glass wrote:
On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds peripheral IDs and timing information
On 11/10/2011 09:25 AM, Anton Vorontsov wrote:
PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.
Other arches might break if some of
Hi Heiko,
This driver provides read/write access to the U-Boot bootcounter
through PROC FS and/or sysFS file.
Why ProcFS? Why ProcFS and/or SysFS? Which has priority? Why not /dev?
I drop the ProcFS support for v2.
Don't bother. This approach starts from the wrong side.
The
Dear Wolfram,
In message 20111206215056.gd14...@pengutronix.de you wrote:
bootcount itself is not a device. It is a feature of certain devices. And that
needs to be implemented; possibly generic enough that it can work for register
based, i2c based, and so forth, accesses.
If boot counter
From: Anton Staff robot...@chromium.org
The Tegra keyboard controller provides a simple interface to a matrix
keyboard.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/dts/tegra20.dtsi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
From: Anton Staff robot...@chromium.org
Seaboard uses a QUERTY keyboard. We add key codes for this to
enable key scanning to work.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Remove status = okay since this is the default anyway
board/nvidia/dts/tegra2-seaboard.dts | 70
From: Anton Staff robot...@chromium.org
Sometimes we don't need a full cell for each value. This provides
a simple function to read a byte array, both with and without
copying it.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use correct name for get_prop_check_min_len()
bootcount itself is not a device. It is a feature of certain devices. And
that
needs to be implemented; possibly generic enough that it can work for
register
based, i2c based, and so forth, accesses.
If boot counter is not a good name for such a device, then what name
would you
On Tuesday 06 December 2011 15:43:45 Pawel Moll wrote:
This patch gets rid of the MMIO_P2V and __MMIO_P2V macros,
defining constant virtual base for motherboard and tile
peripherals instead.
Additionally, in preparation for the new motherboard memory
map, the motherboard peripherals are
On Tuesday 06 December 2011 15:43:46 Pawel Moll wrote:
This patch provides hooks for DT-based tile machine implementations
and adds Flattened Device Tree description for the motherboard.
Signed-off-by: Pawel Moll pawel.m...@arm.com
Reviewed-by: Arnd Bergmann a...@arndb.de
On Tuesday 06 December 2011 15:43:44 Pawel Moll wrote:
Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to versatile_secondary_startup().
Signed-off-by: Pawel Moll pawel.m...@arm.com
Acked-by: Arnd Bergmann a...@arndb.de
On Tuesday 06 December 2011 15:43:48 Pawel Moll wrote:
This patch adds Flattened Device Trees based support for ARM Ltd.
Versatile Express platforms based on Cortex-A5 and Cortex-A9
processors.
Signed-off-by: Pawel Moll pawel.m...@arm.com
Acked-by: Arnd Bergmann a...@arndb.de
On Tuesday 06 December 2011 23:53:46 Arnd Bergmann wrote:
On Tuesday 06 December 2011 15:43:48 Pawel Moll wrote:
This patch adds Flattened Device Trees based support for ARM Ltd.
Versatile Express platforms based on Cortex-A5 and Cortex-A9
processors.
Signed-off-by: Pawel Moll
On 12/06/2011 04:06 PM, Wolfram Sang wrote:
bootcount itself is not a device. It is a feature of certain devices. And
that
needs to be implemented; possibly generic enough that it can work for
register
based, i2c based, and so forth, accesses.
If boot counter is not a good name for such
On Mon, Dec 05, 2011 at 04:29:22PM -0800, Simon Glass wrote:
Hi,
As I understand it, boolean properties in the device tree are defined
as follows:
- if the property is present, then it is true
- if the property is absent, then it is false
That's the common convention. Although an
Hi David,
On Tue, Dec 6, 2011 at 3:12 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Mon, Dec 05, 2011 at 04:29:22PM -0800, Simon Glass wrote:
Hi,
As I understand it, boolean properties in the device tree are defined
as follows:
- if the property is present, then it is true
- if
Hi Mike,
On Mon, Dec 5, 2011 at 7:55 PM, Mike Frysinger vap...@gentoo.org wrote:
On Monday 05 December 2011 17:52:01 Simon Glass wrote:
On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren wrote:
On 12/05/2011 02:56 PM, Simon Glass wrote:
* A system-wide GPIO ID, in which case the numbering is
Add a function to look up a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties, although there is no
actual boolean type in U-Boot.
Signed-off-by: Simon Glass s...@chromium.org
---
This fixes five trivial issues in fdtdec.c:
1. fdtdec_get_is_enabled() doesn't really need a default value
2. The fdt must be word-aligned, since otherwise it will fail on ARM
3. The compat_names[] array is missing its first element. This is needed
only because the first fdt_compat_id is defined
This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:
gpio-function-name = phandle gpio_num flags;
where:
phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/dts/skeleton.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/dts/skeleton.dtsi
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
Signed-off-by: Simon Glass s...@chromium.org
---
board/nvidia/dts/tegra2-seaboard.dts | 36 ++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode
This adds peripheral IDs to the USB part of the device tree for U-Boot.
The peripheral IDs provide easy access to clock registers. We will likely
remove this in favor of a full clock tree when it is available in the
kernel (but probably still retain the peripheral ID, just move it into
a clock
We set up two USB ports, one of which can be host or device.
For some reason the kernel version does enable both ports.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use okay instead of ok for fdt node status
- Remove 0x from fdt aliases
Changes in v3:
- Remove okay from
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
config.mk is updated to provide this file to boards through the
built-in mechanism:
/include/ ARCH_CPU_DTS
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra2/config.mk
By putting the fdt blob into a distinctive area we can ensure that it appears
at the start of the data section and is word-aligned.
Note: It does not seem to be possible to get objcopy to honour its
--section-alignment flag, which would otherwise provide an easier fix
for this problem.
This switches Seaboard over to use FDT for run-time config instead of
CONFIG options. USB is the only user at present.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Drop Tegra USB alignment patch as we will deal with this another way
include/configs/seaboard.h |5 +
On 12/06/2011 05:16 PM, Anton Vorontsov wrote:
PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.
Other arches might break if some of
On 14:17 Thu 21 Jul , ac...@nvidia.com wrote:
From: Andrew Chew ac...@nvidia.com
Add code to try to get platform data information (register base, irq,
modes, various tuning parameters) from device tree, if not present in board
files.
Signed-off-by: Andrew Chew ac...@nvidia.com
Hello Alan,
Alan Cox wrote:
that we have a number of customers who consider the existing wdt
support unsufficient for their use cases. We've been using it on all
kinds on PPC systems, and now on ARM as well.
We will not fight for inclusion of this driver, we just wat to know if
it's worth
On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
This patch enables or updates support for the CC770 and AN82527
CAN controller on the TQM8548 and TQM8xx boards.
I'm a bit confused by the net-next prefix here. Those patches seem to
be only touching arch/powerpc and seem to be sent
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Wed, 07 Dec 2011 18:34:28 +1100
Let me know if I should just remove them from powerpc patchwork.
These are DT entries for CAN devices for which drivers only exist in
the net-next tree, I already included this patch into the net-next
On Wed, 2011-12-07 at 02:39 -0500, David Miller wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Wed, 07 Dec 2011 18:34:28 +1100
Let me know if I should just remove them from powerpc patchwork.
These are DT entries for CAN devices for which drivers only exist in
the
74 matches
Mail list logo
