Andrey Volkov wrote: >> - I never really liked to have multiple "type" of buffer descriptors >>depending of the number of pointers in them. "standard" task have >>either 1 or 2 pointers true but I have custom tasks with 3 so I need a >>subtmitbuffer3 ... Not very extensible imho. I think there is no problem >>as defining the descriptor structure with an array of pointer and then >>just allocate the good size at init. Whoever use them must anyway know >>the number of pointer to fill. > > Accepted. But I think it will be better to start from another end: > allow everyone to create him/here self task (variable buffers number > will consequence of that).
Sure, see my comments about your bestcomm microcode doc in my preceing mail. >> - When I started to clean up bescomm a while ago, the only thing I >>really got done was a rewrite of the SRAM allocator that supports the >>freeing of block at little overcost. I'll try to find it and send it to you. > > I agree with you, sram_free is required function, especially if > sdma-depended drivers will loaded/unloaded as modules. But I also agree > with Dale's comments: What to do with fragmentations? I could lightly > imagine situation, when after some load/unload iterations we receive > ENOMEM :(. Sure, fragmentation is a problem but there is no 'easy' way to prevent that ... It's not perfet but better than nothing IMHO. >> - I like the separation of phys/virt ;) > > I'd like it too :), but I had a pa/va headache when setting up > task/var/inc tables, so everyone, who will write sdma related code must > be very careful. Anyway, they must be careful ;) Bestcomm is like a very fragile balance between numerous task competing for some dma transfers. Without caution, one will starve the others ... Sylvain