Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Nov 2005 23:53:07 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Scott Long <scottl@samsco.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/sparc64/pci psycho.c psychovar.h
Message-ID:  <20051122235307.H16812@newtrinity.zeist.de>
In-Reply-To: <43839E0D.2080108@samsco.org>; from scottl@samsco.org on Tue, Nov 22, 2005 at 03:39:09PM -0700
References:  <200511222232.jAMMWo6u088484@repoman.freebsd.org> <43839E0D.2080108@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, Nov 22, 2005 at 03:39:09PM -0700, Scott Long wrote:
> 
> Marius Strobl wrote:
> 
> > marius      2005-11-22 22:32:50 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/sparc64/pci      psycho.c psychovar.h 
> >   Log:
> >   - Add a workaround (change the interrupt map mask to compare the full
> >     INO) for incorrect interrupt map entries on E250 machines. These
> >     incorrect entries caused the INO of the on-board HME to be also
> >     assigned to the second on-board NS16550 and to the on-board printer
> >     port controller. Further down the road caused hme(4) to fail to attach
> >     to the on-board HME in FreeBSD 5 and 6 as INTR_FAST and non-INTR_FAST
> >     handlers can't share the same IRQ there (it's unknown what whould
> >     happen in -CURRENT now that INTR_FAST and non-INTR_FAST handlers can
> >     share an IRQ but I'd expect funny problems with uart(4)).
> >   - Make sure there are exactly 4 PCI ranges instead of just checking
> >     that the bridge has a 'ranges' property in the OFW device tree at all.
> >     Besides the fact that currently the 64bit memory range isn't used by
> >     this driver it we can't really work with less than 4 ranges and don't
> >     have memory for more than 4 bus handles for the ranges in the softc.
> >   - Remove sc_range and sc_nrange from softc; for the bridges supported
> >     by this driver we no longer need to know the ranges besides the bus
> >     handles obtained from them once this driver is attached. That way we
> >     also can free the memory allocated for sc_range during attach again.
> >   - Remove sc_dvmabase from the softc and pass it to psycho_iommu_init()
> >     via an additional argument as we no longer need to know the DVMA base
> >     in this driver once the IOMMU is initialized.
> >   - Remove sc_dmatag from the softc, there isn't much sense in keeping
> >     the nexus dma tag around locally.
> > 
> 
> It's been a TODO item forever to merge busdma tag management with
> newbus, so that a driver can request the tag of its newbus's parent
> instead of just guessing what constraints the parent allows.
> 

Uhm, was this a FYI or do you mean I shouldn't have removed the
nexus DMA tag from the psycho(4) softc (I fail to see why this
would have to e.g. be reintroduced when busdma tag management is
newbus'ified)?

Marius
 
-- 
This mail was scanned by AntiVir Milter.
This product is licensed for non-commercial use.
See www.antivir.de for details.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051122235307.H16812>