Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Nov 2005 15:55:40 -0700
From:      Scott Long <scottl@samsco.org>
To:        Marius Strobl <marius@alchemy.franken.de>
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:  <4383A1EC.5070907@samsco.org>
In-Reply-To: <20051122235307.H16812@newtrinity.zeist.de>
References:  <200511222232.jAMMWo6u088484@repoman.freebsd.org> <43839E0D.2080108@samsco.org> <20051122235307.H16812@newtrinity.zeist.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl wrote:

> 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
>  

It was an FYI about the last line in your commit and how it could be 
useful in the future.  NetBSD already has this integration, and that's
likely where this came from in the code you modified.

Scott



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