Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi On Fri, 13 Jul 2012, Rob Herring wrote: I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties. Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device. - Paul -- 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: dtb for pandaboard
* Dennis Gilmore den...@ausil.us [120713 06:13]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jul 2012 23:57:00 -0700 Tony Lindgren t...@atomide.com wrote: * Dennis Gilmore den...@ausil.us [120711 06:53]: On Wed, 11 Jul 2012 00:42:33 -0700 Tony Lindgren t...@atomide.com wrote: Sounds like it's some kind of issue with dtb getting overwritten by something. We had an issue where kernel BSS was overlapping dtb in some cases, but those should be fixed. seems that they are not all fixed appending the dtb allows me to boot i could try loading the dtb at a different address. OK sounds like that's the issue then, hopefully moving the dtb around helps. moving the address for the dtb does result in it starting to boot Great. Can you please post the kernel, dtb and initrd addresses for what worked and what did not work? I'd like to know where the overwriting happens: Already in u-boot, while uncompressing kernel, or while kernel resets BSS. Maybe try to leave out ARCH_OMAP2 and ARCH_OMAP3 and maybe CONFIG_NET from your .config to make the kernel smaller and see if that makes a difference? If that works, then moving the dtb address in uEnv.txt should help. Also, please check if the same issue happens with appended dtb: with the appended dtb image im back to where i was not using a dtb file at all. that is that omap is not being autoloaded. and the sdcard so rootfs never shows up. i get dropped to a dracut rescue shell where if i manually modprobe omap nothing is happening. If the SD card is not detected with appended dtb either, the card voltages may not be supported. I believe Rajendra mentioned in some mail that we're still missing some voltage settings for the DT case for omap_hsmmc.c. In that case the card should work for the non-DT booting though. I started trying to use a dtb because the sdcard was not showing up. I wanted to see if using dtb allowed it to work. it doesnt work with or without a dtb. Hmm maybe grep for the MMC errors during the boot without dtb and also post some info on the MMC card? Regards, Tony -- 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] ARM: OMAP3: clockdomain: fix accidental duplicate registration
* Tony Lindgren t...@atomide.com [120712 23:52]: * Kevin Hilman khil...@ti.com [120712 10:55]: Paul Walmsley p...@pwsan.com writes: Commit 3dd50d0545bd5a8ad83d4339f07935cd3e883271 (Merge tag 'omap-cleanup-for-v3.6' into tmp-merge) inadvertently caused a clockdomain to be registered twice on OMAP3 boards. This causes warnings on boot, wild pointer dereferences, and PM regressions. Fix the double registration and add some clockdomain code to prevent this from happening again. As the tmp-merge branch has other branches and never goes upstream, the commit should say: Commit 472fd5401561f94698f4c8f9dbbbfbf76ab55626 (Merge branch 'cleanup-hwmod' into cleanup)... So I've updated the patch and applied it into l-o master. The patch seems to produce a new warning against arm soc tree next/cleanup branch: warning: ‘mpu_3xxx_clkdm’ defined but not used Paul, care to check if a change is needed for the arm soc tree next/cleanup branch version of this patch? Tony -- 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 RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 07/14/2012 01:56 AM, Paul Walmsley wrote: Hi On Fri, 13 Jul 2012, Rob Herring wrote: I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties. Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device. Yes, I understand that. So you should be describing which ones have i/o and what they are connected to. The PWM binding is probably a starting point. Rob - Paul -- 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: Mis?use of aliases
On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote: I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. This brings up an issue that I've been meaning to comment on. The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments. Um, so, properties in /aliases should not have phandle values, flat tree or otherwise. Has this been seen in the wild, or are you being misled by the fact that dtc's reference-to-phandle and reference-to-path syntax is very similar: prop = fred; Will generate a phandle valued property, but prop = fred; Will generate a string (path) valued property. For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like linux,unit#, instead of breaking the standard semantics of /aliases. I don't see how using aliases for unit numbering (inherently) breaks the semantics of /aliases. If phandle valued properties are being used that is wrong, but it's not necessary for the unit numbering anyway. -- 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 -- 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: Mis?use of aliases
On 7/14/2012 6:37 AM, David Gibson wrote: On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote: I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. This brings up an issue that I've been meaning to comment on. The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments. Um, so, properties in /aliases should not have phandle values, flat tree or otherwise. Has this been seen in the wild, or are you being misled by the fact that dtc's reference-to-phandle and reference-to-path syntax is very similar: Yes, I was indeed being misled. Thanks for the clarification. The fred syntax is present in the .dts files that I have looked at. prop = fred; Will generate a phandle valued property, but prop = fred; Will generate a string (path) valued property. For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like linux,unit#, instead of breaking the standard semantics of /aliases. I don't see how using aliases for unit numbering (inherently) breaks the semantics of /aliases. If phandle valued properties are being used that is wrong, but it's not necessary for the unit numbering anyway. I agree, the use of string-valued /aliases is not a semantic problem. That said, I still think that decorating individual nodes is a better approach, for locality reasons. But, now that my misunderstanding has been cleared up, it's a mild preference instead of heartburn. For historical reference: The original use of /aliases was as a component of pathname resolution, which is a global function. In that usage model, a given alias does not necessarily refer specifically to exactly one node, so localizing an alias inside a node doesn't work. The new usage for binding to a Linux name could be localized. My general preference is to localize whenever possible. But, again, breaking that rule in this case is not a huge problem. Thanks again for zeroing in on my mistake. Mitch -- 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 RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Rob, thanks for your response. On Sat, 14 Jul 2012, Rob Herring wrote: On 07/14/2012 01:56 AM, Paul Walmsley wrote: On Fri, 13 Jul 2012, Rob Herring wrote: I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties. Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device. Yes, I understand that. So you (just to clarify, these are Jon's patches) should be describing which ones have i/o and what they are connected to. Right, agreed. The PWM binding is probably a starting point. My point, perhaps unclear, was about the aliases. Do you have a different approach in mind that applications should use, other than requesting a specific timer by ID? - Paul -- 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] ARM: OMAP3: clockdomain: fix accidental duplicate registration
On Sat, 14 Jul 2012, Tony Lindgren wrote: As the tmp-merge branch has other branches and never goes upstream, the commit should say: Commit 472fd5401561f94698f4c8f9dbbbfbf76ab55626 (Merge branch 'cleanup-hwmod' into cleanup)... So I've updated the patch and applied it into l-o master. Thanks for fixing it. The patch seems to produce a new warning against arm soc tree next/cleanup branch: warning: ‘mpu_3xxx_clkdm’ defined but not used Paul, care to check if a change is needed for the arm soc tree next/cleanup branch version of this patch? arm-soc next/cleanup branch doesn't include commit 16e5e2c4 (ARM: OMAP AM35x: clockdomain data: Fix clockdomain dependencies). So that patch won't apply there, and the copy of mach-omap2/clockdomains3xxx_data.c in that branch is clean. - Paul
Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
On Tue, Jul 10, 2012 at 11:11 AM, Tony Lindgren t...@atomide.com wrote: OK so no comments for a while. Here's the patch updated to leave out the comments in the binding example. I reason like this: - My fears is that the code gets hopeless to understand the mux, the only way to understand that aspect of the system will be to read the DTS and have the data sheet ready at hand. But: - Tony knows what he's doing and what is best for OMAP. And this gets (hopefully) all that OMAP mux code out of arch/arm. - Surely it will be better to go through this subsystem if we're refactoring it all again later, and all drivers can be transferred to the abstract pinctrl API which is a big win in itself, bringing coherency to the drivers/* at large. So applied it, so it can be evaluated in real operating environments. But if I don't see OMAP transferred to use this I'll simply delete it again. :-) Yours, Linus Walleij -- 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
[PATCH] OMAP: remove unused parameter arch_id from uncompress.h
From: Domenico Andreoli domenico.andre...@linux.com
There is not point in having arch_id as parameter of __arch_decomp_setup(),
nothing in it uses arch_id. The machine id is already exported (and used)
with symbol __machine_arch_type as per mach-types.h.
Removing the pointless macro as well.
Signed-off-by: Domenico Andreoli domenico.andre...@linux.com
---
arch/arm/plat-omap/include/plat/uncompress.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: b/arch/arm/plat-omap/include/plat/uncompress.h
===
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,7 +103,7 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI81XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
TI81XXUART##p)
-static inline void __arch_decomp_setup(unsigned long arch_id)
+static inline void arch_decomp_setup(void)
{
int port = 0;
@@ -186,8 +186,6 @@ static inline void __arch_decomp_setup(u
} while (0);
}
-#define arch_decomp_setup()__arch_decomp_setup(arch_id)
-
/*
* nothing to do
*/
--
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 2/2] gpio/omap: add *remove* callback in platform_driver
On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman khil...@ti.com wrote: In the case of OMAP GPIO, unless it's an obvious fix, I would recommend you wait at least until you see some acks/tested tags from any of - Santosh Shilimkar santosh.shilim...@ti.com - Rajendra Nayak rna...@ti.com - Benoit Cousson b-cous...@ti.com or Tony, Paul or myself. Instead of trying to store this information in my and Grants brains and us forgetting it, what about patching MAINTAINERS to reflect the fact instead? That's better I think, plus I use that file a lot. For major series, I have been collecting/queueing them for Grant after ensuring they have been well reviewed and well tested (although I am eagerly hoping to hand off this role to someone else.) Listing it under your GIT tree in MAINTAINERS for this driver will make this work better I think. One path for OMAP GPIO patches, simple. It's obviously the ambiguity that cause the trouble. Then you can also decide on each cycle whether to send these to GPIO or ARM SoC etc. Yours, Linus Walleij -- 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
[PATCH 1/1] ARM: OMAP2+: omap2plus_defconfig: enable OMAP DMA engine support
commit 13f30fc893e4610f67dd7a8b0b67aec02eac1775 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sat Apr 21 22:41:10 2012 +0100 mmc: omap: remove private DMA API implementation removed the private DMA API implementation from the OMAP mmc host to make it use exclusively the DMA engine API. Unfortunately the omap2plus_defconfig doesn't enable this feature leading to the following error on an IGEPv2 Rev.C (and probably on most boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set -- 1.7.7.6 -- 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
