MichaÅ Nazarewicz wrote:
> > I mean the ability to move allocated buffers to free more
> > contiguous space. To support this in CMA the API(s) would have to
> > change.
> > * A buffer's physical address cannot be used to identify it as the
> > physical address can change.
> > * Pin/unpin functions would have to be added so that you can pin a
> > buffer when hardware uses it.
> > * The allocators needs to be able to inform CMA that they have
> > moved a buffer. This is so that CMA can keep track of what memory
> > is free so that it can supply the free memory to the kernel for
> > temporary use there.
>
> I don't think those are fundamentally against CMA and as such I see
> no reason why such calls could not be added to CMA. Allocators that
> do not support defragmentation could just ignore those calls.
Sounds good.
> In particular, a cma_alloc() could return a pointer to an opaque
> struct cma and to get physical address user would have to pin the
> buffer with, say, cma_pin() and then call cma_phys() to obtain
> physical address.
I think cma_phys() is redundant, cma_pin() can return the physical
address, that's how we did it in hwmem.
> I'm only wondering if treating "unpin" as "free" and pin as another
> "alloc" would not suffice?
I don't understand. Wouldn't you lose all the data in the buffer
when you free it? How would we handle something like the desktop
image which is blitted to the display all the time but never
changes? We'd have to keep a scattered version and then copy it
into a temporary contiguous buffer which is not optimal
performance wise. The other alternative would be to keep the
allocation but then we would get fragmentation problems.
/Johan Mossberg
ÿô.nlj·ÿ±ég¬±¨ Âaþé» ®&Þ)î¦þ)íèh™¨è&£ù¢¸ÿŠæ¢ú» þÇþm§ÿÿÃÿ–)î¦þŠàb‚nö¥yʦ‰bs(§ ©Ú¯ìáÿÿ÷%½ëÊs÷'þ×j)ÿým£ÿÝ{ÿ’ö+ƒÿÞ¨¥þKÚOèÿ