aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
authorVille Syrjälä <[email protected]>2016-03-07 17:56:59 +0200
committerVille Syrjälä <[email protected]>2016-04-12 13:20:58 +0300
commit3e4d44e0fabf22d742c9669572653fe3399afec5 (patch)
tree0f15b3cdc842ac90b20b70d9dd96ed64511e6258 /tools/perf/scripts/python/bin
parentade754ec1143caeada0bae01e4c3ea3188497bfd (diff)
drm/i915: Restore GMBUS operation after a failed bit-banging fallback
When the GMBUS based i2c transfer times out, we try to fall back to bit-banging and retry the operation that way. However if the bit-banging attempt also fails, we should probably go back to the GMBUS method for the next attempt. Maybe there simply wasn't anyone one the bus at this time. There's also a bit of a mess going on with the force_bit handling. It's supposed to be a ref count actually, and it is as far as intel_gmbus_force_bit() is concerned. But it's treated as just a flag by the timeout based bit-banging fallback. I suppose that's fine since we should never end up in the timeout fallback case if force_bit was already non-zero. However now that we want to restore things back to where they were after the bit-banging attempt failed, we're going to have to do things a bit differently to avoid clobbering the force_bit count as set up by intel_gmbus_force_bit(). So let's dedicate the high bit as a flag for the low level timeout based fallback and treat the rest of the bits as a ref count just as before. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions