svn commit: r197969 - head/sys/conf

[Jung-uk Kim]

On Thursday 15 October 2009 11:18 am, John Baldwin wrote:
> On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote:
> > In message: <200910150833.54252.jhb at freebsd.org>
> >
> >             John Baldwin <jhb at freebsd.org> writes:
> > : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote:
> > : > In message: <200910141738.43910.jhb at freebsd.org>
> > : >
> > : >             John Baldwin <jhb at freebsd.org> writes:
> > : > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar 
wrote:
> > : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote:
> > : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar 
wrote:
> > : > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote:
> > : > : > >>> I can't be more clear than this.  You keep ignoring
> > : > : > >>> me, and it
>
> is
>
> > : > : > >>> very
> > : > : > >>> frustrating.
> > : > : > >>
> > : > : > >> I'm not ignoring you. I'm still talking. You simply
> > : > : > >> haven't
>
> convinced
>
> > : > : > >> me. While it's possible (likely?) that I don't
> > : > : > >> understand the
>
> issues,
>
> > : > : > >> all you've achieved so far is that I'm more convinced
> > : > : > >> that
>
> limiting
>
> > : > : > >> orm(4) to i386 and amd64 is the right thing, because
> > : > : > >> the
>
> alternative
>
> > : > : > >> is not at all appealing.
> > : > : > >>
> > : > : > >>> The problem is that the
> > : > : > >>> powerpc and itanium isa modules allow memory ranges
> > : > : > >>> that
>
> shouldn't
>
> > : > : > >>> be
> > : > : > >>> allowed.  That's the platform specific code that
> > : > : > >>> needs to be
>
> fixed.
>
> > : > : > >> isa_set_resource() is MI code and it happily adds
> > : > : > >> whatever
>
> resources
>
> > : > : > >> a driver wants. The only chance MD code has is to fail
> > : > : > >> the allocation,
> > : > : > >> but since the whole ISA code bypasses the newbus
> > : > : > >> hierarchy,
>
> there's
>
> > : > : > >> no way we know in the isa MD code what is valid and
> > : > : > >> what isn't
>
> unless
>
> > : > : > >> we add kluges to platform code.
> > : > : > >>
> > : > : > >> If you want to fix it for real, does that mean fix it
> > : > : > >> for real or does that mean add kluges to platform
> > : > : > >> code?
> > : > : > >>
> > : > : > >> Shouldn't we have ISA bridges obtain the set of valid
> > : > : > >> resources from their parent in the newbus hierarchy?
> > : > : > >
> > : > : > > Hmm, can we even know that?  PCI-ISA bridges in x86 at
> > : > : > > least don't have any
> > : > : > > I/O limit registers like PCI-PCI bridges, instead they
> > : > : > > are subtractively
> > : > : > > decoded, i.e. they "eat" any memory request that no one
> > : > : > > else
>
> claims.
>
> > : > : > The key here being requests that reach the PCI-ISA
> > : > : > bridge. It's
>
> entirely
>
> > : > : > platform specific which I/O memory addresses generated by
> > : > : > the CPU
>
> gets
>
> > : > : > decoded and forwarded in such a way that it's visible to
> > : > : > the PCI-ISA bridge. This is what needs to be obtained
> > : > : > from the parent in the
>
> newbus
>
> > : > : > hierarchy. Rather than hardcoding [0xC0000 .. 0x100000>
> > : > : > as the ISA option
> > : > : > ROM memory range, it should be something like
>
> [isa_mem_base+0xC0000 ..
>
> > : > : > isa_mem_base + 0x100000> or even [isa_rom_base ..
> > : > : > isa_rom_base + 0x40000>.
> > : > :
> > : > : That might certainly be a reasonable IVAR for isab(4) to
> > : > : provide to
>
> isa(4): a
>
> > : > : ROM base.  However, orm(4) should be enabled for all ISA
> > : > : bridges
>
> assuming
>
> > : > : that is fixed.  OTOH, the way many bus drivers I've seen
> > : > : handle this
>
> so far
>
> > : > : is to change the base address of SYS_RES_MEMORY objects as
> > : > : they pass
>
> through
>
> > : > : the relevant bridge so that the actual memory address is
> > : > : properly
>
> adjusted
>
> > : > : when it gets to the equivalent of the nexus.  This is how
> > : > : many of the Foo->PCI bridges in arm that I've looked at
> > : > : work, and I think this is
>
> more
>
> > : > : inline with Warner's original patch which is to allow the
> > : > : various platform-specific ISA bridge drivers reject memory
> > : > : ranges they do not
>
> decode
>
> > : > : and provide any needed adjustments to ranges they do decode
> > : > : to
>
> transform them
>
> > : > : into suitable resources for their parent.  Then orm(4)
> > : > : would just see
>
> it's
>
> > : > : attempts to do bus_alloc_resource() fail and end up DTRT. 
> > : > : Given that,
>
> I do
>
> > : > : think this logic belongs in the ISA bridge drivers rather
> > : > : than in
>
> individual
>
> > : > : ISA drivers.  We don't make ISA peripheral drivers add
>
> an 'isa_mem_base' or
>
> > : > : equivalent to their I/O resources, and in terms of I/O
> > : > : resources,
>
> orm(4) is
>
> > : > : just a special blackhole device (much like the ACPI or
> > : > : PnPBIOS system resource devices, or the ram0 or apic0
> > : > : devices on x86).
> > : >
> > : > This is exactly what I've been trying to say: the memory
> > : > addresses that orm is using are ISA BUS addresses.  These
> > : > just happen to map 1:1 on x86, but will map to something else
> > : > on other platforms.  But our kernel API is that the driver
> > : > requests the bus address, and that any necessary translation
> > : > happen in the bus_space layer.
> > : >
> > : > I disagree that it belongs entirely in the isa bridge
> > : > drivers.  They may communicate information to the bus_space
> > : > implementation, but it is bus_space that ultimately does this
> > : > translation.
> > :
> > : I think it actually depends on the platform as to where it
> > : belongs.  If
>
> you
>
> > : have some Foo->ISA bridge that uses a window on the Foo bus to
> > : map ISA
>
> space,
>
> > : then I think it makes sense to handle that in the Foo->ISA
> > : bridge,
>
> especially
>
> > : if it is a relocatable window.  If the ISA bus is instead
> > : assigned a fixed range in the system address space then that
> > : probably belongs in the
>
> bus_space
>
> > : support.
> >
> > I'd think it would be the opposite.  bus_space needs to know how
> > to map the request, since it is the last one involved.  If this
> > is mappable or movable, then it needs to know that too.
>
> It depends I think.  If the Foo bus just maps a Foo memory resource
> and then sub-allocates that to satisfy ISA ranges then from
> bus_space's perspective it is just working with Foo resources.  It
> would never know about ISA nor would it need to know.
>
> > However, adjusting the resources that you give to a child on the
> > way through the bridge is just assisting bus_space doing the
> > right thing if the bus_space on that architecture just implements
> > one or two global spaces.
>
> I think we are mostly agreeing actually.  My main statement is that
> how ISA memory resources are actually mapped, etc. is
> platform-dependent but that different platforms may implement that
> support using different means.

This is actually very interesting discussion for me because one of my 
pet projects is extending x86bios to support non-PC architectures.  
If anyone is interested, the current source tarball is here:

http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2

Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH.  
Basically, mapping I/O ports and orm(4) is missing.  We don't have to 
implement I/O ports but orm(4) vs. bus_space(9) is critical to make 
it a reality.  Please consider it as a real practical example for 
orm, not just a blackhole driver. :-)

Jung-uk Kim