Subject: Re: Finding Kernel VA that maps given physical address?
To: None <firstname.lastname@example.org, email@example.com>
From: Wolfgang Solfrank <firstname.lastname@example.org>
Date: 07/22/1997 16:13:24
> Well, my intent here is to _not_ reinvent the wheel. I'm implementing the
> slot manager interface so that other NetBSD/Mac68k device drivers can use
> the existing, on-board ROM-resident driver code and interface to it using
> a documented API - Apple's own driver calls to the Read, Write, Control,
> Prime, etc. entry points.
> By taking this approach, I expect that the normal autoconfiguration
> process will occur, and the code in nubus.c will call all appropriate
> drivers to perform their own attach() calls. Thus, I _assumed_ that the
> drivers themselves would be responsible for calling pmap_map(), as is
> currently the case with the video-board driver grf_mv.c (and presumably
> other nubus drivers, like the ones for Ethernet cards). All I'm looking
> for is some way to find out what the driver code did (or didn't) do - is
> the physical address space for a given slot mapped, and therefore is there
> a driver for the card in that slot?
Hmm, I'm not sure that I understand your intentions correctly. When is your
code intended to be called? I was under the impression that it would be during
autoconfiguration as some last resort if there wasn't a native driver for some
card. If this is indeed the case you cannot rely on the fact that some driver
would have already mapped some memory/device registers. In fact, if some
driver would do this in its match routine and leave the area mapped, this
would be a bug.
If I'm babbling complete nonsense, please enligthen me on the intended
application of your code.
ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800