On Wed, 2011-12-07 at 02:39 -0500, David Miller wrote:
> From: Benjamin Herrenschmidt
> 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 alr
From: Benjamin Herrenschmidt
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
tree so you do not have to
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
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
>>
On 14:17 Thu 21 Jul , ac...@nvidia.com wrote:
> From: Andrew Chew
>
> 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
> Acked-by: Stephen Warren
> ---
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 so
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
---
Changes in v3:
- Drop Tegra USB alignment patch as we will deal with this another way
include/configs/seaboard.h |5 +
1 files changed, 5
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.
Signed-off
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
---
arch/arm/cpu/armv7/tegra2/config.mk |2 +
arch/arm
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
---
Changes in v2:
- Use "okay" instead of "ok" for fdt node status
- Remove 0x from fdt aliases
Changes in v3:
- Remove "okay" from nodes since this
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 nod
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
Signed-off-by: Simon Glass
---
board/nvidia/dts/tegra2-seaboard.dts | 36 ++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 board/nvidia/
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
Signed-off-by: Simon Glass
---
arch/arm/dts/skeleton.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/dts/skeleton.dtsi
diff --git a/arc
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 = ;
where:
phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is a flag, as follows:
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 to
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
---
include/fdtdec.h | 40 ++
Hi Mike,
On Mon, Dec 5, 2011 at 7:55 PM, Mike Frysinger 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 "virtual" (
Hi David,
On Tue, Dec 6, 2011 at 3:12 PM, David Gibson
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 the property i
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
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
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 Mol
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
Acked-by: Arnd Bergmann
_
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
Acked-by: Arnd Bergmann
___
devicetree-discu
On Tuesday 06 December 2011 15:43:47 Pawel Moll wrote:
> This patch adds support for RS1 memory map based Versatile Express
> motherboard.
>
> Signed-off-by: Pawel Moll
Acked-by: Arnd Bergmann
___
devicetree-discuss mailing list
devicetree-discuss@lis
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
Reviewed-by: Arnd Bergmann
___
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 ar
> > 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
Hi Wolfgang,
> > right, this additional API needs new drivers for all the watchdogs? Also, I
> > didn't fully get what you are missing from the combination of the current
> > API
> > and additional userspace-handling? (check [1] for one example, not really
...
> But as Heikow wrote; this is a R
From: Anton Staff
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
---
Changes in v2:
- Use correct name for get_prop_check_min_len() function
include/fdtdec.h | 32
From: Anton Staff
Seaboard uses a QUERTY keyboard. We add key codes for this to
enable key scanning to work.
Signed-off-by: Simon Glass
---
Changes in v2:
- Remove status = "okay" since this is the default anyway
board/nvidia/dts/tegra2-seaboard.dts | 70 ++
From: Anton Staff
The Tegra keyboard controller provides a simple interface to a matrix
keyboard.
Signed-off-by: Simon Glass
---
arch/arm/dts/tegra20.dtsi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 27
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 cou
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.
>
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 so
Hi Stephen,
On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren wrote:
> On 12/05/2011 05:55 PM, Simon Glass wrote:
>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren wrote:
>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds peripheral IDs and timing information to the USB part of the
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
> 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
On 12/05/2011 05:55 PM, Simon Glass wrote:
> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren 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 to
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
d
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 tr
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
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
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
> >
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 r
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 tha
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
> backl
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
> Cc: Grant Likely
> Cc: Rob Herring
The file contains a mix of #ifdef and #if defined().
Replace the #if... by #ifdef.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/
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
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap3-beagle.dts |9 -
arch/arm/boo
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 PROC_DE
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: OMAP2+:
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
---
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 138 +++
arch/arm/mach-vexpress/Kconfig |
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
---
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 131
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 145 +++
This patch adds support for RS1 memory map based Versatile Express
motherboard.
Signed-off-by: Pawel Moll
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 196 +
arch/arm/mach-vexpress/include/mach/debug-macro.S | 37 -
arch/arm/mach-vexpress/include/mach/uncomp
This patch provides hooks for DT-based tile machine implementations
and adds Flattened Device Tree description for the motherboard.
Signed-off-by: Pawel Moll
---
Documentation/devicetree/bindings/arm/vexpress.txt | 118
arch/arm/boot/dts/vexpress-v2m.dtsi| 195
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 compile-tim
Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to versatile_secondary_startup().
Signed-off-by: Pawel Moll
---
arch/arm/mach-realview/platsmp.c |3 +--
arch/arm/mach-vexpress/platsmp.c |4 +---
arch/arm/plat-versatile/headsmp.S |1 +
3 files cha
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
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). I
It adds device tree probe support for mc13xxx mfd driver.
Signed-off-by: Shawn Guo
Cc: Samuel Ortiz
---
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 resend this patch (as v3) instead
of the whole
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
> >f
> 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
> brea
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 t
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 som
> 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 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-discover
> 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.
> 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 c
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
> 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.
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
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 early
> on during the x
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
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.
> 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 amo
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
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 h
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 spec
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
76 matches
Mail list logo
