Re: QVSS driver

[Charles Dickman <chd%chdickman.com@localhost>]

On Wed, Sep 23, 2015 at 3:49 AM, Felix Deichmann <m4j0rd0m0%gmail.com@localhost> wrote:
> 2015-09-23 3:24 GMT+02:00 Charles Dickman <chd%chdickman.com@localhost>:

> Looking at SIMH and the driver code, I'd say both have bugs:

True

> uh_lastiv. This will, more theoretically but well, lead to duplicate
> vectors after the next 64 taken vectors.

I noticed this and wondered about it, but 64 interrupts is a lot of
qbus hardware. I don't think things end well either way. You either
run into an allocated vector or you run off the end of the vectors.

> Also, what I don't understand is why do you need two vectors from the
> pool?

vertical retrace (for not implemented hardware cursor)  and DUART.

> Having said that, I cannot find why our driver shouldn't work with a
> virtual QVSS using 9-bit vectors as everything is handled more or less
> automatically. Could you explain what exactly goes wrong?

The hardware interrupt came in at a different vector than the one that
the handler was attached to. I don't recall what the vector was.

It should have been automatic as you say. ua_cvec contains the
interrupt vector that was found in match and then this is used to
program the hardware. The KA650 manual says that qbus interrupts start
at VAX interrupt 0x200. So if ua_cvec contains the VAX interrupt then
it is 0x200 + the qbus interrupt. This is used to program the
interrupt controller and if it is 16bit instead of 8 (or 9) it gets it
wrong.

It is interesting that ubaprint masks ua_cvec before printing the vector number.

I will have to set up the hardware again to verify.

> BTW, is there a reason why the QVSS stuff alone is in arch/vax/uba/,
> while QDSS and everything else is in dev/qbus/?

I think it all started in arch/vax/uba/ and migrated out as it became
more machine independent.

> Regards,
> Felix

Chuck