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 dyo...@ojctech.com Urbana, IL * (217) 278-3933