From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dell2650.onz.com (onz.com [67.121.61.113]) by ozlabs.org (Postfix) with ESMTP id ED389679E7 for ; Fri, 17 Jun 2005 06:07:50 +1000 (EST) In-Reply-To: <33f285d9677314c043e77908198a3e0e@embeddededge.com> References: <33f285d9677314c043e77908198a3e0e@embeddededge.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Allen Curtis Date: Thu, 16 Jun 2005 13:07:47 -0700 To: Dan Malek 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: , >> 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