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.

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

quoted

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.

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

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

quoted

Should the DPRAM appear as it's own platform_device?

No.

quoted

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.

quoted

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

Allen Curtis wrote:

quoted

quoted

Should the DPRAM appear as it's own platform_device?

No.

quoted

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.

quoted

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