RFC cpm2_devices DPRAM resource

RFC cpm2_devices DPRAM resource

[Allen Curtis]

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.

Re: RFC cpm2_devices DPRAM resource

[Kumar Gala]

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

Re: RFC cpm2_devices DPRAM resource

[Allen Curtis]

>> 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.

Re: RFC cpm2_devices DPRAM resource

[Dan Malek]

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

Re: RFC cpm2_devices DPRAM resource

[Dan Malek]

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

Re: RFC cpm2_devices DPRAM resource

[Allen Curtis]

>> 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

Re: RFC cpm2_devices DPRAM resource

[Pantelis Antoniou]

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