RE: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, May 26, 2009 at 08:04:02, Troy Kisky wrote: Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- I fixed 2 bugs in this version. 1. I ensure that buffer size is a multiple of period size. 2. Disable asp rx on shutdown. If it is not disabled on shutdown, you cannot initialize it to different settings. With this version of the patch, the set of underrun messages which were coming on DM644x EVM initially when loopback is started, are not coming. I observed one strange problem on DM644x. Noise is observed when loopback is run at 44100 KHz sample rate. When loopback is restarted, the noise goes away. On DM355 EVM though, I see one or two underrun messages when loopback is started. Recording and playback are working fine without any issues both on DM644x and DM355 EVMs. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Exact DSP on the OMAP3530
Hi,
Thanks for the answer. We have already adapted the MAR settings, this
wasn't the problem.
For example, consider this block from the file CFG_OMAP3530_SHMEM.c:
{
7, /* ENTRY
DSPL1PRAM, /* NAME
0x5cE0, /* ADDRPHYS
0x10E0, /* ADDRDSPVIRT
(Uint32) -1, /* ADDRGPPVIRT
0x8000, /* SIZE
TRUE,/* SHARED
FALSE/* SYNCD
},
Which document tells me, that L1P RAM starts at 0x5cE0 or
0x10E0 respectively?
Regards,
Ingo
Quoting Kamoolkar, Mugdha mug...@ti.com:
Hi,
Please see here:
http://wiki.davincidsp.com/index.php?title=Changing_DSPLink_Memory_Map
At the bottom of the page, we mention that SPRU871.pdf
(http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru871)
has the required MAR address ranges.
Regards,
Mugdha
-Original Message-
From:
davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com] On Behalf Of Ingo
Jenni
Sent: Tuesday, May 26, 2009 3:09 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Exact DSP on the OMAP3530
Hello all,
We are developing applications to be run on the Beagleboard and Gumstix
Overo equipped with a OMAP3530 system-on-chip. The datasheet of the
latter tells us, that it has a TMS320C64x+ DSP on chip. So far so good.
Problems arised however as we wanted to get deeper into the matters and
change the dsplink standard configuration for cache usage. Trying to
find memory base addresses, both the TMS320C64x+ Megamodule Guide as
well as the Cache User Guide refer to the datasheet of the specific device.
Also the Chip Support Library asks for the exact model in order to know
register addresses and things. Now, what is this specific device? The
C6421, C6424, or some custom omap3530 c64x+ processor? We couldn't find
the answer in the OMAP3530 datasheet nor on the davinci wiki...
Any help would be greatly appreciated!
Best regards
Ingo Jenni
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Exact DSP on the OMAP3530
Ok ... you're looking for this, then:
http://focus.ti.com/docs/prod/folders/print/omap3530.html
For memory map, see:
http://focus.ti.com/lit/ug/spruff2a/spruff2a.pdf
Regards,
Mugdha
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Ingo Jenni
Sent: Tuesday, May 26, 2009 1:03 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Exact DSP on the OMAP3530
Hi,
Thanks for the answer. We have already adapted the MAR settings, this
wasn't the problem.
For example, consider this block from the file CFG_OMAP3530_SHMEM.c:
{
7, /* ENTRY
DSPL1PRAM, /* NAME
0x5cE0, /* ADDRPHYS
0x10E0, /* ADDRDSPVIRT
(Uint32) -1, /* ADDRGPPVIRT
0x8000, /* SIZE
TRUE,/* SHARED
FALSE/* SYNCD
},
Which document tells me, that L1P RAM starts at 0x5cE0 or
0x10E0 respectively?
Regards,
Ingo
Quoting Kamoolkar, Mugdha mug...@ti.com:
Hi,
Please see here:
http://wiki.davincidsp.com/index.php?title=Changing_DSPLink_Memory_Map
At the bottom of the page, we mention that SPRU871.pdf
(http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru871)
has the required MAR address ranges.
Regards,
Mugdha
-Original Message-
From:
davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com]
On Behalf Of Ingo
Jenni
Sent: Tuesday, May 26, 2009 3:09 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Exact DSP on the OMAP3530
Hello all,
We are developing applications to be run on the Beagleboard and Gumstix
Overo equipped with a OMAP3530 system-on-chip. The datasheet of the
latter tells us, that it has a TMS320C64x+ DSP on chip. So far so good.
Problems arised however as we wanted to get deeper into the matters and
change the dsplink standard configuration for cache usage. Trying to
find memory base addresses, both the TMS320C64x+ Megamodule Guide as
well as the Cache User Guide refer to the datasheet of the specific device.
Also the Chip Support Library asks for the exact model in order to know
register addresses and things. Now, what is this specific device? The
C6421, C6424, or some custom omap3530 c64x+ processor? We couldn't find
the answer in the OMAP3530 datasheet nor on the davinci wiki...
Any help would be greatly appreciated!
Best regards
Ingo Jenni
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Exact DSP on the OMAP3530
Wow, great. Thanks a lot!
Regards,
Ingo
Quoting Kamoolkar, Mugdha mug...@ti.com:
Ok ... you're looking for this, then:
http://focus.ti.com/docs/prod/folders/print/omap3530.html
For memory map, see:
http://focus.ti.com/lit/ug/spruff2a/spruff2a.pdf
Regards,
Mugdha
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Ingo Jenni
Sent: Tuesday, May 26, 2009 1:03 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Exact DSP on the OMAP3530
Hi,
Thanks for the answer. We have already adapted the MAR settings, this
wasn't the problem.
For example, consider this block from the file CFG_OMAP3530_SHMEM.c:
{
7, /* ENTRY
DSPL1PRAM, /* NAME
0x5cE0, /* ADDRPHYS
0x10E0, /* ADDRDSPVIRT
(Uint32) -1, /* ADDRGPPVIRT
0x8000, /* SIZE
TRUE,/* SHARED
FALSE/* SYNCD
},
Which document tells me, that L1P RAM starts at 0x5cE0 or
0x10E0 respectively?
Regards,
Ingo
Quoting Kamoolkar, Mugdha mug...@ti.com:
Hi,
Please see here:
http://wiki.davincidsp.com/index.php?title=Changing_DSPLink_Memory_Map
At the bottom of the page, we mention that SPRU871.pdf
(http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru871)
has the required MAR address ranges.
Regards,
Mugdha
-Original Message-
From:
davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+mugdha=ti@linux.davincidsp.com] On Behalf Of
Ingo
Jenni
Sent: Tuesday, May 26, 2009 3:09 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Exact DSP on the OMAP3530
Hello all,
We are developing applications to be run on the Beagleboard and Gumstix
Overo equipped with a OMAP3530 system-on-chip. The datasheet of the
latter tells us, that it has a TMS320C64x+ DSP on chip. So far so good.
Problems arised however as we wanted to get deeper into the matters and
change the dsplink standard configuration for cache usage. Trying to
find memory base addresses, both the TMS320C64x+ Megamodule Guide as
well as the Cache User Guide refer to the datasheet of the specific device.
Also the Chip Support Library asks for the exact model in order to know
register addresses and things. Now, what is this specific device? The
C6421, C6424, or some custom omap3530 c64x+ processor? We couldn't find
the answer in the OMAP3530 datasheet nor on the davinci wiki...
Any help would be greatly appreciated!
Best regards
Ingo Jenni
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 02/16] davinci: Support JTAG ID register at any address
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 15, 2009 at 05:58:20PM -0700, Kevin Hilman wrote: The Davinci cpu_is_davinci_*() macros use the SoC part number and variant retrieved from the JTAG ID register to determine the type of cpu that the kernel is running on. Hmm. Can I suggest that we rethink the naming of these things. The CPU is the core itself, not the whole SoC. These should be called soc_is_davinci_xxx(). Yes, I know that we've a lot of SoCs now which do this (eg, PXA) but I think it's something we should _eventually_ get right. (don't take that as an objection to this patch, merely an observation and a todo item.) ok, added to TODO list ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 01/16] davinci: Encapsulate SoC-specific data in a structure
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 05:58:19PM -0700, Kevin Hilman wrote:
+static struct davinci_soc_info davinci_soc_info;
+
+struct davinci_soc_info *davinci_get_soc_info(void)
+{
+return davinci_soc_info;
+}
+EXPORT_SYMBOL(davinci_get_soc_info);
Another point - there's not much point having this function, it provides
no additional benefit over referencing davinci_soc_info directly.
(It's actually a penalty because the overhead of calling it will be
far higher than accessing the structure directly.)
It only makes sense if you plan to do something in this function, but
then it'll make things like the soc type selection stuff more heavy.
IIRC, the initial version from Mark did it the way you suggested,
which requires a global varilable. I specifially asked for an
accessor function since I didn't like the global usage there but I'm
willing to change it back.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: GPIO interrupt problems
Griffis, Brad bgrif...@ti.com writes: FYI, I just added one other topic and an updated block diagram as well: http://tiexpressdsp.com/index.php?title=Configuring_GPIO_Interrupts Brad, Thanks for all your wiki updates for GPIO. This is a huge improvement. Hopefully you have some luck getting better descriptions into the technical docs too. Kevin, I saw some mention of level-sensitive interrupts in one of your patches for GPIO. Could you elaborate on what you're talking about there? To my knowledge we don't have any level-sensitive interrupts. I was talking about the bank interrupt at the AINTC, not any GPIO interrupts. All the AINTC interrupts (except the timer) are currently handled as a level interrupts. IOW, they it masked during the handling. Kevin -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Griffis, Brad Sent: Thursday, May 14, 2009 11:48 AM To: Kevin Hilman Cc: davinci-linux-open-source@linux.davincidsp.com; Alanis, Miguel Angel Subject: RE: GPIO interrupt problems Thanks for bringing this to our attention. I've written the following wiki article about the issue: http://wiki.davincidsp.com/index.php?title=Avoiding_Double_Interrupts_with_the_GPIO_Peripheral I'm going to send that link to the owner's of the GPIO user's guides in hopes of getting some kind of warning put into the guide. If nothing else though, at least it is now documented somewhere! Brad -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, May 13, 2009 4:17 PM To: Griffis, Brad Cc: David Brownell; Narnakaje, Snehaprabha; davinci-linux-open-source@linux.davincidsp.com; Alanis, Miguel Angel Subject: Re: GPIO interrupt problems Griffis, Brad bgrif...@ti.com writes: On Monday 11 May 2009, Narnakaje, Snehaprabha wrote: Kevin, Dave, We checked this with the hardware team - The GPIO module does't seem to have the ability to enable/disable the direct/banked GPIO[0:9] at the GPIO Level (it does via the SET register, but it doesn't prevent triggering both Interrupts to the CPU). But the option to mask between the direct GPIO interrupts and the bank0 for GPIO[15:0] does exist at the ARM level. That's not quite clear... if SET_FALLING.BIT(5) has enabled one edge and SET_RISING.BIT(1) enables another edge on a different GPIO, and BANK0 is enabled in the AINTC, then BANK0 can be triggered by either of those two events, right? (That's what we expect, and I've seen no reason to think otherwise. BINTEN.BIT(0) set.) If we then toss direct GPIO5 and GPIO1 IRQs into the mix, and they're both enabled in the AINTC ... you're saying both should arrive, yes? Triggered according to those RISING/FALLING settings? Or always active-low? If the RISING/FALLING registers are all clear, but the direct GPIO5 and GPIO1 IRQs are enabled in AINTC, are you saying we still get a BANK0 interrupt? You need to setup either a rising or falling edge interrupt in order for an interrupt to be generated. If you don't set either one then you will not generate any interrupts (bank or individual). I think the ultimate issue here is that the output of the interrupt generation is tied directly to both the bank interrupt and the individual interrupt. That means that the gating of this interrupt is happening at the AINTC level. Therefore if you have both the individual interrupt and the bank interrupt enabled at the AINTC level then you will be interrupted twice for that specific interrupt. Yes, this is the root of the problem. And even more to the point, I discovered this via experimentation because it is far from clear in the docs how this works. So, for example, if at the AINTC level you enable the individual interrupt, but disable the bank interrupt, then you would be fine (i.e. only one interrupt generated). However, if some other code in the system turns on the bank interrupt then you will get interrupted twice for a given interrupt (once for the individual and once for the bank). You could solve this issue a few different ways. (I have not so much as opened the driver so sorry that I have no idea how easy/difficult these approaches will be to implement.) 1. Use only individual interrupts for GPIO[9:0] and don't let anyone in the system use GPIO[15:10]. 2. Use only bank interrupts for GPIO[15:0] and don't let anyone use the individual interrupts (GPIO[9:0]). This is the current approach. 3. Use a mix of bank interrupts and individual interrupts, but whenever an individual interrupt gets used you plug the corresponding bank interrupt with a NOP. The first 2 solutions work by doing the gating at the AINTC level and only allowing one of the interrupts to be enabled, thereby making it impossible to be interrupted twice. Those solutions will be the most efficient from a cycle perspective.
Re: [PATCH 01/16] davinci: Encapsulate SoC-specific data in a structure
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 05:58:19PM -0700, Kevin Hilman wrote:
+static struct davinci_soc_info davinci_soc_info;
+
+struct davinci_soc_info *davinci_get_soc_info(void)
+{
+return davinci_soc_info;
+}
+EXPORT_SYMBOL(davinci_get_soc_info);
Another point - there's not much point having this function, it provides
no additional benefit over referencing davinci_soc_info directly.
(It's actually a penalty because the overhead of calling it will be
far higher than accessing the structure directly.)
It only makes sense if you plan to do something in this function, but
then it'll make things like the soc type selection stuff more heavy.
Any objection to keeping an inline accessor function in
mach/common.h This allows current code to work, but eliminates the
function call overhead.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] davinci GPIO fixes for next merge window
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 15, 2009 at 04:24:08PM -0700, Kevin Hilman wrote: Some misc. DaVinci GPIO fixes for 2.6.31 merge window. The following changes since commit 5d41343ac88eeddd25dc4ffb7050c9095c41a70d: Linus Torvalds (1): Merge branch 'for_linus' of git://git.kernel.org/.../tytso/ext4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git upstream/fixes Series looks fine to me. OK, pushing to for-next branch of DaVinci git. Pull request coming soon. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/11] davinci: more SoCs and platform updates
Kevin Hilman khil...@deeprootsystems.com writes: DaVinci platform updates for next merge window. Depends on recently posted series: [PATCH 0/2] davinci GPIO fixes for next merge window Summary of changes: - add support for DM355 SoC and its evaluation board (EVM) - add support for DM6467 SoC and its evaluation board (EVM) - add support for DM6446-based SFFSDR board - platform device additions for common devices (watchdog, EMAC, MMC) This series has been updated based on review comments and pushed to the for-next branch of DaVinci git. Pull request coming soon. Updates based on review comments: - ETH_ALEN updates. Also dropped MAC_BUF() and print_mac() in favor of using new printk(%pM) format - dropped usage of new cmdline arguments in SFFSDR board file - fixed #include groupings - removed clk_put() for clocks that are always enabled - dropped custom saving of machine # in favor of __machine_arch_type Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/16] davinci: generalize common SoC infrastructure
Kevin Hilman khil...@deeprootsystems.com writes: In preparation for more SoCs in the DaVinci family, generalize common SoC features into a 'struct soc_info' so that common init/setup code can be used across all SoCs in the DaVinci family. An additional goal is to be able to boot a single kernel binary across all SoCs in the DaVinci family. Depends on recently posted series: - [PATCH 0/2] davinci GPIO fixes for next merge window - [PATCH 00/11] davinci: more SoCs and platform updates This series has been updated, incoporating review comments and pushed to the for-next branch of Davinci git (pull request coming soon.) Updates: - dropped soc_info accessor function in favor of direct access - updated description of 1/16 to clarify some confusion Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/3] davinci: add SRAM allocator
Kevin Hilman khil...@deeprootsystems.com writes: Provide a generic SRAM allocator using genalloc, and vaguely modeled after what AVR32 uses. This is the last of the davinci updates for the 2.6.31 merge window and applies on top of the previous 3 series: - [PATCH 0/2] davinci GPIO fixes for next merge window - [PATCH 00/11] davinci: more SoCs and platform updates - [PATCH 00/16] davinci: generalize common SoC infrastructure Upon review/acceptance, I'll merge all of them into a single branch for pulling. This series pushed to for-next branch of DaVinci git (pull request coming soon) Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Add input arguments to codec_engine scale example
Hi all.
I would like to add an input parameter to the ISCALE_InArgs structure
in codec_engine's scale example.
I just added a:
XDAS_Int32 newArg
to the structure:
typedef struct ISCALE_InArgs {
XDAS_Int32 inBufSize;
XDAS_Int32 outBufSize;
XDAS_Int32 inBufValidBytes;
XDAS_Int32 newArg ;
} ISCALE_InArgs;
in the iscale.h file. But it only works when I do not put it in the
last place of the member list in the structure.
Does it only works with 3 args? I think I'm missing something simple...
Some place to define the number of arguments to be passed or the
maximum size of the memory used in the message to the DSP, maybe?
Thanks in advance.
Best regards.
Jos
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Add input arguments to codec_engine scale example
The size of that struct is implicitly built into the
ti.sdo.ce.examples.extensions.scale package. Specifically, scale_stubs.c
(the ARM-side code responsible for marshalling the args into a msg for the
DSP-side) needs to be rebuilt if that struct changes.
I think you need to rebuild the extensions/scale directory - then the DSP
Server - then the ARM-side application so the new stubs/skels know about the
new size of that struct.
One better - if you're using a new release of Codec Engine, I'd recommend the
IUNIVERSAL interface for algs that don't match one of the existing interfaces,
rather than the 'scale' approach:
http://tiexpressdsp.com/index.php?title=Getting_started_with_IUNIVERSAL
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
José María Cubero Muñoz
Sent: Tuesday, May 26, 2009 12:48 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Add input arguments to codec_engine scale example
Hi all.
I would like to add an input parameter to the ISCALE_InArgs structure in
codec_engine's scale example.
I just added a:
XDAS_Int32 newArg
to the structure:
typedef struct ISCALE_InArgs {
XDAS_Int32 inBufSize;
XDAS_Int32 outBufSize;
XDAS_Int32 inBufValidBytes;
XDAS_Int32 newArg ;
} ISCALE_InArgs;
in the iscale.h file. But it only works when I do not put it in the last place
of the member list in the structure.
Does it only works with 3 args? I think I'm missing something simple... Some
place to define the number of arguments to be passed or the maximum size of the
memory used in the message to the DSP, maybe?
Thanks in advance.
Best regards.
José
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Pull request: davinci updates for next merge window
The following changes since commit 59a3759d0fe8d969888c741bb33f4946e4d3750d: Linus Torvalds (1): Linux 2.6.30-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git for-next Chaithrika U S (1): davinci: use 32-bit accesses for low-level debug macros David Brownell (4): davinci: gpio irq enable tweaks davinci: remove remnants of IRAM allocator davinci: soc-specific SRAM setup davinci: add SRAM allocator Hugo Villeneuve (1): davinci: DM644x: add support for SFFSDR board Kevin Hilman (9): davinci: fixups for banked GPIO interrupt handling davinci: add platform support for watchdog timer davinci: DM355: add base SoC and board support davinci: DM646x: add base SoC and board support davinci: update davinci_all_defconfig for dm355, dm6467 davinci: MMC platform support davinci: EMAC platform support davinci: cleanup: move dm355 UART2 define to dm355.c davinci: defconfig update: add EMAC Mark A. Greer (17): davinci: support different UART bases for zImage uncompress davinci: Encapsulate SoC-specific data in a structure davinci: Support JTAG ID register at any address davinci: Add clock init call to common init routine davinci: Add support for multiple PSCs davinci: Move pinmux setup info to SoC infrastructure davinci: Move interrupt ctlr info to SoC infrastructure davinci: Add base address and timer flexibility davinci: Add watchdog base address flexibility davinci: Make GPIO code more generic davinci: Move serial platform_device into SoC-specific files davinci: Move emac platform_data to SoC-specific files davinci: Remove unused i2c eeprom_read/write routines davinci: Factor out emac mac address handling davinci: Integrate cp_intc support into low-level irq code davinci: Add compare register support to timer code davinci: Move PINMUX defines to SoC files Sergei Shtylyov (1): davinci: INTC: add support for TI cp_intc Troy Kisky (1): davinci: interrupts: get_irqnr_and_base: save an instruction arch/arm/Kconfig |1 + arch/arm/configs/davinci_all_defconfig | 21 +- arch/arm/mach-davinci/Kconfig | 47 ++ arch/arm/mach-davinci/Makefile | 13 +- arch/arm/mach-davinci/board-dm355-evm.c| 298 arch/arm/mach-davinci/board-dm355-leopard.c| 296 arch/arm/mach-davinci/board-dm644x-evm.c | 68 +- arch/arm/mach-davinci/board-dm646x-evm.c | 262 +++ arch/arm/mach-davinci/board-sffsdr.c | 189 + arch/arm/mach-davinci/clock.c | 10 +- arch/arm/mach-davinci/clock.h |4 + arch/arm/mach-davinci/common.c | 108 +++ arch/arm/mach-davinci/cp_intc.c| 161 + arch/arm/mach-davinci/devices.c| 211 ++ arch/arm/mach-davinci/dm355.c | 730 arch/arm/mach-davinci/dm644x.c | 204 ++- arch/arm/mach-davinci/dm646x.c | 636 + arch/arm/mach-davinci/gpio.c | 63 +- arch/arm/mach-davinci/id.c | 116 --- .../mach-davinci/include/mach/board-dm6446evm.h| 20 - arch/arm/mach-davinci/include/mach/common.h| 55 ++- arch/arm/mach-davinci/include/mach/cp_intc.h | 57 ++ arch/arm/mach-davinci/include/mach/cputype.h | 29 +- arch/arm/mach-davinci/include/mach/debug-macro.S | 31 +- arch/arm/mach-davinci/include/mach/dm355.h | 22 + arch/arm/mach-davinci/include/mach/dm644x.h|1 + arch/arm/mach-davinci/include/mach/dm646x.h| 26 + arch/arm/mach-davinci/include/mach/edma.h |4 - arch/arm/mach-davinci/include/mach/emac.h | 36 + arch/arm/mach-davinci/include/mach/entry-macro.S | 25 +- arch/arm/mach-davinci/include/mach/gpio.h | 14 +- arch/arm/mach-davinci/include/mach/irqs.h |3 + arch/arm/mach-davinci/include/mach/memory.h|1 - arch/arm/mach-davinci/include/mach/mmc.h | 33 + arch/arm/mach-davinci/include/mach/mux.h | 16 - arch/arm/mach-davinci/include/mach/psc.h |8 +- arch/arm/mach-davinci/include/mach/serial.h|4 +- arch/arm/mach-davinci/include/mach/sram.h | 27 + arch/arm/mach-davinci/include/mach/time.h | 35 + arch/arm/mach-davinci/include/mach/uncompress.h| 19 +- arch/arm/mach-davinci/io.c | 38 - arch/arm/mach-davinci/irq.c| 217 +-- arch/arm/mach-davinci/mux.c| 24 +- arch/arm/mach-davinci/psc.c| 32 +-
RE: SRAM allocator(s!)
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Sunday, May 24, 2009 10:52 AM To: Troy Kisky Cc: Koen Kooi; davinci-linux-open-source@linux.davincidsp.com Subject: Re: SRAM allocator(s!) Troy Kisky wrote: Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream? I've been asking that question to TI engineers for a while now and the only responses usually are That's a good idea! and We don't know if it will be accepted. It shouldn't be too hard to get it pushed into Greg KH's staging tree... regards, Koen My personal bias is against CMEM being in the kernel. I dislike pools of fixed size in an general purpose allocator. I think there are better ways to solve fragmentation problems. Actually, I do not understand why CMEM is always used with all these pools and not with one big heap, where any size chunks can be allocated from. I am using a CMEM compatible heap allocator with Davinci and OMAP3 for a couple of years now and fragmentation never was a problem. FYI, the insmod'er of CMEM can choose to have all pools and no heap, or all heap and no pools, or a mix of both. You may not experience fragmentation of the heap in your personal experience, but there is ample research that no heap-based allocator is immune to fragmentation issues, given the right (or wrong) set of allocation pattern. Having said that, CMEM is not really there to solve any fragmentation issue, it's there to provide physically-contiguous buffers of memory (original intent), and it has been exploited to allow user-mode programs access to general cache maintenance and virtual-to-physical translations of non-CMEM addresses. Regards, - Rob What I think should go into the kernel is a general (heap based) allocator that can supply DSP/DMA mem in large quantities, I agree it may not be CMEM with pools in the end. Regards, Vladimir ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
