Re: [parisc-linux] Virtual mapping of IO cards

[John Marvin <jsm@udlkern.fc.hp.com>]

> >
> > Drivers for memory mapped register only cards, i.e. cards without any
> > type of onboard memory (i.e. framebuffers, script memory, etc.) are
> > not very likely to ever run into a bug of this type, since register
> pointers are usually set up once and never changed.
>
> Agreed. "not very likely" and "never" are not the same. When bringing
> up new drivers, it is in fact more likely than for a mostly working
>  driver. So while I agree with the statement, I don't agree with the
> conclusion.

I guess I was mostly talking from a released version perspective, not a
development perspective.  During development you would actually get even
more debug information if you just put driver specific range checking into
a private version of the read/write macro's (i.e. you could get source
code line numbers, etc.)

I really am not trying to argue strongly against mapping the cards. I
see only two performance issues:

    1) PCXL2 processors require that the U bit be set for IO mappings.
    As far as I can tell, this is the only processor that requires this.
    The TLB miss handlers don't currently support this. We would have
    to add support for it in the D miss handler. Since the U bit is
    in an inconvenient location it would require a separate test and
    deposit, making all code pay the penalty of the additional
    instructions. Perhaps we would eventually want to add the U bit
    support anyway, but not all processors support it (the
    PCXS and PCXT processors do not support it).

    2) I really would like to avoid mapping the framebuffer into
    the kernel address space. Perhaps maybe that is not really an
    issue, since after boot the user will bring up X windows and
    the kernel mapping won't actually be actively used (I'm assuming
    that graphics on Linux maps the framebuffer into the user address
    space, but I haven't checked to be sure).

So, if you want to map the cards, I'm not going to oppose that.

John