RE: [PATCH v4 1/3] ARM: OMAP: TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, December 08, 2011 4:48 AM: * Hemant Pedanekar hema...@ti.com [111009 18:06]: This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved in mach-omap2/common.c as same will be used for TI814X and is not board specific. Looks like this series needs a rebase after the map_io and common.h changes. Can you please rebase against the current omap soc branch at commit 24a5e092a387e4c8e93f33448da334bd3fd15192? Regards, Tony Thanks Tony, I sent v5 in the morning but it didnlt reach the ML may be because I got unsubscribed for some reason. Btw, I am getting following error when trying to build from soc branch: make[1]: *** No rule to make target `arch/arm/mach-omap2/omap-smc.o', needed by `arch/arm/mach-omap2/built-in.o'. Stop. Looks like the commit c95f06a0d4bc9c2546769b5d984cc2dc6665d4f5 added Following but not the corresponding c file(s): +secure-common = omap-smc.o omap-secure.o Hemant-- 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 v3 2/3] ARM: OMAP: TI814X: Add cpu type macros and detection support
Hi Paul, linux-arm-kernel-boun...@lists.infradead.org wrote on : macros and detection support Hi Paul, Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM: Hello Hemant, a few comments: On Thu, 29 Sep 2011, Hemant Pedanekar wrote: [...] Note that following update to common OMAP data structures is made: cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: Hemant Pedanekar hema...@ti.com Also, the opp2xxx.h change looks spurious, is that really needed? I will be removing the above mentioned code changes from v4 since the same were added in arm:omap:am33xx: Update common omap platform files patch and as per Tony's reply today ([1]) the am33xx patch will be added to SoC branch. Thanks. Hemant [1] http://www.spinics.net/lists/linux-omap/msg58853.html I changed prcm_config.flags to accommodate cpu_mask change, as cpu_mask is used with prcm_config.flags (mostly) in clkt2xxx_virt_prcm_set.c as below: prcm-flags cpu_mask And flags is assigned in opp2420_data.c (e.g., RATE_IN_242X) But yes, these are already defined RATE_INs and do not cross 8-bits, so no warnings even if flags is 8-bit and cpu_mask changed to 16-bit. What is your suggestion? I see you mentioned Also in the above comment, but didn't see any comment preceeding. Could you please split the clock-related changes into a separate patch? Then this patch would just be the id.c and cpu.h changes. Other than that, the patch looks okay to me. - Paul Will do that. Thanks. Hemant ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel-- 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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Tony Lindgren wrote on Friday, October 07, 2011 12:47 AM: * Pedanekar, Hemant hema...@ti.com [111004 02:07]: Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM: On 10/03/11 18:45, Pedanekar, Hemant wrote: Hi Igor, Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM: Hi Hemant, On 09/29/11 04:09, Hemant Pedanekar wrote: This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine info for TI8148 EVM and renamed as board-ti81xxevm.c. Should we really rename the existing file? Shouldn't we just stick to the name of the file submitted first? (e.g. board-ti8168evm.c) and just add the support for the new TI8148 EVM in to the existing file? But won't this be misleading? Misleading? For whom? Actually, I don't really care how you call that file. What I care (and I think not just me) is uniformity, so if we decide to rename all those files that have multiple boards supported in them, I'm fine with it. So pros for my proposed approach would be: 1) Currently, there are already board files with multiple boards supported in them that follow the approach and renaming them is really unnecessary. 2) git log will not break. 3) boards that cannot be named after the convention like 81xx but can be added to the same file will not require further renaming (like 82x8 - I don't really know if that will exist, just wondering). 4) This renaming is really what Linus likes ;) cons: 1) Misleading? Currently, I don't think this renaming is good for anything, especially that majority of the board stuff should be transformed to the DT descriptors. Igor, I agree on the DT part and also understand the pros you mentioned. I can submit the v4 of patches with TI8148 EVM support added in exisitng board-ti8168evm.c. Tony, Are you OK with the above approach? Yes, let's not do renaming unless it's really needed. We'll be getting rid of the board-*.c files anyways with device tree. So let's consider the board-*.c files to be in minimal maintenance mode until they will eventually get removed. Regards, Tony Ok, thanks Igor and Tony, I will send v4 with above change. Hemant-- 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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM: On 10/03/11 18:45, Pedanekar, Hemant wrote: Hi Igor, Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM: Hi Hemant, On 09/29/11 04:09, Hemant Pedanekar wrote: This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine info for TI8148 EVM and renamed as board-ti81xxevm.c. Should we really rename the existing file? Shouldn't we just stick to the name of the file submitted first? (e.g. board-ti8168evm.c) and just add the support for the new TI8148 EVM in to the existing file? But won't this be misleading? Misleading? For whom? Actually, I don't really care how you call that file. What I care (and I think not just me) is uniformity, so if we decide to rename all those files that have multiple boards supported in them, I'm fine with it. So pros for my proposed approach would be: 1) Currently, there are already board files with multiple boards supported in them that follow the approach and renaming them is really unnecessary. 2) git log will not break. 3) boards that cannot be named after the convention like 81xx but can be added to the same file will not require further renaming (like 82x8 - I don't really know if that will exist, just wondering). 4) This renaming is really what Linus likes ;) cons: 1) Misleading? Currently, I don't think this renaming is good for anything, especially that majority of the board stuff should be transformed to the DT descriptors. Igor, I agree on the DT part and also understand the pros you mentioned. I can submit the v4 of patches with TI8148 EVM support added in exisitng board-ti8168evm.c. Tony, Are you OK with the above approach? Thanks. Hemant-- 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 0/6] TI81XX: Add clock and hwmod data
Hi Paul, Paul Walmsley wrote on Tuesday, October 04, 2011 2:54 PM: Hi, On Tue, 23 Aug 2011, Hemant Pedanekar wrote: This patch set is the v2 of TI816X clock and hwmods patches sent earlier. The clock data is currently added only for TI816X, while minimal hwmod data common for TI816X and TI814X is added. This patch set depends on following patches: TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM Please note that CHIP_IS_TI816X/CHIP_IS_TI814X are still being used and I will send update once SoC list usage is available. I've been spending some time with these patches. A few aspects don't make much sense to me. For example, looking at the TRMs, the 816x doesn't seem to have powerdomains for HDVICP0, 1, or 2, although they are listed in the patch. Can you please check 18.2.1 in TRM from [1]. Above powerdomains are listed there as HDVICP2-0, 1, 2. Also, the clockdomain layout is quite different between 814x and 816x, according to the TRMs. Are the patches more accurate than the TRMs, or vice versa? You are correct, 814x has differences in clock, clockdomain and powerdomain data. I would say the extent of differences level between 816x and 814x is something like (please also see reference links from Arago devl tree): Clock data: ~90% data is different (main contributors: different PLLs - FAPLL in 816x vs ADPLL 814x, different parent hierarchy) [2] [3] Clockdomains data: ~60% [4] Powerdomains data: ~90% [5] Will send over the current reworked patches for TI81XX PRCM accessors, powerdomain code data, and clockdomain code data. They are intended to apply over the TI814x patches that you sent recently. I'd like to get your opinion(s) on these reworked patches. Please note, so far they have only been compile-tested. - Paul Thanks, I will try those and respond. Hemant [1] http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprugx8 [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/clock816x_data.c;h=32ea958afef915f93e0560f87d1bb2115e24ee2c;hb=HEAD [3] http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/clock814x_data.c;h=282ffa93398db678843a35766219970655563b46;hb=HEAD [4] http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/clockdomains81xx.h;h=217c9b4f85c59cc92e0f36ddd73044136c8e9fff;hb=HEAD [5] http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/powerdomains81xx.h;h=ef1299e00c216aea4d12bca2281540efb7eb77f0;hb=HEAD-- 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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Hi Igor, Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM: Hi Hemant, On 09/29/11 04:09, Hemant Pedanekar wrote: This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine info for TI8148 EVM and renamed as board-ti81xxevm.c. Should we really rename the existing file? Shouldn't we just stick to the name of the file submitted first? (e.g. board-ti8168evm.c) and just add the support for the new TI8148 EVM in to the existing file? But won't this be misleading? Thanks. Hemant Because, I don't see any real necessity in renaming that file. Also, it will spare the changes in Makefile. [...] -- 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 v3 2/3] ARM: OMAP: TI814X: Add cpu type macros and detection support
Hi Paul, Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM: Hello Hemant, a few comments: On Thu, 29 Sep 2011, Hemant Pedanekar wrote: This patch adds cpu type, macros for identification of TI814X device. Note that following update to common OMAP data structures is made: cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: Hemant Pedanekar hema...@ti.com Also, the opp2xxx.h change looks spurious, is that really needed? I changed prcm_config.flags to accommodate cpu_mask change, as cpu_mask is used with prcm_config.flags (mostly) in clkt2xxx_virt_prcm_set.c as below: prcm-flags cpu_mask And flags is assigned in opp2420_data.c (e.g., RATE_IN_242X) But yes, these are already defined RATE_INs and do not cross 8-bits, so no warnings even if flags is 8-bit and cpu_mask changed to 16-bit. What is your suggestion? I see you mentioned Also in the above comment, but didn't see any comment preceeding. Could you please split the clock-related changes into a separate patch? Then this patch would just be the id.c and cpu.h changes. Other than that, the patch looks okay to me. - Paul Will do that. Thanks. Hemant-- 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 v2 1/3] TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, September 22, 2011 11:51 PM:
* Pedanekar, Hemant hema...@ti.com [110921 17:00]:
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
- omapti816x_map_common_io();
+ omap2_set_globals_ti81xx();
+ omapti81xx_map_common_io();
}
MACHINE_START(TI8168EVM, ti8168evm)
/* Maintainer: Texas Instruments */
.atag_offset= 0x100,
.map_io = ti8168_evm_map_io,
- .init_early = ti816x_init_early,
- .init_irq = ti816x_init_irq,
+ .init_early = ti81xx_init_early,
+ .init_irq = ti81xx_init_irq,
.timer = omap3_timer,
.init_machine = ti8168_evm_init,
MACHINE_END
Looks like you still need a minor rebase on the current cleanup
branch as the ti8668_evm_map_io is no longer needed. The cleanup
branch already has Paul's CHIP_IS removal, so that should be trivial.
Tony,
Can you please clarify? Do we not need ti8168_evm_map_io() for global data
initianlization and io init? Or, as you mentioned in comment on 3/3 of the
series, do you mean to rename this with ti81xx and move to common.c?
Yes just have a generic one in common.c should be enough. Sorry I thought
that was already done, but looks like it was only done for omap3_map_io.
Ideally the rename patch would be separate without any functional
changes, maybe you can move the changes and additions to the next patch?
Tony
If the above understanding is correct, then I will just have to rename+move
ti8168_evm_map_io() so the change can still be in this patch, right? Or are
You referring to any other part which should not be in this patch?
Yes it's OK to keep it in this patch.
Tony
Thanks. I will send updated version.
Hemant--
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 v2 1/3] TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
-omap2_set_globals_ti816x();
-omapti816x_map_common_io();
+omap2_set_globals_ti81xx();
+omapti81xx_map_common_io();
}
MACHINE_START(TI8168EVM, ti8168evm)
/* Maintainer: Texas Instruments */
.atag_offset= 0x100,
.map_io = ti8168_evm_map_io,
-.init_early = ti816x_init_early,
-.init_irq = ti816x_init_irq,
+.init_early = ti81xx_init_early,
+.init_irq = ti81xx_init_irq,
.timer = omap3_timer,
.init_machine = ti8168_evm_init,
MACHINE_END
Looks like you still need a minor rebase on the current cleanup
branch as the ti8668_evm_map_io is no longer needed. The cleanup
branch already has Paul's CHIP_IS removal, so that should be trivial.
Tony,
Can you please clarify? Do we not need ti8168_evm_map_io() for global data
initianlization and io init? Or, as you mentioned in comment on 3/3 of the
series, do you mean to rename this with ti81xx and move to common.c?
Ideally the rename patch would be separate without any functional
changes, maybe you can move the changes and additions to the next patch?
Tony
If the above understanding is correct, then I will just have to rename+move
ti8168_evm_map_io() so the change can still be in this patch, right? Or are
You referring to any other part which should not be in this patch?
Thanks.
Hemant--
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 v2 3/3] TI814X: Create board support and enable build for TI8148 EVM
Tony Lindgren wrote on Thursday, September 22, 2011 2:18 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
+
+static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
+}; +
+static void __init ti8148_evm_init(void)
+{
+omap_serial_init();
+omap_board_config = ti8148_evm_config;
+omap_board_config_size = ARRAY_SIZE(ti8148_evm_config); +}
+
+static void __init ti8148_evm_map_io(void)
+{
+omap2_set_globals_ti81xx();
+omapti81xx_map_common_io();
+}
Hmm I guess we still have board specific map_io in board-ti8668evm.c
also. Those would be better replaced with ti81xx_map_io in
mach-omap2/common.c. Care to take a look at that?
Yes, you are right. I will do that.
+MACHINE_START(TI8148EVM, ti8148evm)
+/* Maintainer: Texas Instruments */
+.atag_offset= 0x100,
+.map_io = ti8148_evm_map_io,
+.init_early = ti81xx_init_early,
+.init_irq = ti81xx_init_irq,
+.timer = omap3_timer,
+.init_machine = ti8148_evm_init,
+MACHINE_END
Please add this all to board-ti8168evm.c instead of adding a new
board-*.c file. With the upcoming device tree conversion most of these will
disappear anyways.
Ok, I will do that.
Thanks.
Hemant
Regards,
Tony
Hemant--
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: READ THIS: the next mach-types update
Russell King - ARM Linux wrote on Saturday, September 17, 2011 8:04 PM: On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote: But since I had submitted v1 (see [1]) and am working on v2 post review, can you please suggest how to go about it as I will need the above for adding support for TI8148 EVM? The answer you require is in this statement: # This is a cut-down version of the file; it contains only machines that # are merged into mainline or have been edited in the machine database # within the last 12 months. References to machine_is_NAME() do not count! which highlights the policy. The key thing there is edited. Thanks, got it. Hemant-- 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: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
Tony Lindgren wrote on Monday, September 19, 2011 11:11 PM: device driver) * Pedanekar, Hemant hema...@ti.com [110918 20:32]: Tony, Kernel boots fine on TI816X (should also boot on TI814X) with your patch and patches (including OSC clock fix) from series http://www.spinics.net/lists/linux-omap/msg57011.html OK good to hear, I assume I can add your Tested-by then? Regards, Tony Yes. Thanks. Hemant-- 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: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
Tony Lindgren wrote on Saturday, September 17, 2011 7:06 AM: device driver) * DebBarma, Tarun Kanti tarun.ka...@ti.com [110916 01:56]: [...] Afzal, care to check if that works for AM335X/TI816X/TI814X? It tried it briefly with omap4 gptimer3 as the clockevent and CONFIG_LOCAL_TIMER disabled. The patch is against the current cleanup branch in linux-omap tree. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Fri, 16 Sep 2011 15:44:20 -0700 Subject: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip [...] Tony, Kernel boots fine on TI816X (should also boot on TI814X) with your patch and patches (including OSC clock fix) from series http://www.spinics.net/lists/linux-omap/msg57011.html Thanks. Hemant
RE: READ THIS: the next mach-types update
Hello, linux-arm-kernel-boun...@lists.infradead.org wrote on : I'm going to be merging a mach-types update (the cut-down and the policy-conforming version) for the next merge window. This will mean that things WILL BREAK, and I will not notice that things have broken. In order to fix this, entries need to be fixed to conform to the requirements - where the machine_is_xxx() name is the same as the MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too. Moreover, entries older than 12 months which have not been merged will be removed. It is not possible to automatically check for machine_is_xxx() usages as these could conflict with other architectures, and I'm certainly NOT checking for them by hand (I estimate that'd take a significant amount of manual effort to do.) What that means is that it is _important_ to get the core platform support in _first_ before any drivers which may make use of this. The following will be deleted from the file this time around are: [...] -ti8148evm MACH_TI8148EVM TI8148EVM3004 I guess this was removed due to being older than 12 months. But since I had submitted v1 (see [1]) and am working on v2 post review, can you please suggest how to go about it as I will need the above for adding support for TI8148 EVM? [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html Thanks. Hemant-- 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 0/6] TI81XX: Add clock and hwmod data
Tony Lindgren wrote on Thursday, September 15, 2011 6:03 AM: * Paul Walmsley p...@pwsan.com [110830 11:13]: On Tue, 23 Aug 2011, Hemant Pedanekar wrote: This patch set is the v2 of TI816X clock and hwmods patches sent earlier. The clock data is currently added only for TI816X, while minimal hwmod data common for TI816X and TI814X is added. This patch set depends on following patches: TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM Please note that CHIP_IS_TI816X/CHIP_IS_TI814X are still being used and I will send update once SoC list usage is available. Thanks - am working away on these patches hope to have them out soon. Hemant, can you please rebase your patches on Paul's CHIP_IS removal branch? It's available at: git://git.pwsan.com/linux-2.6 omap_chip_remove_cleanup_3.2 Regards, Tony Thanks, I will do that and send v3. Hemant-- 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
Polling support in omap uart driver
Hello, Does omap serial driver (omap-serial.c) support polling? Without this, kgdboc won't work, is that correct? Thanks. Hemant-- 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 5/6] TI81XX: Add minimal hwmod data
Hilman, Kevin wrote on Thursday, September 08, 2011 11:01 PM:
Pedanekar, Hemant hema...@ti.com writes:
Hilman, Kevin wrote on Tuesday, August 30, 2011 6:03 AM:
Hemant Pedanekar hema...@ti.com writes:
This patch adds minimum required hwmod data (e.g., UARTs) for bootup of
TI81XX devices (currently common data for TI816X and TI814X is added).
Signed-off-by: Hemant Pedanekar hema...@ti.com
I haven't looked at the details yet, but just tried to boot this using
current mainline and it fails.
My first guess is that it appears to be related to a missing clkdm for
the MPU hwmod.
Kevin
Thanks for the feedback.
I think that the issue is bacause clk_get() on fck_source is failing
as TI816X clock data had different clock source names compared to
OMAP3 (e.g., osc_sys_ck instead of sys_ck). I will update this in next
version.
Actually, I realized also that ti816x doesn't boot on current
l-o master
branch, even without this series.
Even after this, the kernel would get stuck at Calibrating delay loop...
because a few timer register offsets on TI81XX are different than
OMAP3.
At least with my tests, it's getting past that and failing here:
[...]
[0.00] NR_IRQS:410
[0.00] IRQ: Found an INTC at 0xfa20 (revision
5.0) with 128 interrup
ts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] omap_hwmod: timer1: cannot setup_one: MPU
initiator hwmod mpu not
yet registered
The reason seems to be that no hwmods are getting registered at all.
Kevin,
By any chance, is patch 6 of this series is not applied in your case?
With all patches in this series applied, I get to following:
[0.00] Total of 128 interrupts on 1 active controller
[0.00] omap_hwmod: mpu: no clkdm_name
[0.00] omap_hwmod: mpu: cannot _init_clocks
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2031
omap_hwmod_setup_one+0x100/0x14c()
[...]
[0.00] Unable to handle kernel NULL pointer dereference at virtual
address
The above crash can be fixed by fixing the correct timer clock source
(match name with OMAP3 OSC source):
diff --git a/arch/arm/mach-omap2/clock816x_data.c
b/arch/arm/mach-omap2/clock816x_data.c
index 496c205..434837f 100644
--- a/arch/arm/mach-omap2/clock816x_data.c
+++ b/arch/arm/mach-omap2/clock816x_data.c
@@ -40,7 +40,7 @@ static struct clk tclkin_ck = {
};
static struct clk osc_sys_ck = {
- .name = osc_sys_ck,
+ .name = sys_ck,
.ops= clkops_null,
.rate = 2700,
};
@@ -994,7 +994,7 @@ static struct clk mcasp2_fck = {
static struct omap_clk ti816x_clks[] = {
CLK(NULL, sys_32k_ck, sys_32k_ck,
CK_TI816X),
CLK(NULL, tclkin_ck,tclkin_ck,
CK_TI816X),
- CLK(NULL, osc_sys_ck, osc_sys_ck,
CK_TI816X),
+ CLK(NULL, sys_ck, osc_sys_ck,
CK_TI816X),
CLK(NULL, main_pll_clk1_ck, main_pll_clk1_ck,
CK_TI816X),
CLK(NULL, sysclk1_ck, sysclk1_ck,
CK_TI816X),
CLK(NULL, dsp_ick, dsp_ick,
CK_TI816X),
Now, the boot should reach till Calibrating delay loop. There will still
be WARNING messages due to absence of MPU clkdm as you mentioned (will fix
in next version), the the hang would be because timer offsets being
different.
(Please note that CONFIG_OMAP_32K_TIMER needs to be disabled)
I see there are some patches floating on ML which add reg_map array
(similar to i2c driver) but seems they have not (yet) been
accepted. Any chance that this will get added to kernel?
I'm not sure. Which series are you referring to?
I was referring to following:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35182.html
E.g., on TI81XX, counter register is @0x3c instead of 0x28 offset.
Kevin
Thanks.
Hemant--
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 5/6] TI81XX: Add minimal hwmod data
Hilman, Kevin wrote on Tuesday, August 30, 2011 6:03 AM: Hemant Pedanekar hema...@ti.com writes: This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI81XX devices (currently common data for TI816X and TI814X is added). Signed-off-by: Hemant Pedanekar hema...@ti.com I haven't looked at the details yet, but just tried to boot this using current mainline and it fails. My first guess is that it appears to be related to a missing clkdm for the MPU hwmod. Kevin Thanks for the feedback. I think that the issue is bacause clk_get() on fck_source is failing as TI816X clock data had different clock source names compared to OMAP3 (e.g., osc_sys_ck instead of sys_ck). I will update this in next version. Even after this, the kernel would get stuck at Calibrating delay loop... because a few timer register offsets on TI81XX are different than OMAP3. I see there are some patches floating on ML which add reg_map array (similar to i2c driver) but seems they have not (yet) been accepted. Any chance that this will get added to kernel? Thanks. Hemant-- 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 3/3] TI814X: Create board support and enable build for TI8148 EVM
Hilman, Kevin wrote on Tuesday, August 30, 2011 5:43 AM:
Hemant Pedanekar hema...@ti.com writes:
This patch adds minimal support and build configuration for TI8148 EVM.
Also adds support for low level debugging on UART1 console on the EVM.
Signed-off-by: Hemant Pedanekar hema...@ti.com
[...]
+static void __init ti8148_init_early(void)
+{
+omap2_init_common_infrastructure();
+omap2_init_common_devices(NULL, NULL);
Note that this function no longer exists in mainline.
Kevin
Will fix this in v2.
Thanks.
Hemant--
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: Question on virtual memory layout: lowmem with memory hole
Russell King - ARM Linux wrote on Friday, August 26, 2011 12:22 AM: On Fri, Aug 26, 2011 at 12:06:20AM +0530, Pedanekar, Hemant wrote: Russell King - ARM Linux wrote on Thursday, August 25, 2011 3:53 PM: On Thu, Aug 25, 2011 at 09:35:07AM +0530, Pedanekar, Hemant wrote: E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 [...] So, larger the hole, more address space will be unusable - is that correct? Correct. This also means vmalloc space is lower compared to when a single mem=40M is passed. Huh. Either your maths is wrong or... Here's case 1: vmalloc : 0xc880 - 0xf800 ( 760 MB) And case 2: vmalloc : 0xc300 - 0xf800 ( 848 MB) Looks to me like case 1, vmalloc space is _higher_ not _lower_. That's expected because you told the kernel it had more memory in case 1. Sorry, my mistake - I actually meant vmalloc space is _smaller_ compared to when a single mem=40M is passed though the actual physical RAM available is same in both the cases. Again, that's expected. We require a 1:1 relationship between virtual and physical addresses for efficiency - having non-linear translation means we'd need a lookup table, and as these translations are heavily used, that will impact performance. Thanks for all the clarifications. Hemant-- 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: Question on virtual memory layout: lowmem with memory hole
Russell King - ARM Linux wrote on Thursday, August 25, 2011 3:53 PM: On Thu, Aug 25, 2011 at 09:35:07AM +0530, Pedanekar, Hemant wrote: E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 (CASE 1) Memory: 32MB 8MB = 40MB total Memory: 28408k/28408k available, 12552k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Is this expected? 88MB space between two 'mem's seems to have lost. Yes. The memory layout lines gives an overview of the virtual memory address space _regions_. What it's saying is that the virtual addresses from 0xc000 - 0xc800 are used for lowmem. That may not be fully populated, but that's what the address range is reserved for. So, larger the hole, more address space will be unusable - is that correct? This also means vmalloc space is lower compared to when a single mem=40M is passed. Huh. Either your maths is wrong or... Here's case 1: vmalloc : 0xc880 - 0xf800 ( 760 MB) And case 2: vmalloc : 0xc300 - 0xf800 ( 848 MB) Looks to me like case 1, vmalloc space is _higher_ not _lower_. That's expected because you told the kernel it had more memory in case 1. Sorry, my mistake - I actually meant vmalloc space is _smaller_ compared to when a single mem=40M is passed though the actual physical RAM available is same in both the cases. Thanks. Hemant-- 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
Question on virtual memory layout: lowmem with memory hole
Hello, While checking with memory hole configuration on OMAP3/TI816X (passing mem=x@y), I see that the whole range from memory start till last bank including the hole is labelled as 'lowmem' when kernel prints Virtual kernel memory layout during boot. E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 (CASE 1) Memory: 32MB 8MB = 40MB total Memory: 28408k/28408k available, 12552k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Is this expected? 88MB space between two 'mem's seems to have lost. This also means vmalloc space is lower compared to when a single mem=40M is passed. E.g., with mem=40M (CASE 2) Memory: 40MB = 40MB total Memory: 28412k/28412k available, 12548k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc300 - 0xf800 ( 848 MB) lowmem : 0xc000 - 0xc280 ( 40 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Any way we can get virtual layout same in CASE 1 as in CASE 2? Thanks. Hemant-- 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 0/3] Add support for TI814X processor series
linux-arm-kernel-boun...@lists.infradead.org wrote on : Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Any comments on this patch set? Thanks. Hemant ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Hello, Can you please provide comments on these patches? Thanks. Hemant-- 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/3] TI814X: Add cpu type macros and detection support
Tony Lindgren wrote on Monday, August 15, 2011 8:47 PM: * Hemant Pedanekar hema...@ti.com [110804 20:39]: This patch adds cpu type, macros for identification of TI814X device. Note that following updates to common OMAP data structures are made: 1) struct omap_chip_id member 'oc' is updated to u32 from u16 as omap chip bitfield has exhausted 16 bits for CHIP_IS_XXX. 2) cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. We'll be getting rid of CHIP_IS usage and replace them with SoC specific lists. So we need to wait few days and then this patch will need to get updated a bit. Tony, Is there a branch which I can have a look at for changes being done? Thanks. Hemant-- 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 3/3] TI814X: Create board support and enable build for TI8148 EVM
Tony Lindgren wrote on Monday, August 15, 2011 8:45 PM: * Hemant Pedanekar hema...@ti.com [110804 20:39]: This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. ... +MACHINE_START(TI8148EVM, ti8148evm) +/* Maintainer: Texas Instruments */ +.boot_params= 0x8100, +.map_io = ti8148_evm_map_io, +.init_early = ti8148_init_early, +.init_irq = ti81xx_init_irq, +.timer = omap3_timer, +.init_machine = ti8148_evm_init, +MACHINE_END Please just combine this with board-ti8168evm.c by adding the MACHINE_START there. It seems the files are identical otherwise? Tony, There will be more additions in respective board files such as I2C I/O expander data, mux handling depending upon the EVM (8168/8148), on board peripherals etc When these board files would deviate. What do you suggest to handle such? Thanks. Hemant-- 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 0/3] Add support for TI814X processor series
linux-arm-kernel-boun...@lists.infradead.org wrote on : linux-arm-kernel-boun...@lists.infradead.org wrote on : Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Hello, Can you please provide comments on these patches? Thanks. Hemant Please disregard, I had missed Tony's comments. Hemant-- 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] omap: timer: Set dmtimer used as clocksource in autoreload mode
Tony Lindgren wrote on Wednesday, August 10, 2011 5:21 PM: * Hemant Pedanekar hema...@ti.com [110809 20:46]: If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the timer stops counting once overflow occurs as it was not set in autoreload mode. This results into timekeeping failure: for example, 'sleep 1' at the shell after the timer counter overflow would hang. This patch sets up autoreload when starting the clocksource timer which fixes the above issue. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index e964072..796b935 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -293,7 +293,7 @@ static void __init omap2_gp_clocksource_init(int gptimer_id, pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n, gptimer_id, clksrc.rate); -__omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1); +omap_dm_timer_set_load_start(clksrc, 1, 0); init_sched_clock(cd, dmtimer_update_sched_clock, 32, clksrc.rate); if (clocksource_register_hz(clocksource_gpt, clksrc.rate)) You should be able to just set the autoreload mode by changing to use OMAP_TIMER_CTRL_POSTED | OMAP_TIMER_CTRL_AR in the __omap_dm_timer_load_start above. This avoids calling something that might be a loadable module eventually. Regards, Tony Yes, that would be better - I didn't think about loadable module option. Thanks. Hemant-- 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 0/3] Add support for TI814X processor series
Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Any comments on this patch set? Thanks. Hemant-- 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/4] TI816X: clock: Add clock data
Hi Paul,
Paul Walmsley wrote on Saturday, July 16, 2011 1:36 PM:
Spot-checking this...
On Fri, 25 Mar 2011, Hemant Pedanekar wrote:
+static struct clk uart1_fck = {
+.name = uart1_fck,
+.parent = sysclk10_ck,
+.ops= clkops_omap2_dflt,
+.enable_reg = TI816X_CM_ALWON_UART_0_CLKCTRL,
+.enable_bit = TI816X_MODULEMODE_SWCTRL,
+.clkdm_name = alwon_l3_slow_clkdm,
+.recalc = followparent_recalc,
+};
Is this really in the alwon_l3_slow_clkdm clockdomain?
Looking at SPRS680
section 5.2 L4 Interconnect, these UARTs seem to be in some L4
clockdomain?
- Paul
Yes UARTs are on L4 slow but the clock domain is labelled as
ALWON_L3_SLOW. Please refer 18.3.2 of SPRUGX8 (TRM from
http://focus.ti.com/docs/prod/folders/print/tms320dm8168.html).
Thanks.
Hemant--
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 1/2] TI816X: Add minimal hwmod data
Hi Paul, Paul Walmsley wrote on Saturday, July 16, 2011 1:38 PM: Hello Hemant, On Wed, 13 Jul 2011, Pedanekar, Hemant wrote: Any comments on the hwmod and clock patch sets? I haven't forgotten about these patches. Here are a few questions: Sorry I missed this mail. - Are there are public documents about what interconnect is used on these chips? Is it a SonicsMX, an Arteris NOC, or something else? I will get back to you on this. - It looks like you've grouped the PRCM implementation with the existing OMAP3 PRCM code. But it appears to me, looking at the 816X TRM, that the register layout is closer to OMAP4 - the MODULEMODE bits, etc. Any comments on this? You are correct. The register layout is closer to OMAP4 hence I have Used .omap4 from PRCM data union field in struct omap_hwmod for Hwmod data. Thanks. Hemant-- 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 3/4] TI816X: clock: Add clockdomains and powerdomains data
Paul Walmsley wrote on Saturday, July 16, 2011 1:25 PM: On Fri, 25 Mar 2011, Hemant Pedanekar wrote: This patch adds data for various clock domains and power domains in TI816X. Note that at present this is not exhaustive and need to add missing domains. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/clockdomains816x.h | 167 arch/arm/mach-omap2/powerdomains816x.h | 74 ++ 2 files changed, 241 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains816x.h create mode 100644 arch/arm/mach-omap2/powerdomains816x.h Static data shouldn't be declared in .h files; it should be declared in *domains81*_data.c files, as is the practice with the rest of the powerdomains/clockdomains data here. Will take care of this in next version. Thanks. Hemant-- 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 1/2] TI816X: Add minimal hwmod data
Hi Kevin, Hilman, Kevin wrote on Friday, July 15, 2011 3:28 AM: Hi Hemant, On Wed, 2011-07-13 at 05:07 +0530, Pedanekar, Hemant wrote: Any comments on the hwmod and clock patch sets? I just discovered that other devices in this family are coming along which will require changing the names/macros/etc. from 816x to 81xx[1]. Merging this series, followed shortly by another series that renames everything is the type of churn we are trying to avoid. To avoid this kind of churn, I recommend starting from the broader family name first. Kevin http://arago-project.org/git/projects/?p=linux-omap3.git;a=com mit;h=ce17fa2f527ed614399e577fc2fd5cd3624ee501 Sure, I will send in TI814X patches then. Thanks. Hemant
RE: [PATCH 1/2] TI816X: Add minimal hwmod data
Hello, Paul Walmsley wrote on Friday, April 29, 2011 8:29 AM: On Thu, 28 Apr 2011, Grosen, Mark wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, April 28, 2011 3:35 PM to review these patches, I'll need a copy of the TRM. Could you point me to it or send me one, please? http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?li teratureNumber=sprugx8 Thanks Mark! - Paul Any comments on the hwmod and clock patch sets? Thanks. Hemant-- 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: !CONFIG_OMAP_32K_TIMER on OMAP4/panda
Hello, linux-omap-ow...@vger.kernel.org wrote on Saturday, May 07, 2011 10:21 PM: On a linux-next kernel built for the Pandaboard, disabling CONFIG_OMAP_32K_TIMER makes the kernel use the gptimer as the clocksource, but this appears to be non-functional. Judging from the all-zeros printk timings and the fact the sleep 1 hangs indefinitely, it looks like the clocksource reads are always zero. Boot log below and .config attached. Ideas? [0.00] Linux version 2.6.39-rc6-next-20110506+ (rabin@debian) [...] [0.00] Freeing init memory: 112K This looks similar to the issue I observed on TI816X with 32K timer disabled. I have created following patch (currently a tempfix) for making timekeeping work with MPU timer selected (other option is to use .flags = HWMOD_INIT_NO_RESET in hwmod data for the timer used as clocksource): commit 77cce922c00ced4407776cc0a1d84cee40b7da90 Author: Hemant Pedanekar hema...@ti.com Date: Thu Apr 28 12:59:24 2011 +0530 dmtimer: Initialize the hwmod for timer used as clocksource Since dmtimer driver still doesn't use hwmods, the 2nd timer used as clocksource is not set up. This results into timekeepoing failure when the timer used as clocksource gets reset during hwmod setup. To prevent this, explicitly call omap_hwmod_setup_one() for timer used as clocksource. Note that is is aplpicable when NOT using 32k timer which is the case for TI816X. For other configurations, this code will not be executed unless 32K timer is explicitly disabled. Signed-off-by: Hemant Pedanekar hema...@ti.com diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c index 3b9cf85..290fbfa 100644 --- a/arch/arm/mach-omap2/timer-gp.c +++ b/arch/arm/mach-omap2/timer-gp.c @@ -229,6 +229,11 @@ static void __init omap2_gp_clocksource_init(void) %s: failed to request dm-timer\n; static char err2[] __initdata = KERN_ERR %s: can't register clocksource!\n; + char clocksource_hwmod_name[8]; /* 8 = sizeof(timerXX0) */ + + /* XXX: This may not be always true, we might get different timer */ + sprintf(clocksource_hwmod_name, timer%d, gptimer_id + 1); + omap_hwmod_setup_one(clocksource_hwmod_name); gpt = omap_dm_timer_request(); if (!gpt) Hemant-- 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 1/4] TI816X: prcm: Add module and register offsets
Hello, Pedanekar, Hemant wrote on Friday, March 25, 2011 9:50 PM: This patch adds PRCM register offsets for TI816X device as required for the clock data. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/cm816x.h | 228 arch/arm/mach-omap2/prm2xxx_3xxx.h | 17 +++ 2 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cm816x.h diff --git a/arch/arm/mach-omap2/cm816x.h b/arch/arm/mach-omap2/cm816x.h new file mode 100644 index 000..b1dbd3d --- /dev/null +++ b/arch/arm/mach-omap2/cm816x.h @@ -0,0 +1,228 @@ +/* + * TI816X CM register access macros. Also contains CM module offsets. + * + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_CM816X_H +#define __ARCH_ARM_MACH_OMAP2_CM816X_H + +#include prcm-common.h + +#define TI816X_CM_REGADDR(module, reg) \ + OMAP2_L4_IO_ADDRESS(TI816X_PRCM_BASE + (module) + (reg)) + +/* + * TI816X CM module offsets + */ + +#define TI816X_CM_DEVICE_MOD 0x0100 /* 256B */ +#define TI816X_CM_DPLL_MOD 0x0300 /* 256B */ +#define TI816X_CM_ACTIVE_MOD 0x0400 /* 256B */ +#define TI816X_CM_DEFAULT_MOD0x0500 /* 256B */ +#define TI816X_CM_IVAHD0_MOD 0x0600 /* 256B */ +#define TI816X_CM_IVAHD1_MOD 0x0700 /* 256B */ +#define TI816X_CM_IVAHD2_MOD 0x0800 /* 256B */ +#define TI816X_CM_SGX_MOD0x0900 /* 256B */ +#define TI816X_CM_ALWON_MOD 0x1400 /* 1KB */ + +/* + * Clock domain register offsets - these are generally CLKSTCTRL registers for + * respective modules. + */ + +/* ALWON */ +#define TI816X_CM_ALWON_MPU_CLKDM0x001C +#define TI816X_CM_ALWON_L3_SLOW_CLKDM0x +#define TI816X_CM_ETHERNET_CLKDM 0x0004 +#define TI816X_CM_MMU_CLKDM 0x000C +#define TI816X_CM_MMUCFG_CLKDM 0x0010 + +/* ACTIVE */ +#define TI816X_CM_ACTIVE_GEM_CLKDM 0x + +/* IVAHD0 */ +#define TI816X_CM_IVAHD0_CLKDM 0x + +/* IVAHD1 */ +#define TI816X_CM_IVAHD1_CLKDM 0x + +/* IVAHD2 */ +#define TI816X_CM_IVAHD2_CLKDM 0x + +/* SGX */ +#define TI816X_CM_SGX_CLKDM 0x + +/* DEFAULT */ +#define TI816X_CM_DEFAULT_L3_MED_CLKDM 0x0004 +#define TI816X_CM_DEFAULT_DUCATI_CLKDM 0x0018 +#define TI816X_CM_DEFAULT_PCI_CLKDM 0x0010 +#define TI816X_CM_DEFAULT_L3_SLOW_CLKDM 0x0014 + +/* + * CM register addresses + */ + +/* CM_DPLL */ +#define TI816X_CM_DPLL_SYSCLK1_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x) +#define TI816X_CM_DPLL_SYSCLK2_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0004) +#define TI816X_CM_DPLL_SYSCLK3_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0008) +#define TI816X_CM_DPLL_SYSCLK4_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x000C) +#define TI816X_CM_DPLL_SYSCLK5_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0010) +#define TI816X_CM_DPLL_SYSCLK6_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0014) +#define TI816X_CM_DPLL_SYSCLK7_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0018) +#define TI816X_CM_DPLL_SYSCLK10_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0024) +#define TI816X_CM_DPLL_SYSCLK11_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x002C) +#define TI816X_CM_DPLL_SYSCLK12_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0030) +#define TI816X_CM_DPLL_SYSCLK13_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0034) +#define TI816X_CM_DPLL_SYSCLK15_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0038) +#define TI816X_CM_DPLL_VPB3_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0040) +#define TI816X_CM_DPLL_VPC1_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0044) +#define TI816X_CM_DPLL_VPD1_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0048) +#define TI816X_CM_DPLL_SYSCLK19_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x004C) +#define TI816X_CM_DPLL_SYSCLK20_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0050) +#define TI816X_CM_DPLL_SYSCLK21_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0054) +#define TI816X_CM_DPLL_SYSCLK22_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0058) +#define TI816X_CM_DPLL_APA_CLKSEL TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD
RE: [PATCH RESEND v6 2/4] TI816X: Update common OMAP machine specific sources
Hilman, Kevin wrote on Tuesday, February 15, 2011 4:58 AM:
Hemant Pedanekar hema...@ti.com writes:
[...]
@@ -402,7 +422,7 @@ void __init
omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
omap_hwmod_late_init();
-if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+if (omap3_has_sdrc()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
}
At first glance, this one doesn't look quite right. Will
omap3_has_sdrc() be true on 24xx? Please confirm.
Kevin
You are right, this is incorrect as there is no 'features' set for
omap24xx. I will send new version with cpu_is_omap24xx() check retained.
Thanks.
Hemant--
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 v5 1/4] TI816X: Update common omap platform files
cvTony Lindgren wrote on Thursday, February 10, 2011 7:09 AM: Hi, * Hemant Pedanekar hema...@ti.com [110209 08:54]: 1) Multi-OMAP build with CONFIG_SOC_OMAPTI816X: The kernel built only for TI816X OMAP3 SoCs along with any other OMAP2/4 (e.g., OMAP4s). May not boot on other OMAP3 SoCs. This option does not sound right. For the multi-omap builds we need to have the system working for all the processors, there should not be any reason not to have things working. Do you have some example in mind where other omaps break? If so, we should just fix that issue. Regards, Tony I will take care of this using separate map_io as you mentioned on the other mail on patch 2 comment. Do you think the 2nd case restriction mentioned in this patch comment is OK? 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X optimized kernel. May not boot on other OMAP3 SoCs. As I had mentioned on follow up on Paul's comment on v4, some OMAP3 specific code may get skipped on non-multi-omap builds with CONFIG_SOC_OMAPTI816X (cpu_is_ti816x() is true) such as: - if (omap_rev() = OMAP3430_REV_ES2_0) + if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0)) omap3_clk_lock_dpll5(); Thanks. Hemant-- 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 v5 2/4] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Thursday, February 10, 2011 7:18 AM: * Tony Lindgren t...@atomide.com [110209 17:45]: We should just have separate struct map_desc omapti816x_io_desc[] then. Maybe have a common struct map_desc omap3_io_desc[] and then separate omap3xxx_io_desc and omapti816x_io_desc? Oh and this will work just fine for map_io without having cpu_is_omap macros working yet because we call set_globals from the board file with the processor class data. Tony So probably I need to create another function (ti816x_map_common_io()) to map just the L4 slow region and call it from board file (after set globals) as distinguishing between OMAP3xxx and TI816X is not possible at that time inside omap34xx_map_common_io() as they both have same class. Does this approach look ok? Thanks. Hemant-- 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 v4 1/4] TI816X: Update common omap platform files
Kevin Hilman wrote on Tuesday, January 25, 2011 1:33 AM: Pedanekar, Hemant hema...@ti.com writes: Hi Kevin, Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: Hi Hemant, Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X support. Also adds new files for TI816X module base addresses and irq definitions. [...] diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h b/arch/arm/plat-omap/include/plat/irqs-ti816x.h new file mode 100644 index 000..3ec5d1b [...] +#define TI816X_IRQ_SECPUBINT 116 +#define TI816X_IRQ_SECSECINT 117 +#define TI816X_IRQ_SECPUBSWINT118 +#define TI816X_IRQ_SECSECSWINT119 +#define TI816X_IRQ_SMRFLX0120 +#define TI816X_IRQ_SMRFLX1121 +#define TI816X_IRQ_SYS_MMU122 +#define TI816X_IRQ_MC_MMU 123 +#define TI816X_IRQ_DMM124 + + +#endif For new platforms, We don't need to have a list of all the IRQ numbers. Driver code should always be getting IRQ numbers (and base addresses etc.) from struct resource/platform_data, which is populated from omap_hwmod. Are you suggesting to get rid of this file altogether or the IRQs which may never be used from kernel be removed from this file (and added later If needed)? Or shall I add this file only in hwmod patch which will be submitted later? You can get rid of the file altogether. Even the hwmod data can just have IRQ numbers and you shouldn't need to add a header file with the defines. Kevin Ok got it. Thanks. Hemant-- 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 v4 0/4] Introduce support for TI816X processor series
linux-omap-ow...@vger.kernel.org wrote on : Pedanekar, Hemant wrote on Monday, January 10, 2011 10:08 PM: This patch set adds support for TI816X processor series. This series includes DM8168, C6A816x and AM389x devices. The details can be found at following links: http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960 http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml This series is architecturally closer to the OMAP devices. Hence, these patches are being submitted on linux-omap. These patches are tested on OMAP3 EVM with multi-omap build. Note that, additional patches consisting of TI816X specific hwmods, clock data and DMTIMER changes, are required to enable successful booting on TI816X EVM. These patches will follow shortly. The TI816X support is added as part of OMAP3 variant. The approach taken is in accordance to the discussions in thread related to following post: http://www.spinics.net/lists/linux-omap/msg41505.html In addition, TI816X specific customizations/optimizations are handled as a part of build configuration CONFIG_SOC_OMAPTI816X. Discussed here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41927.html Hemant Pedanekar (4): TI816X: Update common omap platform files TI816X: Update common OMAP machine specific sources TI816X: Create board support and enable build for TI816X EVM TI816X: Add low level debug support [...] Tony, Can you please provide the comments on v4 patches? Thanks. - Tony, Do you find this series alright? Please let me know your comments. Thanks. Hemant -- 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 v4 1/4] TI816X: Update common omap platform files
Hi Kevin, Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: Hi Hemant, Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X support. Also adds new files for TI816X module base addresses and irq definitions. [...] diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h b/arch/arm/plat-omap/include/plat/irqs-ti816x.h new file mode 100644 index 000..3ec5d1b [...] +#define TI816X_IRQ_SECPUBINT116 +#define TI816X_IRQ_SECSECINT117 +#define TI816X_IRQ_SECPUBSWINT 118 +#define TI816X_IRQ_SECSECSWINT 119 +#define TI816X_IRQ_SMRFLX0 120 +#define TI816X_IRQ_SMRFLX1 121 +#define TI816X_IRQ_SYS_MMU 122 +#define TI816X_IRQ_MC_MMU 123 +#define TI816X_IRQ_DMM 124 + + +#endif For new platforms, We don't need to have a list of all the IRQ numbers. Driver code should always be getting IRQ numbers (and base addresses etc.) from struct resource/platform_data, which is populated from omap_hwmod. Are you suggesting to get rid of this file altogether or the IRQs which may never be used from kernel be removed from this file (and added later If needed)? Or shall I add this file only in hwmod patch which will be submitted later? [...] diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h index cec5d56..3c3c319 100644 --- a/arch/arm/plat-omap/include/plat/serial.h +++ b/arch/arm/plat-omap/include/plat/serial.h @@ -51,6 +51,11 @@ #define OMAP4_UART3_BASE0x4802 #define OMAP4_UART4_BASE0x4806e000 +/* TI816X serial ports */ +#define TI816X_UART1_BASE 0x4802 +#define TI816X_UART2_BASE 0x48022000 +#define TI816X_UART3_BASE 0x48024000 /* External port on Zoom2/3 */ #define ZOOM_UART_BASE 0x1000 #define ZOOM_UART_VIRT 0xfa40 diff --git a/arch/arm/plat-omap/include/plat/ti816x.h b/arch/arm/plat-omap/include/plat/ti816x.h new file mode 100644 index 000..f1729f7 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/ti816x.h @@ -0,0 +1,31 @@ [...] + +#define L3_TI816X_BASE 0x4400 +#define L4_FAST_TI816X_BASE 0x4a00 +#define L4_SLOW_TI816X_BASE 0x4800 + +#define TI816X_SCM_BASE 0x4814 +#define TI816X_CTRL_BASETI816X_SCM_BASE +#define TI816X_PRCM_BASE0x4818 + +#define TI816X_ARM_INTC_BASE0x4820 + +#define TI816X_GPMC_BASE0x5000 + +#endif /* __ASM_ARCH_TI816X_H */ All of these fall into the not used in this patch category. It is best to add these defines in the patches where they are used so reviewers can see the usage and/or the need. With all of these defines, the subject for this patch should probably just be about adding the SoC detection infrastructure. Thanks, Kevin Okay, I will remove some of the unused defs (like GPMC_BASE) and reorganize The patches to have files in correct groups. Thanks. Hemant -- 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 v4 2/4] TI816X: Update common OMAP machine specific sources
Kevin,
Kevin Hilman wrote on Saturday, January 22, 2011 5:19 AM:
Hemant Pedanekar hema...@ti.com writes:
This patch updates the common machine specific source files with support
for TI816X.
The approach taken is to have TI816X only build for OMAP3 when
CONFIG_SOC_OMAPTI816X is defined.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |5 +++-
arch/arm/mach-omap2/common.c | 24 +
arch/arm/mach-omap2/control.h | 17
arch/arm/mach-omap2/id.c | 33
++- arch/arm/mach-omap2/include/mach/entry-macro.S |
13 + arch/arm/mach-omap2/io.c | 13
- arch/arm/mach-omap2/irq.c |5 +++-
arch/arm/mach-omap2/serial.c |8 +++---
arch/arm/plat-omap/io.c|5 +++-
9 files changed, 113 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9ab817e..557de99 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3466,6 +3466,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_omap3630()) {
cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
cpu_clkflg = CK_36XX;
+} else if (cpu_is_ti816x()) {
+cpu_mask = RATE_IN_TI816X;
+cpu_clkflg = CK_TI816X;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
@@ -3545,7 +3548,7 @@ int __init omap3xxx_clk_init(void) /*
* Lock DPLL5 and put it in autoidle.
*/
-if (omap_rev() = OMAP3430_REV_ES2_0)
+if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0))
omap3_clk_lock_dpll5();
/* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 778929f..7f58b7f 100644 --- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -108,6 +108,30 @@ void __init omap3_map_io(void)
omap2_set_globals_3xxx(); omap34xx_map_common_io();
}
+
+/*
+ * Adjust TAP register base such that omap3_check_revision accesses the
correct + * TI816X register for checking device ID (it adds 0x204 to tap
base while + * TI816X DEVICE ID register is at offset 0x600 from control
base). + */ +#define TI816X_TAP_BASE (TI816X_CTRL_BASE + \
+TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals ti816x_globals = {
+.class = OMAP343X_CLASS,
+.tap= OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
+.ctrl = TI816X_CTRL_BASE,
+.prm= TI816X_PRCM_BASE,
+.cm = TI816X_PRCM_BASE,
+.uart1_phys = TI816X_UART1_BASE,
+.uart2_phys = TI816X_UART2_BASE,
+.uart3_phys = TI816X_UART3_BASE,
The uart*_phys are not needed. I just sent a patch to remove these from
the core code.
+};
+
+void __init omap2_set_globals_ti816x(void)
+{
+__omap2_set_globals(ti816x_globals);
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/control.h
b/arch/arm/mach-omap2/control.h
index f0629ae..5c87054 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -52,6 +52,11 @@
#define OMAP343X_CONTROL_PADCONFS_WKUP 0xa00
#define OMAP343X_CONTROL_GENERAL_WKUP 0xa60
+/* TI816X spefic control submodules */
+#define TI816X_CONTROL_OCPCONF 0x000
+#define TI816X_CONTROL_DEVBOOT 0x040
+#define TI816X_CONTROL_DEVCONF 0x600
Not used in this patch (or series)
/* Control register offsets - read/write with
omap_ctrl_{read,write}{bwl}() */
#define OMAP2_CONTROL_SYSCONFIG
(OMAP2_CONTROL_INTERFACE + 0x10)
@@ -241,6 +246,18 @@
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
+/* TI816X CONTROL_DEVBOOT register offsets */
+#define TI816X_CONTROL_STATUS
(TI816X_CONTROL_DEVBOOT + 0x000)
+#define TI816X_CONTROL_BOOTSTAT
(TI816X_CONTROL_DEVBOOT + 0x004)
+
+/* TI816X CONTROL_DEVCONF register offsets */
+#define TI816X_CONTROL_DEVICE_ID(TI816X_CONTROL_DEVCONF + 0x000)
+#define TI816X_CONTROL_MAC_ID0_LO (TI816X_CONTROL_DEVCONF + 0x030)
+#define TI816X_CONTROL_MAC_ID0_HI (TI816X_CONTROL_DEVCONF + 0x034)
+#define TI816X_CONTROL_MAC_ID1_LO (TI816X_CONTROL_DEVCONF + 0x038)
+#define TI816X_CONTROL_MAC_ID1_HI (TI816X_CONTROL_DEVCONF + 0x03c)
+#define TI816X_CONTROL_PCIE_CFG
(TI816X_CONTROL_DEVCONF + 0x040)
Not used in this patch (or series)
In general, we don't like to see unused code added in a patch or series.
It is better for review (and also for later investigtion with git-blame
or git bisect) to have code added only when it is used.
Thanks,
Kevin
I will rearrange
RE: [PATCH v4 4/4] TI816X: Add low level debug support
Hilman, Kevin wrote on Saturday, January 22, 2011 5:21 AM: Hemant Pedanekar hema...@ti.com writes: This patch adds support for low level debugging on TI816X boards. Currently the support for UART3 console on TI816X EVM is added. Signed-off-by: Hemant Pedanekar hema...@ti.com You can add the UART base addresses in this patch since this is the only place they are needed/used. Kevin Yes. Thanks. Hemant -- 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 v4 1/4] TI816X: Update common omap platform files
Paul Walmsley wrote on Tuesday, January 18, 2011 5:38 AM: Hello Hemant, On Mon, 10 Jan 2011, Hemant Pedanekar wrote: 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X optimized kernel. May not boot on other OMAP3 SoCs. ... Note that OMAP3 only build with support for OMAP3 SoCs as well as TI816X is not possible. Could you explain a little bit why this is not possible? Naïvely, to me, it seems that it should be possible. - Paul Hi Paul, You are correct, the OMAP3 only kernel built with TI816X also boots on OMAP3 EVM. But my main concern is with cpu_is_ti816x becoming true for this build (optimized build for TI816X only), some of the OMAP3 related part will be skipped. E.g., - if (omap_rev() = OMAP3430_REV_ES2_0) + if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0)) omap3_clk_lock_dpll5(); Thanks - Hemant -- 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 v4 0/4] Introduce support for TI816X processor series
Pedanekar, Hemant wrote on Monday, January 10, 2011 10:08 PM: This patch set adds support for TI816X processor series. This series includes DM8168, C6A816x and AM389x devices. The details can be found at following links: http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960 http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml This series is architecturally closer to the OMAP devices. Hence, these patches are being submitted on linux-omap. These patches are tested on OMAP3 EVM with multi-omap build. Note that, additional patches consisting of TI816X specific hwmods, clock data and DMTIMER changes, are required to enable successful booting on TI816X EVM. These patches will follow shortly. The TI816X support is added as part of OMAP3 variant. The approach taken is in accordance to the discussions in thread related to following post: http://www.spinics.net/lists/linux-omap/msg41505.html In addition, TI816X specific customizations/optimizations are handled as a part of build configuration CONFIG_SOC_OMAPTI816X. Discussed here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41927.html Hemant Pedanekar (4): TI816X: Update common omap platform files TI816X: Update common OMAP machine specific sources TI816X: Create board support and enable build for TI816X EVM TI816X: Add low level debug support arch/arm/mach-omap2/Kconfig| 16 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-ti8168evm.c | 58 +++ arch/arm/mach-omap2/clock3xxx_data.c |5 +- arch/arm/mach-omap2/common.c | 24 + arch/arm/mach-omap2/control.h | 17 +++ arch/arm/mach-omap2/id.c | 33 ++- arch/arm/mach-omap2/include/mach/debug-macro.S | 12 ++ arch/arm/mach-omap2/include/mach/entry-macro.S | 13 +++ arch/arm/mach-omap2/io.c | 13 ++- arch/arm/mach-omap2/irq.c |5 +- arch/arm/mach-omap2/serial.c |8 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|1 + arch/arm/plat-omap/include/plat/common.h |1 + arch/arm/plat-omap/include/plat/cpu.h | 22 arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/irqs-ti816x.h | 131 arch/arm/plat-omap/include/plat/irqs.h | 3 + arch/arm/plat-omap/include/plat/serial.h |8 ++ arch/arm/plat-omap/include/plat/ti816x.h | 31 ++ arch/arm/plat-omap/include/plat/uncompress.h |7 ++ arch/arm/plat-omap/io.c|5 +- 23 files changed, 406 insertions(+), 10 deletions(-) create mode 100644 arch/arm/mach-omap2/board-ti8168evm.c create mode 100644 arch/arm/plat-omap/include/plat/irqs-ti816x.h create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h Tony, Can you please provide the comments on v4 patches? Thanks. - Hemant -- 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 v3 1/4] TI816X: Update common omap platform files
linux-omap-ow...@vger.kernel.org wrote on : Tony Lindgren wrote on Wednesday, January 05, 2011 4:56 AM: * Paul Walmsley p...@pwsan.com [110104 09:48]: On Tue, 4 Jan 2011, Pedanekar, Hemant wrote: Looking at above, it seems another config option like CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. We already have CONFIG_ARCH_OMAP3430, CONFIG_ARCH_OMAP2430, and CONFIG_ARCH_OMAP2420. I guess at some point those need to be renamed to CONFIG_SOC_*. Yes that's what I was thinking too. Keep CONFIG_ARCH_OMAP2, 3, and 4, and rename CONFIG_ARCH_OMAP3430 etc to CONFIG_SO_COMAP3430 and so on. Regards, Tony So I will add CONFIG_SOC_OMAPTI816X to handle TI816X specific variations. But I think without addition of corresponding CONFIG_SOC_OMAP3XXX, it would be difficult to handle 2nd case I mentioned (OMAP3 build for OMAP3xxx as well as TI816X SoCs). Will it be OK if we consider this 2nd case as invalid/unsupported for the moment - that is, 2nd case = 4th case (OMAP3 build for TI816X only)? Same applies for multi-omap case too. In short, if CONFIG_SOC_OMAPTI816X is selected, the build becomes specific to TI816X and not OMAP3xxx in all the cases (so keep CONFIG_SOC_OMAPTI816X disabled by default in multi-omap configuration). Tony, Does the above look ok? Also please let me know any other comments and I will send updated patches. Thanks - Hemant -- 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 v3 1/4] TI816X: Update common omap platform files
Tony Lindgren wrote on Tuesday, January 04, 2011 7:20 AM: * Paul Walmsley p...@pwsan.com [110103 15:06]: Hello Hemant On Mon, 3 Jan 2011, Hemant Pedanekar wrote: This patch updates the common platform files with TI816X support. Also adds new files for TI816X modules base addresseses and irq definitions. The approach taken in this patch is to add TI816X as part of OMAP3 variant where the cpu class is considered as OMAP34XX and the type is TI816X. This means, both cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X. Looks like you should add a CONFIG_ARCH_OMAPTI816X Kconfig option for this chip. I suspect that many handheld device manufacturers won't want to include TI816X-specific code/data in their builds, and vice versa. Please use CONFIG_SOC_OMAPTI816X instead, eventually we should use CONFIG_ARCH_OMAPX only for something that requires different compiler options. Regards, Tony Thanks Tony and Paul for comments. This means following cases need to handle: 1) Multi-OMAP build. 2) OMAP3 build for OMAP3xxx as well as TI816X SoCs - have precedence to default OMAP3 only build at most of the places. Note that this build will not really be optimized for either of them - some areas being irq macro, clock data handling with various run time checks being executed, few cpu_is_ti816x checks being executed etc. 3) OMAP3 build for OMAP3xxx SoCs only - This should be same as having CONFIG_ARCH_OMAP3 alone as earlier without TI816X patches. Thus, CONFIG_SOC_OMAPTI816X should be disabled in this case. 4) OMAP3 build for TI816X only - CONFIG_SOC_OMAPTI816X should be enabled here, which should lead to apply TI816X specific changes to OMAP3 code. Am I getting this correct? Looking at above, it seems another config option like CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. Please let me know your comments about this. Thanks - Hemant-- 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 v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Monday, December 06, 2010 10:23 PM: [...] Similarly, we will also need to add TI816X specific hwmods. 4) TI816X series shares similarity with OMAP4 too - e.g., various IPs are same, CM module is closer to OMAP4 than OMAP3. Thus, regaring (1) above, I could use OMAP4 code instead of adding new else if. Of course, again, there are above mentioned differences too. We really want to use same code for the shared modules so using feature based detection is the way to go. Tony, Just wanted to confirm: so you are suggesting we do not have any cpu_is_ti81xx() check in the code - is that correct? Thanks - Hemant -- 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 v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Saturday, December 11, 2010 7:21 AM: * Pedanekar, Hemant hema...@ti.com [101210 16:58]: Tony Lindgren wrote on Monday, December 06, 2010 10:23 PM: [...] Similarly, we will also need to add TI816X specific hwmods. 4) TI816X series shares similarity with OMAP4 too - e.g., various IPs are same, CM module is closer to OMAP4 than OMAP3. Thus, regaring (1) above, I could use OMAP4 code instead of adding new else if. Of course, again, there are above mentioned differences too. We really want to use same code for the shared modules so using feature based detection is the way to go. Tony, Just wanted to confirm: so you are suggesting we do not have any cpu_is_ti81xx() check in the code - is that correct? We can have that, but we should avoid it where possible. And ideally cpu_is_ti81xx() would be just something like: #define cpu_is_ti81xx() \\ cpu_is_omap34xx() omap_has_aaa() omap_has_bbb() Regards, Tony Thanks. I will send the patches early next week. - Hemant -- 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 v2 3/6] TI816X: Update common OMAP machine specific sources
Pedanekar, Hemant wrote on Wednesday, December 01, 2010 7:17 AM:
Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
* Pedanekar, Hemant hema...@ti.com [101129 09:07]:
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
Though based on Cortex A8, TI816X series has differences in PRCM, PLL,
clock structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For
example, consider following: File -
arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret =
omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X
as there are no CM_IDELST registers.
OK, so places like these will need different handling, and should
then be based on some idlest flag that gets set during the init
based on cpu_is_omap24xx() || cpu_is_omap3430() || cpu_is_omap3630().
Tony,
Thanks for clarifications. I have some concerns though:
1) I will eventually end up preceeding existing OMAP3 ckecks to have
cpu_is_34xx() fail. Fo example, in above case, since
cpu_is_omap34xx will
be true for ti81xx (which we don't want), I need to update
the code as:
if (cpu_is_omap24xx() || (cpu_is_omap34xx()
!cpu_is_ti816x()) {
OR
if (cpu_is_omap24xx() || (cpu_is_omap34xx()
omap_has_idlest()) {
Then proceed to have a TI816X specific handling in else if part with
cpu_is_ti816x() check.
2) Various module base addresses part of global data are
different compared to
OMAP3/4 - e.g., .tap, .ctrl, .prm etc are different. This
means I will still
need separate global data in arch/arm/mach-omap2/common.c as
present for
OMAP3/4 and have it set up in omap2_set_globals_ti816x().
3) Differences in PRCM, PLL mean we need a separate clock
data files such as
clock816x_data.c, clockdomains816x.h, powerdomains816x.h etc.
In fact, future
SoCs in 816x (or rather, 81xx) series will share the same organization and
we will be adding to these files instead of growing
omap3xxx_data.c etc. Of course,
I see some special handling done depending upon cpu_is_ and
features in
omap3xxx_clk_init() - but will similar approach scale with
TI816X which has
completely different clock data?
Similarly, we will also need to add TI816X specific hwmods.
4) TI816X series shares similarity with OMAP4 too - e.g.,
various IPs are same,
CM module is closer to OMAP4 than OMAP3. Thus, regaring (1)
above, I could use
OMAP4 code instead of adding new else if. Of course, again,
there are above
mentioned differences too.
With all this, won't it be better if we add TI816X (or
TI81XX) series to exist
on similar lines with OMAP3/4?
Please let me know your thoughts on the above. I can send v3 patch set
incorporating your suggestion of plugging TI816X into OMAP3.
Also, the patch set submitted doesn't have complete set of files yet
(particularly PRCM/clock code), please have a look at code
hosted on Arago.
Below is the link to mach-omap2 folder (2.6.34 at the moment)
http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;
a=tree;f=arch/arm/mach-omap2;h=
7f2c48b8cb3213b3850d0b6ea242c0c53fa5d6fa;hb=refs/heads/ti816x-master
Tony,
Could you please provide your comments on the above?
Thanks
-
Hemant
--
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 v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
* Pedanekar, Hemant hema...@ti.com [101129 09:07]:
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
Though based on Cortex A8, TI816X series has differences in PRCM, PLL,
clock structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For
example, consider following: File - arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret =
omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X
as there are no CM_IDELST registers.
OK, so places like these will need different handling, and should
then be based on some idlest flag that gets set during the init
based on cpu_is_omap24xx() || cpu_is_omap3430() || cpu_is_omap3630().
Tony,
Thanks for clarifications. I have some concerns though:
1) I will eventually end up preceeding existing OMAP3 ckecks to have
cpu_is_34xx() fail. Fo example, in above case, since cpu_is_omap34xx will
be true for ti81xx (which we don't want), I need to update the code as:
if (cpu_is_omap24xx() || (cpu_is_omap34xx() !cpu_is_ti816x()) {
OR
if (cpu_is_omap24xx() || (cpu_is_omap34xx() omap_has_idlest()) {
Then proceed to have a TI816X specific handling in else if part with
cpu_is_ti816x() check.
2) Various module base addresses part of global data are different compared to
OMAP3/4 - e.g., .tap, .ctrl, .prm etc are different. This means I will still
need separate global data in arch/arm/mach-omap2/common.c as present for
OMAP3/4 and have it set up in omap2_set_globals_ti816x().
3) Differences in PRCM, PLL mean we need a separate clock data files such as
clock816x_data.c, clockdomains816x.h, powerdomains816x.h etc. In fact, future
SoCs in 816x (or rather, 81xx) series will share the same organization and we
will be adding to these files instead of growing omap3xxx_data.c etc. Of course,
I see some special handling done depending upon cpu_is_ and features in
omap3xxx_clk_init() - but will similar approach scale with TI816X which has
completely different clock data?
Similarly, we will also need to add TI816X specific hwmods.
4) TI816X series shares similarity with OMAP4 too - e.g., various IPs are same,
CM module is closer to OMAP4 than OMAP3. Thus, regaring (1) above, I could use
OMAP4 code instead of adding new else if. Of course, again, there are above
mentioned differences too.
With all this, won't it be better if we add TI816X (or TI81XX) series to exist
on similar lines with OMAP3/4?
Please let me know your thoughts on the above. I can send v3 patch set
incorporating your suggestion of plugging TI816X into OMAP3.
Also, the patch set submitted doesn't have complete set of files yet
(particularly PRCM/clock code), please have a look at code hosted on Arago.
Below is the link to mach-omap2 folder (2.6.34 at the moment)
http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=tree;f=arch/arm/mach-omap2;h=7f2c48b8cb3213b3850d0b6ea242c0c53fa5d6fa;hb=refs/heads/ti816x-master
Thanks
-
Hemant
--
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 v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
* Pedanekar, Hemant hema...@ti.com [101022 10:58]:
Tony Lindgren wrote on Friday, September 17, 2010 3:55 AM:
* Hemant Pedanekar hema...@ti.com [100811 10:03]:
This patch updates the common machine spcific source files with support
for TI816X.
Note that the nr_irqs is overridden in INTC driver since the number of
IRQs on TI816X are different (128) comapared to other OMAPs (96).
snip
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -419,6 +441,9 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
+ } else if (cpu_is_ti816x()) {
+ ti816x_check_revision();
+ return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
This does not look right, at this point you should just know
the processor class set by the set_globals call.
Please take a look at plat-omap/common.c and add an entry for
omap2_set_globals_ti816x. This gets called very early from the board-*.c
file, so you can initialize things.
Tony,
Do you mean following changes in the patch I sent earlier?
No, I'm mostly wondering how come you can't use cpu_is_omap34xx
for ti816x and then detect based on the values set in
omap2_set_globals. Then cpu_is_ti816x just becomes a set of features.
In general, we should initialize more things in set_globals
if necessary rather than sprinkle cpu_is_omap tests all over
the place to add support for new omaps.
Tony,
Though based on Cortex A8, TI816X series has differences in PRCM, PLL, clock
structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For example,
consider following:
File - arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X as
there are no CM_IDELST registers.
Thanks
-
Hemant--
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 v2 3/6] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Friday, September 17, 2010 3:55 AM:
* Hemant Pedanekar hema...@ti.com [100811 10:03]:
This patch updates the common machine spcific source files with support
for TI816X.
Note that the nr_irqs is overridden in INTC driver since the number of
IRQs on TI816X are different (128) comapared to other OMAPs (96).
snip
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -419,6 +441,9 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
+} else if (cpu_is_ti816x()) {
+ti816x_check_revision();
+return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
This does not look right, at this point you should just know
the processor class set by the set_globals call.
Please take a look at plat-omap/common.c and add an entry for
omap2_set_globals_ti816x. This gets called very early from
the board-*.c
file, so you can initialize things.
Tony,
Do you mean following changes in the patch I sent earlier?
In arch/arm/mach-omap2/common.c --
#if defined(CONFIG_ARCH_TI816X)
static struct omap_globals ti816x_globals = {
-.class = TI816X_CLASS,
+.class = TI81XX_CLASS,
In arch/arm/mach-omap2/id.c --
-void __init ti816x_check_revision(void)
+void __init ti81xx_check_revision(void)
{
u32 idcode;
u16 partnum;
u8 rev;
- idcode = read_tap_reg(TI816X_CONTROL_DEVICE_ID);
+ idcode = read_tap_reg(TI81XX_CONTROL_DEVICE_ID);
partnum = (idcode 12) 0x;
rev = (idcode 28) 0xff;
@@ -490,8 +490,8 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
- } else if (cpu_is_ti816x()) {
- ti816x_check_revision();
+ } else if (cpu_is_ti81xx()) {
+ ti81xx_check_revision();
return;
Note that by default we are building in support for omap2, 3 and 4
and support for all the boards too. This allows booting them
with the same kernel binary for developers and distros.
In general, you might want to see how we added support for omap36xx.
TI816X seems to be very close to omap3 with some extra registers, and
I'm not at all convinced that we even need to set it up as a separate
processor. Basically adding the set_globals + doing the more
accurate detection in id.c should do the trick.
The TI816X series, though similar to Omap architecture wise, has
differences in PRCM, PLL etc w.r.t. Omap3.
Please refer following link for more details about the series:
http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960
Thanks
-
Hemant
--
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 v2 5/6] TI816X: Enable Build for TI816X EVM
Tony Lindgren wrote on Friday, September 17, 2010 3:57 AM: * Hemant Pedanekar hema...@ti.com [100811 10:04]: This patch adds build support for TI816X. This enables building files in mach-omap2 and plat-omap directories. This you can merge into the patch adding the board-*.c file. Tony I will merge patch4 5. Thanks - Hemant -- 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 v2 6/6] TI816X: Add low level debug support
Tony Lindgren wrote on Friday, September 17, 2010 3:58 AM: * Hemant Pedanekar hema...@ti.com [100811 10:04]: This patch adds support for low level debugging on TI816X boards. Currently the support for UART3 console on TI816X EVM is added. --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -66,6 +66,12 @@ omap_uart_lsr:.word 0 beq 34f @ configure OMAP3UART4 cmp \rx, #OMAP4UART4@ only on 44xx beq 44f @ configure OMAP4UART4 +cmp \rx, #TI816XUART1 @ ti816x UART offsets different +beq 81f @ configure UART1 +cmp \rx, #TI816XUART2 @ ti816x UART offsets different +beq 82f @ configure UART2 +cmp \rx, #TI816XUART3 @ ti816x UART offsets different +beq 83f @ configure UART3 cmp \rx, #ZOOM_UART @ only on zoom2/3 beq 95f @ configure ZOOM_UART Would be nice to have the TI816XUART defines in this patch too instead of defining them in some other patch earlier. Tony Can you please refer to the patch @https://patchwork.kernel.org/patch/118855/ The file arch/arm/plat-omap/include/plat/serial.h which has these defined, is part of this patch. Thanks - Hemant -- 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 v2 2/6] TI816X: Update common omap platform files
Tony Lindgren wrote on Friday, September 17, 2010 4:01 AM: * Hemant Pedanekar hema...@ti.com [100811 10:03]: --- a/arch/arm/plat-omap/include/plat/serial.h +++ b/arch/arm/plat-omap/include/plat/serial.h @@ -51,6 +51,11 @@ #define OMAP4_UART3_BASE0x4802 #define OMAP4_UART4_BASE0x4806e000 +/* TI816X serial ports */ +#define TI816X_UART1_BASE 0x4802 +#define TI816X_UART2_BASE 0x48022000 +#define TI816X_UART3_BASE 0x48024000 + /* External port on Zoom2/3 */ #define ZOOM_UART_BASE 0x1000 #define ZOOM_UART_VIRT 0xfa40 These defines should get added by the serial port patch in the series, currently 6/6. Tony I have included them here because the common.c (part of this patch) requires UART base addresses in ti816x_globals while the same serial.h file is also part of patch 6 where TI816XUART definitions are used for LL DEBUG. Thanks - Hemant -- 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 4/6] TI816X: Create board support for TI816X_EVM
Kevin Hilman wrote:
Hemant Pedanekar hema...@ti.com writes:
This patch adds minimal support for TI816X EVM to enable kernel boot.
Signed-off-by: Hemant Pedanekar hema...@ti.com
[...]
+#include linux/kernel.h
+#include linux/init.h
+#include linux/device.h
+#include linux/spi/spi.h
+#include linux/spi/flash.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/i2c/pcf857x.h
+#include linux/i2c/at24.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
+#include linux/phy.h
Looks like most of these headers are not needed for this minimal
support. It's preferred to have a minimal set of headers here and add
them later as needed when the devices are added.
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/irqs.h
+#include plat/mux.h
+#include plat/board.h
+#include plat/common.h
+#include plat/timer-gp.h
+
+static void __init ti8168_evm_init_irq(void)
+{
+omap2_gp_clockevent_set_gptimer(2);
Just curious why GPT2 is used here.
+omap2_init_common_hw(NULL, NULL);
+omap_init_irq();
+}
Kevin
Currently, first timer is reserved on TI816X.
I will cleanup the includes and add timer comment.
Thanks
-
Hemant
--
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/6] TI816X: Update common omap platform files
Hi Kevin, Kevin Hilman wrote: Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X specific additions. Also adds new files for TI816X modules base addresseses and irq definitions. Signed-off-by: Hemant Pedanekar hema...@ti.com --- [...] diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 50fd749..6516cbd 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S @@ -34,7 +34,7 @@ .endm /* - * Unoptimized irq functions for multi-omap2, 3 and 4 + * Unoptimized irq functions for multi-omap2, 3, 4 and ti816x */ #ifdef MULTI_OMAP2 @@ -57,7 +57,8 @@ omap_irq_base: .word 0 [...] +bne 9998f + +/* + * ti816x has additional IRQ pending register. Checking this + * register on omap2 omap3 has no effect (read as 0). + */ +ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ +cmp \irqnr, #0x0 This part makes me a slightly nervous. At least according to the TRMs, this address is undefined on OMAP2 OMAP3 (yet still in the INTC block.) Was this tested on OMAP2/3 hardware and verified to return 0? You might also consider wrapping this section in #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would avoid this extra read. Won't the usage of #ifdef inside MULTI_OMAP2 make things look strange? E.g., #ifdef MULTI_OMAP2 ... #ifdef CONFIG_ARCH_TI816X ... #endif #endif (Specifically, since there is already a custom block present in #else part?) Thanks - Hemant -- 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 3/6] TI816X: Update common OMAP machine specific sources
Kevin Hilman wrote:
Hemant Pedanekar hema...@ti.com writes:
This patch updates the common machine spcific source files with support
for TI816X.
Note that the nr_irqs is overridden in INTC driver since the number of
IRQs on TI816X are different (128) comapared to other OMAPs (96).
Signed-off-by: Hemant Pedanekar hema...@ti.com
One minor issue below...
[...]
@@ -899,10 +899,10 @@ void omap2_clkdm_allow_idle(struct clockdomain
*clkdm)
/*
* XXX This should be removed once TI adds wakeup/sleep
- * dependency code and data for OMAP4.
+ * dependency code and data for OMAP4, TI816X
*/
-if (cpu_is_omap44xx()) {
-WARN_ONCE(1, clockdomain: OMAP4 wakeup/sleep dependency
+if (cpu_is_omap44xx() || cpu_is_ti816x()) {
+WARN_ONCE(1, clockdomain: wakeup/sleep dependency
support is not yet implemented\n);
} else {
if (atomic_read(clkdm-usecount) 0)
@@ -941,9 +941,9 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
/*
* XXX This should be removed once TI adds wakeup/sleep
- * dependency code and data for OMAP4.
+ * dependency code and data for OMAP4, TI816X.
*/
-if (cpu_is_omap44xx()) {
+if (cpu_is_omap44xx() || cpu_is_ti816x()) {
WARN_ONCE(1, clockdomain: OMAP4 wakeup/sleep dependency
Did you want to remove the 'OMAP4' here as you did in the hunk above?
Kevin
Yes, I will fix that in v2.
Thanks
-
Hemant
--
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/6] TI816X: Update common omap platform files
Kevin Hilman wrote: Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X specific additions. Also adds new files for TI816X modules base addresseses and irq definitions. [...] +bne 9998f + +/* + * ti816x has additional IRQ pending register. Checking this + * register on omap2 omap3 has no effect (read as 0). + */ +ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ +cmp \irqnr, #0x0 This part makes me a slightly nervous. At least according to the TRMs, this address is undefined on OMAP2 OMAP3 (yet still in the INTC block.) Was this tested on OMAP2/3 hardware and verified to return 0? I tested this on OMAP3 but haven't verified on OMAP2. I will try to check this on all the variants. You might also consider wrapping this section in #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would avoid this extra read. Yes, that is better. Will add. 9998: ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET] and \irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */ @@ -139,6 +148,35 @@ omap_irq_base: .word 0 .endm #endif +/* + * Optimized irq functions for ti816x + */ + +#ifdef CONFiG_ARCH_TI816X ^ typo? these are case-sensitive, so this part would never be compiled Yes, I will fix this. [...] Kevin Thanks - Hemant -- 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
