Date: Sat, 9 Aug 2003 08:01:36 +1000 From: John Birrell <jb@cimlogic.com.au> To: ticso@cicely.de Cc: Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: How to get a device_t Message-ID: <20030809080136.H7321@freebsd1.cimlogic.com.au> In-Reply-To: <20030808123535.GD44229@cicely12.cicely.de>; from ticso@cicely12.cicely.de on Fri, Aug 08, 2003 at 02:35:36PM %2B0200 References: <20030808083617.E7321@freebsd1.cimlogic.com.au> <6421.1060328648@critter.freebsd.dk> <20030808180337.F7321@freebsd1.cimlogic.com.au> <20030808123535.GD44229@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 08, 2003 at 02:35:36PM +0200, Bernd Walter wrote: > What resources does your elanmmcr device manage? > There is a lots of different stuff to manage: timers, pio pins, ... > Just managing exclusive mmcr adresses will not be enough because > different pio pins share registers. > On the other hand it's questionable if those resources should be > managed anyway. My main focus is on the flash drivers. For them I need ISA hints. The MMCR registers are required to access the flash controller. The flash maps into the same memory space as the ISA devices, so I keep asking myself why they can't _just_ _be_ _ISA_ _devices_. I'm still working on a STABLE source base because I need the stability that provides. So the legacy device isn't an option. I've looked at what I need to do to support the ISA style resources that the flash drivers need if the mmcr is implemented as a bus. I don't see the need to cobble up code for managing the resources in an MMCR pseudo-bus when they are perfectly well implemented in the ISA code. For my purposes, I find that I can leave PHK's elan-mmcr stuff virtually as it is and just get my flash drivers to check the MMCR map pointer in their probes to determine if on an Elan SC520. When it comes to writing to the MMCR, the option CPU_ELAN code can just provide a function to do that. I see no need to write more code than is absolutely required. The bus stuff is neat when it works in your favour, but in this case it's just a hassle. The SC520 is intended as a chip for embedded systems. I don't want/need any bells and whistles when I've only got 2 executables in the entire operating system (the kernel and init). I'll go the simple way. -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030809080136.H7321>