On Thu, Jan 19, 2012 at 02:28:28, Grant Likely wrote:
On Wed, Jan 18, 2012 at 12:43:58PM +0530, Vaibhav Hiremath wrote:
Although we consider am33xx device under omap34xx family of devices,
there is indeed difference between them, for example,
- Initial required mapping (-map_io)
* Grant Likely grant.lik...@secretlab.ca [120118 11:48]:
On Wed, Jan 18, 2012 at 07:32:56AM -0800, Tony Lindgren wrote:
But then the .dts file becomes an unreadable matrix unless we have
a preprocessor..
One node per pin does get excessive in a hurry. I prefer the one node
per pin
On Wed, Jan 18, 2012 at 06:04:53PM +, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 05:50:28PM +, Lorenzo Pieralisi wrote:
I agree with you Russell, that's 100% valid on a single cluster. But on
a multi-cluster (eg dual-cluster) the MPIDR might be wired like this:
* Stephen Warren swar...@nvidia.com [120118 11:29]:
Tony Lindgren wrote at Wednesday, January 18, 2012 7:13 AM:
I'd prefer not to do that for my platforms, for the reason Shawn points
out in his reply to yours.
However, I believe the bindings I proposed are flexible enough to allow
you to
Hi Olof,
On Tuesday 20 December 2011 12:39 PM, Aneesh V wrote:
Hi Olof,
On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
Hi,
Some comments below, but also a more general question: How much of
this generic data makes sense to encode in the device tree? Final
hardware configuration
On Thu, Jan 19, 2012 at 12:18:32PM +, Catalin Marinas wrote:
On Wed, Jan 18, 2012 at 06:04:53PM +, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 05:50:28PM +, Lorenzo Pieralisi wrote:
This sounds like you're saying that the contents of MPIDR might be buggy
sometime
On Wed, Jan 18, 2012 at 06:04:53PM +, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 05:50:28PM +, Lorenzo Pieralisi wrote:
This sounds like you're saying that the contents of MPIDR might be buggy
sometime in the future? Do we actually know of any situations where the
On 14 January 2012 02:09, Stephen Warren swar...@nvidia.com wrote:
I thought a bit more about pinmux DT bindings. I came up with something
that I like well enough, and is pretty similar to the binding that Dong
posted recently. I think it'll work for both Tegra's and IMX's needs.
Please take a
Hi,
Sorry about lng delay - I've been on holiday.
On Wed, 2012-01-04 at 16:35 +, David Vrabel wrote:
On 15/12/11 14:02, Pawel Moll wrote:
This patch adds support for RS1 memory map based Versatile Express
motherboard.
[...]
---
On 01/19/2012 07:27 AM, Pawel Moll wrote:
On Tue, 2012-01-10 at 14:21 +, David Vrabel wrote:
On 15/12/11 14:02, Pawel Moll wrote:
This patch adds Device Tree file for the CoreTile Express A15x2
(V2P-CA15) with Test Chip 1.
This doesn't work as-is with the software model as accessing some
On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
You're right - the skeleton.dtsi contains memory mode... Funnily
enough originally I was using that name, but then Rob Herring suggested
changing it to @8000, which seemed reasonable.
Now I wonder - is the memory node special and
On 01/19/2012 07:43 AM, Pawel Moll wrote:
On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
You're right - the skeleton.dtsi contains memory mode... Funnily
enough originally I was using that name, but then Rob Herring suggested
changing it to @8000, which seemed reasonable.
Now I
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently,
we have added properties for only DDR3 and LPDDR2 memories.
However, the binding can be easily extended to describe
other types such as
device tree bindings for DDR SDRAM memories compliant
to JEDEC standards. Currently only DDR3 and LPDDR2 have
been considered for this binding. Properties for other
memory types(DDR2 etc) could be added to this binding
on a need-basis.
The 'ddr' binding in-turn uses another binding 'ddr-timings'
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit
Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 64 +
On Thursday 19 January 2012 07:58 PM, Aneesh V wrote:
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently,
we have added properties for only DDR3 and LPDDR2 memories.
However, the binding
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for LPDDR2 memories.
Second patch provides the bindings for the EMIF controller.
The final patch provides DT data for EMIF controller instances
in OMAP4 and
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR memory devices attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Olof Johansson o...@lixom.net
Signed-off-by: Aneesh V ane...@ti.com
---
Changes in RFC v3:
* Fixed review comments
On Thu, 2012-01-19 at 14:01 +, Rob Herring wrote:
On 01/19/2012 07:43 AM, Pawel Moll wrote:
On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
You're right - the skeleton.dtsi contains memory mode... Funnily
enough originally I was using that name, but then Rob Herring suggested
On 19/01/12 13:21, Pawel Moll wrote:
Hi,
Sorry about lng delay - I've been on holiday.
On Wed, 2012-01-04 at 16:35 +, David Vrabel wrote:
On 15/12/11 14:02, Pawel Moll wrote:
This patch adds support for RS1 memory map based Versatile Express
motherboard.
[...]
---
On Tue, Jan 17, 2012 at 8:50 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Monday, January 16, 2012 9:09 AM:
As you can see none of the text above claims that the group is
about hardware-defined groups or anything like that.
Well, I guess that's true, but didn't we only
* Thomas Abraham thomas.abra...@linaro.org [120119 04:37]:
The io-pad controller (gpio/pinmux/pinconfig) can be represented in a
dtsi file as below. There could be multiple io-pad controllers
supported in the system.
FYI we too have too mux controller instances on omap4. That seems to
work
On 19/01/12 14:51, Pawel Moll wrote:
On Thu, 2012-01-19 at 14:01 +, Rob Herring wrote:
On 01/19/2012 07:43 AM, Pawel Moll wrote:
On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
You're right - the skeleton.dtsi contains memory mode... Funnily
enough originally I was using that name,
* Stephen Warren swar...@nvidia.com [120118 11:21]:
Thomas Abraham wrote at Wednesday, January 18, 2012 5:16 AM:
On 14 January 2012 02:09, Stephen Warren swar...@nvidia.com wrote:
I thought a bit more about pinmux DT bindings. I came up with something
that I like well enough, and is
On Thu, Jan 19, 2012 at 05:00:56PM +, David Vrabel wrote:
I don't expect any real production vexpress system to use this config
options
I do - _if_ I decide to try DT on my Versatile Express. That'll be
with the existing boot setup, which will be ATAG based.
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
The problem wasn't with including skeleton.dtsi.
Including as it is creates two device_type=memory nodes, one with
regs=0 0, which is definitely wrong.
With
CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies the appended
DTB
Olof Johansson wrote at Thursday, January 19, 2012 12:13 AM:
On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass s...@chromium.org wrote:
Hi Olof,
On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson o...@lixom.net wrote:
Hi,
On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass s...@chromium.org wrote:
On Thu, 2012-01-19 at 16:46 +, David Vrabel wrote:
It does for me:
# zcat /proc/config.gz | grep EARLY_PRINTK
CONFIG_EARLY_PRINTK=y
# cat /proc/device-tree/motherboard/arm,v2m-memory-map echo
rs1
#
earlyprintk needs to be on the kernel command line to enable it.
Hi Tony,
On 19 January 2012 22:26, Tony Lindgren t...@atomide.com wrote:
* Thomas Abraham thomas.abra...@linaro.org [120119 04:37]:
The io-pad controller (gpio/pinmux/pinconfig) can be represented in a
dtsi file as below. There could be multiple io-pad controllers
supported in the system.
On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
The problem wasn't with including skeleton.dtsi.
Including as it is creates two device_type=memory nodes, one with
regs=0 0, which is definitely wrong.
With
On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
The problem wasn't with including skeleton.dtsi.
Including as it is creates two
Requesting iomem region and ioremaping is now done using
the resource size specified instead of a constant value.
Each SoC_device.c file is modified accordingly to reflect
actual user interface size.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
This patch series adds the device tree support to the Timer Counter library and
user. The only mainlined user is the clocksource tcb_clksrc.
This series goes on top of current work-in-progress for AIC irqdomain/DT
support:
[PATCH 0/6] ARM: at91: irqdomain and device tree for AIC and GPIO
and
Device tree support added to atmel_tclib: the generic Timer Counter
library. This is used by the clocksource/clockevent driver tcb_clksrc.
The current DT enabled platforms are also modified to use it:
- .dtsi files are modified to add Timer Counter Block entries
- alias are created to allow
Some SoC have a 32 bit variant of Timer Counter Blocks. We do not
need the chaining of two 16 bit counters anymore for them.
The SoC nature is deduced from the device tree compatible string.
For non-device-tree configurations, backward compatibility is maintained
by using the default 16 bit
Tegra20's GPIO controller has 7 banks, and Tegra30's controller has 8
banks. Allow the number of banks to be configured at run-time by the
device tree.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
This patch depends on:
* Thomas Abraham thomas.abra...@linaro.org [120119 09:05]:
On 19 January 2012 22:26, Tony Lindgren t...@atomide.com wrote:
* Thomas Abraham thomas.abra...@linaro.org [120119 04:37]:
i2c0: i2c@1800 {
[... other properties ...]
pinctrl-active = pctrl0 5 0 2 3 0,
On 19 January 2012 23:50, Tony Lindgren t...@atomide.com wrote:
* Thomas Abraham thomas.abra...@linaro.org [120119 09:05]:
On 19 January 2012 22:26, Tony Lindgren t...@atomide.com wrote:
* Thomas Abraham thomas.abra...@linaro.org [120119 04:37]:
i2c0: i2c@1800 {
[... other
On Thu, 19 Jan 2012, Grant Likely wrote:
On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
The problem wasn't with including
Hi,
On Mon, Jan 16, 2012 at 11:15 AM, Turquette, Mike mturque...@ti.com wrote:
And delaying DVFS (at least for the parts affecting mem) until
userspace is loaded doesn't seem great to me either. We're basically
pushing back feature readiness (with respect to boot sequence) in the
name of
Linus Walleij wrote at Thursday, January 19, 2012 9:56 AM:
On Tue, Jan 17, 2012 at 8:50 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Monday, January 16, 2012 9:09 AM:
As you can see none of the text above claims that the group is
about hardware-defined groups or
Hi,
Sorry for the delay in responding, I know you pinged me about it yesterday.
On Thu, Jan 19, 2012 at 6:31 AM, Aneesh V ane...@ti.com wrote:
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
On 01/12/2012 12:00 PM, Simon Glass wrote:
Some devices can deal with multiple compatible properties. The devices
need to know which nodes to bind to which features. For example an
I2C driver which supports two different controller types will want to
know which type it is dealing with in each
On 01/12/2012 12:00 PM, Simon Glass wrote:
Add U-Boot's peripheral clock information to the Tegra20 device tree file.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index ca7b523..963cf27 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -45,6
Hi Olof,
On Friday 20 January 2012 01:01 AM, Olof Johansson wrote:
Hi,
Sorry for the delay in responding, I know you pinged me about it yesterday.
On Thu, Jan 19, 2012 at 6:31 AM, Aneesh Vane...@ti.com wrote:
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
On Thu, Jan 19, 2012 at 11:09 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Thu, 19 Jan 2012, Grant Likely wrote:
On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
On Thu, 2012-01-19 at 17:00
Hi Stephen,
On Thu, Jan 19, 2012 at 12:49 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/12/2012 12:00 PM, Simon Glass wrote:
Some devices can deal with multiple compatible properties. The devices
need to know which nodes to bind to which features. For example an
I2C driver which supports
Hi Stephen,
On Wed, Jan 18, 2012 at 2:24 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/11/2012 09:32 PM, Simon Glass wrote:
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
Hi Stephen,
On Wed, Jan 18, 2012 at 2:30 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/11/2012 09:32 PM, Simon Glass wrote:
Add a directory to hold device tree binding files, to permit easy review
of this material in U-Boot patches.
Signed-off-by: Simon Glass s...@chromium.org
diff
Hi Stephen,
On Wed, Jan 18, 2012 at 4:19 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/11/2012 09:33 PM, Simon Glass wrote:
This adds clock references to the USB part of the device tree for U-Boot.
The USB timing information may vary between boards sometimes, but for
now we hard-code it
Hi,
On Thu, Jan 19, 2012 at 9:33 AM, Stephen Warren swar...@nvidia.com wrote:
Olof Johansson wrote at Thursday, January 19, 2012 12:13 AM:
On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass s...@chromium.org wrote:
Hi Olof,
On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson o...@lixom.net wrote:
On 01/19/2012 04:51 PM, Simon Glass wrote:
Hi Stephen,
On Wed, Jan 18, 2012 at 2:24 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/11/2012 09:32 PM, Simon Glass wrote:
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
config.mk is
On 01/19/2012 04:45 PM, Simon Glass wrote:
Hi Stephen,
On Thu, Jan 19, 2012 at 12:49 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/12/2012 12:00 PM, Simon Glass wrote:
Some devices can deal with multiple compatible properties. The devices
need to know which nodes to bind to which
Hi Stephen,
On Thu, Jan 19, 2012 at 4:17 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/19/2012 04:45 PM, Simon Glass wrote:
Hi Stephen,
On Thu, Jan 19, 2012 at 12:49 PM, Stephen Warren swar...@nvidia.com wrote:
On 01/12/2012 12:00 PM, Simon Glass wrote:
Some devices can deal with
On 01/13/2012 04:10 PM, Simon Glass wrote:
Add a NAND controller along with a bindings file for review.
A few questions to start with:
diff --git a/doc/device-tree-bindings/nand/nvidia-nand.txt
b/doc/device-tree-bindings/nand/nvidia-nand.txt
+NAND Flash
+--
+
+(there isn't yet a
59 matches
Mail list logo
