* Docs for the new style dpalloc/hostalloc patch.
@ 2002-12-18 15:01 Pantelis Antoniou
2002-12-19 8:04 ` Joakim Tjernlund
0 siblings, 1 reply; 4+ messages in thread
From: Pantelis Antoniou @ 2002-12-18 15:01 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Docs for the new style dpalloc/hostalloc patch.
2002-12-18 15:01 Docs for the new style dpalloc/hostalloc patch Pantelis Antoniou
@ 2002-12-19 8:04 ` Joakim Tjernlund
2002-12-19 10:39 ` Pantelis Antoniou
0 siblings, 1 reply; 4+ messages in thread
From: Joakim Tjernlund @ 2002-12-19 8:04 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Docs for the new style dpalloc/hostalloc patch.
2002-12-19 8:04 ` Joakim Tjernlund
@ 2002-12-19 10:39 ` Pantelis Antoniou
2002-12-19 11:03 ` Joakim Tjernlund
0 siblings, 1 reply; 4+ messages in thread
From: Pantelis Antoniou @ 2002-12-19 10:39 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
Joakim Tjernlund wrote:
>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
>
Hi
Yes unfortunately is too big, the complexity will pay off
on the upcoming patches, that will allow to use every last bit
of the dpram.
Just enable the options when compiling.
Every current driver that uses the old-style interface
should work without a problem.
I would be very interested to see them used your updated enet driver.
Regards
Pantelis
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Docs for the new style dpalloc/hostalloc patch.
2002-12-19 10:39 ` Pantelis Antoniou
@ 2002-12-19 11:03 ` Joakim Tjernlund
0 siblings, 0 replies; 4+ messages in thread
From: Joakim Tjernlund @ 2002-12-19 11:03 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
> Joakim Tjernlund wrote:
>
> >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
> >
>
> Hi
>
> Yes unfortunately is too big, the complexity will pay off
> on the upcoming patches, that will allow to use every last bit
> of the dpram.
>
> Just enable the options when compiling.
> Every current driver that uses the old-style interface
> should work without a problem.
>
> I would be very interested to see them used your updated enet driver.
Works just fine on my board!
Anyone else testing this?
Jocke
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-12-19 11:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-18 15:01 Docs for the new style dpalloc/hostalloc patch Pantelis Antoniou
2002-12-19 8:04 ` Joakim Tjernlund
2002-12-19 10:39 ` Pantelis Antoniou
2002-12-19 11:03 ` Joakim Tjernlund
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox