Re: CVS commit: src/sys/dev/ic
On Wed, Mar 31, 2010 at 05:09:41AM +, 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?
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/sys/dev/ic
On Wed, Mar 31, 2010 at 09:45:40AM -0500, David Young wrote:
On Wed, Mar 31, 2010 at 05:09:41AM +, 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?
Additionally, should this read not be after the barrier?
Re: CVS commit: src/sys/dev/ic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 31, 2010, at 10:45 AM, David Young wrote:
On Wed, Mar 31, 2010 at 05:09:41AM +, 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?
I thave no idea. It works without the read on some machines - might be
a quirk in the Blade 2500's hardware. Either way we can probably get
rid of the bus_space_barrier().
have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBS7OOX8pnzkX8Yg2nAQIfgwgAmhqpCkhfn5XBZ9bvj2ycADxjBVGg/7Cb
TGSOLhJ9lizzNZHYh9V2Vtwf3tRgLRS4xLrA6T/UyT5fO+t+uTWzCF77P30LIxrx
faoEPxrOwehxF0inVK/aaxjbOiiAN7zMBMwswC7dJOtG6m6pdpOMAo3mHU4zXWq4
7nFRcrdy1eOc/fGvxuwgnDPvf7CyriMKRMkO7m8QQCKnG4C1XDQ5VJYkLorPKqZm
UEwYl/JhQz1LdTJ6l8SUxAzoCprT7du/iaZvxOHdAsRNtPRhA1pc7E/fFOJg9e3M
1+GXWcY/8SUTTNhUNEreTGPycM6nf6AhjusBFZYeK9Q/lxSF0KI6WQ==
=gpun
-END PGP SIGNATURE-
Re: CVS commit: src/sys/dev/ic
On Wed, Mar 31, 2010 at 02:03:11PM -0400, Michael wrote: On Mar 31, 2010, at 10:45 AM, David Young wrote: I wonder, does the device need the read, or is the bus_space_barrier() insufficient to flush the write to the device? I thave no idea. It works without the read on some machines - might be a quirk in the Blade 2500's hardware. Either way we can probably get rid of the bus_space_barrier(). The barrier here just makes sure the write that just happened will be completed before the next write operation to the same register. It does not have any influence on the write you added. It might make sense to move the read past the barrier and modify that to be BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE. Or try the modified barrier w/o the added read - maybe that is already enough. However, if your pci bridge is not very wiered I doubt that this is the problem - i.e. my bet would be on the device requiring a small delay or actually the read cycle. Martin
Re: CVS commit: src/sys/dev/ic
I wonder, does the device need the read, or is the bus_space_barrier() insufficient to flush the write to the device? I thave no idea. It works without the read on some machines - might be a quirk in the Blade 2500's hardware. Either way we can probably get rid of the bus_space_barrier(). IIRC the pcf8584 has a timing constraint on consecutive bus writes. Something like 5 clocks minimum delay at 10MHz. The dummy read may be a sun-devised way to ensure this constraint is met (I don't think the ebus hardware enforces it).
Re: CVS commit: src/sys/dev/ic
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 +, 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
