Date: Thu, 22 Mar 2007 19:43:05 +0200 From: John Hay <jhay@meraka.org.za> To: Olivier Houchard <mlfbsd@ci0.org> Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy Message-ID: <20070322174305.GB76915@zibbi.meraka.csir.co.za> In-Reply-To: <20070322153123.GB79016@ci0.org> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> <20070322153123.GB79016@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070322174305.GB76915>