DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2006 Dave Airlie <airlied@linux.ie>
|
2010-07-21 06:44:45 +08:00
|
|
|
* Copyright © 2006-2008,2010 Intel Corporation
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
* Jesse Barnes <jesse.barnes@intel.com>
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Eric Anholt <eric@anholt.net>
|
2010-07-21 06:44:45 +08:00
|
|
|
* Chris Wilson <chris@chris-wilson.co.uk>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
*/
|
|
|
|
#include <linux/i2c.h>
|
|
|
|
#include <linux/i2c-algo-bit.h>
|
2011-08-31 06:16:33 +08:00
|
|
|
#include <linux/export.h>
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/drmP.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
#include "intel_drv.h"
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/i915_drm.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
#include "i915_drv.h"
|
|
|
|
|
2015-04-01 15:55:04 +08:00
|
|
|
struct gmbus_pin {
|
2012-03-28 02:36:15 +08:00
|
|
|
const char *name;
|
drm/i915: Type safe register read/write
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
2015-11-18 21:33:26 +08:00
|
|
|
i915_reg_t reg;
|
2012-03-28 02:36:15 +08:00
|
|
|
};
|
|
|
|
|
2015-04-01 15:55:04 +08:00
|
|
|
/* Map gmbus pin pairs to names and registers. */
|
|
|
|
static const struct gmbus_pin gmbus_pins[] = {
|
|
|
|
[GMBUS_PIN_SSC] = { "ssc", GPIOB },
|
|
|
|
[GMBUS_PIN_VGADDC] = { "vga", GPIOA },
|
|
|
|
[GMBUS_PIN_PANEL] = { "panel", GPIOC },
|
|
|
|
[GMBUS_PIN_DPC] = { "dpc", GPIOD },
|
|
|
|
[GMBUS_PIN_DPB] = { "dpb", GPIOE },
|
|
|
|
[GMBUS_PIN_DPD] = { "dpd", GPIOF },
|
2012-03-28 02:36:15 +08:00
|
|
|
};
|
|
|
|
|
2015-05-06 20:33:43 +08:00
|
|
|
static const struct gmbus_pin gmbus_pins_bdw[] = {
|
|
|
|
[GMBUS_PIN_VGADDC] = { "vga", GPIOA },
|
|
|
|
[GMBUS_PIN_DPC] = { "dpc", GPIOD },
|
|
|
|
[GMBUS_PIN_DPB] = { "dpb", GPIOE },
|
|
|
|
[GMBUS_PIN_DPD] = { "dpd", GPIOF },
|
|
|
|
};
|
|
|
|
|
2015-05-06 20:33:44 +08:00
|
|
|
static const struct gmbus_pin gmbus_pins_skl[] = {
|
|
|
|
[GMBUS_PIN_DPC] = { "dpc", GPIOD },
|
|
|
|
[GMBUS_PIN_DPB] = { "dpb", GPIOE },
|
|
|
|
[GMBUS_PIN_DPD] = { "dpd", GPIOF },
|
|
|
|
};
|
|
|
|
|
2015-04-01 15:58:05 +08:00
|
|
|
static const struct gmbus_pin gmbus_pins_bxt[] = {
|
2015-11-05 05:20:00 +08:00
|
|
|
[GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
|
|
|
|
[GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
|
|
|
|
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
|
2015-04-01 15:58:05 +08:00
|
|
|
};
|
|
|
|
|
2017-06-03 04:06:43 +08:00
|
|
|
static const struct gmbus_pin gmbus_pins_cnp[] = {
|
|
|
|
[GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
|
|
|
|
[GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
|
|
|
|
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
|
|
|
|
[GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
|
|
|
|
};
|
|
|
|
|
2015-04-01 15:58:05 +08:00
|
|
|
/* pin is expected to be valid */
|
|
|
|
static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
|
|
|
|
unsigned int pin)
|
|
|
|
{
|
2017-06-03 04:06:43 +08:00
|
|
|
if (HAS_PCH_CNP(dev_priv))
|
|
|
|
return &gmbus_pins_cnp[pin];
|
|
|
|
else if (IS_GEN9_LP(dev_priv))
|
2015-04-01 15:58:05 +08:00
|
|
|
return &gmbus_pins_bxt[pin];
|
2017-01-24 02:32:37 +08:00
|
|
|
else if (IS_GEN9_BC(dev_priv))
|
2015-05-06 20:33:44 +08:00
|
|
|
return &gmbus_pins_skl[pin];
|
2015-05-06 20:33:43 +08:00
|
|
|
else if (IS_BROADWELL(dev_priv))
|
|
|
|
return &gmbus_pins_bdw[pin];
|
2015-04-01 15:58:05 +08:00
|
|
|
else
|
|
|
|
return &gmbus_pins[pin];
|
|
|
|
}
|
|
|
|
|
2015-03-27 06:20:22 +08:00
|
|
|
bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
|
|
|
|
unsigned int pin)
|
|
|
|
{
|
2015-04-01 15:58:05 +08:00
|
|
|
unsigned int size;
|
|
|
|
|
2017-06-03 04:06:43 +08:00
|
|
|
if (HAS_PCH_CNP(dev_priv))
|
|
|
|
size = ARRAY_SIZE(gmbus_pins_cnp);
|
|
|
|
else if (IS_GEN9_LP(dev_priv))
|
2015-04-01 15:58:05 +08:00
|
|
|
size = ARRAY_SIZE(gmbus_pins_bxt);
|
2017-01-24 02:32:37 +08:00
|
|
|
else if (IS_GEN9_BC(dev_priv))
|
2015-05-06 20:33:44 +08:00
|
|
|
size = ARRAY_SIZE(gmbus_pins_skl);
|
2015-05-06 20:33:43 +08:00
|
|
|
else if (IS_BROADWELL(dev_priv))
|
|
|
|
size = ARRAY_SIZE(gmbus_pins_bdw);
|
2015-04-01 15:58:05 +08:00
|
|
|
else
|
|
|
|
size = ARRAY_SIZE(gmbus_pins);
|
|
|
|
|
drm/i915: Type safe register read/write
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
2015-11-18 21:33:26 +08:00
|
|
|
return pin < size &&
|
|
|
|
i915_mmio_reg_valid(get_gmbus_pin(dev_priv, pin)->reg);
|
2015-03-27 06:20:22 +08:00
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
/* Intel GPIO access functions */
|
|
|
|
|
2012-01-28 18:07:09 +08:00
|
|
|
#define I2C_RISEFALL_TIME 10
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2010-09-24 19:52:03 +08:00
|
|
|
static inline struct intel_gmbus *
|
|
|
|
to_intel_gmbus(struct i2c_adapter *i2c)
|
|
|
|
{
|
|
|
|
return container_of(i2c, struct intel_gmbus, adapter);
|
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
void
|
2016-12-01 22:16:44 +08:00
|
|
|
intel_i2c_reset(struct drm_i915_private *dev_priv)
|
2009-04-07 11:02:28 +08:00
|
|
|
{
|
2015-09-19 01:03:38 +08:00
|
|
|
I915_WRITE(GMBUS0, 0);
|
|
|
|
I915_WRITE(GMBUS4, 0);
|
2010-07-21 06:44:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
|
|
|
|
{
|
2010-09-12 04:48:25 +08:00
|
|
|
u32 val;
|
2009-04-07 11:02:28 +08:00
|
|
|
|
|
|
|
/* When using bit bashing for I2C, this bit needs to be set to 1 */
|
2016-04-07 16:08:05 +08:00
|
|
|
if (!IS_PINEVIEW(dev_priv))
|
2009-04-07 11:02:28 +08:00
|
|
|
return;
|
2010-09-12 04:48:25 +08:00
|
|
|
|
|
|
|
val = I915_READ(DSPCLK_GATE_D);
|
2009-04-07 11:02:28 +08:00
|
|
|
if (enable)
|
2010-09-12 04:48:25 +08:00
|
|
|
val |= DPCUNIT_CLOCK_GATE_DISABLE;
|
2009-04-07 11:02:28 +08:00
|
|
|
else
|
2010-09-12 04:48:25 +08:00
|
|
|
val &= ~DPCUNIT_CLOCK_GATE_DISABLE;
|
|
|
|
I915_WRITE(DSPCLK_GATE_D, val);
|
2009-04-07 11:02:28 +08:00
|
|
|
}
|
|
|
|
|
2012-02-15 05:37:22 +08:00
|
|
|
static u32 get_reserved(struct intel_gmbus *bus)
|
2010-09-24 19:52:03 +08:00
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
2010-09-24 19:52:03 +08:00
|
|
|
u32 reserved = 0;
|
|
|
|
|
|
|
|
/* On most chips, these bits must be preserved in software. */
|
2016-11-30 23:43:04 +08:00
|
|
|
if (!IS_I830(dev_priv) && !IS_I845G(dev_priv))
|
2012-02-15 05:37:22 +08:00
|
|
|
reserved = I915_READ_NOTRACE(bus->gpio_reg) &
|
2010-11-08 17:58:16 +08:00
|
|
|
(GPIO_DATA_PULLUP_DISABLE |
|
|
|
|
GPIO_CLOCK_PULLUP_DISABLE);
|
2010-09-24 19:52:03 +08:00
|
|
|
|
|
|
|
return reserved;
|
|
|
|
}
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
static int get_clock(void *data)
|
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct intel_gmbus *bus = data;
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
u32 reserved = get_reserved(bus);
|
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved | GPIO_CLOCK_DIR_MASK);
|
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved);
|
|
|
|
return (I915_READ_NOTRACE(bus->gpio_reg) & GPIO_CLOCK_VAL_IN) != 0;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_data(void *data)
|
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct intel_gmbus *bus = data;
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
u32 reserved = get_reserved(bus);
|
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved | GPIO_DATA_DIR_MASK);
|
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved);
|
|
|
|
return (I915_READ_NOTRACE(bus->gpio_reg) & GPIO_DATA_VAL_IN) != 0;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void set_clock(void *data, int state_high)
|
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct intel_gmbus *bus = data;
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
u32 reserved = get_reserved(bus);
|
2010-09-24 19:52:03 +08:00
|
|
|
u32 clock_bits;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
|
|
|
|
if (state_high)
|
|
|
|
clock_bits = GPIO_CLOCK_DIR_IN | GPIO_CLOCK_DIR_MASK;
|
|
|
|
else
|
|
|
|
clock_bits = GPIO_CLOCK_DIR_OUT | GPIO_CLOCK_DIR_MASK |
|
|
|
|
GPIO_CLOCK_VAL_MASK;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2012-02-15 05:37:22 +08:00
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved | clock_bits);
|
|
|
|
POSTING_READ(bus->gpio_reg);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void set_data(void *data, int state_high)
|
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct intel_gmbus *bus = data;
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
u32 reserved = get_reserved(bus);
|
2010-09-24 19:52:03 +08:00
|
|
|
u32 data_bits;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
|
|
|
|
if (state_high)
|
|
|
|
data_bits = GPIO_DATA_DIR_IN | GPIO_DATA_DIR_MASK;
|
|
|
|
else
|
|
|
|
data_bits = GPIO_DATA_DIR_OUT | GPIO_DATA_DIR_MASK |
|
|
|
|
GPIO_DATA_VAL_MASK;
|
|
|
|
|
2012-02-15 05:37:22 +08:00
|
|
|
I915_WRITE_NOTRACE(bus->gpio_reg, reserved | data_bits);
|
|
|
|
POSTING_READ(bus->gpio_reg);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
2012-03-28 02:36:13 +08:00
|
|
|
static int
|
|
|
|
intel_gpio_pre_xfer(struct i2c_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = container_of(adapter,
|
|
|
|
struct intel_gmbus,
|
|
|
|
adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
2016-12-01 22:16:44 +08:00
|
|
|
intel_i2c_reset(dev_priv);
|
2012-03-28 02:36:13 +08:00
|
|
|
intel_i2c_quirk_set(dev_priv, true);
|
|
|
|
set_data(bus, 1);
|
|
|
|
set_clock(bus, 1);
|
|
|
|
udelay(I2C_RISEFALL_TIME);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
intel_gpio_post_xfer(struct i2c_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = container_of(adapter,
|
|
|
|
struct intel_gmbus,
|
|
|
|
adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
|
|
|
set_data(bus, 1);
|
|
|
|
set_clock(bus, 1);
|
|
|
|
intel_i2c_quirk_set(dev_priv, false);
|
|
|
|
}
|
|
|
|
|
2012-03-28 02:36:15 +08:00
|
|
|
static void
|
2015-04-01 15:55:04 +08:00
|
|
|
intel_gpio_setup(struct intel_gmbus *bus, unsigned int pin)
|
2009-12-02 03:56:30 +08:00
|
|
|
{
|
2012-02-15 05:37:22 +08:00
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
struct i2c_algo_bit_data *algo;
|
2009-12-02 03:56:30 +08:00
|
|
|
|
2012-02-28 07:43:09 +08:00
|
|
|
algo = &bus->bit_algo;
|
2012-02-15 05:37:22 +08:00
|
|
|
|
drm/i915: Type safe register read/write
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
2015-11-18 21:33:26 +08:00
|
|
|
bus->gpio_reg = _MMIO(dev_priv->gpio_mmio_base +
|
|
|
|
i915_mmio_reg_offset(get_gmbus_pin(dev_priv, pin)->reg));
|
2012-02-28 07:43:09 +08:00
|
|
|
bus->adapter.algo_data = algo;
|
2012-02-15 05:37:22 +08:00
|
|
|
algo->setsda = set_data;
|
|
|
|
algo->setscl = set_clock;
|
|
|
|
algo->getsda = get_data;
|
|
|
|
algo->getscl = get_clock;
|
2012-03-28 02:36:13 +08:00
|
|
|
algo->pre_xfer = intel_gpio_pre_xfer;
|
|
|
|
algo->post_xfer = intel_gpio_post_xfer;
|
2012-02-15 05:37:22 +08:00
|
|
|
algo->udelay = I2C_RISEFALL_TIME;
|
|
|
|
algo->timeout = usecs_to_jiffies(2200);
|
|
|
|
algo->data = bus;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
static int gmbus_wait(struct drm_i915_private *dev_priv, u32 status, u32 irq_en)
|
2012-12-01 20:53:43 +08:00
|
|
|
{
|
2012-12-01 20:53:45 +08:00
|
|
|
DEFINE_WAIT(wait);
|
2016-08-20 00:45:02 +08:00
|
|
|
u32 gmbus2;
|
|
|
|
int ret;
|
2013-03-19 16:56:57 +08:00
|
|
|
|
2012-12-01 20:53:45 +08:00
|
|
|
/* Important: The hw handles only the first bit, so set only one! Since
|
|
|
|
* we also need to check for NAKs besides the hw ready/idle signal, we
|
2016-08-20 00:45:02 +08:00
|
|
|
* need to wake up periodically and check that ourselves.
|
|
|
|
*/
|
|
|
|
if (!HAS_GMBUS_IRQ(dev_priv))
|
|
|
|
irq_en = 0;
|
2012-12-01 20:53:45 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
add_wait_queue(&dev_priv->gmbus_wait_queue, &wait);
|
|
|
|
I915_WRITE_FW(GMBUS4, irq_en);
|
2012-12-01 20:53:43 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
status |= GMBUS_SATOER;
|
|
|
|
ret = wait_for_us((gmbus2 = I915_READ_FW(GMBUS2)) & status, 2);
|
|
|
|
if (ret)
|
|
|
|
ret = wait_for((gmbus2 = I915_READ_FW(GMBUS2)) & status, 50);
|
2012-12-01 20:53:45 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS4, 0);
|
|
|
|
remove_wait_queue(&dev_priv->gmbus_wait_queue, &wait);
|
2012-12-01 20:53:43 +08:00
|
|
|
|
|
|
|
if (gmbus2 & GMBUS_SATOER)
|
|
|
|
return -ENXIO;
|
2016-08-20 00:45:02 +08:00
|
|
|
|
|
|
|
return ret;
|
2012-12-01 20:53:43 +08:00
|
|
|
}
|
|
|
|
|
2012-12-01 20:53:46 +08:00
|
|
|
static int
|
|
|
|
gmbus_wait_idle(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2016-08-20 00:45:02 +08:00
|
|
|
DEFINE_WAIT(wait);
|
|
|
|
u32 irq_enable;
|
2012-12-01 20:53:46 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Important: The hw handles only the first bit, so set only one! */
|
2016-08-20 00:45:02 +08:00
|
|
|
irq_enable = 0;
|
|
|
|
if (HAS_GMBUS_IRQ(dev_priv))
|
|
|
|
irq_enable = GMBUS_IDLE_EN;
|
2012-12-01 20:53:46 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
add_wait_queue(&dev_priv->gmbus_wait_queue, &wait);
|
|
|
|
I915_WRITE_FW(GMBUS4, irq_enable);
|
2012-12-01 20:53:46 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
ret = intel_wait_for_register_fw(dev_priv,
|
|
|
|
GMBUS2, GMBUS_ACTIVE, 0,
|
|
|
|
10);
|
2012-12-01 20:53:46 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS4, 0);
|
|
|
|
remove_wait_queue(&dev_priv->gmbus_wait_queue, &wait);
|
|
|
|
|
|
|
|
return ret;
|
2012-12-01 20:53:46 +08:00
|
|
|
}
|
|
|
|
|
2012-03-28 02:36:10 +08:00
|
|
|
static int
|
2015-04-22 00:49:11 +08:00
|
|
|
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
|
|
|
|
unsigned short addr, u8 *buf, unsigned int len,
|
|
|
|
u32 gmbus1_index)
|
2012-03-28 02:36:10 +08:00
|
|
|
{
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS1,
|
|
|
|
gmbus1_index |
|
|
|
|
GMBUS_CYCLE_WAIT |
|
|
|
|
(len << GMBUS_BYTE_COUNT_SHIFT) |
|
|
|
|
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
|
|
|
|
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
|
2012-04-13 19:47:53 +08:00
|
|
|
while (len) {
|
2012-03-30 19:46:41 +08:00
|
|
|
int ret;
|
2012-03-28 02:36:10 +08:00
|
|
|
u32 val, loop = 0;
|
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
ret = gmbus_wait(dev_priv, GMBUS_HW_RDY, GMBUS_HW_RDY_EN);
|
2012-03-30 19:46:41 +08:00
|
|
|
if (ret)
|
2012-12-01 20:53:43 +08:00
|
|
|
return ret;
|
2012-03-28 02:36:10 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
val = I915_READ_FW(GMBUS3);
|
2012-03-28 02:36:10 +08:00
|
|
|
do {
|
|
|
|
*buf++ = val & 0xff;
|
|
|
|
val >>= 8;
|
|
|
|
} while (--len && ++loop < 4);
|
2012-04-13 19:47:53 +08:00
|
|
|
}
|
2012-03-28 02:36:10 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2015-04-22 00:49:11 +08:00
|
|
|
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
|
|
|
|
u32 gmbus1_index)
|
2012-03-28 02:36:10 +08:00
|
|
|
{
|
|
|
|
u8 *buf = msg->buf;
|
2015-04-22 00:49:11 +08:00
|
|
|
unsigned int rx_size = msg->len;
|
|
|
|
unsigned int len;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
do {
|
|
|
|
len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
|
|
|
|
|
|
|
|
ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
|
|
|
|
buf, len, gmbus1_index);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
rx_size -= len;
|
|
|
|
buf += len;
|
|
|
|
} while (rx_size != 0);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
|
|
|
|
unsigned short addr, u8 *buf, unsigned int len)
|
|
|
|
{
|
|
|
|
unsigned int chunk_size = len;
|
2012-03-28 02:36:10 +08:00
|
|
|
u32 val, loop;
|
|
|
|
|
|
|
|
val = loop = 0;
|
2012-03-30 19:46:36 +08:00
|
|
|
while (len && loop < 4) {
|
|
|
|
val |= *buf++ << (8 * loop++);
|
|
|
|
len -= 1;
|
|
|
|
}
|
2012-03-28 02:36:10 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS3, val);
|
|
|
|
I915_WRITE_FW(GMBUS1,
|
|
|
|
GMBUS_CYCLE_WAIT |
|
|
|
|
(chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
|
|
|
|
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
|
|
|
|
GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
|
2012-03-28 02:36:10 +08:00
|
|
|
while (len) {
|
2012-03-30 19:46:41 +08:00
|
|
|
int ret;
|
|
|
|
|
2012-03-28 02:36:10 +08:00
|
|
|
val = loop = 0;
|
|
|
|
do {
|
|
|
|
val |= *buf++ << (8 * loop);
|
|
|
|
} while (--len && ++loop < 4);
|
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS3, val);
|
2012-03-30 19:46:37 +08:00
|
|
|
|
2016-08-20 00:45:02 +08:00
|
|
|
ret = gmbus_wait(dev_priv, GMBUS_HW_RDY, GMBUS_HW_RDY_EN);
|
2012-03-30 19:46:41 +08:00
|
|
|
if (ret)
|
2012-12-01 20:53:43 +08:00
|
|
|
return ret;
|
2012-03-28 02:36:10 +08:00
|
|
|
}
|
2015-04-22 00:49:11 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
|
|
|
|
{
|
|
|
|
u8 *buf = msg->buf;
|
|
|
|
unsigned int tx_size = msg->len;
|
|
|
|
unsigned int len;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
do {
|
|
|
|
len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
|
|
|
|
|
|
|
|
ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
buf += len;
|
|
|
|
tx_size -= len;
|
|
|
|
} while (tx_size != 0);
|
|
|
|
|
2012-03-28 02:36:10 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-03-30 19:46:40 +08:00
|
|
|
/*
|
|
|
|
* The gmbus controller can combine a 1 or 2 byte write with a read that
|
|
|
|
* immediately follows it by using an "INDEX" cycle.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
|
|
|
|
{
|
|
|
|
return (i + 1 < num &&
|
2017-11-24 03:41:56 +08:00
|
|
|
msgs[i].addr == msgs[i + 1].addr &&
|
2017-11-24 03:41:57 +08:00
|
|
|
!(msgs[i].flags & I2C_M_RD) &&
|
|
|
|
(msgs[i].len == 1 || msgs[i].len == 2) &&
|
2012-03-30 19:46:40 +08:00
|
|
|
(msgs[i + 1].flags & I2C_M_RD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
|
|
|
|
{
|
|
|
|
u32 gmbus1_index = 0;
|
|
|
|
u32 gmbus5 = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (msgs[0].len == 2)
|
|
|
|
gmbus5 = GMBUS_2BYTE_INDEX_EN |
|
|
|
|
msgs[0].buf[1] | (msgs[0].buf[0] << 8);
|
|
|
|
if (msgs[0].len == 1)
|
|
|
|
gmbus1_index = GMBUS_CYCLE_INDEX |
|
|
|
|
(msgs[0].buf[0] << GMBUS_SLAVE_INDEX_SHIFT);
|
|
|
|
|
|
|
|
/* GMBUS5 holds 16-bit index */
|
|
|
|
if (gmbus5)
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS5, gmbus5);
|
2012-03-30 19:46:40 +08:00
|
|
|
|
|
|
|
ret = gmbus_xfer_read(dev_priv, &msgs[1], gmbus1_index);
|
|
|
|
|
|
|
|
/* Clear GMBUS5 after each index transfer */
|
|
|
|
if (gmbus5)
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS5, 0);
|
2012-03-30 19:46:40 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
static int
|
2015-12-01 22:29:26 +08:00
|
|
|
do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
|
2010-07-21 06:44:45 +08:00
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = container_of(adapter,
|
|
|
|
struct intel_gmbus,
|
|
|
|
adapter);
|
2012-02-15 05:37:19 +08:00
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
2015-09-19 01:03:38 +08:00
|
|
|
int i = 0, inc, try = 0;
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
int ret = 0;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
drm/i915: Fix DDC probe for passive adapters
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>
2015-06-03 00:21:15 +08:00
|
|
|
retry:
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS0, bus->reg0);
|
2010-07-21 06:44:45 +08:00
|
|
|
|
drm/i915: Fix DDC probe for passive adapters
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>
2015-06-03 00:21:15 +08:00
|
|
|
for (; i < num; i += inc) {
|
|
|
|
inc = 1;
|
2012-03-30 19:46:40 +08:00
|
|
|
if (gmbus_is_index_read(msgs, i, num)) {
|
|
|
|
ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
|
drm/i915: Fix DDC probe for passive adapters
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>
2015-06-03 00:21:15 +08:00
|
|
|
inc = 2; /* an index read is two msgs */
|
2012-03-30 19:46:40 +08:00
|
|
|
} else if (msgs[i].flags & I2C_M_RD) {
|
|
|
|
ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
|
|
|
|
} else {
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
ret = gmbus_xfer_write(dev_priv, &msgs[i]);
|
2012-03-30 19:46:40 +08:00
|
|
|
}
|
2012-03-28 02:36:10 +08:00
|
|
|
|
2015-12-01 22:29:25 +08:00
|
|
|
if (!ret)
|
2016-08-20 00:45:02 +08:00
|
|
|
ret = gmbus_wait(dev_priv,
|
|
|
|
GMBUS_HW_WAIT_PHASE, GMBUS_HW_WAIT_EN);
|
2012-03-28 02:36:10 +08:00
|
|
|
if (ret == -ETIMEDOUT)
|
|
|
|
goto timeout;
|
2015-12-01 22:29:25 +08:00
|
|
|
else if (ret)
|
2012-03-28 02:36:10 +08:00
|
|
|
goto clear_err;
|
2010-07-21 06:44:45 +08:00
|
|
|
}
|
|
|
|
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
/* Generate a STOP condition on the bus. Note that gmbus can't generata
|
|
|
|
* a STOP on the very first cycle. To simplify the code we
|
|
|
|
* unconditionally generate the STOP condition with an additional gmbus
|
|
|
|
* cycle. */
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS1, GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
|
2012-03-30 19:46:38 +08:00
|
|
|
/* Mark the GMBUS interface as disabled after waiting for idle.
|
|
|
|
* We will re-enable it at the start of the next xfer,
|
|
|
|
* till then let it sleep.
|
|
|
|
*/
|
2012-12-01 20:53:46 +08:00
|
|
|
if (gmbus_wait_idle(dev_priv)) {
|
2012-04-13 19:47:54 +08:00
|
|
|
DRM_DEBUG_KMS("GMBUS [%s] timed out waiting for idle\n",
|
2012-03-30 19:46:38 +08:00
|
|
|
adapter->name);
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
ret = -ETIMEDOUT;
|
|
|
|
}
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS0, 0);
|
drm/i915/intel_i2c: use WAIT cycle, not STOP
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>
2012-03-30 19:46:39 +08:00
|
|
|
ret = ret ?: i;
|
2012-03-30 19:46:38 +08:00
|
|
|
goto out;
|
2011-03-30 23:20:43 +08:00
|
|
|
|
|
|
|
clear_err:
|
2012-03-30 19:46:38 +08:00
|
|
|
/*
|
|
|
|
* Wait for bus to IDLE before clearing NAK.
|
|
|
|
* If we clear the NAK while bus is still active, then it will stay
|
|
|
|
* active and the next transaction may fail.
|
2012-05-22 02:19:48 +08:00
|
|
|
*
|
|
|
|
* If no ACK is received during the address phase of a transaction, the
|
|
|
|
* adapter must report -ENXIO. It is not clear what to return if no ACK
|
|
|
|
* is received at other times. But we have to be careful to not return
|
|
|
|
* spurious -ENXIO because that will prevent i2c and drm edid functions
|
|
|
|
* from retrying. So return -ENXIO only when gmbus properly quiescents -
|
|
|
|
* timing out seems to happen when there _is_ a ddc chip present, but
|
|
|
|
* it's slow responding and only answers on the 2nd retry.
|
2012-03-30 19:46:38 +08:00
|
|
|
*/
|
2012-05-22 02:19:48 +08:00
|
|
|
ret = -ENXIO;
|
2012-12-01 20:53:46 +08:00
|
|
|
if (gmbus_wait_idle(dev_priv)) {
|
2012-04-13 19:47:54 +08:00
|
|
|
DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
|
|
|
|
adapter->name);
|
2012-05-22 02:19:48 +08:00
|
|
|
ret = -ETIMEDOUT;
|
|
|
|
}
|
2012-03-30 19:46:38 +08:00
|
|
|
|
2011-03-30 23:20:43 +08:00
|
|
|
/* Toggle the Software Clear Interrupt bit. This has the effect
|
|
|
|
* of resetting the GMBUS controller and so clearing the
|
|
|
|
* BUS_ERROR raised by the slave's NAK.
|
|
|
|
*/
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS1, GMBUS_SW_CLR_INT);
|
|
|
|
I915_WRITE_FW(GMBUS1, 0);
|
|
|
|
I915_WRITE_FW(GMBUS0, 0);
|
2011-03-30 23:20:43 +08:00
|
|
|
|
2012-04-13 19:47:54 +08:00
|
|
|
DRM_DEBUG_KMS("GMBUS [%s] NAK for addr: %04x %c(%d)\n",
|
2012-03-30 19:46:38 +08:00
|
|
|
adapter->name, msgs[i].addr,
|
|
|
|
(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
|
|
|
|
|
drm/i915: Fix DDC probe for passive adapters
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>
2015-06-03 00:21:15 +08:00
|
|
|
/*
|
|
|
|
* Passive adapters sometimes NAK the first probe. Retry the first
|
|
|
|
* message once on -ENXIO for GMBUS transfers; the bit banging algorithm
|
|
|
|
* has retries internally. See also the retry loop in
|
|
|
|
* drm_do_probe_ddc_edid, which bails out on the first -ENXIO.
|
|
|
|
*/
|
|
|
|
if (ret == -ENXIO && i == 0 && try++ == 0) {
|
|
|
|
DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
|
|
|
|
adapter->name);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
goto out;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
timeout:
|
2016-03-07 23:57:00 +08:00
|
|
|
DRM_DEBUG_KMS("GMBUS [%s] timed out, falling back to bit banging on pin %d\n",
|
|
|
|
bus->adapter.name, bus->reg0 & 0xff);
|
2016-08-20 00:45:02 +08:00
|
|
|
I915_WRITE_FW(GMBUS0, 0);
|
2011-03-30 23:20:43 +08:00
|
|
|
|
2015-12-01 22:29:26 +08:00
|
|
|
/*
|
|
|
|
* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
|
|
|
|
* instead. Use EAGAIN to have i2c core retry.
|
|
|
|
*/
|
|
|
|
ret = -EAGAIN;
|
2012-03-28 02:36:13 +08:00
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
out:
|
2015-12-01 22:29:26 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = container_of(adapter, struct intel_gmbus,
|
|
|
|
adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
|
2016-03-07 23:56:59 +08:00
|
|
|
if (bus->force_bit) {
|
2015-12-01 22:29:26 +08:00
|
|
|
ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
|
2016-03-07 23:56:59 +08:00
|
|
|
if (ret < 0)
|
|
|
|
bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
|
|
|
|
} else {
|
2015-12-01 22:29:26 +08:00
|
|
|
ret = do_gmbus_xfer(adapter, msgs, num);
|
2016-03-07 23:56:59 +08:00
|
|
|
if (ret == -EAGAIN)
|
|
|
|
bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
|
|
|
|
}
|
2015-11-09 23:48:19 +08:00
|
|
|
|
|
|
|
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
return ret;
|
2010-07-21 06:44:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 gmbus_func(struct i2c_adapter *adapter)
|
|
|
|
{
|
2012-02-15 01:58:49 +08:00
|
|
|
return i2c_bit_algo.functionality(adapter) &
|
|
|
|
(I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
|
2010-07-21 06:44:45 +08:00
|
|
|
/* I2C_FUNC_10BIT_ADDR | */
|
|
|
|
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
|
|
|
|
I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct i2c_algorithm gmbus_algorithm = {
|
|
|
|
.master_xfer = gmbus_xfer,
|
|
|
|
.functionality = gmbus_func
|
|
|
|
};
|
|
|
|
|
2017-07-26 21:26:47 +08:00
|
|
|
static void gmbus_lock_bus(struct i2c_adapter *adapter,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = to_intel_gmbus(adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
|
|
|
mutex_lock(&dev_priv->gmbus_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int gmbus_trylock_bus(struct i2c_adapter *adapter,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = to_intel_gmbus(adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
|
|
|
return mutex_trylock(&dev_priv->gmbus_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void gmbus_unlock_bus(struct i2c_adapter *adapter,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = to_intel_gmbus(adapter);
|
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
|
|
|
mutex_unlock(&dev_priv->gmbus_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-01 22:31:22 +08:00
|
|
|
static const struct i2c_lock_operations gmbus_lock_ops = {
|
2017-07-26 21:26:47 +08:00
|
|
|
.lock_bus = gmbus_lock_bus,
|
|
|
|
.trylock_bus = gmbus_trylock_bus,
|
|
|
|
.unlock_bus = gmbus_unlock_bus,
|
|
|
|
};
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
/**
|
2010-07-21 06:44:45 +08:00
|
|
|
* intel_gmbus_setup - instantiate all Intel i2c GMBuses
|
2016-12-01 22:16:42 +08:00
|
|
|
* @dev_priv: i915 device private
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
*/
|
2016-12-01 22:16:42 +08:00
|
|
|
int intel_setup_gmbus(struct drm_i915_private *dev_priv)
|
2010-07-21 06:44:45 +08:00
|
|
|
{
|
2016-08-22 18:32:44 +08:00
|
|
|
struct pci_dev *pdev = dev_priv->drm.pdev;
|
2015-04-01 15:55:04 +08:00
|
|
|
struct intel_gmbus *bus;
|
|
|
|
unsigned int pin;
|
|
|
|
int ret;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_NOP(dev_priv))
|
2013-04-06 04:12:41 +08:00
|
|
|
return 0;
|
2015-11-05 05:20:00 +08:00
|
|
|
|
2016-10-14 17:13:44 +08:00
|
|
|
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
|
2013-01-24 21:29:55 +08:00
|
|
|
dev_priv->gpio_mmio_base = VLV_DISPLAY_BASE;
|
drm/i915: Type safe register read/write
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
2015-11-18 21:33:26 +08:00
|
|
|
else if (!HAS_GMCH_DISPLAY(dev_priv))
|
|
|
|
dev_priv->gpio_mmio_base =
|
|
|
|
i915_mmio_reg_offset(PCH_GPIOA) -
|
|
|
|
i915_mmio_reg_offset(GPIOA);
|
2012-03-24 06:43:36 +08:00
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
mutex_init(&dev_priv->gmbus_mutex);
|
2012-12-01 20:53:45 +08:00
|
|
|
init_waitqueue_head(&dev_priv->gmbus_wait_queue);
|
2012-02-14 06:36:54 +08:00
|
|
|
|
2015-04-01 15:55:04 +08:00
|
|
|
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
|
2015-03-27 06:20:22 +08:00
|
|
|
if (!intel_gmbus_is_valid_pin(dev_priv, pin))
|
2015-04-01 15:55:04 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
bus = &dev_priv->gmbus[pin];
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
bus->adapter.owner = THIS_MODULE;
|
|
|
|
bus->adapter.class = I2C_CLASS_DDC;
|
|
|
|
snprintf(bus->adapter.name,
|
2010-11-06 01:51:34 +08:00
|
|
|
sizeof(bus->adapter.name),
|
|
|
|
"i915 gmbus %s",
|
2015-04-01 15:58:05 +08:00
|
|
|
get_gmbus_pin(dev_priv, pin)->name);
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2016-08-22 18:32:44 +08:00
|
|
|
bus->adapter.dev.parent = &pdev->dev;
|
2012-02-15 05:37:19 +08:00
|
|
|
bus->dev_priv = dev_priv;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
bus->adapter.algo = &gmbus_algorithm;
|
2017-07-26 21:26:47 +08:00
|
|
|
bus->adapter.lock_ops = &gmbus_lock_ops;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2016-03-07 23:56:57 +08:00
|
|
|
/*
|
|
|
|
* We wish to retry with bit banging
|
|
|
|
* after a timed out GMBUS attempt.
|
|
|
|
*/
|
|
|
|
bus->adapter.retries = 1;
|
|
|
|
|
2010-09-24 19:52:03 +08:00
|
|
|
/* By default use a conservative clock rate */
|
2015-04-01 15:55:04 +08:00
|
|
|
bus->reg0 = pin | GMBUS_RATE_100KHZ;
|
2010-09-28 20:35:47 +08:00
|
|
|
|
2012-05-13 20:44:20 +08:00
|
|
|
/* gmbus seems to be broken on i830 */
|
2016-10-13 18:02:58 +08:00
|
|
|
if (IS_I830(dev_priv))
|
2012-11-10 23:58:21 +08:00
|
|
|
bus->force_bit = 1;
|
2012-05-13 20:44:20 +08:00
|
|
|
|
2015-04-01 15:55:04 +08:00
|
|
|
intel_gpio_setup(bus, pin);
|
2012-08-13 22:33:02 +08:00
|
|
|
|
|
|
|
ret = i2c_add_adapter(&bus->adapter);
|
|
|
|
if (ret)
|
|
|
|
goto err;
|
2010-07-21 06:44:45 +08:00
|
|
|
}
|
|
|
|
|
2016-12-01 22:16:44 +08:00
|
|
|
intel_i2c_reset(dev_priv);
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
2016-02-10 04:11:13 +08:00
|
|
|
while (pin--) {
|
2015-03-27 06:20:22 +08:00
|
|
|
if (!intel_gmbus_is_valid_pin(dev_priv, pin))
|
2015-04-01 15:55:04 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
bus = &dev_priv->gmbus[pin];
|
2010-07-21 06:44:45 +08:00
|
|
|
i2c_del_adapter(&bus->adapter);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-03-28 02:36:14 +08:00
|
|
|
struct i2c_adapter *intel_gmbus_get_adapter(struct drm_i915_private *dev_priv,
|
2015-03-27 06:20:20 +08:00
|
|
|
unsigned int pin)
|
2012-03-28 02:36:14 +08:00
|
|
|
{
|
2015-03-27 06:20:22 +08:00
|
|
|
if (WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin)))
|
2015-04-01 15:55:04 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return &dev_priv->gmbus[pin].adapter;
|
2012-03-28 02:36:14 +08:00
|
|
|
}
|
|
|
|
|
2010-09-24 19:52:03 +08:00
|
|
|
void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = to_intel_gmbus(adapter);
|
|
|
|
|
2011-06-17 04:36:28 +08:00
|
|
|
bus->reg0 = (bus->reg0 & ~(0x3 << 8)) | speed;
|
2010-09-24 19:52:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
|
|
|
|
{
|
|
|
|
struct intel_gmbus *bus = to_intel_gmbus(adapter);
|
2016-03-07 23:56:58 +08:00
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
|
|
|
|
|
|
|
mutex_lock(&dev_priv->gmbus_mutex);
|
2010-09-24 19:52:03 +08:00
|
|
|
|
2012-11-10 23:58:21 +08:00
|
|
|
bus->force_bit += force_bit ? 1 : -1;
|
|
|
|
DRM_DEBUG_KMS("%sabling bit-banging on %s. force bit now %d\n",
|
|
|
|
force_bit ? "en" : "dis", adapter->name,
|
|
|
|
bus->force_bit);
|
2016-03-07 23:56:58 +08:00
|
|
|
|
|
|
|
mutex_unlock(&dev_priv->gmbus_mutex);
|
2010-09-24 19:52:03 +08:00
|
|
|
}
|
|
|
|
|
2016-12-01 22:16:42 +08:00
|
|
|
void intel_teardown_gmbus(struct drm_i915_private *dev_priv)
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
{
|
2015-04-01 15:55:04 +08:00
|
|
|
struct intel_gmbus *bus;
|
|
|
|
unsigned int pin;
|
|
|
|
|
|
|
|
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
|
2015-03-27 06:20:22 +08:00
|
|
|
if (!intel_gmbus_is_valid_pin(dev_priv, pin))
|
2015-04-01 15:55:04 +08:00
|
|
|
continue;
|
2009-05-31 03:16:25 +08:00
|
|
|
|
2015-04-01 15:55:04 +08:00
|
|
|
bus = &dev_priv->gmbus[pin];
|
2010-07-21 06:44:45 +08:00
|
|
|
i2c_del_adapter(&bus->adapter);
|
|
|
|
}
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|