Home
last modified time | relevance | path

Searched hist:"0 bd904ed4730e481c5ad0dffc27794ec6ac70cfc" (Results 1 – 3 of 3) sorted by relevance

/freebsd/sys/arm/broadcom/bcm2835/
H A Dbcm2835_bscreg.hdiff 0bd904ed4730e481c5ad0dffc27794ec6ac70cfc Sun Oct 01 18:48:36 CEST 2017 Ian Lepore <ian@FreeBSD.org> Work around bcm283x silicon bugs to make i2c repeat-start work for the most
common case where it's needed -- a write followed by a read to the same slave.

The i2c controller in this chip only performs complete transfers, it does
not provide control over start/repeat-start/stop operations on the bus.
Thus, we have gotten a full stop/start sequence rather than a repeat-start
when doing a typical i2c slave access of "write address, read data". Some
i2c slave devices require a repeat-start to work correctly.

These changes cause the controller to do a repeat-start by pre-staging the
read parameters in the controller registers immediate after the controller
has latched the values for the initial write operation, but before any
bytes are actually written. With the values pre-staged, when the write
portion of the transfer completes, the state machine in the silicon sees
a new start operation already staged and that causes it to perform a
repeat-start. The key to tricking the buggy hardware into doing this is
to avoid prefilling any output data in the transmit FIFO so that it is
possible to catch the silicon in the state where transmit values are
latched but the transmit isn't completed yet.
H A Dbcm2835_bscvar.hdiff 0bd904ed4730e481c5ad0dffc27794ec6ac70cfc Sun Oct 01 18:48:36 CEST 2017 Ian Lepore <ian@FreeBSD.org> Work around bcm283x silicon bugs to make i2c repeat-start work for the most
common case where it's needed -- a write followed by a read to the same slave.

The i2c controller in this chip only performs complete transfers, it does
not provide control over start/repeat-start/stop operations on the bus.
Thus, we have gotten a full stop/start sequence rather than a repeat-start
when doing a typical i2c slave access of "write address, read data". Some
i2c slave devices require a repeat-start to work correctly.

These changes cause the controller to do a repeat-start by pre-staging the
read parameters in the controller registers immediate after the controller
has latched the values for the initial write operation, but before any
bytes are actually written. With the values pre-staged, when the write
portion of the transfer completes, the state machine in the silicon sees
a new start operation already staged and that causes it to perform a
repeat-start. The key to tricking the buggy hardware into doing this is
to avoid prefilling any output data in the transmit FIFO so that it is
possible to catch the silicon in the state where transmit values are
latched but the transmit isn't completed yet.
H A Dbcm2835_bsc.cdiff 0bd904ed4730e481c5ad0dffc27794ec6ac70cfc Sun Oct 01 18:48:36 CEST 2017 Ian Lepore <ian@FreeBSD.org> Work around bcm283x silicon bugs to make i2c repeat-start work for the most
common case where it's needed -- a write followed by a read to the same slave.

The i2c controller in this chip only performs complete transfers, it does
not provide control over start/repeat-start/stop operations on the bus.
Thus, we have gotten a full stop/start sequence rather than a repeat-start
when doing a typical i2c slave access of "write address, read data". Some
i2c slave devices require a repeat-start to work correctly.

These changes cause the controller to do a repeat-start by pre-staging the
read parameters in the controller registers immediate after the controller
has latched the values for the initial write operation, but before any
bytes are actually written. With the values pre-staged, when the write
portion of the transfer completes, the state machine in the silicon sees
a new start operation already staged and that causes it to perform a
repeat-start. The key to tricking the buggy hardware into doing this is
to avoid prefilling any output data in the transmit FIFO so that it is
possible to catch the silicon in the state where transmit values are
latched but the transmit isn't completed yet.