From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 17:43:07 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4740116A401 for ; Thu, 22 Mar 2007 17:43:07 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id D929A13C457 for ; Thu, 22 Mar 2007 17:43:06 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7C68733C82; Thu, 22 Mar 2007 19:43:05 +0200 (SAST) Date: Thu, 22 Mar 2007 19:43:05 +0200 From: John Hay To: Olivier Houchard Message-ID: <20070322174305.GB76915@zibbi.meraka.csir.co.za> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> <20070322153123.GB79016@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322153123.GB79016@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 17:43:07 -0000 On Thu, Mar 22, 2007 at 04:31:23PM +0100, Olivier Houchard wrote: > On Thu, Mar 22, 2007 at 08:05:44AM -0700, Sam Leffler wrote: > > John Hay wrote: > > > Hi Guys, > > > > > > What are the ideas (policy) about merging the arm/ixp425/avila stuff > > > to 6-stable? I see some arm stuff gets merged, but it does not look > > > like everything? Is it just that people merge what they need? > > > > > > Just trying to get a feel for it. Up to now I have used 6-stable on > > > our soekris and wrap boards, but we are probably going to use the > > > Avila boards a bit more, so I was wondering if I should use -current > > > or 6-stable on them. Up to now my Avila and ADI testing was done with > > > -current, but I'm not sure if that is a good idea for boxes that will > > > end up in rural areas far far away. Hmm. Not that I have seen a panic > > > on the Avila boards, but they have gone through a lot less testing up > > > to now. > > > > Not sure what's been missed. I see no reason not to MFC anything > > arm-related unless it breaks code compatibility (and even there it's > > unlikely there are 3rd party codes to worry about). > > > > Sam > > Hi John, > > Sorry for lack of answers, I really need to get back in the loop. > Avila works fine in RELENG_6. Maybe I should try it then. :-) > Generally, MFC'ing arm stuff should happen more > often. > On an unrelated note, your changes (I think, maybe I should've had a closer > look) seem to provoke an interrupt storm on ATA when there's no CF card > inserted, I seem to remember it may be why we did some ugly stuff. It might be because of a "bug" that I fixed. Roughly at line 190+: - /* interrupt is active low */ - GPIO_CONF_WRITE_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN), - GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN) | - GPIO_TYPE(AVILA_IDE_GPIN, GPIO_TYPE_ACT_LOW))); + /* interrupt is active high */ + GPIO_CONF_WRITE_4(sa, GPIO_TYPE_REG(ide_gpin), + (GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(ide_gpin)) & + ~GPIO_TYPE(ide_gpin, GPIO_TYPE_MASK)) | + GPIO_TYPE(ide_gpin, GPIO_TYPE_ACT_HIGH)); The old code had a bracket problem, so it actually read from a bogus address: GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN) | GPIO_TYPE(AVILA_IDE_GPIN, GPIO_TYPE_ACT_LOW)) which happened to be all ones, and wrote that to the interrupt config register, which caused all the interrupts in that register to be edge triggered on both edges. So when I fixed it, I also changed it to be active high, because all the docs I could find have the cf interrupt as active high. Maybe the line floats high if nothing is connected to it? The Pronghorn docs says that they have GPIO2 and GPIO3 connected to CD1 and CD2 of the CF header, so you can read GPIO2 and GPIO3 and if both are low, you can assume a CF installed, otherwise there is no CF. So on the Pronghorn board one could do that test in the probe routine and fail there already. Maybe one can only configure the interrupt if there is an CF installed? Or maybe use another interrupt edge? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org