aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_overlay.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2010-09-09 19:06:13 +0100
committerChris Wilson <chris@chris-wilson.co.uk>2010-09-12 13:36:09 +0100
commitb5c616a75428d85f92407e4509553f937b720630 (patch)
treeacd793c74e59365dd7f995df0fac2cd8530e2d5c /drivers/gpu/drm/i915/intel_overlay.c
parentec5da01e23eec303dd313aa62b8ed4712c488437 (diff)
downloadkernel_samsung_smdk4412-b5c616a75428d85f92407e4509553f937b720630.zip
kernel_samsung_smdk4412-b5c616a75428d85f92407e4509553f937b720630.tar.gz
kernel_samsung_smdk4412-b5c616a75428d85f92407e4509553f937b720630.tar.bz2
drm/i915/sdvo: Poll command status 5 times without delay on read
The documentation says that an SDVO command takes a maximum of 15us to be processed by the device, and that it is sufficient to read the status byte 3 times (whilst the command is still in the PENDING state) for the driver to be confident that sufficient time has elapsed. We err on the safe side and try 5 times before giving up. The only question that remains: was the old behaviour derived by experiments with real hardware? A look into the murky history of UMS, implies that the behaviour was accidental and the current retry mechanism was solely designed to catch the status byte indicating PENDING with no reference to hardware behaviour. (commit ac9181c014638dbeb334b40b4029d0ccb2b7a0fc in xf86-video-intel) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_overlay.c')
0 files changed, 0 insertions, 0 deletions