From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailserv.intranet.gr (mailserv.intranet.GR [146.124.14.106]) by ozlabs.org (Postfix) with ESMTP id 6C7E3679E1 for ; Fri, 17 Jun 2005 16:53:52 +1000 (EST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id j5H6xAEY025689 for ; Fri, 17 Jun 2005 09:59:12 +0300 (EEST) Message-ID: <42B27223.3040808@intracom.gr> Date: Fri, 17 Jun 2005 09:48:03 +0300 From: Pantelis Antoniou MIME-Version: 1.0 To: Allen Curtis References: <33f285d9677314c043e77908198a3e0e@embeddededge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Ppc Embedded Subject: Re: RFC cpm2_devices DPRAM resource List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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