From: Pantelis Antoniou <panto@intracom•gr>
To: Allen Curtis <acurtis@onz•com>
Cc: Ppc Embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: RFC cpm2_devices DPRAM resource
Date: Fri, 17 Jun 2005 09:48:03 +0300 [thread overview]
Message-ID: <42B27223.3040808@intracom.gr> (raw)
In-Reply-To: <b2f31907a6e9a9180a96318ceeacb468@onz.com>
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
prev parent reply other threads:[~2005-06-17 6:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-16 17:45 RFC cpm2_devices DPRAM resource Allen Curtis
2005-06-16 17:58 ` Kumar Gala
2005-06-16 18:08 ` Allen Curtis
2005-06-16 19:36 ` Dan Malek
2005-06-16 19:41 ` Dan Malek
2005-06-16 20:07 ` Allen Curtis
2005-06-17 6:48 ` Pantelis Antoniou [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42B27223.3040808@intracom.gr \
--to=panto@intracom$(echo .)gr \
--cc=acurtis@onz$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox