On Tue, Jul 19, 2011 at 09:17:26AM +0800, Shawn Guo wrote:
On Mon, Jul 18, 2011 at 10:02:44AM -0700, Dmitry Torokhov wrote:
On Monday, July 18, 2011 09:45:07 AM Shawn Guo wrote:
The patch makes a copy of platform data into driver data, so that any
reference to platform_data after .probe
Hi Haojian,
On Tue, 19 Jul 2011 10:24:43 +0800, Haojian Zhuang wrote:
It's used to support DT on ARCH-MMP.
Haojian Zhuang (7):
ARM: mmp: parse irq from DT
ARM: mmp: append MMP_USE_OF config
ARM: mmp: support DT on both dkb and brownstone
tty: serial: support
On Mon, Jul 18, 2011 at 09:51:28PM -0400, Chris Ball wrote:
Hi Shawn, Sascha,
On Sat, Jul 09 2011, Shawn Guo wrote:
Shawn Guo (4):
mmc: sdhci-esdhc-imx: do not reference platform data after probe
mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx()
mmc:
On Tue, Jul 19, 2011 at 08:48:41AM +0100, Russell King - ARM Linux wrote:
On Tue, Jul 19, 2011 at 09:17:26AM +0800, Shawn Guo wrote:
On Mon, Jul 18, 2011 at 10:02:44AM -0700, Dmitry Torokhov wrote:
On Monday, July 18, 2011 09:45:07 AM Shawn Guo wrote:
The patch makes a copy of platform
On Tue, Jul 19, 2011 at 10:10:27AM +0200, Sascha Hauer wrote:
On Mon, Jul 18, 2011 at 09:51:28PM -0400, Chris Ball wrote:
Hi Shawn, Sascha,
On Sat, Jul 09 2011, Shawn Guo wrote:
Shawn Guo (4):
mmc: sdhci-esdhc-imx: do not reference platform data after probe
mmc:
On Tue, Jul 19, 2011 at 10:24 AM, Haojian Zhuang
haojian.zhu...@marvell.com wrote:
Support to parse some optional properties. These three properties are
i2c-polling, i2c-frequency, i2c-class.
After supporting these property, i2c-pxa driver can avoid to use platform
data except for slave mode.
On Mon, Jul 18, 2011 at 04:31:40PM -0600, Grant Likely wrote:
This patch adds irq_domain infrastructure for translating from
hardware irq numbers to linux irqs. This is particularly important
for architectures adding device tree support because the current
implementation (excluding PowerPC
Thanks for doing this work. I'm currently working on a One Laptop Per
Child product that is based on the Armada 610, so this very timely for OLPC.
See my in-line comments on the specification of the soc top-level nodes,
related to the addressing of their children, and on the presence of
On Sunday 17 July 2011, Tabi Timur-B04825 wrote:
Shawn Guo wrote:
Ok, I will take this as a serious warning, and start evaluating the
driver consolidation. I will absolutely need you help along the way.
At least, when we get there, I need your favor to test mpc platform,
as I do not have
On Tue, Jul 19, 2011 at 2:00 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Mon, Jul 18, 2011 at 5:53 AM, G, Manjunath Kondaiah
manj...@linaro.org wrote:
Abraham,
Few comments on i2c child devices handling:
On 18 July 2011 06:20, Thomas Abraham thomas.abra...@linaro.org wrote:
Add
On Mon, Jul 18, 2011 at 8:24 PM, Haojian Zhuang
haojian.zhu...@marvell.com wrote:
Parse irq sepcifier from DT and translate it to Linux irq number.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
.../devicetree/bindings/arm/marvell/intc.txt | 120 +++
On Tue, Jul 19, 2011 at 10:24:45AM +0800, Haojian Zhuang wrote:
Since NR_IRQS is defined in irqs.h, parsing irq specifier will be started
from NR_IRQS while both CONFIG_USE_OF and CONFIG_SPARSE_IRQ is enabled.
It breaks the assumption that base irq is started from 0.
Add CONFIG_MMP_USE_OF
On Tue, Jul 19, 2011 at 10:24:46AM +0800, Haojian Zhuang wrote:
Add new boards.c to support both TTC-DKB and MMP2-BROWNSTONE. While
CONFIG_MMP_USE_OF is selected, original ttc_dkb.c and brownstone.c won't be
compiled.
While everything moving to DT in ARCH-MMP, original ttc_dkb.c and
On Tue, Jul 19, 2011 at 10:24:47AM +0800, Haojian Zhuang wrote:
Support both normal platform driver and device tree driver in serial pxa.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
drivers/tty/serial/Kconfig |4 +-
drivers/tty/serial/of_serial.c | 12 +
On Tue, Jul 19, 2011 at 10:24:49AM +0800, Haojian Zhuang wrote:
support i2c-pxa controller from DT.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
drivers/i2c/busses/i2c-pxa.c | 58 ++---
1 files changed, 42 insertions(+), 16 deletions(-)
On Tue, Jul 19, 2011 at 06:17:21PM +0800, Eric Miao wrote:
On Tue, Jul 19, 2011 at 10:24 AM, Haojian Zhuang
haojian.zhu...@marvell.com wrote:
Support to parse some optional properties. These three properties are
i2c-polling, i2c-frequency, i2c-class.
After supporting these property,
On Tuesday 19 July 2011 13:40:10 Grant Likely wrote:
On Tue, Jul 19, 2011 at 10:24:47AM +0800, Haojian Zhuang wrote:
Support both normal platform driver and device tree driver in serial pxa.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
drivers/tty/serial/Kconfig |
On Tue, Jul 19, 2011 at 1:48 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 July 2011 13:40:10 Grant Likely wrote:
On Tue, Jul 19, 2011 at 10:24:47AM +0800, Haojian Zhuang wrote:
Support both normal platform driver and device tree driver in serial pxa.
Signed-off-by: Haojian Zhuang
On Tue, Jul 19, 2011 at 01:53:53PM -0600, Grant Likely wrote:
On Tue, Jul 19, 2011 at 1:48 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 July 2011 13:40:10 Grant Likely wrote:
On Tue, Jul 19, 2011 at 10:24:47AM +0800, Haojian Zhuang wrote:
Support both normal platform driver and
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
* Grant Likely grant.lik...@secretlab.ca [110716 22:08]:
The way I see it, you've got two options:
1) modify the of_platform_bus_create() to call some kind of
of_platform_bus_create_omap() for devices that match
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
---
.../devicetree/bindings/usb/tegra20-ehci.txt | 27
From: Andrew Chew ac...@nvidia.com
These values were derived from various headers in arch/arm/mach-tegra.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/boot/dts/tegra20.dtsi | 52
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git
ac...@nvidia.com wrote at Tuesday, July 19, 2011 4:47 PM:
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
On Tue, Jul 19, 2011 at 03:56:29PM -0700, Stephen Warren wrote:
ac...@nvidia.com wrote at Tuesday, July 19, 2011 4:47 PM:
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
ac...@nvidia.com wrote at Tuesday, July 19, 2011 4:47 PM:
From: Andrew Chew ac...@nvidia.com
Signed-off-by: Andrew Chew ac...@nvidia.com
Removing status=disabled from tegra20.dtsi makes this patch obsolete.
Although that said, since many of the USB properties are board-specific
and
Stephen Warren wrote at Tuesday, July 19, 2011 5:00 PM:
ac...@nvidia.com wrote at Tuesday, July 19, 2011 4:47 PM:
From: Andrew Chew ac...@nvidia.com
These values were derived from various headers in arch/arm/mach-tegra.
...
diff --git a/arch/arm/boot/dts/tegra20.dtsi
Although that said, since many of the USB properties are
board-specific
and determined by system characterization, they aren't generally
applicable to all Tegra devices. As such, should those values be moved
into tegra-seaboard.dts instead? Perhaps tegra20.dtsi should specify
the default
On Tue, Jul 19, 2011 at 4:50 PM, Andrew Chew ac...@nvidia.com wrote:
Although that said, since many of the USB properties are
board-specific
and determined by system characterization, they aren't generally
applicable to all Tegra devices. As such, should those values be moved
into
Hi,
On Tue, Jul 19, 2011 at 3:46 PM, ac...@nvidia.com wrote:
From: Andrew Chew ac...@nvidia.com
These values were derived from various headers in arch/arm/mach-tegra.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/boot/dts/tegra20.dtsi | 52
And since there are defaults specified in tegra20.dtsi,
does it really make sense to also have default values
assigned in ehci-tegra.c (for when a property is not
present)? I worry that the information is now duplicated.
If those properties aren't present, then someone's mucked
with
On Tue, Jul 19, 2011 at 5:07 PM, Andrew Chew ac...@nvidia.com wrote:
And since there are defaults specified in tegra20.dtsi,
does it really make sense to also have default values
assigned in ehci-tegra.c (for when a property is not
present)? I worry that the information is now duplicated.
On Wed, Jul 20, 2011 at 3:45 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Tue, Jul 19, 2011 at 10:24:50AM +0800, Haojian Zhuang wrote:
Support to parse some optional properties. These three properties are
i2c-polling, i2c-frequency, i2c-class.
After supporting these property, i2c-pxa
On Wed, Jul 20, 2011 at 4:05 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jul 19, 2011 at 01:53:53PM -0600, Grant Likely wrote:
On Tue, Jul 19, 2011 at 1:48 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 July 2011 13:40:10 Grant Likely wrote:
On Tue, Jul 19, 2011
On Fri, 2011-07-15 at 12:49 +0800, Shawn Guo wrote:
+static const struct of_device_id dataflash_dt_ids[] = {
+ { .compatible = atmel,at45xxx, },
+ { .compatible = atmel,dataflash, },
+ { /* sentinel */ }
+};
+
This should be protected with a #ifdef CONFIG_OF/#else/#endif,
On Wed, Jul 20, 2011 at 07:40:38AM +0300, Artem Bityutskiy wrote:
On Fri, 2011-07-15 at 12:49 +0800, Shawn Guo wrote:
+static const struct of_device_id dataflash_dt_ids[] = {
+ { .compatible = atmel,at45xxx, },
+ { .compatible = atmel,dataflash, },
+ { /*
On Fri, 2011-07-15 at 16:38 +0800, Shawn Guo wrote:
It adds device tree probe support for mtd_dataflash driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: David Woodhouse dw...@infradead.org
Cc: Artem Bityutskiy artem.bityuts...@nokia.com
On Wed, 2011-07-20 at 12:55 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 07:40:38AM +0300, Artem Bityutskiy wrote:
On Fri, 2011-07-15 at 12:49 +0800, Shawn Guo wrote:
+static const struct of_device_id dataflash_dt_ids[] = {
+ { .compatible = atmel,at45xxx, },
+ {
On Wed, 2011-07-20 at 13:28 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 08:17:45AM +0300, Artem Bityutskiy wrote:
On Wed, 2011-07-20 at 12:55 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 07:40:38AM +0300, Artem Bityutskiy wrote:
On Fri, 2011-07-15 at 12:49 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 01:32, Artem Bityutskiy wrote:
On Wed, 2011-07-20 at 13:28 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 08:17:45AM +0300, Artem Bityutskiy wrote:
On Wed, 2011-07-20 at 12:55 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 07:40:38AM +0300, Artem Bityutskiy wrote:
On Wed, Jul 20, 2011 at 08:32:45AM +0300, Artem Bityutskiy wrote:
On Wed, 2011-07-20 at 13:28 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 08:17:45AM +0300, Artem Bityutskiy wrote:
On Wed, 2011-07-20 at 12:55 +0800, Shawn Guo wrote:
On Wed, Jul 20, 2011 at 07:40:38AM +0300, Artem
On Wed, 2011-07-20 at 13:52 +0800, Shawn Guo wrote:
The argument about this #ifdef thing was the driver could be used by
some platforms that will never migrate to device tree. This table
will be just a waste of bytes for those platforms, if we do not
protect the table by '#ifdef CONFIG_OF'.
41 matches
Mail list logo
