Conference 49.910::kav30

The VDADDRIVER is a bit confusing in that it allows VME_IRQ but doesn't
specify any irq's in the data buffer to actually set:

  vdad$kav_data      = 0x00000000;              /*  No IRQ allowed -     */
  vdad$kav_setup     = KAV$K_ALLOW_VME_IRQ;     /* (initially, at least) */
  KAV$VME_SETUP( &status,
                 vdad$kav_setup,
                 &vdad$kav_data );

This seems to imply that the KAV will mask out VMEbus interrupts since
the default system settings have no irq's enabled.

At what IRQ level does the VDAD device interrupt for its VMEbus vector of 4
and VAX vector of %x810?

Thanks,

Alan

re: 60.0

see line "characteristic /sys..." in sample .dat file for VMEbus setup 
below.
Note, I never use resp. modify VMEbus setup parameters within an
application, because it may affect another one.

vectors, adrs:
1. vdad 
dev_irql=       %x1;            { Interrupt Level }
dev_irqv=       %x4;            { Interrupt Vector, cf. ebuilds .dat-file }
dev_vme_adrs=   %xFE0E00;       { devices physical VMEbus address }

2. smod
DEV_IRQL=       %x2;            { Interrupt Level }
DEV_IRQV=       %x20;           { Interrupt Vector, cf. ebuilds .dat-file }
DEV_VME_ADRS=   %xFD0000;       { device's physical VMEbus address }

3. dioz
dev_irql=       %x1;            { Interrupt Level }
dev_irqv=       %x10;           { Interrupt Vector, cf. ebuilds .dat-file }
dev_vme_adrs=   %xF00000;       { device's physical VMEbus address }


Alfons
		-----

characteristic /remote_cli /remote_term /nofile /net_device=EZA /noserver 
	/objects=512 /emulator=both /jobs=32 -
/subprocesses=128 /debug=both /loader=1024 
/p0_virtual_size=8192 /p1_virtual_size=1024 /io_region=8096 -
/interrupt_stack=128 /target=24
characteristic /sys1_param=%X400FEFF /sys2_param=%X400007
node /lat=active
program SETTIME /initialize
program vdad_SRV /run /warm_debug /kernel_stack=64 /mode=kernel /job_priority=10
program dioz_SRV /run /warm_debug /kernel_stack=64 /mode=kernel /job_priority=12
program smod_SRV /run /warm_debug /kernel_stack=64 /mode=kernel /job_priority=14
device TTA /vector=%X2C0
device EZA /vector=%X130 /net_def
device VDAD /vector=%X810 /noautoload
device DIOZ /vector=%X840 /noautoload
device DIOZ_W /vector=%X840 /noautoload
device SMOD /vector=%X880 /noautoload
terminal TTA1 /driver=SCN /eightbit

	the following is one of the .dat files I used during 'development'
	of this sample driver.

	MVMEDRIVER_T1 is the 'main' programm which calls the driver
	MVMEDRIVER_AST  is the 'ast' version of the driver (documented
	in the PRI and also in sys$examples.kav after installation of
	the toolkit). System parameter setting is described in the PRI
	chapter 5.4.1

--------------------------------------------------------------------------------
characteristic /nonetwork /nofile /net_device=EZA /noserver /emulator=both -
/debug=none -
/p0_virtual_size=2048 /p1_virtual_size=256 /io_region=1042 /interrupt_stack=8 -
/errlog=remote /target=24 -
/sys1_param=%X370000FF /sys2_param=%X400007
program MVMEDRIVER_T1 /kernel_stack=4 /user_stack=4
program MVMEDRIVER_AST /initialize /kernel_stack=8 /user_stack=2 /mode=kernel -
/job_priority=5 /argument=("MVME")
device MVME /vector=%X808 /noautoload
terminal CONSOLE /scope /display=64914::0.0 /vt3xx
--------------------------------------------------------------------------------

	as far as I know, the documented vdad driver did not use irq's...

	there are several different drivers for the vdad board now 
	'hanging around'.., you may ask Alfons Grammer (see .2) for the
	sources of his driver.

    Re: .0
    
    Hi Alan,
    
    The device dependent parameter is an extension to the system
    configuration record structure that was primarily added for use by
    rtVAX 300 based applications.  I'm not sure if the method of accessing
    it is documented (it may be documented in the rtVAX 300 supplement). 
    
    To retrieve the device dependent parameter it is necessary to walk
    through the system device list (pointed to by KER$GA_DEVICE_LIST),
    checking each system configuration record (SCR) for a match with your
    device, the device dependent  parameter is at an offset of
    SCR$L_DEVICE_DEPENDENT  within the SCR.  Traversing the device list is
    relatively simple as it is physically contiguous.
    
    Graham
          

Thanks to all for your replies.

Just a few loose ends:

    re .4: As I read further in the VDAD device driver, it does ultimately
           setup allowing for IRQ 1 in the VDAD$SETUP routine.  I guess this
           was just one way of masking interrupts until it was ready.

    re .2, .3: In each of your System parameter #1 you have the first byte
               set to %XFF indicating that default configurations should be
               used at startup.  However, you have different values in the
               other bytes.  I'm not sure whether this means you are using
               the default settings or whether you are giving specific
               settings.  The doc'n on p5-15 is unclear in the sentence:
 
       "When you want to use the default configurations, set this byte to FF(16)
        and make sure that System Parameter 1 and System Parameter 2 contain
        valid settings.  When you do not want to use the default configurations,
        set this byte to any value other than FF(16)."

    If one wants to use the default settings and specifies %xFF in the low
    byte of param 1, why should it matter what is in the rest of system param 1
    and 2?  It seems if you wanted to set specific values you would have
    specified something other than %xFF in the low byte of param 1.

    Am I missing something?

Thanks again,

Alan

    Hi Alan,
    
    Re: default values, the documentation is incorrect.
    
    The least significant byte of system parameter 1 needs to be set to FF
    to override the default settings, if you set the least significant byte
    to FF then you must provide valid settings for all of the parameters
    that can be set up from system parameters 1 and 2.
    
    Thanks for reporting this, I'll see that it gets changed for VAXELN
    4.4.
    
    Graham