[PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Bjorn Helgaas]

On Sun, Aug 20, 2017 at 12:08:20PM -0700, Benjamin Herrenschmidt wrote:
> On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:
> > So if ARM64 doesn't have these PCI legacy resources, does that mean an
> > ARM64 host bridge cannot generate these legacy addresses on PCI?  That
> > is, there's no host bridge window that maps to those PCI addresses?
> > That seems like a curious restriction on host bridges, but I guess it
> > would be possible.
> 
> It's rather common. For example on POWER8:

I'm just trying to tease out which things are required by PCI and
which things are required by the arch.  It doesn't surprise me at all
that some platforms (on any arch) don't provide access to legacy
resources.  That's totally outside the PCI area.  Do Power and ARM64
actively *prohibit* platforms from using legacy resources?  I can
believe current platforms don't use them, but I can still conceive of
possible systems that could.

I think removing the "(e.g. ARM64)" from the original changelog would
have avoided my questions.  That example suggests that ARM64 is
special in some way and *cannot* use PCI legacy resources.  It's easy
to conceive of a system of any arch that can't use them, simply
because it chose to use a host bridge that can't generate PCI
transactions to the VGA frame buffer or to I/O space.

>  - There is no IO space at all
> 
>  - We configure the 32-bit MMIO window to be around 3..4G (to avoid
> overlapping with DMA space below it).
> 
> So we effectively have no path to the legacy areas, and that hasn't
> been a problem so far.

I assume vga16fb.c and similar things don't work (which isn't a
problem as long as that's what everybody expects).