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 [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 >> >> 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 [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: [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
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: [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 > > 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 [110921 17:00]:
>> Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
>>
>>> * Hemant Pedanekar [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 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 [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: [PATCH v2 1/3] TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
> * Hemant Pedanekar [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] 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 [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: 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 Saturday, September 17, 2011 7:06 AM: > device driver) > > * DebBarma, Tarun Kanti [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 > 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 [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" writes:
>
>> Hilman, Kevin wrote on Tuesday, August 30, 2011 6:03 AM:
>>
>>> Hemant Pedanekar 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
>>>
>>> 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: [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 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
>
> [...]
>
>> +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: [RFC PATCH v2 5/6] TI81XX: Add minimal hwmod data
Hilman, Kevin wrote on Tuesday, August 30, 2011 6:03 AM: > Hemant Pedanekar 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 > > 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: 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 : > 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 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 [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 2/3] TI814X: Add cpu type macros and detection support
Tony Lindgren wrote on Monday, August 15, 2011 8:47 PM: > * Hemant Pedanekar [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 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] omap: timer: Set dmtimer used as clocksource in autoreload mode
Tony Lindgren wrote on Wednesday, August 10, 2011 5:21 PM:
> * Hemant Pedanekar [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
>> ---
>> 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 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 >> --- >> 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 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 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
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
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 > --- > 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) > +#defi
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 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 [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 [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" writes: > >> Hi Kevin, >> >> Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: >> >>> Hi Hemant, >>> >>> Hemant Pedanekar 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 4/4] TI816X: Add low level debug support
Hilman, Kevin wrote on Saturday, January 22, 2011 5:21 AM: > Hemant Pedanekar 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 > > 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 2/4] TI816X: Update common OMAP machine specific sources
Kevin,
Kevin Hilman wrote on Saturday, January 22, 2011 5:19 AM:
> Hemant Pedanekar 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
>> ---
>> 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 unuse
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 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 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
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 [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 Wednesday, January 05, 2011 4:56 AM: > * Paul Walmsley [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). 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 [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 Saturday, December 11, 2010 7:21 AM: > * Pedanekar, Hemant [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
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
Pedanekar, Hemant wrote on Wednesday, December 01, 2010 7:17 AM:
> Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
>
>> * Pedanekar, Hemant [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 [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 [101022 10:58]:
>> Tony Lindgren wrote on Friday, September 17, 2010 3:55 AM:
>>
>>> * Hemant Pedanekar [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).
>>>
>>>
>>>
>>>> --- 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 [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).
>
>
>
>> --- 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 2/6] TI816X: Update common omap platform files
Tony Lindgren wrote on Friday, September 17, 2010 4:01 AM: > * Hemant Pedanekar [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 v2 6/6] TI816X: Add low level debug support
Tony Lindgren wrote on Friday, September 17, 2010 3:58 AM: > * Hemant Pedanekar [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 5/6] TI816X: Enable Build for TI816X EVM
Tony Lindgren wrote on Friday, September 17, 2010 3:57 AM: > * Hemant Pedanekar [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 2/6] TI816X: Update common omap platform files
Hi Kevin, Kevin Hilman wrote: > Hemant Pedanekar 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 >> --- [...] >> >> 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 4/6] TI816X: Create board support for TI816X_EVM
Kevin Hilman wrote:
> Hemant Pedanekar writes:
>
>> This patch adds minimal support for TI816X EVM to enable kernel boot.
>>
>> Signed-off-by: Hemant Pedanekar
>
> [...]
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> 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
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +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
Kevin Hilman wrote: > Hemant Pedanekar 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
RE: [PATCH 3/6] TI816X: Update common OMAP machine specific sources
Kevin Hilman wrote:
> Hemant Pedanekar 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
>
> 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
