RFC cpm2_devices DPRAM resource
Allen Curtis wrote: >>> Should the DPRAM appear as it's own platform_device? >> >> >> No. >> >>> Option 1) Specify the portion of the DPRAM used by each device with >>> that platform_device definition. (current) >> >> >> You mean the parameter space? That's different from DPRAM. >> >>> Option 2) Define the whole DPRAM region as its own platform_device >>> entry. Move the device DPRAM information to the device specific >>> platform structure. >> >> >> How is this any different from using the dpalloc() as it is today? >> >> The problem is that for the few standard devices we publicly support in >> Linux it is easy to think of DPRAM as a "general" resource. However, for >> more challenging devices and implementation, there are sometimes specific >> regions of DPRAM that must be used with various additional restrictions. >> For many of the "real world" devices I have done, drivers would manage >> their own, well known, DPRAM areas. It isn't something that is easy >> to generalize or configure in advance. >> > Time for code. > > - Allen > FWIW the current dpalloc implementation supports "carving out" the usable dpram out of the whole. I mean you could conceivably not "give" the driver specific dpram areas to the generic allocator. This should be a per platform configuration item. The current code just doesn't bother... Regards Pantelis
RFC cpm2_devices DPRAM resource
On Jun 16, 2005, at 1:45 PM, Allen Curtis wrote: > Should the DPRAM appear as it's own platform_device? No. > Option 1) Specify the portion of the DPRAM used by each device with > that platform_device definition. (current) You mean the parameter space? That's different from DPRAM. > Option 2) Define the whole DPRAM region as its own platform_device > entry. Move the device DPRAM information to the device specific > platform structure. How is this any different from using the dpalloc() as it is today? The problem is that for the few standard devices we publicly support in Linux it is easy to think of DPRAM as a "general" resource. However, for more challenging devices and implementation, there are sometimes specific regions of DPRAM that must be used with various additional restrictions. For many of the "real world" devices I have done, drivers would manage their own, well known, DPRAM areas. It isn't something that is easy to generalize or configure in advance. Thanks. -- Dan
RFC cpm2_devices DPRAM resource
On Jun 16, 2005, at 1:58 PM, Kumar Gala wrote: > Well, we already have an allocator for general dpram memory. I'm not > really sure how this would help beyond reducing the fact that we may > ioremap() regions more than once. I think the better solution there > is to look at the patches that have been made to ioremap() to return > the same virtual addresses if you are remapping a region of physical > memory that already has a mapping. I agree. Specifically for 85xx, we have to make sure we have CAMs mapping these spaces and ioremap() will reuse them. -- Dan
RFC cpm2_devices DPRAM resource
>> Should the DPRAM appear as it's own platform_device? > > No. > >> Option 1) Specify the portion of the DPRAM used by each device with >> that platform_device definition. (current) > > You mean the parameter space? That's different from DPRAM. > >> Option 2) Define the whole DPRAM region as its own platform_device >> entry. Move the device DPRAM information to the device specific >> platform structure. > > How is this any different from using the dpalloc() as it is today? > > The problem is that for the few standard devices we publicly support in > Linux it is easy to think of DPRAM as a "general" resource. However, > for > more challenging devices and implementation, there are sometimes > specific > regions of DPRAM that must be used with various additional > restrictions. > For many of the "real world" devices I have done, drivers would manage > their own, well known, DPRAM areas. It isn't something that is easy > to generalize or configure in advance. > Time for code. - Allen
RFC cpm2_devices DPRAM resource
On Jun 16, 2005, at 12:45 PM, Allen Curtis wrote: > Slightly different question than the current thread: > > Should the DPRAM appear as it's own platform_device? > Option 1) Specify the portion of the DPRAM used by each device with > that platform_device definition. (current) > > Option 2) Define the whole DPRAM region as its own platform_device > entry. Move the device DPRAM information to the device specific > platform structure. > > Would this help with a general dpalloc() implementation? It would > reduce the number of ioremap() regions. Well, we already have an allocator for general dpram memory. I'm not really sure how this would help beyond reducing the fact that we may ioremap() regions more than once. I think the better solution there is to look at the patches that have been made to ioremap() to return the same virtual addresses if you are remapping a region of physical memory that already has a mapping. - kumar
RFC cpm2_devices DPRAM resource
>> Slightly different question than the current thread: >> >> Should the DPRAM appear as it's own platform_device? >> Option 1) Specify the portion of the DPRAM used by each device with >> that platform_device definition. (current) >> >> Option 2) Define the whole DPRAM region as its own platform_device >> entry. Move the device DPRAM information to the device specific >> platform structure. >> >> Would this help with a general dpalloc() implementation? It would >> reduce the number of ioremap() regions. > > Well, we already have an allocator for general dpram memory. I'm not > really sure how this would help beyond reducing the fact that we may > ioremap() regions more than once. I think the better solution there > is to look at the patches that have been made to ioremap() to return > the same virtual addresses if you are remapping a region of physical > memory that already has a mapping. > I guess my thought regarding the dpalloc() statement is that those functions could query the platform_device structure to find the region they are managing. Make them a little more general.
RFC cpm2_devices DPRAM resource
Slightly different question than the current thread: Should the DPRAM appear as it's own platform_device? Option 1) Specify the portion of the DPRAM used by each device with that platform_device definition. (current) Option 2) Define the whole DPRAM region as its own platform_device entry. Move the device DPRAM information to the device specific platform structure. Would this help with a general dpalloc() implementation? It would reduce the number of ioremap() regions. Another thought.
