Re: Multihead ISA

[Lee Olsen]

Egbert Eich wrote:

Lee Olsen writes:
> Hello Egbert;
> 
> Egbert Eich wrote:
> 
> >Hello Lee,
> >
> >thank you for the patches! 
> >
> >Lee Olsen writes:
> >
> > > I have completed  my tests with my supply of trailing edge hardware, and 
> > > my hercules driver plays
> > > well with X440. There are two attachments, one is a tar file of the 
> > > hercules driver source and the other
> > > is unified diffs in the forward direction of changes that let X440 do 
> > > multihead ISA.
> >
> >I'd expect that there are very few people who can still test the
> >hercules driver, but if you are willing to do the support this 
> >should not be a problem.
> > > 
> > > The diffs do three things: separate color and mono resources, disable 
> > > vga routing for busses that
> > > don't have routing functions, and let the configure process collect ISA 
> > > resource usage like it does
> > > for PCI.
> >
> >I don't understand this. The configure process is not there to collect
> >resources. This is done during xf86ConfigIsaEntity(). This function should
> >not return an allocated ScreenInfo structure if it finds conflicts.
> >Unresolvable ISA resources should really disable both confliciting 
> >resources.
> >  
> >
> The problem is resource conflicts are fatal. If a vendor specific 
> Probe() succeeds, then the vesa and vga
> probes must fail. It might be different if resource conflicts propogated 

That's what you want. You probe as long as you found a driver.
The vesa and vga probes are at the end as they are considered 
fallbacks only. If you want the vesa driver even if a chipset
driver exists you need to use a config tool.
Also the autoconfiguration will always try to get you the chipset
specific driver.

> back up and became PreInit()
> failures, but that's not the case. The question is how do you know if 
> the current Probe() should fail?

The Probe() function should fail if the driver isn't able to identify
a chipset as his. It also fails if another driver has allocated the 
(fixed) resources the driver wants. 
This should happen on the second pass thru configure.

> The existing code checks to see if any non-PCI devices have been 
> configured and if so, forces
> subsequent non-PCI Probe()s to fail. What I'd like to do is use the 

Yes. 
       for (i = 0;  i < nDevToConfig;  i++)
           if (!DevToConfig[i].pVideo)
               return NULL;
Does that.

> resource list to tell me if the
> device being Probe()d has been successfully Probe()d by a different 
> driver. If so, the current
> Probe() should fail. Since the resources are exclusive, any overlap 
> means two drivers
> want the same device. MatchIsaInstances already had the resource data, 
> it just needed to use
> AddBusDeviceToConfigure() to make it available to DoConfigure().

Ah, I see. 
OK, I understand that. For PCI we do:
     for (i = 0;  i < nDevToConfig;  i++)
           if (DevToConfig[i].pVideo &&
               (DevToConfig[i].pVideo->bus == pVideo->bus) &&
               (DevToConfig[i].pVideo->device == pVideo->device) &&
               (DevToConfig[i].pVideo->func == pVideo->func))
               return NULL;

For ISA we obviously have no ID to identify the device :-/
so you are using the resources as an identifier. Well,
I guess one can do that. 
On the other hand DoConfigure does a second pass thru Probe()
- this time it doesn't set PROBE_DETECT, therefore xf86ConfigIsaEntity()
is called and should do the same thing, namely to check for conflicts
with a previously detected device.
I must admit I forgot the details, maybe there is some other reason
why it doesn't work this way. Have you checked? 
 

At this point, resource conflicts detected within 
ConfigIsaEntity/ClaimFixedResources
go directly to FatalError, and pass two cannot return false as it never 
regains control:

       switch (range.type & ResAccMask) {
       case ResExclusive:
           if (!xf86ChkConflict(&range, entityIndex)) {
               Acc = xf86AddResToList(Acc, &range, entityIndex);
#ifdef REDUCER
           } else {
               range.type |= ResEstimated;
               if (!xf86ChkConflict(&range, entityIndex) &&
                   !checkConflict(&range, AccReducers, entityIndex,
                                  SETUP, FALSE)) {
                   range.type &= ~(ResEstimated | ResBios);
                   AccReducers =
                       xf86AddResToList(AccReducers, &range, entityIndex);
#endif
               } else resError(&range); /* no return */
To stay out of FatalError, the resource check has to be before 
ConfigIsaEntity and
needs an entityIndex < -2, since -1 means available, -2 is used by the 
check routines,
and positive values are configured entities.

Pass two from the vesa driver starts like this:
       if (flags & PROBE_DETECT)
           foundScreen = TRUE;
       else for (i = 0; i < numUsed; i++) {
           ScrnInfoPtr pScrn = NULL;
           if ((pScrn = xf86ConfigIsaEntity(pScrn, 0,usedChips[i],
                                            VESAISAchipsets, NULL,
                                            NULL, NULL, NULL, NULL))) {
          
 And xf86ConfigIsaEntity()  creates a screen, adds the entity to the 
screen and claims
the fixed resources. The test could be at the beginning of 
xf86ConfigIsaEntity() instead
of pass one. Any later and you wind up creating a screen just so you can 
destroy it.

The second call to the driver Probe function looks like this:

           (*xf86DriverList[i]->Probe)(xf86DriverList[i], 0);

So any error returned is ignored. We probably wind up with a three-headed
config file (proprietary, vesa, and vga). I saw things like this in 
initial testing
before adding the conflict checks.

One more gotcha: The ati driver does not call xf86ConfigIsaEntity(), iy has
it's own path to xf86ClaimFixedResources(), and xf86ClaimFixedResources(0
is a void function.
> 
> >
> >1. The minor issue: You are deleting xf86AddDeviceToConfigure()
> >   It looks like that this function is not needed any more. However
> >   it may have to be kept for backward compatibility as it is
> >   exposed to drivers. We have no information if older binary
> >   only drivers use it (although I don't think so).
> >  
> >
> I had not considered third party drivers. It does not need to go away, 
> nor it's reference in loader/xf86sym.c.

Right. I cannot say for sure anyway, it may well be that we are carrying
dead code around for nothing. But that's the problem with a public API:
you have to support old versions of it until you say, here we need to 
make a backward incompatible change. Then you can drop all this, too.

xf86AddDeviceToConfigure should use something other than NULL for the 
isa case. Probably resVgaExclusiveColor
to match the other isa defines.

> 
> >2. You are splitting the mono and color resources. This is good,
> >   however it may cause problems: VGA devices may be configured
> >   to use the monochrome resources. I've seen BIOSes doing that
> >   when they find another card with color resources. Therefore
> >   we are allocating both sets of resources. We need to think how
> >   deal with that. I'd suggest to continue to allocate both
> >   mono and color resources for PCI devices as those resources
> >   are shared anyway. For ISA devices it is a little bit more 
> >   difficult. Since we don't know if the device we are probing
> >   is the one we are interested in or another one.
> >
> >  
> >
> There are three sets of resource blocks in xf86Bus.c, color, mono, and 
> both. The shorthand defines
> I pointed at color and mono. The ati driver uses both but does not use 
> the define.
> 
> In xf86Resources.h:
> #define RES_SHARED_VGA          resVgaSharedColor
> goes back to the original:
> #define RES_SHARED_VGA          resVgaShared
> 
> That will allocate both for PCI cards.

OK.

> ISA cards should not be both until we know for sure. You can try an X 
> -configure on the vga
> alone and see if it adds the hercules head. It may use the memory block 
> without the registers,
> which the X -configure won't detect, or it might work.
> I keep the hercules cards around for the extra parallel port, which I 
> use for pic programming. If
> I need that capability on my PCI box, I'll look at PCI vs ISA resources. 
> Until then, this looks fine.

For hercules you need a special monitor with 'digital' input, don't you?
Digital not in the sense we understand it today with DVI, though ;-)
I'd expect that I could find a card somewhere - but Monitors may be hard
to find these days ;-)
 

Yeah, they are rare. db-9 connectors like serial ports, but the gender 
is wrong. I've seen a few on ebay this winter.
I've seen 9-15 converters for driving ega/multisync 9 pin monitors from 
vga cards, but nothing going the other way.

My point about the resources was that we allocated both mono and color
resources in Probe() because a VGA card could use both. Since we don't
know yet which ones it does use we took the simple approach when this
was implemented.
We could add a heuristic to the driver which selects the correct resource:
1. Probe for the misc out register (which doesn't exist on herc) if it
  is not present probe for the mono registers: if they exist there is
   only a mono card in the system -> take the mono resource.
2. If it exists: check the setting: If it is mono, we have a VGA card
  set to mono, there cannot be another mono card present (the system
  would have acted up at boot time) we should take both as we don't
  have to expect a conflict with a mono card.
3. If it is set to color, also probe if the mono registers are present.
  Only in this case you have to use the color registers only.
I proposed something like this for the vga driver. Once you have a vga 
device, check the misc out register
and claim the color or the mono resources accordingly. I didn't do the 
misc out check in the hercules probe, but
adding it sounds right. When I put my vga cards into mono mode, they 
stopped using the 0x3c0-0x3cf vga registers.
The only combination I found that used mono resources and 0x3c0-0x3cf 
was an ega in mono mode.
If the vga mode is color, we should not care if the mono registers are 
present, we
shouldn't be using them. It's one less test if we always release them in 
color mode.

The drivers would have to be changed for that, though. Another apporach
would be to add some code to xf86ConfigIsaEntity() to do the magic described
above to detect 3. and remove the HGA resources from the list before 
registering them.

I like the idea of one test rather than one in each driver, but 
xf86ConfigIsaEntity is not used by all drivers. The ati driver
does not, and third party drivers are unknown. The ati driver should not 
release the mono resources, so if it missed the
chance to do so, that's ok. Sayng the same thing for third party drivers 
may be ok too.

That way we would not interfer with exisiting behavior but still be able
to support mono cards. Poking around in PIO space without knowing if
HW is actually is present generally is not a good idea. (On 'legacy free
systems' it will lead to machine checks) but if we do things in 
xf86ConfigIsaEntity() it should be save as we only should get there
if the system supports ISA in which case poking is no problem as
that's what everybody did in those days.

Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
 

Enjoy
Lee
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel