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"
|
|
|
|
|
2012-03-28 02:36:15 +08:00
|
|
|
struct gmbus_port {
|
|
|
|
const char *name;
|
|
|
|
int reg;
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct gmbus_port gmbus_ports[] = {
|
|
|
|
{ "ssc", GPIOB },
|
|
|
|
{ "vga", GPIOA },
|
|
|
|
{ "panel", GPIOC },
|
|
|
|
{ "dpc", GPIOD },
|
|
|
|
{ "dpb", GPIOE },
|
|
|
|
{ "dpd", GPIOF },
|
|
|
|
};
|
|
|
|
|
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
|
|
|
|
intel_i2c_reset(struct drm_device *dev)
|
2009-04-07 11:02:28 +08:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-03-24 06:43:36 +08:00
|
|
|
I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 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 */
|
2010-07-21 06:44:45 +08:00
|
|
|
if (!IS_PINEVIEW(dev_priv->dev))
|
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
|
|
|
struct drm_device *dev = dev_priv->dev;
|
|
|
|
u32 reserved = 0;
|
|
|
|
|
|
|
|
/* On most chips, these bits must be preserved in software. */
|
|
|
|
if (!IS_I830(dev) && !IS_845G(dev))
|
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;
|
|
|
|
|
|
|
|
intel_i2c_reset(dev_priv->dev);
|
|
|
|
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
|
2012-02-15 01:58:49 +08:00
|
|
|
intel_gpio_setup(struct intel_gmbus *bus, u32 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
|
|
|
|
2012-03-28 02:36:15 +08:00
|
|
|
/* -1 to map pin pair to gmbus index */
|
|
|
|
bus->gpio_reg = dev_priv->gpio_mmio_base + gmbus_ports[pin - 1].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-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
|
|
|
}
|
|
|
|
|
2012-03-28 02:36:10 +08:00
|
|
|
static int
|
2012-03-30 19:46:40 +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
|
|
|
{
|
|
|
|
int reg_offset = dev_priv->gpio_mmio_base;
|
|
|
|
u16 len = msg->len;
|
|
|
|
u8 *buf = msg->buf;
|
|
|
|
|
|
|
|
I915_WRITE(GMBUS1 + reg_offset,
|
2012-03-30 19:46:40 +08:00
|
|
|
gmbus1_index |
|
2012-03-28 02:36:10 +08:00
|
|
|
GMBUS_CYCLE_WAIT |
|
|
|
|
(len << GMBUS_BYTE_COUNT_SHIFT) |
|
|
|
|
(msg->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;
|
2012-03-30 19:46:41 +08:00
|
|
|
u32 gmbus2;
|
2012-03-28 02:36:10 +08:00
|
|
|
|
2012-03-30 19:46:41 +08:00
|
|
|
ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
|
|
|
|
(GMBUS_SATOER | GMBUS_HW_RDY),
|
|
|
|
50);
|
|
|
|
if (ret)
|
2012-03-28 02:36:10 +08:00
|
|
|
return -ETIMEDOUT;
|
2012-03-30 19:46:41 +08:00
|
|
|
if (gmbus2 & GMBUS_SATOER)
|
2012-03-28 02:36:10 +08:00
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
val = I915_READ(GMBUS3 + reg_offset);
|
|
|
|
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
|
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
|
|
|
gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
|
2012-03-28 02:36:10 +08:00
|
|
|
{
|
|
|
|
int reg_offset = dev_priv->gpio_mmio_base;
|
|
|
|
u16 len = msg->len;
|
|
|
|
u8 *buf = msg->buf;
|
|
|
|
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
|
|
|
|
|
|
|
I915_WRITE(GMBUS3 + reg_offset, val);
|
|
|
|
I915_WRITE(GMBUS1 + reg_offset,
|
|
|
|
GMBUS_CYCLE_WAIT |
|
|
|
|
(msg->len << GMBUS_BYTE_COUNT_SHIFT) |
|
|
|
|
(msg->addr << GMBUS_SLAVE_ADDR_SHIFT) |
|
|
|
|
GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
|
|
|
|
while (len) {
|
2012-03-30 19:46:41 +08:00
|
|
|
int ret;
|
|
|
|
u32 gmbus2;
|
|
|
|
|
2012-03-28 02:36:10 +08:00
|
|
|
val = loop = 0;
|
|
|
|
do {
|
|
|
|
val |= *buf++ << (8 * loop);
|
|
|
|
} while (--len && ++loop < 4);
|
|
|
|
|
|
|
|
I915_WRITE(GMBUS3 + reg_offset, val);
|
2012-03-30 19:46:37 +08:00
|
|
|
|
2012-03-30 19:46:41 +08:00
|
|
|
ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
|
|
|
|
(GMBUS_SATOER | GMBUS_HW_RDY),
|
|
|
|
50);
|
|
|
|
if (ret)
|
2012-03-30 19:46:37 +08:00
|
|
|
return -ETIMEDOUT;
|
2012-03-30 19:46:41 +08:00
|
|
|
if (gmbus2 & GMBUS_SATOER)
|
2012-03-30 19:46:37 +08:00
|
|
|
return -ENXIO;
|
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 &&
|
|
|
|
!(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 &&
|
|
|
|
(msgs[i + 1].flags & I2C_M_RD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
|
|
|
|
{
|
|
|
|
int reg_offset = dev_priv->gpio_mmio_base;
|
|
|
|
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)
|
|
|
|
I915_WRITE(GMBUS5 + reg_offset, gmbus5);
|
|
|
|
|
|
|
|
ret = gmbus_xfer_read(dev_priv, &msgs[1], gmbus1_index);
|
|
|
|
|
|
|
|
/* Clear GMBUS5 after each index transfer */
|
|
|
|
if (gmbus5)
|
|
|
|
I915_WRITE(GMBUS5 + reg_offset, 0);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
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);
|
2012-02-15 05:37:19 +08:00
|
|
|
struct drm_i915_private *dev_priv = bus->dev_priv;
|
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 i, reg_offset;
|
|
|
|
int ret = 0;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
mutex_lock(&dev_priv->gmbus_mutex);
|
|
|
|
|
|
|
|
if (bus->force_bit) {
|
2012-03-28 02:36:13 +08:00
|
|
|
ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
|
2012-02-14 06:36:54 +08:00
|
|
|
goto out;
|
|
|
|
}
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2012-03-24 06:43:36 +08:00
|
|
|
reg_offset = dev_priv->gpio_mmio_base;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
2010-09-24 19:52:03 +08:00
|
|
|
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
for (i = 0; i < num; i++) {
|
2012-03-30 19:46:41 +08:00
|
|
|
u32 gmbus2;
|
|
|
|
|
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]);
|
|
|
|
i += 1; /* set i to the index of the read xfer */
|
|
|
|
} 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
|
|
|
|
|
|
|
if (ret == -ETIMEDOUT)
|
|
|
|
goto timeout;
|
|
|
|
if (ret == -ENXIO)
|
|
|
|
goto clear_err;
|
|
|
|
|
2012-03-30 19:46:41 +08:00
|
|
|
ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
|
|
|
|
(GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
|
|
|
|
50);
|
|
|
|
if (ret)
|
2010-07-21 06:44:45 +08:00
|
|
|
goto timeout;
|
2012-03-30 19:46:41 +08:00
|
|
|
if (gmbus2 & GMBUS_SATOER)
|
2011-03-30 23:20:43 +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. */
|
|
|
|
I915_WRITE(GMBUS1 + reg_offset, GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
|
|
|
|
|
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.
|
|
|
|
*/
|
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
|
|
|
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
|
|
|
|
10)) {
|
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;
|
|
|
|
}
|
2012-03-30 19:46:38 +08:00
|
|
|
I915_WRITE(GMBUS0 + reg_offset, 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-03-30 19:46:38 +08:00
|
|
|
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
|
2012-05-22 02:19:48 +08:00
|
|
|
10)) {
|
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.
|
|
|
|
*/
|
|
|
|
I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
|
|
|
|
I915_WRITE(GMBUS1 + reg_offset, 0);
|
2012-03-30 19:46:38 +08:00
|
|
|
I915_WRITE(GMBUS0 + reg_offset, 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);
|
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
goto out;
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
timeout:
|
2012-03-28 02:36:11 +08:00
|
|
|
DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin %d\n",
|
|
|
|
bus->adapter.name, bus->reg0 & 0xff);
|
2011-03-30 23:20:43 +08:00
|
|
|
I915_WRITE(GMBUS0 + reg_offset, 0);
|
|
|
|
|
2012-03-28 02:36:15 +08:00
|
|
|
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */
|
2012-11-10 23:58:21 +08:00
|
|
|
bus->force_bit = 1;
|
2012-03-28 02:36:15 +08:00
|
|
|
ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
|
2012-03-28 02:36:13 +08:00
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
out:
|
|
|
|
mutex_unlock(&dev_priv->gmbus_mutex);
|
|
|
|
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
|
|
|
|
};
|
|
|
|
|
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
|
|
|
|
* @dev: DRM device
|
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
|
|
|
int intel_setup_gmbus(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int ret, i;
|
|
|
|
|
2012-03-24 06:43:36 +08:00
|
|
|
if (HAS_PCH_SPLIT(dev))
|
|
|
|
dev_priv->gpio_mmio_base = PCH_GPIOA - GPIOA;
|
|
|
|
else
|
|
|
|
dev_priv->gpio_mmio_base = 0;
|
|
|
|
|
2012-02-14 06:36:54 +08:00
|
|
|
mutex_init(&dev_priv->gmbus_mutex);
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
for (i = 0; i < GMBUS_NUM_PORTS; i++) {
|
|
|
|
struct intel_gmbus *bus = &dev_priv->gmbus[i];
|
2012-03-28 02:36:15 +08:00
|
|
|
u32 port = i + 1; /* +1 to map gmbus index to pin pair */
|
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",
|
2012-03-28 02:36:15 +08:00
|
|
|
gmbus_ports[i].name);
|
2010-07-21 06:44:45 +08:00
|
|
|
|
|
|
|
bus->adapter.dev.parent = &dev->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;
|
|
|
|
|
2010-09-24 19:52:03 +08:00
|
|
|
/* By default use a conservative clock rate */
|
2012-03-28 02:36:15 +08:00
|
|
|
bus->reg0 = port | 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 */
|
|
|
|
if (IS_I830(dev))
|
2012-11-10 23:58:21 +08:00
|
|
|
bus->force_bit = 1;
|
2012-05-13 20:44:20 +08:00
|
|
|
|
2012-03-28 02:36:15 +08:00
|
|
|
intel_gpio_setup(bus, port);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
intel_i2c_reset(dev_priv->dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
while (--i) {
|
|
|
|
struct intel_gmbus *bus = &dev_priv->gmbus[i];
|
|
|
|
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,
|
|
|
|
unsigned port)
|
|
|
|
{
|
|
|
|
WARN_ON(!intel_gmbus_is_port_valid(port));
|
2012-03-28 02:36:15 +08:00
|
|
|
/* -1 to map pin pair to gmbus index */
|
2012-03-28 02:36:14 +08:00
|
|
|
return (intel_gmbus_is_port_valid(port)) ?
|
2012-03-28 02:36:15 +08:00
|
|
|
&dev_priv->gmbus[port - 1].adapter : NULL;
|
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);
|
|
|
|
|
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);
|
2010-09-24 19:52:03 +08:00
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
void intel_teardown_gmbus(struct drm_device *dev)
|
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
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int i;
|
2009-05-31 03:16:25 +08:00
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
for (i = 0; i < GMBUS_NUM_PORTS; i++) {
|
|
|
|
struct intel_gmbus *bus = &dev_priv->gmbus[i];
|
|
|
|
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
|
|
|
}
|