- Original message -
- Original message -
On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury
st...@snewbury.org.uk wrote:
- Original message -
On Wed, 30 Mar 2011 17:07:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Once a NAK has been
- Original message -
On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury
st...@snewbury.org.uk wrote:
- Original message -
On Wed, 30 Mar 2011 17:07:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Once a NAK has been asserted by the slave, we need to reset
Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.
If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC
On Wed, 30 Mar 2011 09:48:25 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 30 Mar 2011 17:07:11 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+clear_err:
+ I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
+ POSTING_READ(GMBUS1 + reg_offset);
+ I915_WRITE(GMBUS1 +
On Wed, 30 Mar 2011 17:59:51 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'm not even sure we need the first posting read. Maybe it should be a
wait_for(I915_READ(GMBUS1 + reg_offset) GMBUS_SW_CLR_INT, 100)
to be clearer that we are simply giving the hardware the chance to assert
On Wed, 30 Mar 2011 17:07:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.
