From: Jan Kneschke <Jan.Kneschke@kiel.netsurf.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 7 Sep 1998 22:53:14 +0200 (MEST)

Re: vision-driver

On Mon, 7 Sep 1998, Steffen Seeger wrote:

>  
> > On Mon, 7 Sep 1998, Steffen Seeger wrote:
> > 
> > >  
> > > > - the PCICFG_VADDR-hack is gone. it is replaced by a more general version
> > > > that will be used in the s3-common-driver, too. i will pollish it a bit more
> > > > and will propose it for all the other drivers out there because every driver
> > > > are is doing it its own way.
> > > 
> > > What's your solution instead? The PCICFG_VADDR was not meant to be a hack. 
> > the PCICFG_VADDR was used this way:
> > 
> > 	pci->dev = PCICFG_VADDR (0, 10, 0);
> > 
> > this is a hack.
> 
> If you use it this way, yes, that's a hack. The pci_options->dev field was
> meant to be initialized by the operating system layer, not the chipset driver.
> The 'not meant to be a hack' referred to the PCICFG I/O space itself and the
> handling of PCI-Device addressing.
i've only done this because kgicon isn't offering this service for me, now.
 
> The new KGI handles PCI autodetection as follows (PCICFG_SIGNATURE being 
> a macro that merges vendor and model ID into one 32bit int):
> 
> static const kgi_u32 pgc_pcicfg[] =
> {
>         PCICFG_SIGNATURE(PCI_VENDOR_ID_3Dlabs, PCI_DEVICE_ID_PERMEDIA),
>         PCICFG_SIGNATURE(PCI_VENDOR_ID_3Dlabs, PCI_DEVICE_ID_PERMEDIA2),
>         PCICFG_SIGNATURE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TVP4010),
>         PCICFG_SIGNATURE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TVP4020),
>         PCICFG_SIGNATURE(0,0)
> };
it looks like i had a similar idea. 
/me is feeling proud that he had the same idea like the master of kgi-magic .)

> 
> The idea is that in the driver you don't have to care if a PCI bus is
> present at all, and that you only have to worry about the devices you
> can support. The effect of this code:
> 
> - in single-head environments, just load the driver and everthing is 
>   auto-detected
> 
> - in multi-head environments you have to give the pcibus,pcidev and 
>   (optionally) pcifn options and the driver knows the device to drive.
>   It cannot use auto-detection, as there is no general way to tell if 
>   a detected device is served by a driver or not.
how about a general struct containing every pci-gfx-device like the
pci-struvt plus an option-tag ?? the pci-struct is served by the kernel-part
of the driver. 
no. it sound like we need a master-module that control the
availability of pci-devices and every driver report to this master module
that he is serving this device. this means that their must be two modules
loaded, the first one is the master-module on which every kgicon-module
(loaded second) depends on.

> - you have one scan for all supported devices, even if they are from different
>   vendors/are different models.
> 
> Compared to a current driver, this only requires to add the pcicfg_find
> call and the array of signatures, given the current driver does
> a check for validity of pci->dev and then verifies the device.
/me is thing if he had published this idea first. if true /me feels very
very proud now.

> 			Steffen
> 
> ----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------
> 
> 


thats all
  Jan

--- 
       Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/
         -)=  Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(-