summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_i2c.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Actually retry with bit-banging after GMBUS timeoutVille Syrjälä2016-03-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | After the GMBUS transfer times out, we set force_bit=1 and return -EAGAIN expecting the i2c core to call the .master_xfer hook again so that we will retry the same transfer via bit-banging. This is in case the gmbus hardware is somehow faulty. Unfortunately we left adapter->retries to 0, meaning the i2c core didn't actually do the retry. Let's tell the core we want one retry when we return -EAGAIN. Note that i2c-algo-bit also uses this retry count for some internal retries, so we'll end up increasing those a bit as well. Cc: Jani Nikula <jani.nikula@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: bffce907d640 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8b1f165a4a8f64c28cf42d10e1f4d3b451dedc51) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: fix error path in intel_setup_gmbus()Rasmus Villemoes2016-02-101-1/+1
| | | | | | | | | | | | | This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links") Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk (cherry picked from commit 2417c8c03f508841b85bf61acc91836b7b0e2560) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Separate cherryview from valleyviewWayne Boyer2015-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to .is_cherryview in the cherryview device info structure and simplifies the IS_CHERRYVIEW macro. Then where appropriate, instances of IS_VALLEYVIEW are replaced with IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent. v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro. Also add followup patches to fix issues discovered during the first review. (Ville) v3: Fix some style issues and one gen check. Remove CRT related changes as CRT is not supported on CHV. (Imre, Ville) v4: Make a few more optimizations. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: abstract i2c bit banging fallback in gmbus xferJani Nikula2015-12-021-14/+25
| | | | | | | | | | | | Choose between i2c bit banging and gmbus in a new higher level function, and let the i2c core retry the first time we fall back to bit banging. The i2c core imposes a timeout on -EAGAIN, but it defaults to 1 second, and shouldn't be a problem for us. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448980166-23055-2-git-send-email-jani.nikula@intel.com
* drm/i915: simplify gmbus xfer error checksJani Nikula2015-12-021-8/+4
| | | | | | | | | Shorter, easier to follow code with no functional changes. In all cases, the return value ultimately comes from gmbus_wait_hw_status() anyway. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448980166-23055-1-git-send-email-jani.nikula@intel.com
* drm/i915: Type safe register read/writeVille Syrjälä2015-11-181-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
* drm/i915: Streamline gpio_mmio_base deductionVille Syrjälä2015-11-181-8/+7
| | | | | | | | | | | | | | | | If we ignore the BXT situation, we can observe that the only variables affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT situation we can fit into the same pattern if we change gmbus_pins_bxt[] to house the GMCH GPIO register offsets (like we do for all other platfotms). So let's do that. We could even simplify the VLV situation more by including the display_mmio_offset in the GPIO register defines, but let's leave it be for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Introduce a gmbus power domainVille Syrjälä2015-11-171-2/+4
| | | | | | | | | | | | | | | | | | | | | Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well 2 on BXT. So add a new power domnain for gmbus and kill off the now unused intel_aux_display_runtime_get/put. And change intel_hdmi_set_edid() to use the gmbus power domain too since that's all we need there. Also toss in a BUILD_BUG_ON() to catch problems if we run out of bits for power domains. We're already really close to the limit... [Patrik: Add gmbus string to debugfs output] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
* drm/i915/kbl: Introduce Kabylake platform defition.Rodrigo Vivi2015-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kabylake is a Intel® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Include gpio_mmio_base in GMBUS reg definesVille Syrjälä2015-10-131-31/+23
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2015-06-261-28/+90
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "This is the main drm pull request for v4.2. I've one other new driver from freescale on my radar, it's been posted and reviewed, I'd just like to get someone to give it a last look, so maybe I'll send it or maybe I'll leave it. There is no major nouveau changes in here, Ben was working on something big, and we agreed it was a bit late, there wasn't anything else he considered urgent to merge. There might be another msm pull for some bits that are waiting on arm-soc, I'll see how we time it. This touches some "of" stuff, acks are in place except for the fixes to the build in various configs,t hat I just applied. Summary: New drivers: - virtio-gpu: KMS only pieces of driver for virtio-gpu in qemu. This is just the first part of this driver, enough to run unaccelerated userspace on. As qemu merges more we'll start adding the 3D features for the virgl 3d work. - amdgpu: a new driver from AMD to driver their newer GPUs. (VI+) It contains a new cleaner userspace API, and is a clean break from radeon moving forward, that AMD are going to concentrate on. It also contains a set of register headers auto generated from AMD internal database. core: - atomic modesetting API completed, enabled by default now. - Add support for mode_id blob to atomic ioctl to complete interface. - bunch of Displayport MST fixes - lots of misc fixes. panel: - new simple panels - fix some long-standing build issues with bridge drivers radeon: - VCE1 support - add a GPU reset counter for userspace - lots of fixes. amdkfd: - H/W debugger support module - static user-mode queues - support killing all the waves when a process terminates - use standard DECLARE_BITMAP i915: - Add Broxton support - S3, rotation support for Skylake - RPS booting tuning - CPT modeset sequence fixes - ns2501 dither support - enable cmd parser on haswell - cdclk handling fixes - gen8 dynamic pte allocation - lots of atomic conversion work exynos: - Add atomic modesetting support - Add iommu support - Consolidate drm driver initialization - and MIC, DECON and MIPI-DSI support for exynos5433 omapdrm: - atomic modesetting support (fixes lots of things in rewrite) tegra: - DP aux transaction fixes - iommu support fix msm: - adreno a306 support - various dsi bits - various 64-bit fixes - NV12MT support rcar-du: - atomic and misc fixes sti: - fix HDMI timing complaince tilcdc: - use drm component API to access tda998x driver - fix module unloading qxl: - stability fixes" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (872 commits) drm/nouveau: Pause between setting gpu to D3hot and cutting the power drm/dp/mst: close deadlock in connector destruction. drm: Always enable atomic API drm/vgem: Set unique to "vgem" of: fix a build error to of_graph_get_endpoint_by_regs function drm/dp/mst: take lock around looking up the branch device on hpd irq drm/dp/mst: make sure mst_primary mstb is valid in work function of: add EXPORT_SYMBOL for of_graph_get_endpoint_by_regs ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi' drm/atomic: Don't set crtc_state->enable manually drm/exynos: dsi: do not set TE GPIO direction by input drm/exynos: dsi: add support for MIC driver as a bridge drm/exynos: dsi: add support for Exynos5433 drm/exynos: dsi: make use of array for clock access drm/exynos: dsi: make use of driver data for static values drm/exynos: dsi: add macros for register access drm/exynos: dsi: rename pll_clk to sclk_clk drm/exynos: mic: add MIC driver of: add helper for getting endpoint node of specific identifiers drm/exynos: add Exynos5433 decon driver ...
| * drm/i915: don't register invalid gmbus pins for sklJani Nikula2015-05-201-0/+10
| | | | | | | | | | | | | | | | Do not expose invalid gmbus pins as i2c devices to userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: don't register invalid gmbus pins for bdwJani Nikula2015-05-201-0/+11
| | | | | | | | | | | | | | | | Do not expose invalid gmbus pins as i2c devices to userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'drm-intel-next-2015-04-23-fixed' of ↵Dave Airlie2015-05-081-28/+69
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2015-04-23: - dither support for ns2501 dvo (Thomas Richter) - some polish for the gtt code and fixes to finally enable the cmd parser on hsw - first pile of bxt stage 1 enabling (too many different people to list ...) - more psr fixes from Rodrigo - skl rotation support from Chandra - more atomic work from Ander and Matt - pile of cleanups and micro-ops for execlist from Chris drm-intel-next-2015-04-10: - cdclk handling cleanup and fixes from Ville - more prep patches for olr removal from John Harrison - gmbus pin naming rework from Jani (prep for bxt) - remove ->new_config from Ander (more atomic conversion work) - rps (boost) tuning and unification with byt/bsw from Chris - cmd parser batch bool tuning from Chris - gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky) - execlist tuning (not yet all of it) from Chris - add drm_plane_from_index (Chandra) - various small things all over * tag 'drm-intel-next-2015-04-23-fixed' of git://anongit.freedesktop.org/drm-intel: (204 commits) drm/i915/gtt: Allocate va range only if vma is not bound drm/i915: Enable cmd parser to do secure batch promotion for aliasing ppgtt drm/i915: fix intel_prepare_ddi drm/i915: factor out ddi_get_encoder_port drm/i915/hdmi: check port in ibx_infoframe_enabled drm/i915/hdmi: fix vlv infoframe port check drm/i915: Silence compiler warning in dvo drm/i915: Update DRIVER_DATE to 20150423 drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010 rm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c drm/i915: Unduplicate i915_ggtt_unbind/bind_vma drm/i915: Move ppgtt_bind/unbind around drm/i915: move i915_gem_restore_gtt_mappings around drm/i915: Fix up the vma aliasing ppgtt binding drm/i915: Remove misleading comment around bind_to_vm drm/i915: Don't use atomics for pg_dirty_rings drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt drm/i915/skl: Support Y tiling in MMIO flips drm/i915: Fixup kerneldoc for struct intel_context ... Conflicts: drivers/gpu/drm/i915/i915_drv.c
| | * drm/i915: add bxt gmbus supportJani Nikula2015-04-141-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For BXT gmbus is pulled from PCH to CPU. From implementation point of view only pin pair configuration will change. The existing implementation supports all platforms previous to GEN8 and also SKL. But for BXT pin pair configuration is completely different than SKL or other previous GEN's. This patch introduces the new pin pair configuration structure specific to BXT and also ensures every real gmbus port has a gpio pin. v3 by Jani: with the platform independent prep work in place, the bxt enabling reduces to a fairly trivial patch. Credits are due Sunil for giving me the ideas (with his patches) what the platform independent parts should look like. v4: Fix intel_hdmi_init_connector() for bxt. Abstract gmbus_pin access more. s/GPU/PCH/ in commit message. v5: Rebase. Issue: VIZ-3574 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: base gmbus pin validity check on the gmbus pin map arrayJani Nikula2015-04-011-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will be helpful for adding future platforms. It is better to keep the information in the single point of truth (the table) instead of duplicating it into the validity function. While at it, add dev_priv parameter to the function, also to prepare for adding future platform support. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: index gmbus tables using the pin pair numberJani Nikula2015-04-011-27/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Index the gmbus tables directly using the pin instead of having a confusing "port = i + 1" mapping. This finishes off removing the "gmbus port" as a notion, and leaves us with just the "gmbus pin". As pin 0 is invalid by definition and the gmbus tables will have a gap at that index, add pin validity check to all the loops. This will be benefitial for supporting platforms that have different numbers of pins, or gaps. v2: s/GMBUS_PIN_MAX/GMBUS_NUM_PINS/ (Ville, Daniel) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: refer to pin instead of port in the intel_i2c.c interfacesJani Nikula2015-04-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename intel_gmbus_is_port_valid to intel_gmbus_is_valid_pin, and rename port parameters to pin as well. This matches usage all around, as usually a pin is passed to the validity check function. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Fix DDC probe for passive adaptersJani Nikula2015-06-091-3/+17
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI devices, as they do not have a sink device in them to respond to any AUX traffic. When probing these dongles over the DDC, sometimes they will NAK the first attempt even though the transaction is valid and they support the DDC protocol. The retry loop inside of drm_do_probe_ddc_edid() would normally catch this case and try the transaction again, resulting in success. That, however, was thwarted by the fix for [1]: commit 9292f37e1f5c79400254dca46f83313488093825 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Thu Jan 5 09:34:28 2012 -0200 drm: give up on edid retries when i2c bus is not responding This added code to exit immediately if the return code from the i2c_transfer function was -ENXIO in order to reduce the amount of time spent in waiting for unresponsive or disconnected devices. That was possible because the underlying i2c bit banging algorithm had retries of its own (which, of course, were part of the reason for the bug the commit fixes). Since its introduction in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links we've been flipping back and forth enabling the GMBUS transfers, but we've settled since then. The GMBUS implementation does not do any retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop on first encounter of -ENXIO. This, combined with Eugeni's commit, broke the retry on -ENXIO. Retry GMBUS once on -ENXIO on first message to mitigate the issues with passive adapters. This patch is based on the work, and commit message, by Todd Previte <tprevite@gmail.com>. [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059 v2: Don't retry if using bit banging. v3: Move retry within gmbux_xfer, retry only on first message. v4: Initialize GMBUS0 on retry (Ville). v5: Take index reads into account (Ville). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924 Cc: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2) Tested-by: Jim Bride <jim.bride@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: cope with large i2c transfersDmitry Torokhov2015-04-231-10/+56
|/ | | | | | | | | | | | | | | | | | The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Kill duplicated cdclk readout code from i2cVille Syrjälä2014-07-071-54/+0
| | | | | | | | | | | | | | We have a slightly different way of readoing out the cdclk in gmbus_set_freq(). Kill that and just call .get_display_clock_speed(). Also need to remove the GMBUSFREQ update from intel_i2c_reset() since that gets called way too early. Let's do it in intel_modeset_init_hw() instead, and also pull the initial vlv_cdclk_freq update there from init_clock gating. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Change vlv cdclk to use kHz unitsVille Syrjälä2014-07-071-1/+1
| | | | | | | | | | | Use kHz units in vlv cdclk code since that's more customary. Also replace the precomputed 90% values with *9/10 computation for extra clarity. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disable dp aux irq on g4xDaniel Vetter2014-02-071-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently it's broken in the exact same way as the gmbus irq. For reference of the full story see commit c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4 Author: Jiri Kosina <jkosina@suse.cz> Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips The effect is that we have a storm of unclaimed interrupts on the legacy irq line. If that one is used by a different device then the kernel will complain and rather quickly kill the irq source. Which breaks any device trying to actually use the legacy irq line. This regression has been introduced commit 4aeebd7443e36b0a40032e518a9338f48bd27efc Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 31 09:53:36 2013 +0100 drm/i915: dp aux irq support for g4x/vlv Note that disabling MSI works around the issue, but we can't do that since apparently then the hw will miss interrupts. At least if relevant comments in i915_irq.c are accurate. v2: Cross-reference dp aux and gmbus gen4 comments. v3: Consolidate harder into i915_drv.h as suggested by Chris. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/vlv: split CCK and DDR freq usageJesse Barnes2013-11-051-8/+3
| | | | | | | | | | | It's possible that the CCK clock could run at a different rate than the DDR clock, so use the same method to get CCK as the GMBUS code does when calculating the new CDclk divider in the VLV display code. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/vlv: modeset_global_* for VLV v7Jesse Barnes2013-11-051-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | On VLV/BYT, we can adjust the CDclk frequency up or down based on the max pixel clock we need to drive. Lowering it can save power, while raising it is necessary to support high resolution. Add a new callback in modeset_affected_pipes and a modeset_global_resources function to perform this adjustment as necessary. v2: use punit interface for 320 and 266 MHz CDclk adjustments (Ville) v3: reset GMBUS dividers too, since we changed CDclk (Ville) v4: jump to highest voltage when going to 400MHz CDclk (Jesse) v5: drop duplicate define (Ville) use shifts by 1 for fixed point (Ville) drop new callback (Daniel) v6: fixup adjusted_mode.clock -> adjusted_mode.crtc_clock again (Ville) document Bunit reg access better (Ville) v7: pass modeset_pipes and pipe_config to global_pipes so we get the right clock data (Ville) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Program GMBUS Frequency based on the CDCLK for VLV.Chon Ming Lee2013-10-011-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CDCLK is used to generate the gmbus clock. This is normally done by BIOS. Program the value if the BIOS-less system doesn't do it. v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency during resume. (Daniel) v3: Change GMBUS_FREQ to GMBUSFREQ_VLV, and use VLV_DISPLAY_BASE. (Ville). Remove cdclk_ratio[] table, and calculate the cdclk ratio instead. (Ville). Change the shift then mask for reg read, to mask first, then shift. (Ville). Remove the gmbus frequency calculation = cdclk/1.01. Based on BIOS programming, gmbus frequency = cdclk frequency. (Ville) Add get_disp_clk_div, which can use to get cdclk/czclk divide. v4: Fix the mmio_offset base for CZCLK_CDCLK_FREQ_RATIO, gmbus_freq calculation, and duplicate check for gmbus_freq. (Ville) In VLV, the spec is wrong about 4Mhz reference frequency for GMBUS. It should be 1Mhz. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [danvet: Add the comment Ville suggested. Also appease checkpatch a bit.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: allow package C8+ states on Haswell (disabled)Paulo Zanoni2013-08-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows PC8+ states on Haswell. These states can only be reached when all the display outputs are disabled, and they allow some more power savings. The fact that the graphics device is allowing PC8+ doesn't mean that the machine will actually enter PC8+: all the other devices also need to allow PC8+. For now this option is disabled by default. You need i915.allow_pc8=1 if you want it. This patch adds a big comment inside i915_drv.h explaining how it works and how it tracks things. Read it. v2: (this is not really v2, many previous versions were already sent, but they had different names) - Use the new functions to enable/disable GTIMR and GEN6_PMIMR - Rename almost all variables and functions to names suggested by Chris - More WARNs on the IRQ handling code - Also disable PC8 when there's GPU work to do (thanks to Ben for the help on this), so apps can run caster - Enable PC8 on a delayed work function that is delayed for 5 seconds. This makes sure we only enable PC8+ if we're really idle - Make sure we're not in PC8+ when suspending v3: - WARN if IRQs are disabled on __wait_seqno - Replace some DRM_ERRORs with WARNs - Fix calls to restore GT and PM interrupts - Use intel_mark_busy instead of intel_ring_advance to disable PC8 v4: - Use the force_wake, Luke! v5: - Remove the "IIR is not zero" WARNs - Move the force_wake chunk to its own patch - Only restore what's missing from RC6, not everything Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: avoid premature DP AUX timeoutsImre Deak2013-05-221-1/+2
| | | | | | | | | | | | | | During DP AUX communication we might time out 1 jiffy too early, because the calculated expiry jiffy value is one less than needed. This is only one reason for false DP AUX timeouts. For a complete solution we also need the following fix, which is now queued for mainline: http://marc.info/?l=linux-kernel&m=136748515710837&w=2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64133 Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use msecs_to_jiffies_timeout instead of open coding the sameImre Deak2013-05-221-1/+1
| | | | | Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't touch South Display when PCH_NOPBen Widawsky2013-04-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will be bad for CPU" range when we have PCH_NOP. There is a bit of a hack in init clock gating. We want to do most of the clock gating, but the part we skip will hang the system. It could probably be abstracted a bit better, but I don't feel it's too unsightly. v2: Use inverse HAS_PCH_NOP check (Jani) v3: Actually do what I claimed in v2 (spotted by Daniel) Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel) Move LVDS bail into this patch (Ben) v4: logical rebase conflict resolution with SDEIIR (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Brush up patch a bit and resolve conflicts: - Adjust PCH_NOP checks due to Egbert's hpd handling rework. - Addd a PCH_NOP check in the irq uninstall code. - Resolve conflicts with Paulo's SDE irq handling race fix. v5: Drop the added hunks in the ilk irq handler again, they're bogus. OOps. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: stop using GMBUS IRQs on Gen4 chipsJiri Kosina2013-03-201-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [ 9.636345] irq 16: nobody cared (try booting with the "irqpoll" option) [ 9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g0863702 #422 [ 9.639484] Call Trace: [ 9.640731] <IRQ> [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7 [ 9.640731] [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8 [ 9.640731] [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214 [ 9.640731] [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c [ 9.640731] [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0 [ 9.640731] [<ffffffff8100400e>] handle_irq+0x1a/0x24 [ 9.640731] [<ffffffff81003d17>] do_IRQ+0x48/0xaf [ 9.640731] [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a [ 9.640731] <EOI> [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b [ 9.640731] handlers: [ 9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore] [ 9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket] [ 9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). I have no idea how that even can happen. To avoid tempting this elephant into a rage, just disable gmbus interrupt support on gen 4. v2: Improve the commit message with exact details of what's going on. Also add a comment in the code to warn against this particular elephant in the room. v3: Move the comment explaing how gen4 blows up next to the definition of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris Wilson. Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://lkml.org/lkml/2013/3/8/325 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: GPIO/GMBUS registers need an offset on VLVVille Syrjälä2013-01-241-0/+2
| | | | | | | | GPIO/GMBUS registers must be offset on VLV, so simply adjust gpio_mmio_base to include the correct offset. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use _NOTRACE for gmbus/dp aux wait loopsDaniel Vetter2012-12-061-2/+2
| | | | | | | | | | | | | | Less clutter in the traces. And in both cases we yell rather loud into the logs if we time out. Patch suggested by Chris Wilson. v2: Annotate another I915_READ in dp_aux to be consistent - we filter out all register io in wait_for and similar loops. Chris also suggested to mark all dp_aux register access as _NOTRACE, but I think we should keep all functionally relevant access around, and filter unneeded bits in userspace after the trace is captured. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use gmbus irq to wait for gmbus idleDaniel Vetter2012-12-061-4/+28
| | | | | | | | | | | | | | | | | | | GMBUS_ACTIVE has inverted sense and so doesn't fit into the wait_hw_status helper, hence create a new gmbus_wait_idle functions. Also, we only care about the idle irq event and nothing else, which allows us to use the wait_event_timeout helper directly without jumping through hoops to catch NAKs. Since gen2/3 don't have gmbus interrupts, handle them separately with the old wait_for macro. This shaves another few ms off reading EDID from a hdmi screen on my testbox here. EDID reading with interrupt driven gmbus is now as fast as with busy-looping gmbus at 28 ms here (with negligible cpu overhead). Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use the gmbus irq for waitsDaniel Vetter2012-12-061-11/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need two special things to properly wire this up: - Add another argument to gmbus_wait_hw_status to pass in the correct interrupt bit in gmbus4. - Since we can only get an irq for one of the two events we want, hand-roll the wait_event_timeout code so that we wake up every jiffie and can check for NAKs. This way we also subsume gmbus support for platforms without interrupts (or where those are not yet enabled). The important bit really is to only enable one gmbus interrupt source at the same time - with that piece of lore figured out, this seems to work flawlessly. Ben Widawsky rightfully complained the lack of measurements for the claimed benefits (especially since the first version was actually broken and fell back to bit-banging). Previously reading the 256 byte hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms. Given that transfering the 256 bytes over i2c at wire speed takes 20.5ms alone, the reduction in additional overhead is rather nice. v2: Chris Wilson wondered whether GMBUS4 might contain some set bits when booting up an hence result in some spurious interrupts. Since we clear GMBUS4 after every wait and we do gmbus transfer really early in the setup sequence to detect displays the window is small, but still be paranoid and clear it properly. v3: Clarify the comment that gmbus irq generation can only support one kind of event, why it bothers us and how we work around that limit. Cc: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: extract gmbus_wait_hw_statusDaniel Vetter2012-12-061-21/+25
| | | | | | | | | | | | | | | | | | | | The gmbus interrupt generation is rather fiddly: We can only ever enable one interrupt source (but we always want to check for NAK in addition to the real bit). And the bits in the gmbus status register don't map at all to the bis in the irq register. To prepare for this mess, start by extracting the hw status wait loop into it's own function, consolidate the NAK error handling a bit. To keep things flexible, pass in the status bit we care about (in addition to any NAK signalling). v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted, Chris Wilson gladly pointed that out for me. To keep things simple, ignore that case for now (we only need to idle the gmbus controller at the end of an entire i2c transaction, not after every message). Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/i2c: Track users of GMBUS force-bitChris Wilson2012-11-131-3/+6
| | | | | | | | | | | | | | | | | | | | | | This fixes a regression for SDVO from commit fbfcc4f3a0cf8bbde87646b74241faa8e37426bf Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Oct 22 16:12:18 2012 +0300 drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures As SDVOB and SDVOC are multiplexed on the same pin, if a chipset does not have the second SDVO encoder, it will then remove the force-bit setting on the common i2c adapter during teardown. All subsequent attempts of trying to use GMBUS with SDVOB then fail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: fixup inversion in the debug printout, noticed by Jani Nikulai.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells2012-10-021-2/+2
| | | | | | | | | | | Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.David Howells2012-10-021-1/+0
| | | | | | | | | | | | | | | | | | | | | Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* drm/i915: ensure i2c adapter is all set before adding itJani Nikula2012-08-131-3/+4
| | | | | | | | | | | | | i2c_add_adapter() may do i2c transfers on the bus to detect supported devices. Therefore the adapter needs to be all set before adding it. This was not the case for the bit-banging fallback, resulting in an oops if the device detection GMBUS transfers timed out. Fix the issue by calling i2c_add_adapter() only after intel_gpio_setup(). LKML-Reference: <5021F00B.7000503@ionic.de> Tested-by: Mihai Moldovan <ionic@ionic.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: Remove silly testAlan Cox2012-07-261-3/+0
| | | | | | | | | | | | | drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful than a chocolate teapot. Possibly we should be testing bus != NULL each iteration of the loop instead ? gcc could help by warning too! Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: be more careful when returning -ENXIO in gmbus transferDaniel Vetter2012-05-211-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... flaky ddc hardware can cause a spurious NAK, resulting in the i2c core and drm edid functions not trying to retry the edid transfer. Luckily the gmbus quiescenting also times out for these cases, so we can get out of this mess by returning -ETIMEDOUT for this specific case. This way we keep the fast-fail of returning -ENXIO if there is no device present, speeding up the boot process. This regression has been introduced in commit e646d5773572bf52017983d758bdf05777dc5600 Author: Daniel Kurtz <djkurtz@chromium.org> Date: Fri Mar 30 19:46:38 2012 +0800 drm/i915/intel_i2c: always wait for IDLE before clearing NAK v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs, suggested by Daniel Kurtz. Cc: Daniel Kurtz <djkurtz@chromium.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518 Reported-and-Tested-by: Julian Simioni <julian.simioni@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable gmbus on i830Daniel Vetter2012-05-191-0/+4
| | | | | | | | | The hw just returns garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838 Reported-and-tested-by: Vladyslav <DFEW.Entwickler@googlemail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: reduce verbosity of some messagesDaniel Kurtz2012-04-131-3/+4
| | | | | | | | | Some of these messages can be hit when userspace tries to probe the i2c with nothing connected or if the driver code tries to do the same. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48248 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: handle zero-length readsDaniel Kurtz2012-04-131-2/+2
| | | | | | | | | | | | | | A common method of probing an i2c bus is trying to do a zero-length read. Handle this case by checking the length first waiting for data to be read. This is actually important, since attempting a zero-length read is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is device present on the bus with a given address. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48269 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfersDaniel Kurtz2012-04-121-3/+0
| | | | | | | | | | The POSTING_READ() calls were originally added to make sure the writes were flushed before any timing delays and across loops. Now that the code has settled a bit, let's remove them. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: reuse GMBUS2 value read in polling loopDaniel Kurtz2012-04-121-12/+22
| | | | | | | | | | | | | | Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for memory mapped IO registers. To avoid "assigning in if clause" checkpatch errors", use a ret variable to store the wait_for macro return value. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: use INDEX cycles for i2c read transactionsDaniel Kurtz2012-04-121-4/+50
| | | | | | | | | | | | | | | | It is very common for an i2c device to require a small 1 or 2 byte write followed by a read. For example, when reading from an i2c EEPROM it is common to write and address, offset or index followed by a reading some values. The i915 gmbus controller provides a special "INDEX" cycle for performing such a small write followed by a read. The INDEX can be either one or two bytes long. The advantage of using such a cycle is that the CPU has slightly less work to do once the read with INDEX cycle is started. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: use WAIT cycle, not STOPDaniel Kurtz2012-04-121-15/+18
| | | | | | | | | | | | | | | | | | | | | | The i915 is only able to generate a STOP cycle (i.e. finalize an i2c transaction) during a DATA or WAIT phase. In other words, the controller rejects a STOP requested as part of the first transaction in a sequence. Thus, for the first transaction we must always use a WAIT cycle, detect when the device has finished (and is in a WAIT phase), and then either start the next transaction, or, if there are no more transactions, generate a STOP cycle. Note: Theoretically, the last transaction of a multi-transaction sequence could initiate a STOP cycle. However, this slight optimization is left for another patch. We return -ETIMEDOUT if the hardware doesn't deactivate after the STOP cycle. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> [danvet: added comment to the code that gmbus can't generate STOP on the very first cycle.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: always wait for IDLE before clearing NAKDaniel Kurtz2012-04-121-10/+31
| | | | | | | | | | | | | | | | The GMBUS controller can report a NAK condition while a transaction is still active. If the driver is fast enough, and the bus is slow enough, the driver may clear the NAK condition while the controller is still busy, resulting in a confused GMBUS controller. This will leave the controller in a bad state such that the next transaction may fail. Also, return -ENXIO if a device NAKs a transaction. Note: this patch also refactors gmbus_xfer to remove the "done" label. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud