Re: [PATCH 1/1 v3] dt: add property iteration helpers
On Mon, Apr 9, 2012 at 12:46 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: This patch adds macros of_property_for_each_u32() and of_property_for_each_string(), which iterate over an array of values within a device-tree property. Usage is for example: struct property *prop; const __be32 *p; u32 u; of_property_for_each_u32(np, propname, prop, p, u) printk(U32 value: %x\n, u); struct property *prop; const char *s; of_property_for_each_string(np, propname, prop, s) printk(String value: %s\n, s); Based on work by Rob Herring robherri...@gmail.com Signed-off-by: Stephen Warren swar...@wwwdotorg.org Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- I need it for at91 for the interrupt controller and pinctrl This is merged into the pinctrl tree now anyway, can I add your Acked-by:? Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1 v3] dt: add property iteration helpers
On Mon, Apr 9, 2012 at 5:26 PM, Stephen Warren swar...@wwwdotorg.org wrote: Linus, Grant, Rob, can you co-ordinate this? If you want, I can create the branch and send a pull request to LinusW. I'm not sure which branch Jean-Christophe needs this in for his IRQ work. If we don't change the patch at all I think git will survive if it gets merged into multiple trees... Else whatever branch needs this patch will need to merge the pinctrl baseline or something like that. I will stabilize the pinctrl tree as soon as I've pushed pending fixes for the -rc:s to Torvalds. Thanks, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
Hi Omar,
On 4/11/2012 2:16 AM, Ramirez Luna, Omar wrote:
Hi,
On Wed, Dec 14, 2011 at 5:55 AM, Rajendra Nayakrna...@ti.com wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
...
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
1.7.1
I'm fairly new to DT and I'm trying to boot it with pandaboard and
k3.3, however above hunk deletes omap serial initialization, which
causes a panic on boot, because pdata is NULL:
static void serial_omap_start_tx(struct uart_port *port)
{
...
if (pdata-set_noidle)
Perhaps because this change skips the following path:
omap_serial_init-omap_serial_board_init-omap_serial_init_port
Where pdata is built in omap_device_build.
I'm just trying to confirm that I'm not alone or doing some silly
thing before getting in depth with the code.
Yes, it is a known issue and the fix was unfortunately was not merged
during -rc phases but is fixed in 3.4 and should be fixed in 3.3 stable
branch as well. I received the notification from Greg KH 2 weeks ago
about the stable: Patch tty: serial: OMAP: Fix oops due to NULL pdata
in DT boot has been added to the 3.3-stable tree
You should just switch to 3.4-rc2 or get the patch if you are stuck to 3.3.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Question: Does devicetree capable of describing pinmux?
Hi Fork: I would like to know whether device tree capable of describing pinmux? Say, one pin (PIN_10) which can be configured as I2C_SDL, SPI_CLK, GPIO23, How can I describe in device tree? Or, the I2C controller 1 can be configured to use PIN(23, 24) or PIN(45,46), What should I should do with device tree? Thanks Dennis ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Question: Does devicetree capable of describing pinmux?
Possibly that can be connected to pinctrl subsystem, right? On Wed, Apr 11, 2012 at 5:35 PM, Dennis.Yxun dennis.y...@gmail.com wrote: Hi Fork: I would like to know whether device tree capable of describing pinmux? Say, one pin (PIN_10) which can be configured as I2C_SDL, SPI_CLK, GPIO23, How can I describe in device tree? Or, the I2C controller 1 can be configured to use PIN(23, 24) or PIN(45,46), What should I should do with device tree? Thanks Dennis ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wednesday 11 April 2012 03:56 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
Its the missing context thats confusing :-)
This is how the code looks in the file after the patch.
if ((OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)
(ios-vdd == DUAL_VOLT_OCR_BIT)
/*
* With pbias cell programming missing, this
* can't be allowed when booting with device
* tree.
*/
!host-dev-of_node) {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 03:59:55PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:56 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:
On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:
On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host
*mmc, struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
won't compile
why? compiles fine for me.
aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?
Its the missing context thats confusing :-)
This is how the code looks in the file after the patch.
if ((OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)
(ios-vdd == DUAL_VOLT_OCR_BIT)
/*
* With pbias cell programming missing, this
* can't be allowed when booting with device
* tree.
*/
!host-dev-of_node) {
ok, my bad then. Should've looked at the source code. Sorry for the
noise.
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On 04/11/2012 05:03 AM, Rajendra Nayak wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Ack
Rob
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 1/4] iommu: tegra/gart: use correct gart_device
From: Vandana Salve vsa...@nvidia.com Pass the correct gart device pointer. Reviewed-by: Vandana Salve vsa...@nvidia.com Tested-by: Vandana Salve vsa...@nvidia.com Reviewed-by: Hiroshi Doyu hd...@nvidia.com Reviewed-by: Bharat Nihalani bnihal...@nvidia.com Signed-off-by: Hiroshi DOYU hd...@nvidia.com --- drivers/iommu/tegra-gart.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c index 779306e..f6bc1e6 100644 --- a/drivers/iommu/tegra-gart.c +++ b/drivers/iommu/tegra-gart.c @@ -158,7 +158,7 @@ static int gart_iommu_attach_dev(struct iommu_domain *domain, struct gart_client *client, *c; int err = 0; - gart = dev_get_drvdata(dev-parent); + gart = gart_handle; if (!gart) return -EINVAL; domain-priv = gart; -- 1.7.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 3/4] drm: fixed: Add dfixed_frac() macro
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
include/drm/drm_fixed.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 4a08a66..0ead502 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -37,6 +37,7 @@ typedef union dfixed {
#define dfixed_init(A) { .full = dfixed_const((A)) }
#define dfixed_init_half(A) { .full = dfixed_const_half((A)) }
#define dfixed_trunc(A) ((A).full 12)
+#define dfixed_frac(A) ((A).full ((1 12) - 1))
static inline u32 dfixed_floor(fixed20_12 A)
{
--
1.7.10
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 0/4] Add NVIDIA Tegra DRM support
This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. Note that this is very early work-in-progress and there is a lot of room for improvement and cleanup. You'll also note that there is still a whole lot of debugging output, most of which is disabled by default. However I explicitly wanted to post this early to get feedback and to discuss options on how to get this included in the mainline kernel. I have been in contact with some people at NVIDIA and they seem to be willing to work together on a solution that satisfies both their requirements and those of the community. Thierry Thierry Reding (3): iommu: tegra/gart: Add device tree support drm: fixed: Add dfixed_frac() macro drm: Add NVIDIA Tegra support Vandana Salve (1): iommu: tegra/gart: use correct gart_device .../devicetree/bindings/gpu/drm/tegra.txt | 24 + arch/arm/boot/dts/tegra20.dtsi |6 + arch/arm/mach-tegra/board-dt-tegra20.c |4 + arch/arm/mach-tegra/tegra2_clocks.c|8 +- drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/tegra/Kconfig | 10 + drivers/gpu/drm/tegra/Makefile |5 + drivers/gpu/drm/tegra/tegra_drv.c | 2241 drivers/gpu/drm/tegra/tegra_drv.h | 184 ++ drivers/iommu/tegra-gart.c | 12 +- include/drm/drm_fixed.h|1 + include/drm/tegra_drm.h| 44 + 13 files changed, 2537 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/drm/tegra.txt create mode 100644 drivers/gpu/drm/tegra/Kconfig create mode 100644 drivers/gpu/drm/tegra/Makefile create mode 100644 drivers/gpu/drm/tegra/tegra_drv.c create mode 100644 drivers/gpu/drm/tegra/tegra_drv.h create mode 100644 include/drm/tegra_drm.h -- 1.7.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 2/4] iommu: tegra/gart: Add device tree support
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
arch/arm/mach-tegra/board-dt-tegra20.c |1 +
drivers/iommu/tegra-gart.c | 10 ++
3 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 55b28fd..cf3ff41 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -212,5 +212,11 @@
interrupts = 0 97 0x04 ;
phy_type = utmi;
};
+
+ gart: gart@7000f000 {
+ compatible = nvidia,tegra20-gart;
+ reg = 0x7000f000 0x0100/* controller registers */
+ 0x5800 0x0200 ; /* GART aperture */
+ };
};
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
index 57745e6..bffba1b 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -66,6 +66,7 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(nvidia,tegra20-ehci, TEGRA_USB3_BASE, tegra-ehci.2,
tegra_ehci3_pdata),
OF_DEV_AUXDATA(nvidia,tegra20-pwm, TEGRA_PWFM_BASE, tegra-pwm,
NULL),
+ OF_DEV_AUXDATA(nvidia,tegra20-gart, TEGRA_MC_BASE, tegra-gart,
NULL),
{}
};
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index f6bc1e6..4a571b7 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -29,6 +29,7 @@
#include linux/device.h
#include linux/io.h
#include linux/iommu.h
+#include linux/of.h
#include asm/cacheflush.h
@@ -422,6 +423,13 @@ const struct dev_pm_ops tegra_gart_pm_ops = {
.resume = tegra_gart_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id tegra_gart_of_match[] __devinitdata = {
+ { .compatible = nvidia,tegra20-gart, },
+ { },
+};
+#endif
+
static struct platform_driver tegra_gart_driver = {
.probe = tegra_gart_probe,
.remove = tegra_gart_remove,
@@ -429,6 +437,7 @@ static struct platform_driver tegra_gart_driver = {
.owner = THIS_MODULE,
.name = tegra-gart,
.pm = tegra_gart_pm_ops,
+ .of_match_table = of_match_ptr(tegra_gart_of_match),
},
};
@@ -448,4 +457,5 @@ module_exit(tegra_gart_exit);
MODULE_DESCRIPTION(IOMMU API for GART in Tegra20);
MODULE_AUTHOR(Hiroshi DOYU hd...@nvidia.com);
+MODULE_ALIAS(platform:tegra-gart);
MODULE_LICENSE(GPL v2);
--
1.7.10
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 03/17] pwm: Add debugfs interface
On Tue, Apr 10, 2012 at 05:06:26PM +0200, Thierry Reding wrote: This commit adds a debugfs interface that can be used to list the current internal state of the PWM devices registered with the PWM framework. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com Reviewed-by: Reviewed-by: Shawn Guo shawn@linaro.org I have done review only once :) -- Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 03/17] pwm: Add debugfs interface
* Shawn Guo wrote: On Tue, Apr 10, 2012 at 05:06:26PM +0200, Thierry Reding wrote: This commit adds a debugfs interface that can be used to list the current internal state of the PWM devices registered with the PWM framework. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com Reviewed-by: Reviewed-by: Shawn Guo shawn@linaro.org I have done review only once :) Heh, good catch! =) Thanks, Thierry pgpSKB7IBLSri.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 04/17] pwm: Add table-based lookup for static mappings
* Shawn Guo wrote:
On Tue, Apr 10, 2012 at 05:06:27PM +0200, Thierry Reding wrote:
[...]
+ static struct pwm_lookup board_pwm_lookup[] = {
+ PWM_LOOKUP(tegra-pwm, 0, pwm-backlight),
PWM_LOOKUP takes 4 parameters now. Other than that,
Right, I missed that.
Reviewed-by: Shawn Guo shawn@linaro.org
Thanks,
Thierry
pgpChqNlz41PW.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 05/17] pwm: Add device tree support
On Tue, Apr 10, 2012 at 05:06:28PM +0200, Thierry Reding wrote:
This patch adds helpers to support device tree bindings for the generic
PWM API. Device tree binding documentation for PWM controllers is also
provided.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Arnd Bergmann a...@arndb.de
---
Changes in v6:
- don't override error code in of_pwm_simple_xlate()
- no longer export of_pwm_request(), only pwm_get() should be used
Ok, I read this here ...
+/**
+ * of_pwm_request() - request a PWM via the PWM framework
+ * @np: device node to get the PWM from
+ * @con_id: consumer name
+ *
+ * Returns the PWM device parsed from the phandle and index specified in the
+ * pwms property of a device tree node or a negative error-code on failure.
+ * Values parsed from the device tree are stored in the returned PWM device
+ * object.
+ *
+ * If con_id is NULL, the first PWM device listed in the pwms property will
+ * be requested. Otherwise the pwm-names property is used to do a reverse
+ * lookup of the PWM index. This also means that the pwm-names property
+ * becomes mandatory for devices that look up the PWM device via the con_id
+ * parameter.
+ */
+static struct pwm_device *of_pwm_request(struct device_node *np,
+ const char *con_id)
+{
...
+}
+EXPORT_SYMBOL(of_pwm_request);
... so this line should be removed. Otherwise,
Reviewed-by: Shawn Guo shawn@linaro.org
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 05/17] pwm: Add device tree support
* Shawn Guo wrote:
On Tue, Apr 10, 2012 at 05:06:28PM +0200, Thierry Reding wrote:
This patch adds helpers to support device tree bindings for the generic
PWM API. Device tree binding documentation for PWM controllers is also
provided.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Arnd Bergmann a...@arndb.de
---
Changes in v6:
- don't override error code in of_pwm_simple_xlate()
- no longer export of_pwm_request(), only pwm_get() should be used
Ok, I read this here ...
+/**
+ * of_pwm_request() - request a PWM via the PWM framework
+ * @np: device node to get the PWM from
+ * @con_id: consumer name
+ *
+ * Returns the PWM device parsed from the phandle and index specified in
the
+ * pwms property of a device tree node or a negative error-code on
failure.
+ * Values parsed from the device tree are stored in the returned PWM device
+ * object.
+ *
+ * If con_id is NULL, the first PWM device listed in the pwms property
will
+ * be requested. Otherwise the pwm-names property is used to do a reverse
+ * lookup of the PWM index. This also means that the pwm-names property
+ * becomes mandatory for devices that look up the PWM device via the con_id
+ * parameter.
+ */
+static struct pwm_device *of_pwm_request(struct device_node *np,
+const char *con_id)
+{
...
+}
+EXPORT_SYMBOL(of_pwm_request);
... so this line should be removed. Otherwise,
You are absolutely right. I always thought that gcc would complain if you
tried to export a static function. Funny also that my compile tests haven't
caught this in the !OF configuration. Anyway, since of_pwm_request() is no
longer exported, I've replaced this by an IS_ENABLED(CONFIG_OF) construct
similar to the calls to of_pwmchip_add() and of_pwmchip_remove().
Reviewed-by: Shawn Guo shawn@linaro.org
Thanks,
Thierry
pgpTuX9Xj60Ca.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
On Wed, 11 Apr 2012 14:10:26 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. You should only need continguous memory with GEM for the framebuffer / console bits via /dev/fb. In theory the fb layer can be taught to hanndle non linear framebuffers but nobody has yet done so. (Now there's a GSOC project ... ;)) What we do on GMA500 is to allocate the kernel framebuffer from linearly mapped memory but the normal GEM objects from anywhere as the GEM mapping into userspace will deal with presenting it to user space as a virtually linear buffer. Alan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
* Hiroshi Doyu wrote: From: Thierry Reding thierry.red...@avionic-design.de [...] Thierry Reding (3): iommu: tegra/gart: Add device tree support drm: fixed: Add dfixed_frac() macro drm: Add NVIDIA Tegra support Vandana Salve (1): iommu: tegra/gart: use correct gart_device I guess that the following 2 patches can be merged now, independet of the rest of drm patches. [RFC 1/4] iommu: tegra/gart: use correct gart_device [RFC 2/4] iommu: tegra/gart: Add device tree support Yes, I can probably post those separately so they can be applied independently. Should they go in via the IOMMU tree or the Tegra tree? Thierry pgpaqVBSfY4Sm.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 16/17] pwm-backlight: Add rudimentary device tree support
On Tue, Apr 10, 2012 at 05:06:39PM +0200, Thierry Reding wrote: This commit adds very basic support for device tree probing. Currently, only a PWM and a list of distinct brightness levels can be specified. Enabling or disabling backlight power via GPIOs is not yet supported. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Reviewed-by: Shawn Guo shawn@linaro.org [Tested on mach-mxs] ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] staging:iio:adc: Add SPEAr ADC driver
This patch implements the basic single data conversion support for
the SPEAr600 SoC ADC. The register layout of SPEAr600 differs a bit
from other SPEAr SoC variants (e.g. SPEAr3xx). These differences are
handled via DT compatible testing. Resuling in a multi-arch binary.
This driver is currently tested only on SPEAr600. Futur patches may add
support for other SoC variants (SPEAr3xx) and features like software
buffer or DMA.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Jonathan Cameron ji...@cam.ac.uk
Cc: Viresh Kumar viresh.ku...@st.com
---
.../bindings/staging/iio/adc/spear-adc.txt | 26 ++
drivers/staging/iio/adc/Kconfig|7 +
drivers/staging/iio/adc/Makefile |1 +
drivers/staging/iio/adc/spear_adc.c| 439
4 files changed, 473 insertions(+)
create mode 100644
Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
create mode 100644 drivers/staging/iio/adc/spear_adc.c
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
new file mode 100644
index 000..02ea23a
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
@@ -0,0 +1,26 @@
+* ST SPEAr ADC device driver
+
+Required properties:
+- compatible: Should be st,spear600-adc
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the ADC interrupt
+- sampling-frequency: Default sampling frequency
+
+Optional properties:
+- vref-external: External voltage reference in milli-volts. If omitted
+ the internal voltage reference will be used.
+- average-samples: Number of samples to generate an average value. If
+ omitted, single data conversion will be used.
+
+Examples:
+
+ adc: adc@d820 {
+ compatible = st,spear600-adc;
+ reg = 0xd820 0x1000;
+ interrupt-parent = vic1;
+ interrupts = 6;
+ sampling-frequency = 500;
+ vref-external = 2500; /* 2.5V VRef */
+ };
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index 592eabd..ec006e7 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -202,4 +202,11 @@ config LPC32XX_ADC
touchscreen driver, so you can only select one of the two drivers
(lpc32xx_adc or lpc32xx_ts). Provides direct access via sysfs.
+config SPEAR_ADC
+ tristate ST SPEAr ADC
+ depends on PLAT_SPEAR
+ help
+ Say yes here to build support for the integrated ADC inside the
+ ST SPEAr SoC. Provides direct access via sysfs.
+
endmenu
diff --git a/drivers/staging/iio/adc/Makefile b/drivers/staging/iio/adc/Makefile
index f83ab95..14e98b6 100644
--- a/drivers/staging/iio/adc/Makefile
+++ b/drivers/staging/iio/adc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_ADT7310) += adt7310.o
obj-$(CONFIG_ADT7410) += adt7410.o
obj-$(CONFIG_AD7280) += ad7280a.o
obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
+obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
diff --git a/drivers/staging/iio/adc/spear_adc.c
b/drivers/staging/iio/adc/spear_adc.c
new file mode 100644
index 000..ce518bc
--- /dev/null
+++ b/drivers/staging/iio/adc/spear_adc.c
@@ -0,0 +1,439 @@
+/*
+ * ST SPEAr ADC driver
+ *
+ * Copyright 2012 Stefan Roese s...@denx.de
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/completion.h
+#include linux/of.h
+
+#include ../iio.h
+#include ../sysfs.h
+
+/*
+ * SPEAR registers definitions
+ */
+
+#define SCAN_RATE_LO(x)((x) 0x)
+#define SCAN_RATE_HI(x)(((x) 0x10) 0x)
+#define CLK_LOW(x) (((x) 0xf) 0)
+#define CLK_HIGH(x)(((x) 0xf) 4)
+
+/* Bit definitions for SPEAR_ADC_STATUS */
+#define START_CONVERSION (1 0)
+#define CHANNEL_NUM(x) ((x) 1)
+#define ADC_ENABLE (1 4)
+#define AVG_SAMPLE(x) ((x) 5)
+#define VREF_INTERNAL (1 9)
+
+#define DATA_MASK 0x03ff
+#define DATA_BITS 10
+
+#define MOD_NAME spear-adc
+
+#define ADC_CHANNEL_NUM8
+
+struct adc_regs_spear3xx {
+ u32 status;
+ u32 average;
+ u32 scan_rate;
+ u32 clk;/* Not avail for 1340 1310 */
+ u32 ch_ctrl[ADC_CHANNEL_NUM];
+ u32 ch_data[ADC_CHANNEL_NUM];
+};
+
+struct chan_data {
+ u32 lsb;
+ u32 msb;
+};
+
+struct adc_regs_spear6xx {
+ u32 status;
+ u32 pad[2];
+ u32 clk;
+ u32 ch_ctrl[ADC_CHANNEL_NUM];
+ struct chan_data ch_data[ADC_CHANNEL_NUM];
+
Re: [PATCH V3 1/5] ARM: kirkwood: Basic support for DNS-320 and DNS-325
On Wed, 11 Apr 2012 01:43:24 +0100, Jason Cooper ja...@lakedaemon.net wrote: In a future land where everything has been converted to devicetree, what would be best? An option to Build all kirkwood-based .dtb's, an option to build all D-link .dtb's, Q-QNAP .dtb's, etc. or an option for each board? I've not got any strong opinion, so will reformat the above to whatever is considered best. Based on Grant's comment, I'll probably be working towards a MACH_GLOBALSCALE_DT option to catch dreamplug,sheevaplug,guruplug, etc. Perhaps this should be MACH_BUFFALO_DT? Thinking about it, MACH_DNSKW_DT would probably be best. Anything more general, e.g. MACH_DLINK_DNS_DT, would also cover the orion-based DNS-313/323/343. Presumably there will always be differences between kirkwood and orion5x? Did you mean D-Link, or is there some relationship between Buffalo and D-link I'm not aware of? I know Conceptronic sold a ~identical device to the DNS-323, but not aware of anything else. You never know who truly makes the devices nowadays anyway. -- Jamie Lentin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
* Alan Cox wrote: On Wed, 11 Apr 2012 14:10:26 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. You should only need continguous memory with GEM for the framebuffer / console bits via /dev/fb. In theory the fb layer can be taught to hanndle non linear framebuffers but nobody has yet done so. (Now there's a GSOC project ... ;)) What we do on GMA500 is to allocate the kernel framebuffer from linearly mapped memory but the normal GEM objects from anywhere as the GEM mapping into userspace will deal with presenting it to user space as a virtually linear buffer. That's actually what the driver does as well. It uses the shmfs-backed memory provided by GEM and only maps it through the GART to provide a linear view for the display controller which cannot do scatter-gather I/O. Neither the kernel nor the user-space mapping go through the GART. You are right that for anything but the framebuffer objects it probably doesn't matter. It's a little hard to tell because I don't have any documentation for either the 2D nor 3D engines. Eventually a better option might be to use stolen memory instead of remapping it through the GART. Thierry pgpmnA9tbwKhP.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 3:33 PM, Rajendra Nayak rna...@ti.com wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Looks good to me
Reviewed-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Daniel Vetter wrote: On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote: This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. Maybe your question is answered by my reply to Alan's comment. The mapping is actually done to get a linear view for the display controller which doesn't support SG transfers. The kernel and user-space already have virtual linear buffers. Perhaps I'm being dense? Thierry pgpCSMPp2Bykj.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/5] ARM: kirkwood: Basic support for DNS-320 and DNS-325
On Wed, Apr 11, 2012 at 02:32:34PM +0100, Jamie Lentin wrote: On Wed, 11 Apr 2012 01:43:24 +0100, Jason Cooper ja...@lakedaemon.net wrote: In a future land where everything has been converted to devicetree, what would be best? An option to Build all kirkwood-based .dtb's, an option to build all D-link .dtb's, Q-QNAP .dtb's, etc. or an option for each board? I've not got any strong opinion, so will reformat the above to whatever is considered best. Based on Grant's comment, I'll probably be working towards a MACH_GLOBALSCALE_DT option to catch dreamplug,sheevaplug,guruplug, etc. Perhaps this should be MACH_BUFFALO_DT? Thinking about it, MACH_DNSKW_DT would probably be best. Anything more general, e.g. MACH_DLINK_DNS_DT, would also cover the orion-based DNS-313/323/343. Presumably there will always be differences between kirkwood and orion5x? Hmm, Well, I think I would prefer MACH_DLINK_KIRKWOOD_DT, MACH_DLINK_ORION5X_DT. This way, all the dtb's for a given manf/SoC are built in one go, and the correct board-dt file is built as well. So, in my case, I would do MACH_GLOBALSCALE_KIRKWOOD_DT, and MACH_GLOBALSCALE_ARMADA_DT. Grant, Arnd, sound sensible? Did you mean D-Link, or is there some relationship between Buffalo and D-link I'm not aware of? I know Conceptronic sold a ~identical device to the DNS-323, but not aware of anything else. You never know who truly makes the devices nowadays anyway. Nope, just a momentary symlink'd /dev/brain - /dev/random. Fixed now, thanks. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
Hi,
On Wed, Apr 11 2012, Rajendra Nayak wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
Thanks, pushed to mmc-next for 3.4.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
Hm, in that case it looks like your iommu works more like the gtt on intel chips Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU side access of the GTT map (ie you can't use it to linearise pages for CPU view) and the 3600 is even stranger Alan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
Maybe your question is answered by my reply to Alan's comment. The mapping is actually done to get a linear view for the display controller which doesn't support SG transfers. The kernel and user-space already have virtual linear buffers. The framebuffer currently needs a physically contiguous map for the console devices. Well you could vmap them but that is pretty hideous on a 32bit platform with 32bit 1080p display plugged into it! Alan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Daniel Vetter wrote: On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote: This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. Maybe your question is answered by my reply to Alan's comment. The mapping is actually done to get a linear view for the display controller which doesn't support SG transfers. The kernel and user-space already have virtual linear buffers. Hm, in that case it looks like your iommu works more like the gtt on intel chips and less like the iommu on intel platforms (which we access through the dma_map api). Yes, it's very much like the GTT on Intel chips. In fact I've been using the gma500 driver as a source for inspiration. Wikipedia confirms that GTT and GART are synonymous. I wonder whether that will end up in some layering fun together with dma_buf, which conceptually is at the same level as the dma api, which usually uses an underlying iommu exposed with the iommu api you're using. That's odd. The only users of the IOMMU API that I can find in the kernel tree are in drivers/remoteproc and drivers/media/video/omap3isp. And omap3isp doesn't do any actual mapping at a quick glance. Can you point me to where this is hooked up with the Intel IOMMU? Thierry pgpzu3IiL9Ype.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Alan Cox wrote: Maybe your question is answered by my reply to Alan's comment. The mapping is actually done to get a linear view for the display controller which doesn't support SG transfers. The kernel and user-space already have virtual linear buffers. The framebuffer currently needs a physically contiguous map for the console devices. Well you could vmap them but that is pretty hideous on a 32bit platform with 32bit 1080p display plugged into it! Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it is hideous? I'll have to investigate what an appropriate alternative would look like. Thierry pgp5cCIucNT6d.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/5] ARM: kirkwood: Basic support for DNS-320 and DNS-325
On Wednesday 11 April 2012, Jason Cooper wrote: Thinking about it, MACH_DNSKW_DT would probably be best. Anything more general, e.g. MACH_DLINK_DNS_DT, would also cover the orion-based DNS-313/323/343. Presumably there will always be differences between kirkwood and orion5x? Hmm, Well, I think I would prefer MACH_DLINK_KIRKWOOD_DT, MACH_DLINK_ORION5X_DT. This way, all the dtb's for a given manf/SoC are built in one go, and the correct board-dt file is built as well. So, in my case, I would do MACH_GLOBALSCALE_KIRKWOOD_DT, and MACH_GLOBALSCALE_ARMADA_DT. Grant, Arnd, sound sensible? I think it's fine, I just don't spend too much time on the naming when the goal is to eventually just have one config option for all manufacturers. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it is hideous? On x86 we don't have a vast amount of address space available for virtual remappings and the framebuffer then eats over 8MB of it. The ideal case is that the fb layer can be taught to do page/offset addressing nicely. At that point we'd be able to attach the text consoles to arbitary GEM objects.. which means we can do really cool stuff. Alan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 03/17] pwm: Add debugfs interface
On Wed, Apr 11, 2012 at 08:33:56PM +0800, Shawn Guo wrote: On Tue, Apr 10, 2012 at 05:06:26PM +0200, Thierry Reding wrote: Reviewed-by: Reviewed-by: Shawn Guo shawn@linaro.org I have done review only once :) But it was a really thorough and detailed review! ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On Wednesday 11 April 2012, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote: This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. dma_map_sg is certainly the right interface to use, and Marek Szyprowski has patches to make that work on ARM, hopefully going into v3.5, so you could use those. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Question: Does devicetree capable of describing pinmux?
On Wed, Apr 11, 2012 at 5:35 PM, Dennis.Yxun dennis.y...@gmail.com mailto:dennis.y...@gmail.com wrote: Hi Fork: I would like to know whether device tree capable of describing pinmux? ... On 04/11/2012 03:42 AM, Dennis.Yxun wrote: Possibly that can be connected to pinctrl subsystem, right? Yes, the pinctrl subsystem recently grew support for representing pinmux in the device tree. See for example: repo git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git branch for-next path Documentation/devicetree/bindings/pinctrl/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/9] ARM: at91: DT: add Calao USB A9260 DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/usb_a9260.dts | 23 +++
arch/arm/mach-at91/Makefile.boot |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/usb_a9260.dts
diff --git a/arch/arm/boot/dts/usb_a9260.dts b/arch/arm/boot/dts/usb_a9260.dts
new file mode 100644
index 000..2962160
--- /dev/null
+++ b/arch/arm/boot/dts/usb_a9260.dts
@@ -0,0 +1,23 @@
+/*
+ * usb_a9260.dts - Device Tree file for Caloa USB A9260 board
+ *
+ * Copyright (C) 2011-2012 Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ at91sam9260.dtsi
+/include/ usb_a9260_common.dtsi
+
+/ {
+ model = Calao USB A9260;
+ compatible = calao,usb-a9260, atmel,at91sam9260, atmel,at91sam9;
+
+ chosen {
+ bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock5 rw
rootfstype=ubifs;
+ };
+
+ memory {
+ reg = 0x2000 0x400;
+ };
+};
diff --git a/arch/arm/mach-at91/Makefile.boot b/arch/arm/mach-at91/Makefile.boot
index 30d6c10..b2ac536 100644
--- a/arch/arm/mach-at91/Makefile.boot
+++ b/arch/arm/mach-at91/Makefile.boot
@@ -16,6 +16,7 @@ endif
# Keep dtb files sorted alphabetically for each SoC
# sam9260
dtb-$(CONFIG_MACH_AT91SAM_DT) += tny_a9260.dtb
+dtb-$(CONFIG_MACH_AT91SAM_DT) += usb_a9260.dtb
# sam9g20
dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9g20ek.dtb
dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9g20ek_2mmc.dtb
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/9] ARM: at91: standard device init only if DT is not populated.
This will avoid the CONFIG_OF on the *_devices.c as this file is deprecated
for DT support.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/mach-at91/at91sam9260_devices.c | 20 +++-
arch/arm/mach-at91/at91sam9g45_devices.c | 30 --
2 files changed, 7 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c
b/arch/arm/mach-at91/at91sam9260_devices.c
index ad00fe9..d556de1 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -702,25 +702,8 @@ static struct platform_device at91sam9260_tcb1_device = {
.num_resources = ARRAY_SIZE(tcb1_resources),
};
-#if defined(CONFIG_OF)
-static struct of_device_id tcb_ids[] = {
- { .compatible = atmel,at91rm9200-tcb },
- { /*sentinel*/ }
-};
-#endif
-
static void __init at91_add_device_tc(void)
{
-#if defined(CONFIG_OF)
- struct device_node *np;
-
- np = of_find_matching_node(NULL, tcb_ids);
- if (np) {
- of_node_put(np);
- return;
- }
-#endif
-
platform_device_register(at91sam9260_tcb0_device);
platform_device_register(at91sam9260_tcb1_device);
}
@@ -1364,6 +1347,9 @@ void __init at91_add_device_cf(struct at91_cf_data *
data) {}
*/
static int __init at91_add_standard_devices(void)
{
+ if (of_have_populated_dt())
+ return 0;
+
at91_add_device_rtt();
at91_add_device_watchdog();
at91_add_device_tc();
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c
b/arch/arm/mach-at91/at91sam9g45_devices.c
index db2f88c2..35bd42d 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -69,15 +69,7 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
-#if defined(CONFIG_OF)
- struct device_node *of_node =
- of_find_node_by_name(NULL, dma-controller);
-
- if (of_node)
- of_node_put(of_node);
- else
-#endif
- platform_device_register(at_hdmac_device);
+ platform_device_register(at_hdmac_device);
}
#else
void __init at91_add_device_hdmac(void) {}
@@ -1094,25 +1086,8 @@ static struct platform_device at91sam9g45_tcb1_device = {
.num_resources = ARRAY_SIZE(tcb1_resources),
};
-#if defined(CONFIG_OF)
-static struct of_device_id tcb_ids[] = {
- { .compatible = atmel,at91rm9200-tcb },
- { /*sentinel*/ }
-};
-#endif
-
static void __init at91_add_device_tc(void)
{
-#if defined(CONFIG_OF)
- struct device_node *np;
-
- np = of_find_matching_node(NULL, tcb_ids);
- if (np) {
- of_node_put(np);
- return;
- }
-#endif
-
platform_device_register(at91sam9g45_tcb0_device);
platform_device_register(at91sam9g45_tcb1_device);
}
@@ -1763,6 +1738,9 @@ void __init at91_add_device_serial(void) {}
*/
static int __init at91_add_standard_devices(void)
{
+ if (of_have_populated_dt())
+ return 0;
+
at91_add_device_hdmac();
at91_add_device_rtc();
at91_add_device_rtt();
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/9] ARM: at91: Calao USB A926x factorize common binding in usb_a9260_common
This will simplify the adding of the A9260.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
.../dts/{usb_a9g20.dts = usb_a9260_common.dtsi} | 22 +---
arch/arm/boot/dts/usb_a9g20.dts| 165
2 files changed, 32 insertions(+), 155 deletions(-)
rename arch/arm/boot/dts/{usb_a9g20.dts = usb_a9260_common.dtsi} (77%)
rewrite arch/arm/boot/dts/usb_a9g20.dts (74%)
diff --git a/arch/arm/boot/dts/usb_a9g20.dts
b/arch/arm/boot/dts/usb_a9260_common.dtsi
similarity index 77%
rename from arch/arm/boot/dts/usb_a9g20.dts
rename to arch/arm/boot/dts/usb_a9260_common.dtsi
index 0f88ec8..e70d229 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9260_common.dtsi
@@ -1,25 +1,12 @@
/*
- * usb_a9g20.dts - Device Tree file for Caloa USB A9G20 board
+ * usb_a926x.dts - Device Tree file for Caloa USB A926x board
*
- * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ * Copyright (C) 2011-2012 Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com
*
* Licensed under GPLv2 or later.
*/
-/dts-v1/;
-/include/ at91sam9g20.dtsi
/ {
- model = Calao USB A9G20;
- compatible = calao,usb-a9g20, atmel,at91sam9g20, atmel,at91sam9;
-
- chosen {
- bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock5 rw
rootfstype=ubifs;
- };
-
- memory {
- reg = 0x2000 0x400;
- };
-
clocks {
#address-cells = 1;
#size-cells = 1;
@@ -126,10 +113,5 @@
i2c@0 {
status = okay;
-
- rv3029c2@56 {
- compatible = rv3029c2;
- reg = 0x56;
- };
};
};
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/usb_a9g20.dts
dissimilarity index 74%
index 0f88ec8..2dacb16c 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9g20.dts
@@ -1,135 +1,30 @@
-/*
- * usb_a9g20.dts - Device Tree file for Caloa USB A9G20 board
- *
- * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
- *
- * Licensed under GPLv2 or later.
- */
-/dts-v1/;
-/include/ at91sam9g20.dtsi
-
-/ {
- model = Calao USB A9G20;
- compatible = calao,usb-a9g20, atmel,at91sam9g20, atmel,at91sam9;
-
- chosen {
- bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock5 rw
rootfstype=ubifs;
- };
-
- memory {
- reg = 0x2000 0x400;
- };
-
- clocks {
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- main_clock: clock@0 {
- compatible = atmel,osc, fixed-clock;
- clock-frequency = 1200;
- };
- };
-
- ahb {
- apb {
- dbgu: serial@f200 {
- status = okay;
- };
-
- macb0: ethernet@fffc4000 {
- phy-mode = rmii;
- status = okay;
- };
-
- usb1: gadget@fffa4000 {
- atmel,vbus-gpio = pioC 5 0;
- status = okay;
- };
- };
-
- nand0: nand@4000 {
- nand-bus-width = 8;
- nand-ecc-mode = soft;
- nand-on-flash-bbt;
- status = okay;
-
- at91bootstrap@0 {
- label = at91bootstrap;
- reg = 0x0 0x2;
- };
-
- barebox@2 {
- label = barebox;
- reg = 0x2 0x4;
- };
-
- bareboxenv@6 {
- label = bareboxenv;
- reg = 0x6 0x2;
- };
-
- bareboxenv2@8 {
- label = bareboxenv2;
- reg = 0x8 0x2;
- };
-
- oftree@8 {
- label = oftree;
- reg = 0xa 0x2;
- };
-
- kernel@a {
- label = kernel;
- reg = 0xc 0x40;
- };
-
- rootfs@4a {
- label = rootfs;
- reg = 0x4c 0x780;
- };
-
- data@7ca {
- label = data;
- reg = 0x7cc 0x834;
- };
[PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
Add both board revision support 1mmc and 2mmc and use a dtsi for common part.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/at91sam9g20ek.dts | 29 ++
arch/arm/boot/dts/at91sam9g20ek_2mmc.dts| 29 ++
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 142 +++
arch/arm/mach-at91/Makefile.boot|2 +
4 files changed, 202 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9g20ek.dts
create mode 100644 arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
create mode 100644 arch/arm/boot/dts/at91sam9g20ek_common.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g20ek.dts
b/arch/arm/boot/dts/at91sam9g20ek.dts
new file mode 100644
index 000..e5324bf
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g20ek.dts
@@ -0,0 +1,29 @@
+/*
+ * at91sam9g20ek.dts - Device Tree file for Atmel at91sam9g20ek board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+/dts-v1/;
+/include/ at91sam9g20ek_common.dtsi
+
+/ {
+ model = Atmel at91sam9g20ek;
+ compatible = atmel,at91sam9g20ek, atmel,at91sam9g20,
atmel,at91sam9;
+
+ leds {
+ compatible = gpio-leds;
+
+ ds1 {
+ label = ds1;
+ gpios = pioA 9 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ ds5 {
+ label = ds5;
+ gpios = pioA 6 1;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
b/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
new file mode 100644
index 000..f1b2e14
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
@@ -0,0 +1,29 @@
+/*
+ * at91sam9g20ek_2mmc.dts - Device Tree file for Atmel at91sam9g20ek 2 MMC
board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+/dts-v1/;
+/include/ at91sam9g20ek_common.dtsi
+
+/ {
+ model = Atmel at91sam9g20ek 2 mmc;
+ compatible = atmel,at91sam9g20ek_2mmc, atmel,at91sam9g20,
atmel,at91sam9;
+
+ leds {
+ compatible = gpio-leds;
+
+ ds1 {
+ label = ds1;
+ gpios = pioB 9 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ ds5 {
+ label = ds5;
+ gpios = pioB 8 1;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
new file mode 100644
index 000..b06c0db
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -0,0 +1,142 @@
+/*
+ * at91sam9g20ek_common.dtsi - Device Tree file for Atmel at91sam9g20ek board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+/include/ at91sam9g20.dtsi
+
+/ {
+
+ chosen {
+ bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock5 rw
rootfstype=ubifs;
+ };
+
+ memory {
+ reg = 0x2000 0x400;
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ main_clock: clock@0 {
+ compatible = atmel,osc, fixed-clock;
+ clock-frequency = 18432000;
+ };
+ };
+
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+
+ usart0: serial@fffb {
+ status = okay;
+ };
+
+ usart1: serial@fffb4000 {
+ status = okay;
+ };
+
+ macb0: ethernet@fffc4000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ usb1: gadget@fffa4000 {
+ atmel,vbus-gpio = pioC 5 0;
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt;
+ status = okay;
+
+ at91bootstrap@0 {
+ label = at91bootstrap;
+ reg = 0x0 0x2;
+ };
+
+ barebox@2 {
+ label = barebox;
+ reg = 0x2 0x4;
+ };
+
+ bareboxenv@6 {
+ label = bareboxenv;
+
[PATCH 2/9] arm: at91: add Calao TNY-A9260 and TNY-A9G20 board support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/tny_a9260.dts | 15 ++
arch/arm/boot/dts/tny_a9260_common.dtsi | 83 +++
arch/arm/boot/dts/tny_a9g20.dts | 15 ++
arch/arm/mach-at91/Makefile.boot|2 +
4 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tny_a9260.dts
create mode 100644 arch/arm/boot/dts/tny_a9260_common.dtsi
create mode 100644 arch/arm/boot/dts/tny_a9g20.dts
diff --git a/arch/arm/boot/dts/tny_a9260.dts b/arch/arm/boot/dts/tny_a9260.dts
new file mode 100644
index 000..367a16d
--- /dev/null
+++ b/arch/arm/boot/dts/tny_a9260.dts
@@ -0,0 +1,15 @@
+/*
+ * tny_a9260.dts - Device Tree file for Caloa TNY A9260 board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+/dts-v1/;
+/include/ at91sam9260.dtsi
+/include/ tny_a9260_common.dtsi
+
+/ {
+ model = Calao TNY A9260;
+ compatible = calao,tny-a9260, atmel,at91sam9260, atmel,at91sam9;
+};
diff --git a/arch/arm/boot/dts/tny_a9260_common.dtsi
b/arch/arm/boot/dts/tny_a9260_common.dtsi
new file mode 100644
index 000..0e6d3de
--- /dev/null
+++ b/arch/arm/boot/dts/tny_a9260_common.dtsi
@@ -0,0 +1,83 @@
+/*
+ * tny_a9260_common.dtsi - Device Tree file for Caloa TNY A926x board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+ chosen {
+ bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock6 rw
rootfstype=ubifs;
+ };
+
+ memory {
+ reg = 0x2000 0x400;
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ main_clock: clock@0 {
+ compatible = atmel,osc, fixed-clock;
+ clock-frequency = 1200;
+ };
+ };
+
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt;
+ status = okay;
+
+ at91bootstrap@0 {
+ label = at91bootstrap;
+ reg = 0x0 0x2;
+ };
+
+ barebox@2 {
+ label = barebox;
+ reg = 0x2 0x4;
+ };
+
+ bareboxenv@6 {
+ label = bareboxenv;
+ reg = 0x6 0x2;
+ };
+
+ bareboxenv2@8 {
+ label = bareboxenv2;
+ reg = 0x8 0x2;
+ };
+
+ oftree@8 {
+ label = oftree;
+ reg = 0xa 0x2;
+ };
+
+ kernel@a {
+ label = kernel;
+ reg = 0xc 0x40;
+ };
+
+ rootfs@4a {
+ label = rootfs;
+ reg = 0x4c 0x780;
+ };
+
+ data@7ca {
+ label = data;
+ reg = 0x7cc 0x834;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/tny_a9g20.dts b/arch/arm/boot/dts/tny_a9g20.dts
new file mode 100644
index 000..e1ab64c
--- /dev/null
+++ b/arch/arm/boot/dts/tny_a9g20.dts
@@ -0,0 +1,15 @@
+/*
+ * tny_a9g20.dts - Device Tree file for Caloa TNY A9G20 board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2.
+ */
+/dts-v1/;
+/include/ at91sam9g20.dtsi
+/include/ tny_a9260_common.dtsi
+
+/ {
+ model = Calao TNY A9G20;
+ compatible = calao,tny-a9g20, atmel,at91sam9g20, atmel,at91sam9;
+};
diff --git a/arch/arm/mach-at91/Makefile.boot b/arch/arm/mach-at91/Makefile.boot
index 0c2336c..bdf9841 100644
--- a/arch/arm/mach-at91/Makefile.boot
+++ b/arch/arm/mach-at91/Makefile.boot
@@ -15,7 +15,9 @@ endif
# Keep dtb files sorted alphabetically for each SoC
# sam9260
+dtb-$(CONFIG_MACH_AT91SAM_DT) += tny_a9260.dtb
# sam9g20
+dtb-$(CONFIG_MACH_AT91SAM_DT) += tny_a9g20.dtb
dtb-$(CONFIG_MACH_AT91SAM_DT) += usb_a9g20.dtb
# sam9g45
dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9m10g45ek.dtb
--
1.7.9.1
___
devicetree-discuss mailing list
[PATCH 1/9] ARM: at91: add at91sam9260 DT support
The at91sam9260 and at91sam9g20 share most of the same IP.
So udpate the node property in the at91sam9g20 only.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
.../dts/{at91sam9g20.dtsi = at91sam9260.dtsi} |8 +-
arch/arm/boot/dts/at91sam9g20.dtsi | 257 ++--
arch/arm/mach-at91/Makefile.boot |1 +
3 files changed, 23 insertions(+), 243 deletions(-)
rename arch/arm/boot/dts/{at91sam9g20.dtsi = at91sam9260.dtsi} (96%)
rewrite arch/arm/boot/dts/at91sam9g20.dtsi (95%)
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
similarity index 96%
rename from arch/arm/boot/dts/at91sam9g20.dtsi
rename to arch/arm/boot/dts/at91sam9260.dtsi
index 799ad18..71c78d1 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -1,5 +1,5 @@
/*
- * at91sam9g20.dtsi - Device Tree Include file for AT91SAM9G20 family SoC
+ * at91sam9260.dtsi - Device Tree Include file for AT91SAM9260 family SoC
*
* Copyright (C) 2011 Atmel,
*2011 Nicolas Ferre nicolas.fe...@atmel.com,
@@ -11,8 +11,8 @@
/include/ skeleton.dtsi
/ {
- model = Atmel AT91SAM9G20 family SoC;
- compatible = atmel,at91sam9g20;
+ model = Atmel AT91SAM9260 family SoC;
+ compatible = atmel,at91sam9260;
interrupt-parent = aic;
aliases {
@@ -36,7 +36,7 @@
};
memory {
- reg = 0x2000 0x0800;
+ reg = 0x2000 0x0400;
};
ahb {
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
b/arch/arm/boot/dts/at91sam9g20.dtsi
dissimilarity index 95%
index 799ad18..0eb1a75 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -1,239 +1,18 @@
-/*
- * at91sam9g20.dtsi - Device Tree Include file for AT91SAM9G20 family SoC
- *
- * Copyright (C) 2011 Atmel,
- *2011 Nicolas Ferre nicolas.fe...@atmel.com,
- *2011 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
- *
- * Licensed under GPLv2 or later.
- */
-
-/include/ skeleton.dtsi
-
-/ {
- model = Atmel AT91SAM9G20 family SoC;
- compatible = atmel,at91sam9g20;
- interrupt-parent = aic;
-
- aliases {
- serial0 = dbgu;
- serial1 = usart0;
- serial2 = usart1;
- serial3 = usart2;
- serial4 = usart3;
- serial5 = usart4;
- serial6 = usart5;
- gpio0 = pioA;
- gpio1 = pioB;
- gpio2 = pioC;
- tcb0 = tcb0;
- tcb1 = tcb1;
- };
- cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
- };
- };
-
- memory {
- reg = 0x2000 0x0800;
- };
-
- ahb {
- compatible = simple-bus;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- apb {
- compatible = simple-bus;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- aic: interrupt-controller@f000 {
- #interrupt-cells = 2;
- compatible = atmel,at91rm9200-aic;
- interrupt-controller;
- interrupt-parent;
- reg = 0xf000 0x200;
- };
-
- ramc0: ramc@ea00 {
- compatible = atmel,at91sam9260-sdramc;
- reg = 0xea00 0x200;
- };
-
- pmc: pmc@fc00 {
- compatible = atmel,at91rm9200-pmc;
- reg = 0xfc00 0x100;
- };
-
- rstc@fd00 {
- compatible = atmel,at91sam9260-rstc;
- reg = 0xfd00 0x10;
- };
-
- shdwc@fd10 {
- compatible = atmel,at91sam9260-shdwc;
- reg = 0xfd10 0x10;
- };
-
- pit: timer@fd30 {
- compatible = atmel,at91sam9260-pit;
- reg = 0xfd30 0xf;
- interrupts = 1 4;
- };
-
- tcb0: timer@fffa {
- compatible = atmel,at91rm9200-tcb;
- reg = 0xfffa 0x100;
- interrupts = 17 4 18 4 19 4;
- };
-
- tcb1: timer@fffdc000 {
- compatible =
[PATCH 8/9] ARM: at91: add at91sam9263 DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/at91sam9263.dtsi | 221 ++
arch/arm/mach-at91/at91sam9263.c | 10 ++
arch/arm/mach-at91/at91sam9263_devices.c | 20 +++
3 files changed, 251 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9263.dtsi
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
new file mode 100644
index 000..baecf52
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -0,0 +1,221 @@
+/*
+ * at91sam9263.dtsi - Device Tree Include file for AT91SAM9263 family SoC
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2 only.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ model = Atmel AT91SAM9263 family SoC;
+ compatible = atmel,at91sam9263;
+ interrupt-parent = aic;
+
+ aliases {
+ serial0 = dbgu;
+ serial1 = usart0;
+ serial2 = usart1;
+ serial3 = usart2;
+ gpio0 = pioA;
+ gpio1 = pioB;
+ gpio2 = pioC;
+ gpio3 = pioD;
+ gpio4 = pioE;
+ tcb0 = tcb0;
+ };
+ cpus {
+ cpu@0 {
+ compatible = arm,arm926ejs;
+ };
+ };
+
+ memory {
+ reg = 0x2000 0x0800;
+ };
+
+ ahb {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ apb {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ aic: interrupt-controller@f000 {
+ #interrupt-cells = 2;
+ compatible = atmel,at91rm9200-aic;
+ interrupt-controller;
+ interrupt-parent;
+ reg = 0xf000 0x200;
+ };
+
+ pmc: pmc@fc00 {
+ compatible = atmel,at91rm9200-pmc;
+ reg = 0xfc00 0x100;
+ };
+
+ ramc: ramc@e200 {
+ compatible = atmel,at91sam9260-sdramc;
+ reg = 0xe200 0x200
+ 0xe800 0x200;
+ };
+
+ pit: timer@fd30 {
+ compatible = atmel,at91sam9260-pit;
+ reg = 0xfd30 0xf;
+ interrupts = 1 4;
+ };
+
+ tcb0: timer@fff7c000 {
+ compatible = atmel,at91rm9200-tcb;
+ reg = 0xfff7c000 0x100;
+ interrupts = 19 4;
+ };
+
+ rstc@fd00 {
+ compatible = atmel,at91sam9260-rstc;
+ reg = 0xfd00 0x10;
+ };
+
+ shdwc@fd10 {
+ compatible = atmel,at91sam9260-shdwc;
+ reg = 0xfd10 0x10;
+ };
+
+ pioA: gpio@f200 {
+ compatible = atmel,at91rm9200-gpio;
+ reg = 0xf200 0x100;
+ interrupts = 2 4;
+ #gpio-cells = 2;
+ gpio-controller;
+ interrupt-controller;
+ };
+
+ pioB: gpio@f400 {
+ compatible = atmel,at91rm9200-gpio;
+ reg = 0xf400 0x100;
+ interrupts = 3 4;
+ #gpio-cells = 2;
+ gpio-controller;
+ interrupt-controller;
+ };
+
+ pioC: gpio@f600 {
+ compatible = atmel,at91rm9200-gpio;
+ reg = 0xf600 0x100;
+ interrupts = 4 4;
+ #gpio-cells = 2;
+ gpio-controller;
+ interrupt-controller;
+ };
+
+ pioD: gpio@f800 {
+ compatible = atmel,at91rm9200-gpio;
+ reg = 0xf800 0x100;
+ interrupts = 4 4;
+ #gpio-cells = 2;
+
[PATCH 9/9] ARM: at91: add at91sam9263ek DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/at91sam9263ek.dts | 156 +++
arch/arm/mach-at91/Makefile.boot|2 +
2 files changed, 158 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9263ek.dts
diff --git a/arch/arm/boot/dts/at91sam9263ek.dts
b/arch/arm/boot/dts/at91sam9263ek.dts
new file mode 100644
index 000..f86ac4b
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -0,0 +1,156 @@
+/*
+ * at91sam9263ek.dts - Device Tree file for Atmel at91sam9263 reference board
+ *
+ * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Licensed under GPLv2 only
+ */
+/dts-v1/;
+/include/ at91sam9263.dtsi
+
+/ {
+ model = Atmel at91sam9263ek;
+ compatible = atmel,at91sam9263ek, atmel,at91sam9263,
atmel,at91sam9;
+
+ chosen {
+ bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock5 rw
rootfstype=ubifs;
+ };
+
+ memory {
+ reg = 0x2000 0x400;
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ main_clock: clock@0 {
+ compatible = atmel,osc, fixed-clock;
+ clock-frequency = 16367660;
+ };
+ };
+
+ ahb {
+ apb {
+ dbgu: serial@ee00 {
+ status = okay;
+ };
+
+ usart0: serial@fff8c000 {
+ status = okay;
+ };
+
+ macb0: ethernet@fffbc000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ usb1: gadget@fff78000 {
+ atmel,vbus-gpio = pioA 25 0;
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt = 1;
+ status = okay;
+
+ at91bootstrap@0 {
+ label = at91bootstrap;
+ reg = 0x0 0x2;
+ };
+
+ barebox@2 {
+ label = barebox;
+ reg = 0x2 0x4;
+ };
+
+ bareboxenv@6 {
+ label = bareboxenv;
+ reg = 0x6 0x2;
+ };
+
+ bareboxenv2@8 {
+ label = bareboxenv2;
+ reg = 0x8 0x2;
+ };
+
+ oftree@8 {
+ label = oftree;
+ reg = 0xa 0x2;
+ };
+
+ kernel@a {
+ label = kernel;
+ reg = 0xc 0x40;
+ };
+
+ rootfs@4a {
+ label = rootfs;
+ reg = 0x4c 0x780;
+ };
+
+ data@7ca {
+ label = data;
+ reg = 0x7cc 0x834;
+ };
+ };
+
+ usb0: ohci@00a0 {
+ num-ports = 2;
+ status = okay;
+ atmel,vbus-gpio = pioA 24 0
+ pioA 21 0
+ ;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+
+ d3 {
+ label = d3;
+ gpios = pioB 7 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ d2 {
+ label = d2;
+ gpios = pioC 29 1;
+ linux,default-trigger = nand-disk;
+ };
+ };
+
+ gpio_keys {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ left_click {
+ label = left_click;
+ gpios = pioC 5 1;
+ linux,code = 272;
+ gpio-key,wakeup;
+ };
+
+ right_click {
+ label = right_click;
+ gpios = pioC 4 1;
+ linux,code = 273;
+ gpio-key,wakeup;
+ };
+ };
+
+
[PATCH 4/9] ARM: at91: USB A926x update nand partition
We now store the dtb in a nand partition.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
arch/arm/boot/dts/usb_a9g20.dts | 11 ---
arch/arm/mach-at91/board-usb-a926x.c |4
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/usb_a9g20.dts
index 7c2399c..0f88ec8 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9g20.dts
@@ -74,19 +74,24 @@
reg = 0x8 0x2;
};
+ oftree@8 {
+ label = oftree;
+ reg = 0xa 0x2;
+ };
+
kernel@a {
label = kernel;
- reg = 0xa 0x40;
+ reg = 0xc 0x40;
};
rootfs@4a {
label = rootfs;
- reg = 0x4a 0x780;
+ reg = 0x4c 0x780;
};
data@7ca {
label = data;
- reg = 0x7ca 0x836;
+ reg = 0x7cc 0x834;
};
};
diff --git a/arch/arm/mach-at91/board-usb-a926x.c
b/arch/arm/mach-at91/board-usb-a926x.c
index 332ecd4..95393fc 100644
--- a/arch/arm/mach-at91/board-usb-a926x.c
+++ b/arch/arm/mach-at91/board-usb-a926x.c
@@ -172,6 +172,10 @@ static struct mtd_partition __initdata ek_nand_partition[]
= {
.offset = MTDPART_OFS_NXTBLK,
.size = SZ_128K,
}, {
+ .name = oftree,
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_128K,
+ }, {
.name = kernel,
.offset = MTDPART_OFS_NXTBLK,
.size = 4 * SZ_1M,
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 2/4] iommu: tegra/gart: Add device tree support
On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit adds device tree support for the GART hardware available on NVIDIA Tegra 20 SoCs. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/boot/dts/tegra20.dtsi |6 ++ arch/arm/mach-tegra/board-dt-tegra20.c |1 + drivers/iommu/tegra-gart.c | 10 ++ 3 files changed, 17 insertions(+) I think I'd prefer at least the tegra20.dtsi change split out into a separate patch so I can queue it in a dt topic branch in the Tegra repo. It might be a good idea to split this into two on an arch/arm vs. drivers/iommu boundary. Looking at Olof's branches for 3.4, that split is what happened there. Finally, there should be a binding documentation file in Documentation/devicetree/bindings in order to specify the number of reg property entries needed, and their meaning, since there's more than 1 (even though you did comment it nicely in the .dtsi file) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 3/4] drm: fixed: Add dfixed_frac() macro
On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit is taken from the Chromium tree and was originally written by Robert Morell. Maybe just cherry-pick it from there? That way, the git authorship will show up as Robert. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
standalone dtc compiler build from git://git.jdl.com/software/dtc.git gives error
Hi, Jon Lolieger, I have tried using the standalone dtc compiler at git://git.jdl.com/software/dtc.git to compile my dts file and got the following error:- a0868495@ares-ubuntu:~/dtc$ dtc -I dts -O dtb tci6614-evm.dts DTC: dts-dtb on file tci6614-evm.dts tci6614-evm.dts:4 syntax error The dtc in the linux tree (Linux version 3.2) is able to compile the dts file and I am able to boot kernel using the dtb. I am using v1.3.0 tag of the dtc git repo. Comparing the files with that under scripts/dtc in the kernel tree, I find they are different. Why is the dtc not able to compile the dts file? How is the dtc tree synced with the Linux kernel tree? As a user, how do I know what version of dtc I need to use for a given kernel release? Any help here? Murali Karicheri Software Design Engineer ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of things still need
to be worked out and there is a lot of room for cleanup.
I'll let Jon Mayo comment on the actual driver implementation, since
he's a lot more familiar with Tegra's display hardware. However, I have
some general comments below.
.../devicetree/bindings/gpu/drm/tegra.txt | 24 +
arch/arm/mach-tegra/board-dt-tegra20.c |3 +
arch/arm/mach-tegra/tegra2_clocks.c|8 +-
drivers/gpu/drm/Kconfig|2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/tegra/Kconfig | 10 +
drivers/gpu/drm/tegra/Makefile |5 +
drivers/gpu/drm/tegra/tegra_drv.c | 2241
drivers/gpu/drm/tegra/tegra_drv.h | 184 ++
include/drm/tegra_drm.h| 44 +
Splitting this patch into two, between arch/arm and drivers/gpu would be
a good idea.
diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
+ drm@5420 {
+ compatible = nvidia,tegra20-drm;
This doesn't seem right; there isn't a DRM hardware module on Tegra,
since DRM is a Linux/software-specific term.
I'd at least expect to see this compatible flag be renamed to something
more like nvidia,tegra20-dc (dc==display controller).
Since Tegra has two display controller modules (I believe identical?),
and numerous other independent(?) blocks, I'd expect to see multiple
nodes in device tree, one per hardware block, such that each block gets
its own device and driver. That said, I'm not familiar enough with
Tegra's display and graphics HW to know if this makes sense. Jon, what's
your take here? The clock change below, and in particular the original
code there that we use downstream, lends weight to my argument.
+ reg = 0x5420 0x0004/* display A */
+ 0x5424 0x0004/* display B */
+ 0x5800 0x0200 ; /* GART aperture */
+ interrupts = 0 73 0x04/* display A */
+0 74 0x04 ; /* display B */
+
+ lvds {
+ type = rgb;
These sub-nodes probably want a compatible property rather than a
type property.
+ size = 345 194;
+
+ default-mode {
+ pixel-clock = 61715000;
+ vertical-refresh = 50;
+ resolution = 1366 768;
+ bits-per-pixel = 16;
+ horizontal-timings = 4 136 2 36;
+ vertical-timings = 2 4 21 10;
+ };
+ };
I imagine that quite a bit of thought needs to be put into the output
part of the binding in order to:
* Model the outputs/connectors separately from display controllers.
* Make sure that the basic infra-structure for representing an output is
general enough to be extensible to all the kinds of outputs we support,
not just the LVDS output.
* We were wondering about putting an EDID into the DT to represent the
display modes, so that all outputs had EDIDs rather than real monitors
having EDIDs, and fixed internal displays having some other
representation of capabilities.
I'm hoping that Jon will drive this.
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c
b/arch/arm/mach-tegra/tegra2_clocks.c
- PERIPH_CLK(disp1, tegradc.0,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
- PERIPH_CLK(disp2, tegradc.1,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp1, tegra-drm,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp2, tegra-drm,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
This doesn't seem right, and couples back to my assertion above that the
two display controller modules probably deserve separate device objects,
named e.g. tegradc.*.
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
new file mode 100644
index 000..f3382c9
--- /dev/null
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -0,0 +1,10 @@
+config DRM_TEGRA
+ tristate NVIDIA Tegra
+ depends on DRM ARCH_TEGRA
Jon, do you think we'll end up eventually having a unified
Re: standalone dtc compiler build from git://git.jdl.com/software/dtc.git gives error
On 04/11/2012 11:59 AM, Karicheri, Muralidharan wrote: Hi, Jon Lolieger, I have tried using the standalone dtc compiler at git://git.jdl.com/software/dtc.git to compile my dts file and got the following error:- a0868495@ares-ubuntu:~/dtc$ dtc -I dts -O dtb tci6614-evm.dts DTC: dts-dtb on file tci6614-evm.dts tci6614-evm.dts:4 syntax error ... Why is the dtc not able to compile the dts file? I think the only way to answer that is going to be to post your .dts file, or at least the first 4 or 5 lines of it. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] dtc: Remove spurious output on stderr
Outputing to stderr is best avoided unless there is an error or warning to
display. At present dtc always displays the name of the file it is compiling
and the input/output formats. For example:
DTC: dts-dts on file -
This can cause problems in some build systems. For example, U-Boot shows
build errors for any boards which use dtc at present. It is typically the
only message output during such a build. The C compiler does not output
anything in general. The current dtc behaviour makes it difficult to
provide a silent build in the normal case where nothing went wrong.
The -q flag is currently used to ignore warnings, and this message is not
really a warning. If we inserted another level of quietness that just
supresses non-warnings, then this would break the current behaviour of -q.
Therefore a new flag seems appropriate. Unfortunately both -v and -V are
already used, so I have come up with the random choice of -a: announce
operation.
This also changes current behaviour, but hopefully in a good way. The main
problem is that people will wonder whether dtc actually ran at all, since
they are used to seeing the message. A quick check should confirm this, or
the -a flag can be added if desired.
I'm hoping someone has a better solution.
Signed-off-by: Simon Glass s...@chromium.org
---
dtc.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/dtc.c b/dtc.c
index 83aef32..685d046 100644
--- a/dtc.c
+++ b/dtc.c
@@ -58,6 +58,8 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, \t\tThis help text\n);
fprintf(stderr, \t-q\n);
fprintf(stderr, \t\tQuiet: -q suppress warnings, -qq errors, -qqq
all\n);
+ fprintf(stderr, \t-a\n);
+ fprintf(stderr, \t\tAnnounce: Announce the file being processed\n);
fprintf(stderr, \t-I input format\n);
fprintf(stderr, \t\tInput formats are:\n);
fprintf(stderr, \t\t\tdts - device tree source text\n);
@@ -103,7 +105,7 @@ int main(int argc, char *argv[])
const char *outform = dts;
const char *outname = -;
const char *depname = NULL;
- int force = 0, sort = 0;
+ int force = 0, sort = 0, announce = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -115,9 +117,12 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
- while ((opt = getopt(argc, argv, hI:O:o:V:d:R:S:p:fqb:i:vH:s))
+ while ((opt = getopt(argc, argv, ahI:O:o:V:d:R:S:p:fqb:i:vH:s))
!= EOF) {
switch (opt) {
+ case 'a':
+ announce = 1;
+ break;
case 'I':
inform = optarg;
break;
@@ -193,8 +198,11 @@ int main(int argc, char *argv[])
if (minsize)
fprintf(stderr, DTC: Use of \-S\ is deprecated; it will be
removed soon, use \-p\ instead\n);
- fprintf(stderr, DTC: %s-%s on file \%s\\n,
- inform, outform, arg);
+ /* Messages on stderr are bad, so don't print this one unless asked */
+ if (announce) {
+ fprintf(stderr, DTC: %s-%s on file \%s\\n,
+ inform, outform, arg);
+ }
if (depname) {
depfile = fopen(depname, w);
--
1.7.7.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V1 1/2] staging: iio: add driver for isl29028
On Wed, Apr 11, 2012 at 10:58:03PM +0530, Laxman Dewangan wrote:
Intersil's ISL29028 is concurrent Ambient Light and
Proximity Sensor device.
Add driver to access the light and IR intensity and
proximity value via iio interface.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
drivers/staging/iio/light/Kconfig| 10 +
drivers/staging/iio/light/Makefile |1 +
drivers/staging/iio/light/isl29028.c | 538
++
3 files changed, 549 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/iio/light/isl29028.c
diff --git a/drivers/staging/iio/light/Kconfig
b/drivers/staging/iio/light/Kconfig
index e7e9159..53b49f7 100644
--- a/drivers/staging/iio/light/Kconfig
+++ b/drivers/staging/iio/light/Kconfig
@@ -14,6 +14,16 @@ config SENSORS_ISL29018
in lux, proximity infrared sensing and normal infrared sensing.
Data from sensor is accessible via sysfs.
+config SENSORS_ISL29028
+ tristate Intersil ISL29028 Concurrent Light and Proximity Sensor
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Provides driver for the Intersil's ISL29028 device.
+ This driver supports the sysfs interface to get the ALS, IR intensity,
+ Proximity value via iio. The ISL29028 provides the concurrent sensing
+ of ambient light and proximity.
+
config SENSORS_TSL2563
tristate TAOS TSL2560, TSL2561, TSL2562 and TSL2563 ambient light
sensors
depends on I2C
diff --git a/drivers/staging/iio/light/Makefile
b/drivers/staging/iio/light/Makefile
index 3011fbf..535d313 100644
--- a/drivers/staging/iio/light/Makefile
+++ b/drivers/staging/iio/light/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_SENSORS_TSL2563)+= tsl2563.o
obj-$(CONFIG_SENSORS_ISL29018) += isl29018.o
+obj-$(CONFIG_SENSORS_ISL29028) += isl29028.o
obj-$(CONFIG_TSL2583)+= tsl2583.o
diff --git a/drivers/staging/iio/light/isl29028.c
b/drivers/staging/iio/light/isl29028.c
new file mode 100644
index 000..ccd1f7c
--- /dev/null
+++ b/drivers/staging/iio/light/isl29028.c
@@ -0,0 +1,538 @@
+/*
+ * A iio driver for the light sensor ISL29028.
+ * ISL29028 is Concurrent Ambient Light and Proximity Sensor
+ *
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/regmap.h
+#include ../iio.h
+#include ../sysfs.h
+
+#define CONVERSION_TIME_MS 100
+
+#define ISL29028_REG_CONFIGURE 0x01
+
+#define CONFIGURE_ALS_IR_MODE_ALS0
+#define CONFIGURE_ALS_IR_MODE_IR BIT(0)
+#define CONFIGURE_ALS_IR_MODE_MASK BIT(0)
+
+#define CONFIGURE_ALS_RANGE_LOW_LUX 0
+#define CONFIGURE_ALS_RANGE_HIGH_LUX BIT(1)
+#define CONFIGURE_ALS_RANGE_MASK BIT(1)
+
+#define CONFIGURE_ALS_DIS0
+#define CONFIGURE_ALS_EN BIT(2)
+#define CONFIGURE_ALS_EN_MASKBIT(2)
+
+#define CONFIGURE_PROX_DRIVE BIT(3)
+
+#define CONFIGURE_PROX_SLP_SH4
+#define CONFIGURE_PROX_SLP_MASK (7 CONFIGURE_PROX_SLP_SH)
+
+#define CONFIGURE_PROX_ENBIT(7)
+#define CONFIGURE_PROX_EN_MASK BIT(7)
+
+#define ISL29028_REG_INTERRUPT 0x02
+
+#define ISL29028_REG_PROX_DATA 0x08
+#define ISL29028_REG_ALSIR_L 0x09
+#define ISL29028_REG_ALSIR_U 0x0A
+
+#define ISL29028_REG_TEST1_MODE 0x0E
+#define ISL29028_REG_TEST2_MODE 0x0F
+
+#define ISL29028_MAX_REGS(ISL29028_REG_TEST2_MODE + 1)
+
+enum als_ir_mode {
+ MODE_NONE = 0,
+ MODE_ALS,
+ MODE_IR
+};
+
+struct isl29028_chip {
+ struct device *dev;
+ struct mutexlock;
+
+ int prox_period;
+ boolenable_prox;
+
+ int lux_scale;
+ int als_ir_mode;
+
+ struct regmap *regmap;
+};
+
+static int isl29028_set_proxim_period(struct isl29028_chip *chip, int period)
+{
+ static int prox_period[] = {800, 400, 200, 100, 75, 50, 12, 0};
+ int sel;
+
+ for (sel = 0; sel ARRAY_SIZE(prox_period); ++sel) {
Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
On Wed, 11 Apr 2012 15:29:42 +1000, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2012-04-11 at 11:33 +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-04-11 at 11:13 +1000, Benjamin Herrenschmidt wrote: On Sat, 2012-04-07 at 14:27 +0200, Andreas Schwab wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: It's arguable that this irq_set_irq_type(,NONE) shouln't be there but still ... it's been around for ever and things worked :-) So something -else- is causing the problem and I'd like to understand what exactly. AFAICS before a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 irq_set_irq_type(,NONE) was actually a no-op. So I'm still a bit baffled... ie, I understand some of what's happening but not why it breaks things, I haven't yet managed to reproduce but I haven't tried too hard just yet (was away from the HW) : Allright, I have a repro-case, I'll dig. Ok, so it's Grant's fault :-) I pretty much expected it would be. :-p So basically, it's quite subtle and I'm only 99% sure of the details but I believe what happens is: - The audio interrupts get virq 64 and 65 (so above NR_IRQS) - The reverse map isn't pre-filled at map time (we should probably do it nowadays), we do it lazily so ... Hmmm... I though I had merged a patch that does that. /me goes to look again... Okay, I did write that patch, but I never merged it because it didn't get much review and I was already nervous about the other irq_domain changes. I'll post it again and ask for feedback. - The whole business with irq_virq_count needs fixing. Basically the default value shouldn't be NR_IRQ. I suggest making it 0 and have all the use sites do something like: max = irq_virq_count ? irq_virq_count : nr_irqs; (Grant, can you take care of that ?) Yeah, I've got a different way to fix it though. There is exactly one user of irq_virq_count in-tree right now: PS3. Also, irq_virq_count is only useful for the NOMAP mapping. So, instead of having a single global irq_virq_count values, I've dropped it entirely and added a max_irq argument to irq_domain_add_nomap(). That makes it a property of an individual nomap irq domain instead of a global system settting. Hopefully I'll have a draft patch ready today. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
On Wed, 2012-04-11 at 14:57 -0600, Grant Likely wrote: Yeah, I've got a different way to fix it though. There is exactly one user of irq_virq_count in-tree right now: PS3. Also, irq_virq_count is only useful for the NOMAP mapping. So, instead of having a single global irq_virq_count values, I've dropped it entirely and added a max_irq argument to irq_domain_add_nomap(). That makes it a property of an individual nomap irq domain instead of a global system settting. Hopefully I'll have a draft patch ready today. That works for me. I'll send patches for cleanup MPIC as well. One thing tho (Thomas, Russell) is that I like using set_irq_trigger to establish the defaults in mpic, ie, it does the descriptor locking etc... for me, I'd rather avoid open coding all of that. What I need is a variant that doesn't actually change the trigger but instead initializes the irq_desc with whatever settings the HW currently has (ie, I need to make sure things are properly in sync) though other implementations may want to use that for defaults. Any objection to defining something like IRQ_TYPE_DEFAULT ? I was thinking about making it equal to IRQ_TYPE_SENSE_MASK since that can obviously not be a valid trigger value and is distinct from IRQ_TYPE_NONE. Cheers, Ben. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
On Thu, 12 Apr 2012, Benjamin Herrenschmidt wrote: On Wed, 2012-04-11 at 14:57 -0600, Grant Likely wrote: Yeah, I've got a different way to fix it though. There is exactly one user of irq_virq_count in-tree right now: PS3. Also, irq_virq_count is only useful for the NOMAP mapping. So, instead of having a single global irq_virq_count values, I've dropped it entirely and added a max_irq argument to irq_domain_add_nomap(). That makes it a property of an individual nomap irq domain instead of a global system settting. Hopefully I'll have a draft patch ready today. That works for me. I'll send patches for cleanup MPIC as well. One thing tho (Thomas, Russell) is that I like using set_irq_trigger to establish the defaults in mpic, ie, it does the descriptor locking etc... for me, I'd rather avoid open coding all of that. What I need is a variant that doesn't actually change the trigger but instead initializes the irq_desc with whatever settings the HW currently has (ie, I need to make sure things are properly in sync) though other implementations may want to use that for defaults. Any objection to defining something like IRQ_TYPE_DEFAULT ? I was thinking about making it equal to IRQ_TYPE_SENSE_MASK since that can obviously not be a valid trigger value and is distinct from IRQ_TYPE_NONE. No objections. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: standalone dtc compiler build from git://git.jdl.com/software/dtc.git gives error
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Wednesday, April 11, 2012 2:21 PM
To: Karicheri, Muralidharan
Cc: devicetree-discuss@lists.ozlabs.org
Subject: Re: standalone dtc compiler build from
git://git.jdl.com/software/dtc.git gives
error
On 04/11/2012 11:59 AM, Karicheri, Muralidharan wrote:
Hi, Jon Lolieger,
I have tried using the standalone dtc compiler at
git://git.jdl.com/software/dtc.git
to compile my dts file and got the following error:-
a0868495@ares-ubuntu:~/dtc$ dtc -I dts -O dtb tci6614-evm.dts
DTC: dts-dtb on file tci6614-evm.dts
tci6614-evm.dts:4 syntax error
...
Why is the dtc not able to compile the dts file?
I think the only way to answer that is going to be to post your .dts
file, or at least the first 4 or 5 lines of it.
Stephen,
Thanks for responding.
Here it is
/dts-v1/;
/include/ skeleton.dtsi
/ {
model = Texas Instruments TCI6614 EVM;
compatible = ti,tci6614-evm;
#address-cells = 1;
#size-cells = 1;
And skeleton.dtsi has
/*
* Skeleton device tree; the bare minimum needed to boot; just include and
* add a compatible value. The bootloader will typically populate the memory
* node.
*/
/ {
#address-cells = 1;
#size-cells = 1;
chosen { };
aliases { };
memory { device_type = memory; reg = 0 0; };
};
BTW, the dtc compiler in the Linux kernel tree runs fine. Also I get the same
error when I run the
dtc against other existing dts files in the Linux 3.2 kernel tree. Any clue?
Thanks
Murali
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] dtc: Remove spurious output on stderr
On Wed, Apr 11, 2012 at 11:55:16AM -0700, Simon Glass wrote: Outputing to stderr is best avoided unless there is an error or warning to display. At present dtc always displays the name of the file it is compiling and the input/output formats. For example: DTC: dts-dts on file - This can cause problems in some build systems. For example, U-Boot shows build errors for any boards which use dtc at present. It is typically the only message output during such a build. The C compiler does not output anything in general. The current dtc behaviour makes it difficult to provide a silent build in the normal case where nothing went wrong. The -q flag is currently used to ignore warnings, and this message is not really a warning. If we inserted another level of quietness that just supresses non-warnings, then this would break the current behaviour of -q. Therefore a new flag seems appropriate. Unfortunately both -v and -V are already used, so I have come up with the random choice of -a: announce operation. This also changes current behaviour, but hopefully in a good way. The main problem is that people will wonder whether dtc actually ran at all, since they are used to seeing the message. A quick check should confirm this, or the -a flag can be added if desired. I'm hoping someone has a better solution. Ugh. Don't bother with the option, just remove the message. I've been half meaning to get rid of it for ages. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: standalone dtc compiler build from git://git.jdl.com/software/dtc.git gives error
On 04/11/2012 04:26 PM, Karicheri, Muralidharan wrote: -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, April 11, 2012 2:21 PM To: Karicheri, Muralidharan Cc: devicetree-discuss@lists.ozlabs.org Subject: Re: standalone dtc compiler build from git://git.jdl.com/software/dtc.git gives error On 04/11/2012 11:59 AM, Karicheri, Muralidharan wrote: Hi, Jon Lolieger, I have tried using the standalone dtc compiler at git://git.jdl.com/software/dtc.git to compile my dts file and got the following error:- a0868495@ares-ubuntu:~/dtc$ dtc -I dts -O dtb tci6614-evm.dts DTC: dts-dtb on file tci6614-evm.dts tci6614-evm.dts:4 syntax error ... Why is the dtc not able to compile the dts file? I think the only way to answer that is going to be to post your .dts file, or at least the first 4 or 5 lines of it. Stephen, Thanks for responding. Here it is ... That's odd. I just tried both v1.3.0 and master dtc, and could compile your example just fine. I also compiled arch/arm/boot/dts/tegra-cardhu.dts from the kernel (next-20120411). Both worked fine. Note that I get the error you're seeing if I run Ubuntu's packaged dtc, which is 1.1.0.dfsg-1build1 on my system. Are you sure you're running the dtc binary you think you are? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] dtc: Remove spurious output on stderr
Hi David, On Wed, Apr 11, 2012 at 3:45 PM, David Gibson da...@gibson.dropbear.id.au wrote: On Wed, Apr 11, 2012 at 11:55:16AM -0700, Simon Glass wrote: Outputing to stderr is best avoided unless there is an error or warning to display. At present dtc always displays the name of the file it is compiling and the input/output formats. For example: DTC: dts-dts on file - This can cause problems in some build systems. For example, U-Boot shows build errors for any boards which use dtc at present. It is typically the only message output during such a build. The C compiler does not output anything in general. The current dtc behaviour makes it difficult to provide a silent build in the normal case where nothing went wrong. The -q flag is currently used to ignore warnings, and this message is not really a warning. If we inserted another level of quietness that just supresses non-warnings, then this would break the current behaviour of -q. Therefore a new flag seems appropriate. Unfortunately both -v and -V are already used, so I have come up with the random choice of -a: announce operation. This also changes current behaviour, but hopefully in a good way. The main problem is that people will wonder whether dtc actually ran at all, since they are used to seeing the message. A quick check should confirm this, or the -a flag can be added if desired. I'm hoping someone has a better solution. Ugh. Don't bother with the option, just remove the message. I've been half meaning to get rid of it for ages. :-) That's not the answer I expected. Will do. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson Regards Simon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] dtc: Remove spurious output on stderr
Outputing to stderr is best avoided unless there is an error or warning to
display. At present dtc always displays the name of the file it is compiling
and the input/output formats. For example:
DTC: dts-dts on file -
This can cause problems in some build systems. For example, U-Boot shows
build errors for any boards which use dtc at present. It is typically the
only message output during such a build. The C compiler does not output
anything in general. The current dtc behaviour makes it difficult to
provide a silent build in the normal case where nothing went wrong.
Remove the message entirely.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Drop the announce option; just remove the stderr output completely
dtc.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/dtc.c b/dtc.c
index 83aef32..bee5085 100644
--- a/dtc.c
+++ b/dtc.c
@@ -193,9 +193,6 @@ int main(int argc, char *argv[])
if (minsize)
fprintf(stderr, DTC: Use of \-S\ is deprecated; it will be
removed soon, use \-p\ instead\n);
- fprintf(stderr, DTC: %s-%s on file \%s\\n,
- inform, outform, arg);
-
if (depname) {
depfile = fopen(depname, w);
if (!depfile)
--
1.7.7.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] dtc: Remove spurious output on stderr
On Wed, Apr 11, 2012 at 04:32:26PM -0700, Simon Glass wrote: Outputing to stderr is best avoided unless there is an error or warning to display. At present dtc always displays the name of the file it is compiling and the input/output formats. For example: DTC: dts-dts on file - This can cause problems in some build systems. For example, U-Boot shows build errors for any boards which use dtc at present. It is typically the only message output during such a build. The C compiler does not output anything in general. The current dtc behaviour makes it difficult to provide a silent build in the normal case where nothing went wrong. Remove the message entirely. Signed-off-by: Simon Glass s...@chromium.org Acked-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] dtc: Remove spurious output on stderr
On 04/11/2012 04:34 PM, David Gibson wrote: On Wed, Apr 11, 2012 at 04:32:26PM -0700, Simon Glass wrote: Outputing to stderr is best avoided unless there is an error or warning to display. At present dtc always displays the name of the file it is compiling and the input/output formats. For example: DTC: dts-dts on file - This can cause problems in some build systems. For example, U-Boot shows build errors for any boards which use dtc at present. It is typically the only message output during such a build. The C compiler does not output anything in general. The current dtc behaviour makes it difficult to provide a silent build in the normal case where nothing went wrong. Remove the message entirely. Signed-off-by: Simon Glasss...@chromium.org Acked-by: David Gibsonda...@gibson.dropbear.id.au I agree, I just saw two of them not 30 seconds ago. So FWIW: Acked-by: Signed-off-by: David Daney dda...@caviumnetworks.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Booting DT support without U-Boot supporting it
Hi, My U-boot is on an older version and that doesn't have DT support for ARM. Now, is there any way of booting Linux with DT, without U-Boot supporting DT? Like, if we can compile dtb somehow with Linux or something else? -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Booting DT support without U-Boot supporting it
On Thu, Apr 12, 2012 at 09:50:39AM +0530, Viresh Kumar wrote: Hi, My U-boot is on an older version and that doesn't have DT support for ARM. Now, is there any way of booting Linux with DT, without U-Boot supporting DT? This is how I responded to Fabio on the same query a few hours ago :) - Turn on CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT - cat zImage mx27pdk.dtb zImage_dtb - Boot zImage_dtb as you do with zImage Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 0/4] pinctrl: Add SPEAr pinctrl support
This patchset replaces existing pinmux framework for SPEAr family of SoC with generic pinctrl framework. @Linus: I would need your Acks on it, after which i will take it through ARM-SoC tree, as it has dependency on that. V2-V3 - Add DT bindings for pinmux mappings for SPEAr - Pass pin maps from dtb instead of mach-spear3xx/spear3*0.c files - use of_iomap() instead of devm_ioremap() and platform_get_resource() V1-V2 - Earlier padmux support removed - single patch for spear pinctrl drivers broken into two: one for spear and other for 3xx family - add pinctrl support in arch/arm/mach-spear3xx/ and dts files - pinctrl-spear.* made as library instead of platform driver - pinctrl-spear300, spear310, spear320 are now platform drivers - other minor fixes. Viresh Kumar (4): SPEAr: Remove existing padmux support for SPEAr pinctrl: Add SPEAr pinctrl drivers pinctrl: Add SPEAr3xx pinctrl drivers SPEAr3xx: Add pinctrl support for boards .../devicetree/bindings/pinctrl/pinctrl_spear.txt | 48 + MAINTAINERS| 23 +- arch/arm/boot/dts/spear300-evb.dts | 38 + arch/arm/boot/dts/spear300.dtsi|5 + arch/arm/boot/dts/spear310-evb.dts | 61 + arch/arm/boot/dts/spear310.dtsi|5 + arch/arm/boot/dts/spear320-evb.dts | 61 + arch/arm/boot/dts/spear320.dtsi|7 +- arch/arm/mach-spear3xx/Kconfig |3 + arch/arm/mach-spear3xx/include/mach/generic.h | 128 - arch/arm/mach-spear3xx/spear300.c | 389 +--- arch/arm/mach-spear3xx/spear310.c | 161 +- arch/arm/mach-spear3xx/spear320.c | 403 +--- arch/arm/mach-spear3xx/spear3xx.c | 425 --- arch/arm/plat-spear/Kconfig|1 + arch/arm/plat-spear/Makefile |2 +- arch/arm/plat-spear/include/plat/padmux.h | 92 - arch/arm/plat-spear/padmux.c | 164 - drivers/pinctrl/Kconfig|2 + drivers/pinctrl/Makefile |2 + drivers/pinctrl/spear/Kconfig | 34 + drivers/pinctrl/spear/Makefile |7 + drivers/pinctrl/spear/pinctrl-spear.c | 349 ++ drivers/pinctrl/spear/pinctrl-spear.h | 142 + drivers/pinctrl/spear/pinctrl-spear300.c | 708 drivers/pinctrl/spear/pinctrl-spear310.c | 431 +++ drivers/pinctrl/spear/pinctrl-spear320.c | 3468 drivers/pinctrl/spear/pinctrl-spear3xx.c | 588 drivers/pinctrl/spear/pinctrl-spear3xx.h | 92 + 29 files changed, 6063 insertions(+), 1776 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt delete mode 100644 arch/arm/plat-spear/include/plat/padmux.h delete mode 100644 arch/arm/plat-spear/padmux.c create mode 100644 drivers/pinctrl/spear/Kconfig create mode 100644 drivers/pinctrl/spear/Makefile create mode 100644 drivers/pinctrl/spear/pinctrl-spear.c create mode 100644 drivers/pinctrl/spear/pinctrl-spear.h create mode 100644 drivers/pinctrl/spear/pinctrl-spear300.c create mode 100644 drivers/pinctrl/spear/pinctrl-spear310.c create mode 100644 drivers/pinctrl/spear/pinctrl-spear320.c create mode 100644 drivers/pinctrl/spear/pinctrl-spear3xx.c create mode 100644 drivers/pinctrl/spear/pinctrl-spear3xx.h -- 1.7.9 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 2/4] pinctrl: Add SPEAr pinctrl drivers
This adds pinctrl driver for SPEAr platform. It also updates MAINTAINERS file
for SPEAr pinctrl drivers.
Signed-off-by: Viresh Kumar viresh.ku...@st.com
---
MAINTAINERS | 23 +--
drivers/pinctrl/Kconfig |2 +
drivers/pinctrl/Makefile |2 +
drivers/pinctrl/spear/Kconfig | 14 ++
drivers/pinctrl/spear/Makefile|3 +
drivers/pinctrl/spear/pinctrl-spear.c | 349 +
drivers/pinctrl/spear/pinctrl-spear.h | 142 +
7 files changed, 520 insertions(+), 15 deletions(-)
create mode 100644 drivers/pinctrl/spear/Kconfig
create mode 100644 drivers/pinctrl/spear/Makefile
create mode 100644 drivers/pinctrl/spear/pinctrl-spear.c
create mode 100644 drivers/pinctrl/spear/pinctrl-spear.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e7ec09..1f2bc24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5233,6 +5233,14 @@ M: Linus Walleij linus.wall...@linaro.org
S: Maintained
F: drivers/pinctrl/
+PIN CONTROLLER - ST SPEAR
+M: Viresh Kumar viresh.ku...@st.com
+L: spear-de...@list.st.com
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+W: http://www.st.com/spear
+S: Maintained
+F: driver/pinctrl/spear/
+
PKTCDVD DRIVER
M: Peter Osterlund pete...@telia.com
S: Maintained
@@ -6329,21 +6337,6 @@ F: arch/arm/mach-spear*/clock.c
F: arch/arm/plat-spear/clock.c
F: arch/arm/plat-spear/include/plat/clock.h
-SPEAR PAD MULTIPLEXING SUPPORT
-M: Viresh Kumar viresh.ku...@st.com
-L: spear-de...@list.st.com
-L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-W: http://www.st.com/spear
-S: Maintained
-F: arch/arm/plat-spear/include/plat/padmux.h
-F: arch/arm/plat-spear/padmux.c
-F: arch/arm/mach-spear*/spear*xx.c
-F: arch/arm/mach-spear*/include/mach/generic.h
-F: arch/arm/mach-spear3xx/spear3*0.c
-F: arch/arm/mach-spear3xx/spear3*0_evb.c
-F: arch/arm/mach-spear6xx/spear600.c
-F: arch/arm/mach-spear6xx/spear600_evb.c
-
SPI SUBSYSTEM
M: Grant Likely grant.lik...@secretlab.ca
L: spi-devel-gene...@lists.sourceforge.net
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index d68c878..9908bba 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -89,6 +89,8 @@ config PINCTRL_COH901
COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
ports of 8 GPIO pins each.
+source drivers/pinctrl/spear/Kconfig
+
endmenu
endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 5412f60..878a2dc 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_PINCTRL_TEGRA20) += pinctrl-tegra20.o
obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
obj-$(CONFIG_PINCTRL_COH901) += pinctrl-coh901.o
+
+obj-$(CONFIG_PLAT_SPEAR) += spear/
diff --git a/drivers/pinctrl/spear/Kconfig b/drivers/pinctrl/spear/Kconfig
new file mode 100644
index 000..47a0e295
--- /dev/null
+++ b/drivers/pinctrl/spear/Kconfig
@@ -0,0 +1,14 @@
+#
+# ST Microelectronics SPEAr PINCTRL drivers
+#
+
+if PLAT_SPEAR
+
+config PINCTRL_SPEAR
+ bool
+ depends on OF
+ select PINMUX
+ help
+ This enables pin control drivers for SPEAr Platform
+
+endif
diff --git a/drivers/pinctrl/spear/Makefile b/drivers/pinctrl/spear/Makefile
new file mode 100644
index 000..69c1a51
--- /dev/null
+++ b/drivers/pinctrl/spear/Makefile
@@ -0,0 +1,3 @@
+# SPEAr pinmux support
+
+obj-$(CONFIG_PINCTRL_SPEAR)+= pinctrl-spear.o
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c
b/drivers/pinctrl/spear/pinctrl-spear.c
new file mode 100644
index 000..c86a7fb
--- /dev/null
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -0,0 +1,349 @@
+/*
+ * Driver for the ST Microelectronics SPEAr pinmux
+ *
+ * Copyright (C) 2012 ST Microelectronics
+ * Viresh Kumar viresh.ku...@st.com
+ *
+ * Inspired from:
+ * - U300 Pinctl drivers
+ * - Tegra Pinctl drivers
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/pinctrl/machine.h
+#include linux/pinctrl/pinctrl.h
+#include linux/pinctrl/pinmux.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include pinctrl-spear.h
+
+#define DRIVER_NAME spear-pinmux
+
+static inline u32 pmx_readl(struct spear_pmx *pmx, u32 reg)
+{
+ return readl_relaxed(pmx-vbase + reg);
+}
+
+static inline void pmx_writel(struct spear_pmx *pmx, u32 val, u32 reg)
+{
+ writel_relaxed(val, pmx-vbase + reg);
+}
+
+static int set_mode(struct spear_pmx *pmx, int mode)
+{
+ struct spear_pmx_mode *pmx_mode = NULL;
[PATCH V3 1/4] SPEAr: Remove existing padmux support for SPEAr
We must use pinctrl framework instead of defining per SoC pinmux drivers. This patch removes existing padmux support present for SPEAr platform. Signed-off-by: Viresh Kumar viresh.ku...@st.com --- arch/arm/mach-spear3xx/include/mach/generic.h | 128 arch/arm/mach-spear3xx/spear300.c | 389 +-- arch/arm/mach-spear3xx/spear310.c | 161 +-- arch/arm/mach-spear3xx/spear320.c | 403 +--- arch/arm/mach-spear3xx/spear3xx.c | 425 - arch/arm/plat-spear/Makefile |2 +- arch/arm/plat-spear/include/plat/padmux.h | 92 -- arch/arm/plat-spear/padmux.c | 164 -- 8 files changed, 4 insertions(+), 1760 deletions(-) delete mode 100644 arch/arm/plat-spear/include/plat/padmux.h delete mode 100644 arch/arm/plat-spear/padmux.c diff --git a/arch/arm/mach-spear3xx/include/mach/generic.h b/arch/arm/mach-spear3xx/include/mach/generic.h index a756958..9603bf4 100644 --- a/arch/arm/mach-spear3xx/include/mach/generic.h +++ b/arch/arm/mach-spear3xx/include/mach/generic.h @@ -20,7 +20,6 @@ #include linux/amba/bus.h #include asm/mach/time.h #include asm/mach/map.h -#include plat/padmux.h /* spear3xx declarations */ /* @@ -43,147 +42,20 @@ void __init spear3xx_dt_init_irq(void); void spear_restart(char, const char *); -/* pad mux declarations */ -#define PMX_FIRDA_MASK (1 14) -#define PMX_I2C_MASK (1 13) -#define PMX_SSP_CS_MASK(1 12) -#define PMX_SSP_MASK (1 11) -#define PMX_MII_MASK (1 10) -#define PMX_GPIO_PIN0_MASK (1 9) -#define PMX_GPIO_PIN1_MASK (1 8) -#define PMX_GPIO_PIN2_MASK (1 7) -#define PMX_GPIO_PIN3_MASK (1 6) -#define PMX_GPIO_PIN4_MASK (1 5) -#define PMX_GPIO_PIN5_MASK (1 4) -#define PMX_UART0_MODEM_MASK (1 3) -#define PMX_UART0_MASK (1 2) -#define PMX_TIMER_3_4_MASK (1 1) -#define PMX_TIMER_1_2_MASK (1 0) - -/* pad mux devices */ -extern struct pmx_dev spear3xx_pmx_firda; -extern struct pmx_dev spear3xx_pmx_i2c; -extern struct pmx_dev spear3xx_pmx_ssp_cs; -extern struct pmx_dev spear3xx_pmx_ssp; -extern struct pmx_dev spear3xx_pmx_mii; -extern struct pmx_dev spear3xx_pmx_gpio_pin0; -extern struct pmx_dev spear3xx_pmx_gpio_pin1; -extern struct pmx_dev spear3xx_pmx_gpio_pin2; -extern struct pmx_dev spear3xx_pmx_gpio_pin3; -extern struct pmx_dev spear3xx_pmx_gpio_pin4; -extern struct pmx_dev spear3xx_pmx_gpio_pin5; -extern struct pmx_dev spear3xx_pmx_uart0_modem; -extern struct pmx_dev spear3xx_pmx_uart0; -extern struct pmx_dev spear3xx_pmx_timer_3_4; -extern struct pmx_dev spear3xx_pmx_timer_1_2; - -#if defined(CONFIG_MACH_SPEAR310) || defined(CONFIG_MACH_SPEAR320) -/* padmux plgpio devices */ -extern struct pmx_dev spear3xx_pmx_plgpio_0_1; -extern struct pmx_dev spear3xx_pmx_plgpio_2_3; -extern struct pmx_dev spear3xx_pmx_plgpio_4_5; -extern struct pmx_dev spear3xx_pmx_plgpio_6_9; -extern struct pmx_dev spear3xx_pmx_plgpio_10_27; -extern struct pmx_dev spear3xx_pmx_plgpio_28; -extern struct pmx_dev spear3xx_pmx_plgpio_29; -extern struct pmx_dev spear3xx_pmx_plgpio_30; -extern struct pmx_dev spear3xx_pmx_plgpio_31; -extern struct pmx_dev spear3xx_pmx_plgpio_32; -extern struct pmx_dev spear3xx_pmx_plgpio_33; -extern struct pmx_dev spear3xx_pmx_plgpio_34_36; -extern struct pmx_dev spear3xx_pmx_plgpio_37_42; -extern struct pmx_dev spear3xx_pmx_plgpio_43_44_47_48; -extern struct pmx_dev spear3xx_pmx_plgpio_45_46_49_50; -#endif - /* spear300 declarations */ #ifdef CONFIG_MACH_SPEAR300 -/* pad mux modes */ -extern struct pmx_mode spear300_nand_mode; -extern struct pmx_mode spear300_nor_mode; -extern struct pmx_mode spear300_photo_frame_mode; -extern struct pmx_mode spear300_lend_ip_phone_mode; -extern struct pmx_mode spear300_hend_ip_phone_mode; -extern struct pmx_mode spear300_lend_wifi_phone_mode; -extern struct pmx_mode spear300_hend_wifi_phone_mode; -extern struct pmx_mode spear300_ata_pabx_wi2s_mode; -extern struct pmx_mode spear300_ata_pabx_i2s_mode; -extern struct pmx_mode spear300_caml_lcdw_mode; -extern struct pmx_mode spear300_camu_lcd_mode; -extern struct pmx_mode spear300_camu_wlcd_mode; -extern struct pmx_mode spear300_caml_lcd_mode; - -/* pad mux devices */ -extern struct pmx_dev spear300_pmx_fsmc_2_chips; -extern struct pmx_dev spear300_pmx_fsmc_4_chips; -extern struct pmx_dev spear300_pmx_keyboard; -extern struct pmx_dev spear300_pmx_clcd; -extern struct pmx_dev spear300_pmx_telecom_gpio; -extern struct pmx_dev spear300_pmx_telecom_tdm; -extern struct pmx_dev spear300_pmx_telecom_spi_cs_i2c_clk; -extern struct pmx_dev spear300_pmx_telecom_camera; -extern struct pmx_dev spear300_pmx_telecom_dac; -extern struct pmx_dev spear300_pmx_telecom_i2s; -extern struct pmx_dev spear300_pmx_telecom_boot_pins; -extern struct pmx_dev spear300_pmx_telecom_sdhci_4bit; -extern struct pmx_dev
[PATCH V3 4/4] SPEAr3xx: Add pinctrl support for boards
Signed-off-by: Viresh Kumar viresh.ku...@st.com
---
arch/arm/boot/dts/spear300-evb.dts | 38 ++
arch/arm/boot/dts/spear300.dtsi|5 +++
arch/arm/boot/dts/spear310-evb.dts | 61
arch/arm/boot/dts/spear310.dtsi|5 +++
arch/arm/boot/dts/spear320-evb.dts | 61
arch/arm/boot/dts/spear320.dtsi|7 +++-
arch/arm/mach-spear3xx/Kconfig |3 ++
arch/arm/plat-spear/Kconfig|1 +
8 files changed, 180 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/spear300-evb.dts
b/arch/arm/boot/dts/spear300-evb.dts
index eaecc29..48a848a 100644
--- a/arch/arm/boot/dts/spear300-evb.dts
+++ b/arch/arm/boot/dts/spear300-evb.dts
@@ -25,6 +25,44 @@
};
ahb {
+ pinmux@9900 {
+ st,pinmux-mode=2;
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ i2c0 {
+ st,pins = i2c0_grp;
+ st,function = i2c0;
+ };
+ ssp0 {
+ st,pins = ssp0_grp;
+ st,function = ssp0;
+ };
+ mii0 {
+ st,pins = mii0_grp;
+ st,function = mii0;
+ };
+ uart0 {
+ st,pins = uart0_grp;
+ st,function = uart0;
+ };
+ clcd {
+ st,pins = clcd_pfmode_grp;
+ st,function = clcd;
+ };
+ sdhci {
+ st,pins = sdhci_4bit_grp;
+ st,function = sdhci;
+ };
+ gpio1 {
+ st,pins = gpio1_4_to_7_grp,
+ gpio1_0_to_3_grp;
+ st,function = gpio1;
+ };
+ };
+ };
+
clcd@6000 {
status = okay;
};
diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
index f9fcbf4..01c5e35 100644
--- a/arch/arm/boot/dts/spear300.dtsi
+++ b/arch/arm/boot/dts/spear300.dtsi
@@ -21,6 +21,11 @@
ranges = 0x6000 0x6000 0x5000
0xd000 0xd000 0x3000;
+ pinmux@9900 {
+ compatible = st,spear300-pinmux;
+ reg = 0x9900 0x1000;
+ };
+
clcd@6000 {
compatible = arm,clcd-pl110, arm,primecell;
reg = 0x6000 0x1000;
diff --git a/arch/arm/boot/dts/spear310-evb.dts
b/arch/arm/boot/dts/spear310-evb.dts
index c86af33..6d95317 100644
--- a/arch/arm/boot/dts/spear310-evb.dts
+++ b/arch/arm/boot/dts/spear310-evb.dts
@@ -25,6 +25,67 @@
};
ahb {
+ pinmux@b400 {
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ gpio0 {
+ st,pins = gpio0_pin0_grp,
+ gpio0_pin1_grp,
+ gpio0_pin2_grp,
+ gpio0_pin3_grp,
+ gpio0_pin4_grp,
+ gpio0_pin5_grp;
+ st,function = gpio0;
+ };
+ i2c0 {
+ st,pins = i2c0_grp;
+ st,function = i2c0;
+ };
+ mii0 {
+ st,pins = mii0_grp;
+ st,function = mii0;
+ };
+ ssp0 {
+ st,pins = ssp0_grp;
+ st,function = ssp0;
+ };
+ uart0 {
+ st,pins = uart0_grp;
+ st,function = uart0;
+ };
+
