Re: CVS commit: src/sys/dev/ic

[David Young <dyoung%pobox.com@localhost>]

On Wed, Mar 31, 2010 at 01:19:10PM -0700, Jason Thorpe wrote:
> 
> On Mar 31, 2010, at 7:45 AM, David Young wrote:
> 
> > On Wed, Mar 31, 2010 at 05:09:41AM +0000, Michael Lorenz wrote:
> >> Module Name:       src
> >> Committed By:      macallan
> >> Date:              Wed Mar 31 05:09:41 UTC 2010
> >> 
> >> Modified Files:
> >>    src/sys/dev/ic: pcf8584.c
> >> 
> >> Log Message:
> >> Do as OpenSolaris does and read the status register after each write.
> >> Now this driver works on my Blade 2500.
> > 
> > void
> > pcfiic_write(struct pcfiic_softc *sc, bus_size_t r, u_int8_t v)
> > {
> > +       volatile uint8_t junk;
> >        bus_space_write_1(sc->sc_iot, sc->sc_ioh, sc->sc_regmap[r], v);
> > +       junk = bus_space_read_1(sc->sc_iot, sc->sc_ioh, PCF_S1);
> >        bus_space_barrier(sc->sc_iot, sc->sc_ioh, sc->sc_regmap[r], 1,
> >            BUS_SPACE_BARRIER_WRITE);
> > }
> > 
> > I wonder, does the device need the read, or is the bus_space_barrier()
> > insufficient to flush the write to the device?
> 
> bus_space_barrier() doesn't flush ... barriers only enforce
> the ordering of operations (and, of course, with respect to
> non-overlapping addresses ... obviously reads after writes of the
> same address in code will be enforced on the bus without an explicit
> barrier).

Right.  Putting the question another way, Is it important that reading
the register we wrote "lands" the write as a side-effect?  Do we
expect that on sparc64, the bus barrier also "lands" the write as a
side-effect?

It sounds like the answer to both questions may be "no," and the
write-to-write delay is key.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933