Thanks Dan for your explaination. I am linking multiple BDs only but no of BDs are very large in my case so I am allocating the memory and updating the BD pointer for all BDs. I am thinking of using mem start parameter option. I even tried using __get_free_page instead of using cpm_hostalloc() but that also did not help. If i use mem= option as kernel command line argument then I will have to just ioremap() this reserved address in my driver and start accessing the memory. I do not have to worry about cache related things. right?
Thanks again, Prashant On 8/9/05, Dan Malek <dan at embeddededge.com> wrote: > > On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote: > > > Since the existing UART/ethernet drivers are using cpm_hostalloc() so > > I am also using the same function. > > As I have said too many times before, cpm_hostalloc() is only used > to allocate small memory regions that would otherwise be wasteful > with the normal Linux memory allocators. This function does not > do anything special with the memory, aside from allowing us have > multiple drivers share a page for efficiency. > > > Then can I use kmalloc() to alloc > > such huge memory. > > Yes, and you should. > > > If at all I have to configure BATx to just test how > > it behaves. > > No, that's not all you have to do. It's not a trivial process > easily described here. > > > ..... One more thing is that > > totally I am allocating about 1MB memory in a chunk of 200K. > > I can't comprehend a reason why you need to allocate so much > space in a driver, especially for CPM devices. The driver is just > a temporary FIFO for data flowing to/from other consumer/producers > of the data in the system. If the software above a driver needs > that kind of buffering, it should manage that itself. > > If you do need so much space, use the beauty of the CPM and > link multiple BDs with reasonable sized buffers more easily > managed by the existing Linux allocators. > > The other alternative is just reserve memory using the 'mem=' > start parameter so it isn't know to Linux, and manage entirely > yourself. > > > -- Dan > >
