Subject: Re: ET4000 driver - more help needed
To: Leo Weppelman <leo@wau.mis.ah.nl>
From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
List: port-atari
Date: 01/09/1998 17:11:38
Leo Weppelman wrote:
> Julians question basically boils down to:
> How do I obtain the (opaque!) tags in the console probe when
> the bus is not yet probed.
Ah, but I didn't put it that succinctly! :)
> Some design issues:
> - I don't want to scatter 'opaque' bus knowledge in different parts
> of the system. Basically, this knowledge belongs in
> .../<bus>/<bus>_machdep.c.
Agreed.
> - maximum reuse of code (ie. the et_probe_card() function performing
> a kind of pci-bus scan is bogus).
Yes. Because the ET4000 card routines are mixed with the PCI code, I
started to unglue the ET4000 configure and probe parts.
> - quiet and simple ;-)
Well, if you haven't found the console yet, you can't be noisy! Simple
would be good too. (Then I can understand it first go ;-)
> I was thinking to define an 'early_<bus>_scan()' function. As an
> argument, it should get a probe function. The 'early_<bus>_scan'
> function calls the probe function with a '<bus>_attach_args' argument.
Yes, this looks nice. I notice that other drivers have a ...match() and
a ...attach() routine. Does it make sense to have match() and attach()
routines, rather than a probe() routine? That way, the driver code could
be the same as those for the 'normal' bus scans. For example, if I wanted
my VME card as console, I just define it in the kernel config, otherwise
I get a TT video console and the VME card found later (and grf attached).
One snag is that you have more parameters to worry about.
Anyway, I shall go back to separating the functionality. With any luck,
I'll have time this weekend and be able to look at the X server too.
J
--
1024/55A5BC19 0F 3F 62 56 18 10 8B 84 43 8F F4 94 93 37 76 AA
S.E.P.