Docs for the new style dpalloc/hostalloc patch.

Joakim Tjernlund joakim.tjernlund at lumentis.se
Thu Dec 19 19:04:02 EST 2002


Hi

This looks good to me. It's only a bit big, but I guess that's the price one
has to pay. I haven't tested it yet though.

    Jocke
>
>
>
> Hello.
>
> Since the first mail I've sent hit the mailing list limit
> and got deleted, the following with only the patches
> are rather confusing.
>
> Here are some pointers about what the patch does and the
> rational behind it's creation...
>
> The patch is against the current top linuxppc_2_4_devel tree,
> and provides better functions for allocation of dual ported
> memory and uncached host memory for the 8xx family of processors.
>
> The problem with the current allocation routines are
> that are very simplistic. They only keep a top
> pointer to the next memory range to allocate
> and never free the allocated memory.
>
> This is fine for any drivers compiled into the kernel,
> but brakes down when you want to have your driver
> as a module.
>
> The requirement to have a driver as a module is
> peculiar when talking about so small systems, but
> it is the only way if you want to avoid GPLing all
> your design.
>
> As I mentioned we will submit all changes done to
> the kernel and the standard drivers, but
> we cannot do that for our proprietary hardware.
>
> The new routines get around the problem by
> managing the memory properly.
>
> That is the memory allocated can be freed and
> then reused for any following requests.
>
> The implementation is done by using something
> called a remote heap.
> It is called remote because in constrast to
> the normal heap management schemes we cannot
> use the memory we allocate to implement lists
> holding the allocated and free region.
> A nice side effect is that there is no overhead
> on the managed address ranges.
>
> The enable switches are under 'MPC8xx CPM Options'.
> If you don't enable then everything works the same as
> before.
>
> The functions are:
>
> void *new_m8xx_cpm_dpalloc(unsigned int size, const char *owner);
>
>    Allocate the given amount of memory from the dual port ram
>    and assign a text string describing the owner.
>    A future patch that will add a proc interface to the cpm.
>    The size is rounded to the next 8 bytes.
>
>    Returns the va of the allocated address on success.
>    It is always aligned to an 8 byte boundary.
>    NULL otherwise
>
> int new_m8xx_cpm_dpfree(void *start);
>
>    Free the previously allocated memory.
>    Returns the size of the freed block, or -EINVAL in
>    case the start argument does not lie in any allocated
>    block.
>
> void *new_m8xx_cpm_dpalloc_fixed(void *start, int size,
>                                   const char *owner);
>
>    The same thins as the previous dpalloc function, but
>    you can request memory from a specific address.
>    In a future patch, this is used to allocate the
>    microcode dpram areas.
>
> void *new_m8xx_cpm_hostalloc(unsigned int size, const char *owner);
>
>    Allocate the given amount of uncached host memory for use by
>    the cpm. Typically this memory will used for FIFOs, BDs and
>    such when the cost of explicitly calling the invalidate_dcache
>    and flush_dcache function is provibitive.
>    If no available free memory is already present, it will allocate
>    enough pages to satisfy the request. These pages
>    will be tracked and when a later free releases all the
>    memory allocated from them, they will be freed.
>    Return NULL on out of memory.
>
> int   new_m8xx_cpm_hostfree(void *start);
>
>    Frees the given memory by a previous call to the hostalloc function.
>    Returns the size of the free memory block or -EINVAL on error.
>
>
> That's it, please contact my for any more info.
>
> Pantelis
>
>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-embedded mailing list