On Thu, Jul 1, 2010 at 13:30, Robin Getz wrote: > On Wed 30 Jun 2010 17:46, Mike Frysinger pondered: >> On Wed, Jun 30, 2010 at 16:09, Robin Getz wrote: >> > Adding run time locking is a better way to do resource management (same >> > way we >> > do L1 data, or L1 instruction) than a compile time configuration. IMO >> >> which we have via the sram allocator, but the Kconfig option expands >> into removing struct members and shrinking code > > For scratch? I don't think any such thing exists, since scratchpad is only 4k. > > If you mean a single int in the kernel that keeps track of is L1_scratch being > used or not, then -- yeah, it's worth it. (IHMO).
we do have an API for the scratch pad. it is just poorly named. l1sram_init() l1sram_alloc() l1sram_alloc_max() l1sram_free() >> i have a problem with the >> #ifdef in the C code tying unrelated options together. the removal of >> APP_STACK_L1 made Barry change all the ifdefs from the logical >> binding: >> >> #ifdef CONFIG_APP_STACK_L1 >> /* do stuff related to APP STACK L1 */ >> #endf >> >> to the illogical binding: >> #ifndef CONFIG_EXCEPTION_L1_SCRATCH >> /* do stuff related to APP STACK L1 */ >> #endif > > I guess I would think (and I might be wrong) that we want to get rid of those > bindings.. > > /* if L1_scratch is avaliable - do stuff related to APP STACK L1 */ so you want to remove all the ifdefs and have the code always be compiled. i'm fine with that. >> so if we add another L1 scratch option, the C code would have to change to: >> #if !defined(CONFIG_EXCEPTION_L1_SCRATCH) && >> !defined(CONFIG_SOME_NEW_L1_SCRATCH_FEATURE) >> /* do stuff related to APP STACK L1 */ >> #endif > > No, it just does the same check if L1_scratch is avaliable. > > Just like the rest of L1 - what ever grabs it first - gets to use it. (which > will be the kernel exception, if that is what the Kconfig says to do). there is already resource checking going on. if you try to run a FLAT binary that wants an 8k stack in L1 scratch you'll get an error message. but the CONFIG_EXCEPTION_L1_SCRATCH option does not use the L1 allocator at the moment; presumably that should be changed at boot. -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
