Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: [Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: Also, current arm perf code don't handle three IRQs(one pl310 irq and two CTI irq) inside one device correctly. To fix this, that ARM perf code should either be using platform_get_irq_byname(), or the hwmod hardware data will need to be rearranged to meet the arbitrary ordering requirement. I'd suggest pinging Will on this issue to see what he wants to do. The issue stems from the fact that we have to route the PMU interrupts to the correct CPU manually (I think only MSM routes them as PPIs, which is clearly the correct thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. There isn't yet a way to do naming of resources with DT, and although I think there was a proposal for doing named register resources I don't think this has been accepted and there wasn't anything for IRQ resources... Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2 07/13] dt: omap: create platform bus for omap devices
Hi,
This creates a build failure for non-omap platforms as they don't know
about struct omap_device_pm_latency, struct omap_hwmod etc.
An empty of_omap_device_create() as inline should do the trick.
Jamie
On Tue, Aug 23, 2011 at 10:03:35AM +0500, G, Manjunath Kondaiah wrote:
The omap devices will use HWMOD for fetching device information
hence it needs to be handled seperately during platform bus
creation during dt build.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
drivers/of/platform.c | 41 -
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index e50ffcb..bd2c089 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -24,6 +24,10 @@
#include linux/of_platform.h
#include linux/platform_device.h
+#ifdef CONFIG_ARCH_OMAP2PLUS
+#include plat/omap_device.h
+#endif
+
const struct of_device_id of_default_bus_match_table[] = {
{ .compatible = simple-bus, },
#ifdef CONFIG_ARM_AMBA
@@ -544,6 +548,36 @@ static const struct of_dev_auxdata *of_dev_lookup(const
struct of_dev_auxdata *l
return NULL;
}
#ifdef ARCH_OMAP
+static struct omap_device_pm_latency omap_device_latency[] = {
+ [0] = {
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int of_omap_device_create(struct device_node *np, const char *name, int id,
+ void *platform_data,
+ int pd_size)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+
+ oh = omap_hwmod_lookup(name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, name);
+ return -EEXIST;
+ }
+
+ pdev = omap_device_build_dt(np, name, id, oh, platform_data,
+ sizeof(platform_data), omap_device_latency,
+ ARRAY_SIZE(omap_device_latency), 0);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n, name);
+
+ pr_info(DT: omap_device build for %s is successful\n, name);
+ return PTR_ERR(pdev);
+}
#else /* ARCH_OMAP */
static inline int of_omap_device_create(struct device_node *np,
const char *name, int id,
void *platform_data, int pd_size)
{
return -ENODEV;
}
#endif /* ARCH_OMAP */
+
/**
* of_platform_bus_create() - Create a device for a node and its children.
* @bus: device node of the bus to instantiate
@@ -565,7 +599,7 @@ static int of_platform_bus_create(struct device_node *bus,
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
- int pd_size;
+ int pd_size = 0;
int id = -1;
int rc = 0;
@@ -597,6 +631,11 @@ static int of_platform_bus_create(struct device_node
*bus,
return 0;
}
+ if (of_device_is_compatible(bus, ti,omap-device)) {
+ of_omap_device_create(bus, bus_id, id, platform_data, pd_size);
+ return 0;
+ }
+
dev = of_platform_device_create_pdata(bus, bus_id, platform_data,
parent);
/* override the id if auxdata gives an id */
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Clean up mach/gpio.h headers
Hi Russell, On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote: This is a preliminary posting of my gpio patch set. This patch series moves the trivial gpiolib implementations out of mach/gpio.h and into asm/gpio.h. As a side effect of that, most of this patch series is about fixing up direct includes of mach/gpio.h - this is something I've been on at people over the last year or more about ensuring that they use linux/gpio.h in preference. While I've blindly converted all arch/arm to use linux/gpio.h (with the exception of mach/ includes which are converted to asm/gpio.h), drivers were only converted to asm/gpio.h. These should be reviewed and changed to linux/gpio.h. As a result of this patch series, several mach/gpio.h end up being empty. Nice series! This gives me an empty gpio.h for picoxcell. Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC+CFT] Use word operations in bitops
On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux wrote: XXX WARNING: bitops are used heavily by filesystem code: there be dragons XXX I strongly suggest you ensure you have a copy of your filesystems before trying this patch. The patch below switches the bitops to use word loads/stores rather than byte operations - so that we can avoid using the ldrexb/strexb instructions which are only supported from ARMv6k and up. [...] This does need a fair amount of testing before it can be merged, so I'd like to see a number of Tested-by's against this patch. Please also indicate whether you tested on LE or BE or both, which filesystems, and whether they were read-only mounted or read-write mounted. Hi Russell, I've tested these on my picoxcell board (ARMv6K UP LE) with UBIFS, JFFS2 and NFS all mounted rw and haven't seen any problems. Our platforms aren't particulary FS intensive so I'll keep these patches applied to give them a bit more time. Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC+CFT] Use word operations in bitops
On Sun, Jan 16, 2011 at 06:15:51PM +, Russell King - ARM Linux wrote: Revised patch - the previous one was slightly buggered for BE. We also don't need to touch the findbit operations at all, so that part has been dropped. This includes a patch by Akinobu Mita (arm: introduce little-endian bitops, v4). Oops, I hit reply to the wrong patch before. Sorry! Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] arm: omap: add minimal support for RM-680
Hi Aaro,
A couple of small comments below, otherwise looks nice to me.
Jamie
On Thu, Dec 09, 2010 at 06:39:24PM +0200, Aaro Koskinen wrote:
Add minimal support for Nokia RM-680 board.
Tested with omap2plus_defconfig.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
[...]
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+static struct omap_onenand_platform_data board_onenand_data[] = {
+ {
+ .gpio_irq = 65,
+ .flags = ONENAND_SYNC_READWRITE,
+ }
+};
+#endif
+
+/* eMMC */
+static struct omap2_hsmmc_info mmc[] __initdata = {
+ {
+ .name = internal,
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MMC_HIGHSPEED,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ { /* Terminator */ }
+};
+
+static void __init rm680_peripherals_init(void)
+{
+ platform_add_devices(rm680_peripherals_devices,
+ ARRAY_SIZE(rm680_peripherals_devices));
+ rm680_i2c_init();
+ gpmc_onenand_init(board_onenand_data);
What happens if CONFIG_MTD_ONENAND_OMAP2=n and
CONFIG_MTD_ONENAND_OMAP2_MODULE=n? Do you need to define board_onenand_data to
NULL if these aren't enabled?
+ omap2_hsmmc_init(mmc);
+}
+
+static void __init rm680_init_irq(void)
+{
+ struct omap_sdrc_params *sdrc_params;
+
+ sdrc_params = nokia_get_sdram_timings();
+ omap2_init_common_hw(sdrc_params, sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct omap_musb_board_data rm680_musb_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init rm680_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
The same here as with the onenand data.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] arm: omap: add minimal support for RM-680
On Thu, Dec 09, 2010 at 07:11:28PM +0200, Aaro Koskinen wrote:
Hi,
On Thu, 9 Dec 2010, Jamie Iles wrote:
+static void __init rm680_peripherals_init(void)
+{
+ platform_add_devices(rm680_peripherals_devices,
+ ARRAY_SIZE(rm680_peripherals_devices));
+ rm680_i2c_init();
+ gpmc_onenand_init(board_onenand_data);
What happens if CONFIG_MTD_ONENAND_OMAP2=n and
CONFIG_MTD_ONENAND_OMAP2_MODULE=n? Do you need to define board_onenand_data
to
NULL if these aren't enabled?
[...]
+static void __init rm680_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
The same here as with the onenand data.
Check the following commits in linux-omap tree:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=5403187f83c12c6f4c03547e0cc05bac0310be7b
and
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7203f8a48bb63015ebe58a6f2a38aec1cb208b9d
Thanks for the pointer! It looks a bit confusing to my eyes but I guess it's
better than lots of ifdeffery.
Jamie
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
