summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_i2c.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* drm/i915/intel_i2c: use double-buffered writesDaniel Kurtz2012-04-121-7/+7
| | | | | | | | | | | | | | The GMBUS controller GMBUS3 register is double-buffered. Take advantage of this by writing two 4-byte words before the first wait for HW_RDY. This helps keep the GMBUS controller from becoming idle during long writes. In fact, during experiments using the GMBUS interrupts, the HW_RDY interrupt would only trigger for transactions >4 bytes after 2 writes to GMBUS3. 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: handle zero-length writesDaniel Kurtz2012-04-121-3/+4
| | | | | | | | | | | | | A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write 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. 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: allocate gmbus array as part of drm_i915_privateDaniel Kurtz2012-03-281-10/+0
| | | | | | | | | This memory is always allocated, and it is always a fixed size, so just allocate it along with the rest of the driver state. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: gmbus disabled and reserved ports are invalidDaniel Kurtz2012-03-281-43/+27
| | | | | | | | | | | | | There is no GMBUS "disabled" port 0, nor "reserved" port 7. For the other 6 ports there is a fixed 1:1 mapping between pin pairs and gmbus ports, which means every real gmbus port has a gpio pin. Given these realizations, clean up gmbus initialization. Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: refactor using intel_gmbus_get_adapterDaniel Kurtz2012-03-281-0/+8
| | | | | | | | | | | | | | | | | | Instead of letting other modules directly access the ->gmbus array, introduce intel_gmbus_get_adapter() for looking up an i2c_adapter for a given gmbus port identifier. This will enable later refactoring of the gmbus port list. Note: Before requesting an adapter for a given gmbus port number, the driver must first check its validity using i2c_intel_gmbus_is_port_valid(). If this check fails, a call to intel_gmbus_get_adapter() will WARN_ON and return NULL. This is relevant for parts of the driver that read a port from VBIOS, which might be improperly initialized and contain an invalid port. In these cases, the driver must fall back to using a safer default port. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfersDaniel Kurtz2012-03-281-26/+34
| | | | | | | | | | | Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: assign HDMI port D to pin pair 6Daniel Kurtz2012-03-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to i915 documentation [1], "Port D" (DP/HDMI Port D) is actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b). Pin pair 7 is a reserved pair. [1] Documentation for [DevSNB+] and [DevIBX], as found on http://intellinuxgraphics.org: [DevSNB+]: http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf Section 2.2.2 lists the 6 gmbus ports (gpio pin pairs): [ 5: HDMI/DPD, 4: HDMIB, 3: HDMI/DPC, 2: LVDS, 1: SSC, 0: VGA ] 2.2.2.1 lists the GPIO registers to control these 6 ports. 2.2.3.1 lists the mapping between 5 of these gmbus ports and the 3 Pin_Pair_Select bits (of the GMBUS0 register). This table is missing HDMIB (port 101). [DevIBX]: http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf Section 2.2.2 lists the same 6 gmbus ports plus two 'reserved' gpio ports. 2.2.2.1 lists 8 GPIO registers... however, it says the size of the block is 6x32, which implies that those 2 reserved GPIO registers (GPIO_6 & GPIO_7) don't actually exist (or are irrelevant). 2.2.3.1 lists the mapping between the 6 named gmbus ports and the 3 Pin_Pair_Select bits (of the GMBUS0 register). This table has HDMIB. Note: the "reserved" and "disabled" pairs do not actually map to a physical pair of pins, nor GPIO regs and shouldn't be initialized or used. Fixing this is left for a later patch. This bug had not been noticed earlier for two reasons: 1) Until recently, "gmbus" mode was disabled - all transfers actually used "bit-bang" mode on GPIO port 5 (the "HDMI/DPD CTLDATA/CLK" pair), at register 0x5024 (defined as GPIOF i915_reg.h). Since this is the correct pair of pins for HDMI1, transfers succeed. 2) Even if gmbus mode is re-enabled, the first attempted transaction will fail because it tries to use the wrong ("Reserved") pin pair. However, the driver immediately falls back again to the bit-bang method, which correctly uses GPIOF, so again, transfers succeed. However, if gmbus mode is re-enabled and the GPIO fall-back mode is disabled, then reading an attached monitor's EDID fail. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/intel_i2c: cleanup error messages and commentsDaniel Kurtz2012-03-281-4/+7
| | | | | | 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: refactor gmbus_xferDaniel Kurtz2012-03-281-59/+92
| | | | | | | | Split out gmbus_xfer_read/write() helper functions. 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: enable gmbus on gen2Daniel Vetter2012-03-251-4/+0
| | | | | | | With the recent set of gmbus fixes, this seems to work on my i855gm. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add an explict mmio base for gpio/gmbus ioDaniel Vetter2012-03-251-7/+8
| | | | | | | | | | | Again, Valleyview modes these around, so make the mmio base more explicit to consolidate the base address computations to one HAS_PCH_SPLIT check. v2: Fix up the PCH_SPLIT braino ... it actually works that way round. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: reenable gmbus on gen3+ againDaniel Vetter2012-02-291-1/+1
| | | | | | | | | | | | | | | | | | With the rework to merge the bit-banging fallback into the gmbus i2c adapter we've gotten rid of the deadlock possibility that originally lead to the disabling of this code. This reverts the revert commit 826c7e4147f902737b281e8a5a7d7aa33fd63316 Author: Jean Delvare <khali@linux-fr.org> Date: Sat Jun 4 19:34:56 2011 +0000 Revert "drm/i915: Enable GMBUS for post-gen2 chipsets" Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=35572 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: i2c: unconditionally set up gpio fallbackDaniel Vetter2012-02-291-31/+20
| | | | | | | | | | | | | | | | | This way we can simplify the setup and teardown a bit. Because we don't actually allocate anything anymore for the force_bit case, we can now convert that into a boolean. Also and the functionality supported by the bit-banging together with what gmbus can do, so that this doesn't randomly change any more. v2: Chris Wilson noticed that I've mixed up && and & ... v3: Clarify an if block as suggested by Eugeni Dodonov. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: merge gmbus and gpio i2c adpater into oneDaniel Vetter2012-02-291-33/+5
| | | | | | | | | | | | | ... and directly call the newly exported i2c bit-banging functions. The code is still pretty convoluted because we only set up the gpio i2c stuff when actually falling back, resulting in more complexity than necessary. This will be fixed up in the next patch. v2: Use exported i2c_bit_algo vtable instead of exported functions. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: merge struct intel_gpio into struct intel_gmbusDaniel Vetter2012-02-291-73/+71
| | | | | | | | | | | | When we set up the gpio fallback, we always have a 1:1 relationship with an intel_gmbus. Exploit that to store all gpio related data in there, too. This is a preparation step to merge the tw i2c adapters controlling the same bus into one. Just mundane code-munging in this patch. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add dev_priv to intel_gmbusDaniel Vetter2012-02-291-3/+3
| | | | | | | | This way we can free up the bus->adaptor.algo_data pointer and make it available for use with the bitbanging fallback algo. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix single msg gmbus_xfers writesBenson Leung2012-02-291-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | gmbus_xfer with a single message (particularly a single message write) would set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b, No Index, Stop cycle. This would not start single message i2c transactions. Also, gmbus_xfer done: will disable the interface without checking if it is idle. In the case of writes, there will be no wait on status or delay to ensure the write starts and completes before the interface is turned off. Fixed the former issue by using the same cycle selection as used in the I2C_M_RD for the write case. GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0) Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable. Note from the grumpy d-i-n maintainer: The first hunk that changes the gmbus read path is just cosmetics to align the code with the write path. I.e. the commit message above is slightly lying because the first issue is _only_ with writes (and not simply "particularly"). Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge remote-tracking branch 'airlied/drm-next' into for-airliedDaniel Vetter2012-02-231-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Manually resolve the conflict between the new enum drm property helpers in drm-next and the new "force-dvi" option that the "audio" output property gained in drm-intel-next. While resolving this conflict, switch the new drm_prop_enum_list to use the newly introduced enum defines instead of magic values. Conflicts: drivers/gpu/drm/i915/intel_modes.c Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: Fix kcalloc parameters swappedAxel Lin2012-02-131-1/+1
| | | | | | | | | | | | | | | | | | The first parameter should be "number of elements" and the second parameter should be "element size". Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/kms: Make i2c buses fasterJean Delvare2012-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C devices can typically operate faster than this, 50 kbps should be fine for all devices (and compliant devices can always stretch the clock if needed.) FWIW, the vast majority of framebuffer drivers set udelay to 10 already. So set it to 10 in DRM drivers too, this will make EDID block reads faster. We might even lower the udelay value later if no problem is reported. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915: Fix race condition in accessing GMBUSYufeng Shen2012-02-141-7/+17
|/ | | | | | | | | | | | | | | | GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). v2: Moved gmbus_mutex below intel_gmbus and added comments. Rebased to drm-intel-next-queued. Signed-off-by: Yufeng Shen <miletus@chromium.org> [danvet: Shortened the gmbus_mutex comment a bit and add the patch revision comment to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* gpu: Add export.h as required to drivers/gpu files.Paul Gortmaker2011-10-311-0/+1
| | | | | | They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* drm/i915: Remove redundant bit shifting from intel_gmbus_set_speedAdam Jackson2011-10-201-7/+1
| | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"Jean Delvare2011-06-171-2/+1
| | | | | | | | | | | | | Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a hang when loading the eeprom driver (see bug #35572.) GMBUS will be re-enabled later, differently. Signed-off-by: Jean Delvare <khali@linux-fr.org> Reported-by: Marek Otahal <markotahal@gmail.com> Tested-by: Yermandu Patapitafious <yermandu.dev@gmail.com> Tested-by: Andrew Lutomirski <luto@mit.edu> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Reset GMBUS controller after NAKChris Wilson2011-03-311-4/+21
| | | | | | | | | | | | | | | | | 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 probes and EDID retrieval. v2: Add some comments as suggested by Keith Packard. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: "Mengmeng Meng" <mengmeng.meng@intel.com>
* drm/i915: Enable GMBUS for post-gen2 chipsetsChris Wilson2011-02-011-1/+2
| | | | | | | With the recent SDVO fix, this is working on all the machines I have to hand - except for an 845G. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2010-11-151-5/+6
|\ | | | | | | | | | | Conflicts: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_ringbuffer.c
| * drm/i915: Fix I2C adapter registrationJean Delvare2010-11-091-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix many small bugs in I2C adapter registration: * Properly reject unsupported GPIO pin. * Fix improper use of I2C_NAME_SIZE (which is the size of i2c_client.name, not i2c_adapter.name.) * Prefix adapter names with "i915" so that the user knows what the I2C channel is connected to. * Fix swapped characters in the string used to name the GPIO-based adapter. * Add missing comma in gmbus name table. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: POSTING_READs are simply flushes and so irrelevant to tracingChris Wilson2010-11-081-2/+2
| | | | | | | | | | | | | | | | | | As we use POSTING_READ to flush the write to the register before proceeding, we do not care what the return value is and similar we do not care for the read to be recorded whilst tracing register read/writes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: filter out the read/write of GPIO registers from debug tracingYuanhan Liu2010-11-081-12/+13
|/ | | | | | | | | These registers are written very frequently, are timing sensitive, and not particularly relevant to any debugging, so remove the tracepoints from these. Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Fix GPIO pin to register mappingZhenyu Wang2010-10-191-0/+1
| | | | | | | In i2c GPIO fallback, index 6 is reserved for nothing. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Use i2c bit banging instead of GMBUSChris Wilson2010-09-281-0/+3
| | | | | | | | | There are several reported instances of GMBUS failing to successfully read the EDID, so revert back to bit banging until the issue is resolved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Fix GMBUSificationChris Wilson2010-09-281-57/+124
| | | | | | | | Besides a couple of bugs when writing more than a single byte along the GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use bit banging instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: use GMBUS to manage i2c linksChris Wilson2010-09-181-113/+268
| | | | | | | | | | | | | | Use the GMBUS interface rather than direct bit banging to grab the EDID over DDC (and for other forms of auxiliary communication with external display controllers). The hope is that this method will be much faster and more reliable than bit banging for fetching EDIDs from buggy monitors or through switches, though we still preserve the bit banging as a fallback in case GMBUS fails. Based on an original patch by Jesse Barnes. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/i2c: Track the parent encoder rather than just the devChris Wilson2010-09-141-9/+17
| | | | | | | | The SDVO proxy i2c adapter wants to be able to use information stored in the encoder, so pass that through intel_i2c rather than iterate over all known encoders every time. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/i2c: The bit-banging interface controls the delay, drop oursChris Wilson2010-09-111-19/+15
| | | | | | | Remove our redundant udelay() as the timings are already handled by the i2c-algo-bit controller. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge.Eric Anholt2010-02-261-1/+1
| | | | | | I think this is pretty much correct. Not really tested. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Fix product names and #definesAdam Jackson2009-12-071-2/+2
| | | | | | | | | IGD* isn't a useful name. Replace with the codenames, as sourced from pci.ids. Signed-off-by: Adam Jackson <ajax@redhat.com> [anholt: Fixed up for merge with pineview/ironlake changes] Signed-off-by: Eric Anholt <eric@anholt.net>
OpenPOWER on IntegriCloud