Re: [00/02] MPC5200 Bestcomm platform driver

[Sylvain Munaut <tnt@246tNt.com>]

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