> > No, I don't think so. If I understand what you're talking about, you
> > want to add some extra initialisation for a specific but otherwise
> > standard PCI VGA card, and you want to do this with a device driver which
> > "owns" the card.
>
> Exactly.
>
> > The best way I can think of doing this is as follows:
> >
> > - Your driver should determine whether the VGA adapter is the "primary"
> > adapter. Working this out may be a little tricky.
>
> As a first cut, I would consider it as the only card. But yes, I should
> take this into account.
Yes. 8)
> > - In your attach routine (not in the probe routine, since you may not
> > actually win the probe bidding), add extra resources to the device_t
> > which match the "legacy" VGA resources, so that you claim exclusive
> > ownership of these resources. You can do this with bus_set_resource.
>
> Can I claim ISA resources while in a PCI probe? Resources are bus dependent
> like the bus_xxx_resource() functions.
Resources are not bus-dependant (there are exceptions, but this is
generally true). Even if an ISA driver, or an ISA PnP entry lists these
resources, you can still claim them in another driver.
> In fact, I want to add the linear buffer configuration trick for some S3 cards
> which have linear frame buffering support but *only* 1.2 VESA. It uses some
> extra ISA ports just after the standard VGA ones.
They're not "ISA ports" so much as just regions in I/O space, and yes,
you can easily just claim these.
> For this, I was thinking of newbusifying vga / vesa and fb and attach
> my S3 trick to pci and vga. VGA would be a child of isa_vga, as currently,
> vesa a child of VGA and fb a child of VESA and VGA. Of course in a VESA+VGA
> configuration there would be two fb... one with vesa support, one without.
I would come up with a generic 'vga' driver that has ISA and PCI
attachments. You could even ignore ISA-only VGA cards if you were
feeling really modern, as they are basically all junk these days. 8)
I'm not 100% sure whether VESA should just be an extension to the 'vga'
driver, since it just provides a better way of doing some things that the
driver would otherwise do.
Then 'fb' would be a child of 'vga' (and of any other pixmap device if we
ever add others).
> But this would make the hypothesis that the PCI probe is made before the ISA.
You can safely assume that this is true.
> I'm a bit confused with the current architecture of the VGA/VESA/FB drivers.
> They call each other and not always in the same direction. Espacially the
> FB and VGA. Should we have the VGA driver as a backend of the FB one?
pci
\
vga
| \
fb syscons
Is how I think it should probably be done, or something similar.
Regards,
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
