Re: [Intel-gfx] [PATCH v2] drm/i915: De-magic the PSR AUX message
On Wed, Oct 01, 2014 at 04:56:56PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
> and use the defines from dp_dp_helper.h to populate the message
> contents.
>
> v2: Use sizeof() for message size (Jani)
> Use a generic loop to write EDP_PSR_AUX_DATA registers
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Signed-off-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 --
> drivers/gpu/drm/i915/intel_dp.c | 21 -
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2e0eb16..09c4af3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2506,9 +2506,7 @@ enum punit_power_well {
>
> #define EDP_PSR_AUX_CTL(dev) (EDP_PSR_BASE(dev) + 0x10)
> #define EDP_PSR_AUX_DATA1(dev) (EDP_PSR_BASE(dev) +
> 0x14)
> -#define EDP_PSR_DPCD_COMMAND 0x8006
> #define EDP_PSR_AUX_DATA2(dev) (EDP_PSR_BASE(dev) +
> 0x18)
> -#define EDP_PSR_DPCD_NORMAL_OPERATION (1<<24)
> #define EDP_PSR_AUX_DATA3(dev) (EDP_PSR_BASE(dev) +
> 0x1c)
> #define EDP_PSR_AUX_DATA4(dev) (EDP_PSR_BASE(dev) +
> 0x20)
> #define EDP_PSR_AUX_DATA5(dev) (EDP_PSR_BASE(dev) +
> 0x24)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ad4eb6d..76317ad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -225,7 +225,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> }
>
> static uint32_t
> -pack_aux(uint8_t *src, int src_bytes)
> +pack_aux(const uint8_t *src, int src_bytes)
> {
> int i;
> uint32_t v = 0;
> @@ -2049,8 +2049,17 @@ static void intel_edp_psr_enable_sink(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t aux_clock_divider;
> int precharge = 0x3;
> - int msg_size = 5; /* Header(4) + Message(1) */
> bool only_standby = false;
> + static const uint8_t aux_msg[] = {
> + [0] = DP_AUX_NATIVE_WRITE << 4,
> + [1] = DP_SET_POWER >> 8,
> + [2] = DP_SET_POWER & 0xff,
> + [3] = 1 - 1,
> + [4] = DP_SET_POWER_D0,
> + };
> + int i;
> +
> + BUILD_BUG_ON(sizeof(aux_msg) > 20);
>
> aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
>
> @@ -2066,11 +2075,13 @@ static void intel_edp_psr_enable_sink(struct intel_dp
> *intel_dp)
> DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
>
> /* Setup AUX registers */
> - I915_WRITE(EDP_PSR_AUX_DATA1(dev), EDP_PSR_DPCD_COMMAND);
> - I915_WRITE(EDP_PSR_AUX_DATA2(dev), EDP_PSR_DPCD_NORMAL_OPERATION);
> + for (i = 0; i < sizeof(aux_msg); i += 4)
> + I915_WRITE(EDP_PSR_AUX_DATA1(dev) + i,
> +pack_aux(&aux_msg[i], sizeof(aux_msg) - i));
> +
> I915_WRITE(EDP_PSR_AUX_CTL(dev),
> DP_AUX_CH_CTL_TIME_OUT_400us |
> -(msg_size << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
> +(sizeof(aux_msg) << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
> (precharge << DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) |
> (aux_clock_divider << DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
> }
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Constify send buffer for intel_dp_aux_ch
Inspired by Ville constifying the send buffer for pach_aux.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7ba3e1bb711a..b2aedcf8c8ec 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -718,7 +718,7 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp
*intel_dp,
static int
intel_dp_aux_ch(struct intel_dp *intel_dp,
- uint8_t *send, int send_bytes,
+ const uint8_t *send, int send_bytes,
uint8_t *recv, int recv_size)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] randconfig build error with next-20141001, in drivers/gpu/drm/i915
On Wed, 01 Oct 2014, Randy Dunlap wrote: > On 10/01/14 10:57, Jani Nikula wrote: >> On Wed, 01 Oct 2014, Jim Davis wrote: >>> Building with the attached random configuration file, >>> >>> warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct >>> dependencies (DMADEVICES && MFD_TIMBERDALE) >>> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG >>> which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME) >>> >>> drivers/built-in.o: In function `intel_panel_setup_backlight': >>> (.text+0x11855d): undefined reference to `backlight_device_register' >>> drivers/built-in.o: In function `intel_panel_destroy_backlight': >>> (.text+0x118624): undefined reference to `backlight_device_unregister' >>> make: *** [vmlinux] Error 1 >> >> It's the combination: >> >>> CONFIG_DRM_I915=y >>> CONFIG_BACKLIGHT_CLASS_DEVICE=m >> >> Not sure what the Kconfig magic spell needs to be when we don't want to >> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled >> (y or m). > > Something like: > > depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n > > is what we usually use. Oh boy this gets ugly. Trying diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 4e39ab34eb1c..daa453c62aa6 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -3,6 +3,7 @@ config DRM_I915 depends on DRM depends on X86 && PCI depends on (AGP || AGP=n) + depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n) select INTEL_GTT select AGP_INTEL if AGP select INTERVAL_TREE leads to scripts/kconfig/conf --olddefconfig Kconfig drivers/gpu/drm/i915/Kconfig:1:error: recursive dependency detected! drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on BACKLIGHT_CLASS_DEVICE drivers/video/backlight/Kconfig:156:symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_I915 because we depend on ACPI_VIDEO when ACPI is enabled, originally done in commit ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6 Author: Len Brown Date: Fri Apr 24 11:33:47 2009 -0400 ACPI, i915: build fix Now, trying to fix that with what seems to me like the obvious dependency, conveying what we really want diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 4e39ab34eb1c..f5a1ee37603e 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -3,6 +3,7 @@ config DRM_I915 depends on DRM depends on X86 && PCI depends on (AGP || AGP=n) + depends on ((ACPI && ACPI_VIDEO) || ACPI=n) select INTEL_GTT select AGP_INTEL if AGP select INTERVAL_TREE @@ -11,13 +12,6 @@ config DRM_I915 select SHMEM select TMPFS select DRM_KMS_HELPER - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select INPUT if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI help Choose this option if you have a system that has "Intel Graphics Media Accelerator" or "HD Graphics" integrated graphics, leads to more fun scripts/kconfig/conf --olddefconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_I915_FBDEV drivers/gpu/drm/i915/Kconfig:40:symbol DRM_I915_FBDEV depends on DRM_I915 drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on ACPI_VIDEO drivers/acpi/Kconfig:130: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE drivers/video/backlight/Kconfig:156:symbol BACKLIGHT_CLASS_DEVICE is selected by FB_BACKLIGHT drivers/video/fbdev/Kconfig:188:symbol FB_BACKLIGHT is selected by PMAC_BACKLIGHT drivers/macintosh/Kconfig:135: symbol PMAC_BACKLIGHT depends on FB and the rabbit hole gets deeper than I thought. I guess it always does. At this point the question is whether "depends on ((ACPI && ACPI_VIDEO) || ACPI=n)" is worth pursuing and makes more sense than the "select foo if ACPI" lines, or do we need to build hacks upon hacks to get this fixed. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make sink_crc return -EIO on aux read/write failure
On Wed, Oct 01, 2014 at 07:32:37AM -0700, Rodrigo Vivi wrote:
Nothing is usually to little commit message. I've fixed this while
applying.
> Cc: Daniel Vetter
> Cc: Todd Previte
> Signed-off-by: Rodrigo Vivi
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ad4eb6d..8ead695 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3868,16 +3868,21 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> if (!(buf & DP_TEST_CRC_SUPPORTED))
> return -ENOTTY;
>
> - drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf);
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> + return -EIO;
> +
> if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> buf | DP_TEST_SINK_START) < 0)
> return -EIO;
>
> - drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf);
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> + return -EIO;
> test_crc_count = buf & DP_TEST_COUNT_MASK;
>
> do {
> - drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf);
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_TEST_SINK_MISC, &buf) < 0)
> + return -EIO;
> intel_wait_for_vblank(dev, intel_crtc->pipe);
> } while (--attempts && (buf & DP_TEST_COUNT_MASK) == test_crc_count);
>
> @@ -3889,9 +3894,11 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
> return -EIO;
>
> - drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf);
> - drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> - buf & ~DP_TEST_SINK_START);
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> + return -EIO;
> + if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> +buf & ~DP_TEST_SINK_START) < 0)
> + return -EIO;
>
> return 0;
> }
> --
> 1.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] limiting modes on 4k monitors on Haswell ULT
On Thu, Oct 02, 2014 at 01:30:48PM +1000, Dave Airlie wrote: > Hey guys, > > so I have a haswell ULT laptop (lenovo t440s), and got access to a > Samsung single panel 4k monitor (no MST). > > Now we detect the monitor fine, but unfortunately the ULT hsw can't > run it over DP, as it has clock limits in place. However we still > offer the 60hz mode and we pick it by default, ensuing black screens. > > I've tested the same monitor with a haswell in a t540p and it works > fine due to having the higher limits in place. We have the IS_HSW_ULX check in intel_dp_max_link_bw, and that's used by both compute_config and mode_valid. So it should work, and from a quick look I don't see any bugs. But obviously something is busted. Can you please printk-augment intel_dp_mode_valid and check what's going wrong there? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix short vs. long hpd detection
Fix short vs. long hpd detection for non-g4x and non-pch split
platforms.
Broken since introduction in
commit 13cf550448b58abf8f44f5d6a560f2d20871c965
Author: Dave Airlie
Date: Wed Jun 18 11:29:35 2014 +1000
drm/i915: rework digital port IRQ handling (v2)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83175
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 72cb9397ecc5..3ff6f1bb594a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1708,7 +1708,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
#define HPD_STORM_DETECT_PERIOD 1000
#define HPD_STORM_THRESHOLD 5
-static int ilk_port_to_hotplug_shift(enum port port)
+static int pch_port_to_hotplug_shift(enum port port)
{
switch (port) {
case PORT_A:
@@ -1724,7 +1724,7 @@ static int ilk_port_to_hotplug_shift(enum port port)
}
}
-static int g4x_port_to_hotplug_shift(enum port port)
+static int i915_port_to_hotplug_shift(enum port port)
{
switch (port) {
case PORT_A:
@@ -1782,12 +1782,12 @@ static inline void intel_hpd_irq_handler(struct
drm_device *dev,
if (port && dev_priv->hpd_irq_port[port]) {
bool long_hpd;
- if (IS_G4X(dev)) {
- dig_shift = g4x_port_to_hotplug_shift(port);
- long_hpd = (hotplug_trigger >> dig_shift) &
PORTB_HOTPLUG_LONG_DETECT;
- } else {
- dig_shift = ilk_port_to_hotplug_shift(port);
+ if (HAS_PCH_SPLIT(dev)) {
+ dig_shift = pch_port_to_hotplug_shift(port);
long_hpd = (dig_hotplug_reg >> dig_shift) &
PORTB_HOTPLUG_LONG_DETECT;
+ } else {
+ dig_shift = i915_port_to_hotplug_shift(port);
+ long_hpd = (hotplug_trigger >> dig_shift) &
PORTB_HOTPLUG_LONG_DETECT;
}
DRM_DEBUG_DRIVER("digital hpd port %c - %s\n",
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix short vs. long hpd detection
On Thu, Oct 02, 2014 at 11:16:32AM +0300, Jani Nikula wrote:
> Fix short vs. long hpd detection for non-g4x and non-pch split
> platforms.
>
> Broken since introduction in
> commit 13cf550448b58abf8f44f5d6a560f2d20871c965
> Author: Dave Airlie
> Date: Wed Jun 18 11:29:35 2014 +1000
>
> drm/i915: rework digital port IRQ handling (v2)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83175
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_irq.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 72cb9397ecc5..3ff6f1bb594a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1708,7 +1708,7 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> #define HPD_STORM_DETECT_PERIOD 1000
> #define HPD_STORM_THRESHOLD 5
>
> -static int ilk_port_to_hotplug_shift(enum port port)
> +static int pch_port_to_hotplug_shift(enum port port)
> {
> switch (port) {
> case PORT_A:
> @@ -1724,7 +1724,7 @@ static int ilk_port_to_hotplug_shift(enum port port)
> }
> }
>
> -static int g4x_port_to_hotplug_shift(enum port port)
> +static int i915_port_to_hotplug_shift(enum port port)
> {
> switch (port) {
> case PORT_A:
> @@ -1782,12 +1782,12 @@ static inline void intel_hpd_irq_handler(struct
> drm_device *dev,
> if (port && dev_priv->hpd_irq_port[port]) {
> bool long_hpd;
>
> - if (IS_G4X(dev)) {
> - dig_shift = g4x_port_to_hotplug_shift(port);
> - long_hpd = (hotplug_trigger >> dig_shift) &
> PORTB_HOTPLUG_LONG_DETECT;
> - } else {
> - dig_shift = ilk_port_to_hotplug_shift(port);
> + if (HAS_PCH_SPLIT(dev)) {
> + dig_shift = pch_port_to_hotplug_shift(port);
> long_hpd = (dig_hotplug_reg >> dig_shift) &
> PORTB_HOTPLUG_LONG_DETECT;
Using the new HAS_GMCH_DISPLAY will probably survive longer (i.e. skl).
-Daniel
> + } else {
> + dig_shift = i915_port_to_hotplug_shift(port);
> + long_hpd = (hotplug_trigger >> dig_shift) &
> PORTB_HOTPLUG_LONG_DETECT;
> }
>
> DRM_DEBUG_DRIVER("digital hpd port %c - %s\n",
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] limiting modes on 4k monitors on Haswell ULT
On Thu, Oct 02, 2014 at 10:00:50AM +0200, Daniel Vetter wrote: > On Thu, Oct 02, 2014 at 01:30:48PM +1000, Dave Airlie wrote: > > Hey guys, > > > > so I have a haswell ULT laptop (lenovo t440s), and got access to a > > Samsung single panel 4k monitor (no MST). > > > > Now we detect the monitor fine, but unfortunately the ULT hsw can't > > run it over DP, as it has clock limits in place. However we still > > offer the 60hz mode and we pick it by default, ensuing black screens. > > > > I've tested the same monitor with a haswell in a t540p and it works > > fine due to having the higher limits in place. > > We have the IS_HSW_ULX check in intel_dp_max_link_bw, and that's used by > both compute_config and mode_valid. So it should work, and from a quick > look I don't see any bugs. But obviously something is busted. > > Can you please printk-augment intel_dp_mode_valid and check what's going > wrong there? Or maybe this is about cdclk instead of link clock? I believe the max cdclk ULT can support is 450MHz. I'm not sure if the default would be 450MHz or 337.5MHz. Also we still don't have support for changing that during runtime even though I regularly try to trick people into implementing it. What's the pixel clock of the mode that fails? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert "drm/i915: Reject the pin ioctl on gen6+"
On Fri, Sep 19, 2014 Daniel Vetter wrote: > I still consider pinning stuff behind the kernels back too evil. So if people > want that I'd like to see the use-case and why we can't do this differently. > > And I've never approved of the pin ioctl but really loudly complained about > each occasion I've spotted, so I think the internal users just have to keep > the > pieces for a bit longer. > -Daniel Daniel. All that's being asked for is a re-instatement of the old mechanism until a better solution can be designed and implemented. It may well be evil, but the mechanism was there, and was the only known way to handle the OA buffer, so why wouldn't someone use it ? You've broken userspace before you provided any alternative solution. Please, let's revert this while a more elegant solution is designed, implemented, reviewed, re-implemented, reviewed again, and maybe one day merged. Remember that it will take a while to filter down to people even after you merge any new solution to nightly, or even drm-next. If we have to wait for the new design, it's not likely to reach us until next year. Can't we just agree that we're evil, but turn a blind eye while we're coaxed slowly back towards the light ? Jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] limiting modes on 4k monitors on Haswell ULT
On 2 October 2014 18:40, Ville Syrjälä wrote: > On Thu, Oct 02, 2014 at 10:00:50AM +0200, Daniel Vetter wrote: >> On Thu, Oct 02, 2014 at 01:30:48PM +1000, Dave Airlie wrote: >> > Hey guys, >> > >> > so I have a haswell ULT laptop (lenovo t440s), and got access to a >> > Samsung single panel 4k monitor (no MST). >> > >> > Now we detect the monitor fine, but unfortunately the ULT hsw can't >> > run it over DP, as it has clock limits in place. However we still >> > offer the 60hz mode and we pick it by default, ensuing black screens. >> > >> > I've tested the same monitor with a haswell in a t540p and it works >> > fine due to having the higher limits in place. >> >> We have the IS_HSW_ULX check in intel_dp_max_link_bw, and that's used by >> both compute_config and mode_valid. So it should work, and from a quick >> look I don't see any bugs. But obviously something is busted. >> >> Can you please printk-augment intel_dp_mode_valid and check what's going >> wrong there? > > Or maybe this is about cdclk instead of link clock? I believe the max > cdclk ULT can support is 450MHz. I'm not sure if the default would be > 450MHz or 337.5MHz. Also we still don't have support for changing that > during runtime even though I regularly try to trick people into > implementing it. What's the pixel clock of the mode that fails? yup it appears to max cdclk, which is 450Mhz on the ULT and 540Mhz on normal hsw. Modeline "3840x2160R" 533.00 3840 3888 3920 4000 2160 2163 2168 +hsync -vsync cvt gives me that for reduced blank, so around that I guess, I can get the exact mode line from logs tomorrow if required. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests: Sprinkle missing igt_exit() where needed.
From: Daniel Vetter
Yay for breaking piles of tests.
This regression has been introduced with
commit 5782eca1e19e85a04ad402fa4094aa1b5f9c53ce
Author: Tim Gore
Date: Wed Oct 1 13:25:20 2014 +0100
lib/igt_core.c: disable lowmemorykiller during tests
Cc: Tim Gore
Signed-off-by: Daniel Vetter
---
tests/gem_ctx_basic.c| 2 +-
tests/gem_exec_blt.c | 2 +-
tests/gem_gtt_speed.c| 2 +-
tests/gem_hang.c | 2 +-
tests/gem_ppgtt.c| 2 --
tests/gem_render_copy.c | 2 +-
tests/gem_render_copy_redux.c| 2 --
tests/gem_render_linear_blits.c | 2 +-
tests/gem_render_tiled_blits.c | 2 +-
tests/gem_seqno_wrap.c | 7 ++-
tests/gem_stress.c | 2 +-
tests/gem_userptr_blits.c| 2 --
tests/gen3_mixed_blits.c | 2 +-
tests/gen3_render_linear_blits.c | 2 +-
tests/gen3_render_mixed_blits.c | 2 +-
tests/gen3_render_tiledx_blits.c | 2 +-
tests/gen3_render_tiledy_blits.c | 2 +-
tests/testdisplay.c | 4 +++-
18 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/tests/gem_ctx_basic.c b/tests/gem_ctx_basic.c
index a0bec602a911..b8b01c03e122 100644
--- a/tests/gem_ctx_basic.c
+++ b/tests/gem_ctx_basic.c
@@ -166,5 +166,5 @@ int main(int argc, char *argv[])
free(threads);
close(fd);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_exec_blt.c b/tests/gem_exec_blt.c
index db997b335197..301c9397c590 100644
--- a/tests/gem_exec_blt.c
+++ b/tests/gem_exec_blt.c
@@ -270,5 +270,5 @@ int main(int argc, char **argv)
} else
run(OBJECT_SIZE);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_gtt_speed.c b/tests/gem_gtt_speed.c
index 5125078d36e8..c8581035653d 100644
--- a/tests/gem_gtt_speed.c
+++ b/tests/gem_gtt_speed.c
@@ -329,5 +329,5 @@ int main(int argc, char **argv)
gem_close(fd, handle);
close(fd);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_hang.c b/tests/gem_hang.c
index 7a7c8acbd84a..8767615c83ea 100644
--- a/tests/gem_hang.c
+++ b/tests/gem_hang.c
@@ -93,5 +93,5 @@ int main(int argc, char **argv)
close(fd);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c
index 8c560f269601..0ee4f5b2a31e 100644
--- a/tests/gem_ppgtt.c
+++ b/tests/gem_ppgtt.c
@@ -230,6 +230,4 @@ int main(int argc, char **argv)
}
igt_exit();
-
- return 0;
}
diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c
index 6ff0c776e5e4..094816c92143 100644
--- a/tests/gem_render_copy.c
+++ b/tests/gem_render_copy.c
@@ -186,5 +186,5 @@ int main(int argc, char **argv)
scratch_buf_check(&data, &dst, WIDTH - 10, HEIGHT - 10,
SRC_COLOR);
}
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_render_copy_redux.c b/tests/gem_render_copy_redux.c
index cb48aa73e6c3..6fc82df9a858 100644
--- a/tests/gem_render_copy_redux.c
+++ b/tests/gem_render_copy_redux.c
@@ -241,6 +241,4 @@ int main(int argc, char **argv)
}
igt_exit();
-
- return 0;
}
diff --git a/tests/gem_render_linear_blits.c b/tests/gem_render_linear_blits.c
index 28fd8c8c482a..60ba83162d40 100644
--- a/tests/gem_render_linear_blits.c
+++ b/tests/gem_render_linear_blits.c
@@ -200,5 +200,5 @@ int main(int argc, char **argv)
for (i = 0; i < count; i++)
check_bo(fd, bo[i]->handle, start_val[i]);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_render_tiled_blits.c b/tests/gem_render_tiled_blits.c
index ea1d59da8f07..dc22529c4d7e 100644
--- a/tests/gem_render_tiled_blits.c
+++ b/tests/gem_render_tiled_blits.c
@@ -211,5 +211,5 @@ int main(int argc, char **argv)
for (i = 0; i < count; i++)
check_bo(batch, &buf[i], start_val[i]);
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
index e8528ec68575..6772d1e1436f 100644
--- a/tests/gem_seqno_wrap.c
+++ b/tests/gem_seqno_wrap.c
@@ -527,10 +527,7 @@ int main(int argc, char **argv)
options.dontwrap ? "tests" : "wraps", wcount);
}
- if (options.rounds == wcount) {
- igt_debug("done %d wraps successfully\n", wcount);
- return 0;
- }
+ igt_assert(options.rounds == wcount);
- return r;
+ igt_exit();
}
diff --git a/tests/gem_stress.c b/tests/gem_stress.c
index 8d62b0357565..ab2cd0eb4656 100644
--- a/tests/gem_stress.c
+++ b/tests/gem_stress.c
@@ -914,5 +914,5 @@ int main(int argc, char **argv)
igt_stop_signal_helper();
- return 0;
+ igt_exit();
}
diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
index 638b74c29c24..a729f3191dae 100644
--- a/tests/gem_userptr_blits.c
+++ b/tests/gem_userptr_blits.c
@@ -1443,6 +1443,4 @@ int main(int argc, char **argv)
test_access_control(fd);
igt_exit();
-
-
Re: [Intel-gfx] limiting modes on 4k monitors on Haswell ULT
On Thu, Oct 02, 2014 at 10:00:50AM +0200, Daniel Vetter wrote: > On Thu, Oct 02, 2014 at 01:30:48PM +1000, Dave Airlie wrote: > > Hey guys, > > > > so I have a haswell ULT laptop (lenovo t440s), and got access to a > > Samsung single panel 4k monitor (no MST). > > > > Now we detect the monitor fine, but unfortunately the ULT hsw can't > > run it over DP, as it has clock limits in place. However we still > > offer the 60hz mode and we pick it by default, ensuing black screens. > > > > I've tested the same monitor with a haswell in a t540p and it works > > fine due to having the higher limits in place. > > We have the IS_HSW_ULX check in intel_dp_max_link_bw, and that's used by > both compute_config and mode_valid. So it should work, and from a quick > look I don't see any bugs. But obviously something is busted. Just to be a bit more specific: ULT != ULX, the two SKUs have different limits. The test in intel_dp_max_link_bw() is about eDP/DP max link rate: HBR2(ULT) Vs HBR(ULX). I'd go with Ville, that sounds like CDCLK is the limiting factor, and we're missing these checks. From a cursory glance, it doesn't seem we can do 4k on ULT. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests: Sprinkle missing igt_exit() where needed.
> -Original Message-
> From: root [mailto:daniel.vet...@ffwll.ch]
> Sent: Thursday, October 02, 2014 10:36 AM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Gore, Tim; Vetter, Daniel
> Subject: [PATCH] tests: Sprinkle missing igt_exit() where needed.
>
> From: Daniel Vetter
>
> Yay for breaking piles of tests.
>
> This regression has been introduced with
>
Oops yes, this was my mistake. Forgot about the tests that use the igt init
function but then just use return. Patch looks sensible, especially as this
brings the single tests more into line with the multi-tests. I am very much
in favour of this.
Tim
> commit 5782eca1e19e85a04ad402fa4094aa1b5f9c53ce
> Author: Tim Gore
> Date: Wed Oct 1 13:25:20 2014 +0100
>
> lib/igt_core.c: disable lowmemorykiller during tests
>
> Cc: Tim Gore
> Signed-off-by: Daniel Vetter
> ---
> tests/gem_ctx_basic.c| 2 +-
> tests/gem_exec_blt.c | 2 +-
> tests/gem_gtt_speed.c| 2 +-
> tests/gem_hang.c | 2 +-
> tests/gem_ppgtt.c| 2 --
> tests/gem_render_copy.c | 2 +-
> tests/gem_render_copy_redux.c| 2 --
> tests/gem_render_linear_blits.c | 2 +-
> tests/gem_render_tiled_blits.c | 2 +-
> tests/gem_seqno_wrap.c | 7 ++-
> tests/gem_stress.c | 2 +-
> tests/gem_userptr_blits.c| 2 --
> tests/gen3_mixed_blits.c | 2 +-
> tests/gen3_render_linear_blits.c | 2 +- tests/gen3_render_mixed_blits.c |
> 2 +- tests/gen3_render_tiledx_blits.c | 2 +-
> tests/gen3_render_tiledy_blits.c | 2 +-
> tests/testdisplay.c | 4 +++-
> 18 files changed, 18 insertions(+), 25 deletions(-)
>
> diff --git a/tests/gem_ctx_basic.c b/tests/gem_ctx_basic.c index
> a0bec602a911..b8b01c03e122 100644
> --- a/tests/gem_ctx_basic.c
> +++ b/tests/gem_ctx_basic.c
> @@ -166,5 +166,5 @@ int main(int argc, char *argv[])
> free(threads);
> close(fd);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_exec_blt.c b/tests/gem_exec_blt.c index
> db997b335197..301c9397c590 100644
> --- a/tests/gem_exec_blt.c
> +++ b/tests/gem_exec_blt.c
> @@ -270,5 +270,5 @@ int main(int argc, char **argv)
> } else
> run(OBJECT_SIZE);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_gtt_speed.c b/tests/gem_gtt_speed.c index
> 5125078d36e8..c8581035653d 100644
> --- a/tests/gem_gtt_speed.c
> +++ b/tests/gem_gtt_speed.c
> @@ -329,5 +329,5 @@ int main(int argc, char **argv)
> gem_close(fd, handle);
> close(fd);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_hang.c b/tests/gem_hang.c index
> 7a7c8acbd84a..8767615c83ea 100644
> --- a/tests/gem_hang.c
> +++ b/tests/gem_hang.c
> @@ -93,5 +93,5 @@ int main(int argc, char **argv)
>
> close(fd);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c index
> 8c560f269601..0ee4f5b2a31e 100644
> --- a/tests/gem_ppgtt.c
> +++ b/tests/gem_ppgtt.c
> @@ -230,6 +230,4 @@ int main(int argc, char **argv)
> }
>
> igt_exit();
> -
> - return 0;
> }
> diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c index
> 6ff0c776e5e4..094816c92143 100644
> --- a/tests/gem_render_copy.c
> +++ b/tests/gem_render_copy.c
> @@ -186,5 +186,5 @@ int main(int argc, char **argv)
> scratch_buf_check(&data, &dst, WIDTH - 10, HEIGHT - 10,
> SRC_COLOR);
> }
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_render_copy_redux.c
> b/tests/gem_render_copy_redux.c index cb48aa73e6c3..6fc82df9a858
> 100644
> --- a/tests/gem_render_copy_redux.c
> +++ b/tests/gem_render_copy_redux.c
> @@ -241,6 +241,4 @@ int main(int argc, char **argv)
> }
>
> igt_exit();
> -
> - return 0;
> }
> diff --git a/tests/gem_render_linear_blits.c
> b/tests/gem_render_linear_blits.c index 28fd8c8c482a..60ba83162d40
> 100644
> --- a/tests/gem_render_linear_blits.c
> +++ b/tests/gem_render_linear_blits.c
> @@ -200,5 +200,5 @@ int main(int argc, char **argv)
> for (i = 0; i < count; i++)
> check_bo(fd, bo[i]->handle, start_val[i]);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_render_tiled_blits.c b/tests/gem_render_tiled_blits.c
> index ea1d59da8f07..dc22529c4d7e 100644
> --- a/tests/gem_render_tiled_blits.c
> +++ b/tests/gem_render_tiled_blits.c
> @@ -211,5 +211,5 @@ int main(int argc, char **argv)
> for (i = 0; i < count; i++)
> check_bo(batch, &buf[i], start_val[i]);
>
> - return 0;
> + igt_exit();
> }
> diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c index
> e8528ec68575..6772d1e1436f 100644
> --- a/tests/gem_seqno_wrap.c
> +++ b/tests/gem_seqno_wrap.c
> @@ -527,10 +527,7 @@ int main(int argc, char **argv)
> options.dontwrap ? "tests" : "wraps", wcount);
> }
>
> - if (options.rounds == wcount) {
> - igt_debug("d
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, final regression fix for 3.17. BR, Jani. The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb: Linux 3.17-rc7 (2014-09-28 14:29:07 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-10-02 for you to fetch changes up to 91e56499304f3d612053a9cf17f350868182c7d8: drm/i915: Flush the PTEs after updating them before suspend (2014-09-29 16:41:17 +0300) Chris Wilson (1): drm/i915: Flush the PTEs after updating them before suspend drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> The register can house two different swing marging/deemph settings at
> once. However only one gets used based on some other bits. Make sure we
> set those bits correctly to make the hardware use the settings we
> provided.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 19 +++
> drivers/gpu/drm/i915/intel_dp.c | 14 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 14 ++
> 3 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2df946d..b8e8d33 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -824,12 +824,31 @@ enum punit_power_well {
>
> #define _VLV_PCS_DW9_CH0 0x8224
> #define _VLV_PCS_DW9_CH1 0x8424
> +#define DPIO_PCS_TX2MARGIN_MASK(0x7<<13)
> +#define DPIO_PCS_TX2MARGIN_000 (0<<13)
> +#define DPIO_PCS_TX2MARGIN_101 (1<<13)
> +#define DPIO_PCS_TX1MARGIN_MASK(0x7<<10)
> +#define DPIO_PCS_TX1MARGIN_000 (0<<10)
> +#define DPIO_PCS_TX1MARGIN_101 (1<<10)
> #define VLV_PCS_DW9(ch) _PORT(ch, _VLV_PCS_DW9_CH0, _VLV_PCS_DW9_CH1)
>
> +#define _VLV_PCS01_DW9_CH0 0x224
> +#define _VLV_PCS23_DW9_CH0 0x424
> +#define _VLV_PCS01_DW9_CH1 0x2624
> +#define _VLV_PCS23_DW9_CH1 0x2824
> +#define VLV_PCS01_DW9(ch) _PORT(ch, _VLV_PCS01_DW9_CH0, _VLV_PCS01_DW9_CH1)
> +#define VLV_PCS23_DW9(ch) _PORT(ch, _VLV_PCS23_DW9_CH0, _VLV_PCS23_DW9_CH1)
> +
> #define _CHV_PCS_DW10_CH00x8228
> #define _CHV_PCS_DW10_CH10x8428
> #define DPIO_PCS_SWING_CALC_TX0_TX2(1<<30)
> #define DPIO_PCS_SWING_CALC_TX1_TX3(1<<31)
> +#define DPIO_PCS_TX2DEEMP_MASK (0xf<<24)
> +#define DPIO_PCS_TX2DEEMP_9P5 (0<<24)
> +#define DPIO_PCS_TX2DEEMP_6P0 (2<<24)
> +#define DPIO_PCS_TX1DEEMP_MASK (0xf<<16)
> +#define DPIO_PCS_TX1DEEMP_9P5 (0<<16)
> +#define DPIO_PCS_TX1DEEMP_6P0 (2<<16)
> #define CHV_PCS_DW10(ch) _PORT(ch, _CHV_PCS_DW10_CH0, _CHV_PCS_DW10_CH1)
>
> #define _VLV_PCS01_DW10_CH0 0x0228
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e5ada4f..f8e4578 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2632,12 +2632,26 @@ static uint32_t intel_chv_signal_levels(struct
> intel_dp *intel_dp)
> /* Clear calc init */
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
> val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> + val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> + val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
>
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
> val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> + val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> + val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
>
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
> + val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
> + val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW9(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW9(ch));
> + val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
> + val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW9(ch), val);
> +
> /* Program swing deemph */
> for (i = 0; i < 4; i++) {
> val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW4(ch, i));
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 9169786..f3bf0c7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1414,12 +1414,26 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder)
> /* Clear calc init */
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
> val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> + val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> + val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
>
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
> val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> + val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> + val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
>
> + val = vlv_dpio_read(de
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Clear TX FIFO reset master override bits on chv
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Clear the override bits to make sure the hardware maanages
> the TX FIFO reset master on its own.
>
> v2: Squash with the earlier attempt at forcing the override bits
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 12
> drivers/gpu/drm/i915/intel_dp.c | 9 +
> drivers/gpu/drm/i915/intel_hdmi.c | 9 +
> 3 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b8e8d33..daac02b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -784,6 +784,8 @@ enum punit_power_well {
> #define _VLV_PCS_DW0_CH1 0x8400
> #define DPIO_PCS_TX_LANE2_RESET(1<<16)
> #define DPIO_PCS_TX_LANE1_RESET(1<<7)
> +#define DPIO_LEFT_TXFIFO_RST_MASTER2 (1<<4)
> +#define DPIO_RIGHT_TXFIFO_RST_MASTER2 (1<<3)
> #define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
>
> #define _VLV_PCS01_DW0_CH0 0x200
> @@ -860,8 +862,18 @@ enum punit_power_well {
>
> #define _VLV_PCS_DW11_CH00x822c
> #define _VLV_PCS_DW11_CH10x842c
> +#define DPIO_LANEDESKEW_STRAP_OVRD (1<<3)
> +#define DPIO_LEFT_TXFIFO_RST_MASTER(1<<1)
> +#define DPIO_RIGHT_TXFIFO_RST_MASTER (1<<0)
> #define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
>
> +#define _VLV_PCS01_DW11_CH0 0x022c
> +#define _VLV_PCS23_DW11_CH0 0x042c
> +#define _VLV_PCS01_DW11_CH1 0x262c
> +#define _VLV_PCS23_DW11_CH1 0x282c
> +#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0, _VLV_PCS01_DW0_CH1)
> +#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0, _VLV_PCS23_DW0_CH1)
> +
> #define _VLV_PCS_DW12_CH00x8230
> #define _VLV_PCS_DW12_CH10x8430
> #define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f8e4578..4f69648 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2223,6 +2223,15 @@ static void chv_pre_enable_dp(struct intel_encoder
> *encoder)
>
> mutex_lock(&dev_priv->dpio_lock);
>
> + /* allow hardware to manage TX FIFO reset source */
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> + val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> + val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> +
> /* Deassert soft data lane reset*/
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> val |= CHV_PCS_REQ_SOFTRESET_EN;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f3bf0c7..f0cff45 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1378,6 +1378,15 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder)
>
> mutex_lock(&dev_priv->dpio_lock);
>
> + /* allow hardware to manage TX FIFO reset source */
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> + val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> + val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> +
> /* Deassert soft data lane reset*/
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> val |= CHV_PCS_REQ_SOFTRESET_EN;
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] lib/Android.mk: add define of IGT_DATADIR for igt_fb.c
From: Tim Gore
Since the igt_create_stereo_fb function moved into igt_fb.c
we need to add the definition of IGT_DATADIR in the Android
makefile in order to build the cairo dependent tests.
Signed-off-by: Tim Gore
---
lib/Android.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Android.mk b/lib/Android.mk
index 5739c80..bd8cf58 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -35,7 +35,7 @@ LOCAL_SHARED_LIBRARIES := libpciaccess \
ifeq ("${ANDROID_HAS_CAIRO}", "1")
skip_lib_list :=
LOCAL_C_INCLUDES += $(ANDROID_BUILD_TOP)/external/cairo-1.12.16/src
-LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1
+LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1 -DIGT_DATADIR=\".\"
else
skip_lib_list := \
igt_kms.c \
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/Android.mk: add define of IGT_DATADIR for igt_fb.c
On 2 October 2014 16:26, wrote:
> From: Tim Gore
>
> Since the igt_create_stereo_fb function moved into igt_fb.c
> we need to add the definition of IGT_DATADIR in the Android
> makefile in order to build the cairo dependent tests.
>
> Signed-off-by: Tim Gore
Patch merged, thanks.
> ---
> lib/Android.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/Android.mk b/lib/Android.mk
> index 5739c80..bd8cf58 100644
> --- a/lib/Android.mk
> +++ b/lib/Android.mk
> @@ -35,7 +35,7 @@ LOCAL_SHARED_LIBRARIES := libpciaccess \
> ifeq ("${ANDROID_HAS_CAIRO}", "1")
> skip_lib_list :=
> LOCAL_C_INCLUDES += $(ANDROID_BUILD_TOP)/external/cairo-1.12.16/src
> -LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1
> +LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1 -DIGT_DATADIR=\".\"
> else
> skip_lib_list := \
> igt_kms.c \
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] randconfig build error with next-20141001, in drivers/gpu/drm/i915
On 10/02/14 00:46, Jani Nikula wrote: > On Wed, 01 Oct 2014, Randy Dunlap wrote: >> On 10/01/14 10:57, Jani Nikula wrote: >>> On Wed, 01 Oct 2014, Jim Davis wrote: Building with the attached random configuration file, warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct dependencies (DMADEVICES && MFD_TIMBERDALE) warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME) drivers/built-in.o: In function `intel_panel_setup_backlight': (.text+0x11855d): undefined reference to `backlight_device_register' drivers/built-in.o: In function `intel_panel_destroy_backlight': (.text+0x118624): undefined reference to `backlight_device_unregister' make: *** [vmlinux] Error 1 >>> >>> It's the combination: >>> CONFIG_DRM_I915=y CONFIG_BACKLIGHT_CLASS_DEVICE=m >>> >>> Not sure what the Kconfig magic spell needs to be when we don't want to >>> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled >>> (y or m). >> >> Something like: >> >> depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n >> >> is what we usually use. > > Oh boy this gets ugly. Trying > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 4e39ab34eb1c..daa453c62aa6 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -3,6 +3,7 @@ config DRM_I915 > depends on DRM > depends on X86 && PCI > depends on (AGP || AGP=n) > + depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n) > select INTEL_GTT > select AGP_INTEL if AGP > select INTERVAL_TREE > > leads to > > scripts/kconfig/conf --olddefconfig Kconfig > drivers/gpu/drm/i915/Kconfig:1:error: recursive dependency detected! > drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on > BACKLIGHT_CLASS_DEVICE > drivers/video/backlight/Kconfig:156: symbol BACKLIGHT_CLASS_DEVICE is > selected by DRM_I915 > > because we depend on ACPI_VIDEO when ACPI is enabled, originally done in > > commit ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6 > Author: Len Brown > Date: Fri Apr 24 11:33:47 2009 -0400 > > ACPI, i915: build fix > > Now, trying to fix that with what seems to me like the obvious > dependency, conveying what we really want > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 4e39ab34eb1c..f5a1ee37603e 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -3,6 +3,7 @@ config DRM_I915 > depends on DRM > depends on X86 && PCI > depends on (AGP || AGP=n) > + depends on ((ACPI && ACPI_VIDEO) || ACPI=n) > select INTEL_GTT > select AGP_INTEL if AGP > select INTERVAL_TREE > @@ -11,13 +12,6 @@ config DRM_I915 > select SHMEM > select TMPFS > select DRM_KMS_HELPER > - # i915 depends on ACPI_VIDEO when ACPI is enabled > - # but for select to work, need to select ACPI_VIDEO's dependencies, ick > - select BACKLIGHT_LCD_SUPPORT if ACPI > - select BACKLIGHT_CLASS_DEVICE if ACPI > - select INPUT if ACPI > - select ACPI_VIDEO if ACPI > - select ACPI_BUTTON if ACPI > help > Choose this option if you have a system that has "Intel Graphics > Media Accelerator" or "HD Graphics" integrated graphics, > > leads to more fun > > scripts/kconfig/conf --olddefconfig Kconfig > drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! > drivers/video/fbdev/Kconfig:5:symbol FB is selected by > DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by > DRM_I915_FBDEV > drivers/gpu/drm/i915/Kconfig:40: symbol DRM_I915_FBDEV depends on > DRM_I915 > drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on ACPI_VIDEO > drivers/acpi/Kconfig:130: symbol ACPI_VIDEO is selected by > BACKLIGHT_CLASS_DEVICE > drivers/video/backlight/Kconfig:156: symbol BACKLIGHT_CLASS_DEVICE is > selected by FB_BACKLIGHT > drivers/video/fbdev/Kconfig:188: symbol FB_BACKLIGHT is selected by > PMAC_BACKLIGHT > drivers/macintosh/Kconfig:135:symbol PMAC_BACKLIGHT depends on FB > > and the rabbit hole gets deeper than I thought. I guess it always does. > > At this point the question is whether "depends on ((ACPI && ACPI_VIDEO) > || ACPI=n)" is worth pursuing and makes more sense than the "select foo > if ACPI" lines, or do we need to build hacks upon hacks to get this > fixed. I certainly prefer the depends that you added to all of those selects. I'm afraid that I can't help you much here other than to say that if you can express the driver needs with depends instead of select, you should come out ahead by removing some of the depth of the rabbit hole. -- ~Randy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesk
Re: [Intel-gfx] [PATCH 07/14] drm/i915: s/pm._irqs_disabled/pm.irqs_enabled/
2014-09-30 5:56 GMT-03:00 Daniel Vetter :
> Double negations just parse harder. Also this allows us to ditch some
> init code since clearing to 0 dtrt. Also ditch the assignment in
> intel_pm_setup, that's not redundant since we do the assignement now
> while setting up interrupts.
>
> While at it do engage in a bit of OCD and wrap up the few lines of
> setup/teardown code into little helper functions: intel_irq_fini for
> cleanup and intel_irq_init_hw for hw setup.
So the werid thing is that we now have:
- intel_irq_init
- intel_irq_init_hw
- intel_irq_fini
But the intel_irq_fini doesn't finish what intel_irq_init started, it
finishes what intel_irq_init_hw started. Since the functions you
introduced are basically wrappers to drm_irq_{un,}install, my bikeshed
would be to call the new functions simply intel_irq_install and
intel_irq_uninstall.
With or without that: Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 9 +
> drivers/gpu/drm/i915/i915_drv.h | 4 +++-
> drivers/gpu/drm/i915/i915_irq.c | 26 +-
> drivers/gpu/drm/i915/intel_display.c | 4 +---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 1 -
> 6 files changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 7075bd2adee8..969f0cff9fef 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1338,14 +1338,7 @@ static int i915_load_modeset_init(struct drm_device
> *dev)
>
> intel_power_domains_init_hw(dev_priv);
>
> - /*
> -* We enable some interrupt sources in our postinstall hooks, so mark
> -* interrupts as enabled _before_ actually enabling them to avoid
> -* special cases in our ordering checks.
> -*/
> - dev_priv->pm._irqs_disabled = false;
> -
> - ret = drm_irq_install(dev, dev->pdev->irq);
> + ret = intel_irq_init_hw(dev_priv);
> if (ret)
> goto cleanup_gem_stolen;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1d8a4b7bf61a..1eec0e81a5ca 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1405,7 +1405,7 @@ struct ilk_wm_values {
> */
> struct i915_runtime_pm {
> bool suspended;
> - bool _irqs_disabled;
> + bool irqs_enabled;
> };
>
> enum intel_pipe_crc_source {
> @@ -2285,6 +2285,8 @@ void gen6_set_pm_mask(struct drm_i915_private
> *dev_priv, u32 pm_iir,
> int new_delay);
> extern void intel_irq_init(struct drm_device *dev);
> extern void intel_hpd_init(struct drm_device *dev);
> +int intel_irq_init_hw(struct drm_i915_private *dev_priv);
> +void intel_irq_fini(struct drm_i915_private *dev_priv);
>
> extern void intel_uncore_sanitize(struct drm_device *dev);
> extern void intel_uncore_early_sanitize(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1ddfc81c..d9d09a9b4fc7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4656,9 +4656,6 @@ void intel_irq_init(struct drm_device *dev)
>
> pm_qos_add_request(&dev_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
> PM_QOS_DEFAULT_VALUE);
>
> - /* Haven't installed the IRQ handler yet */
> - dev_priv->pm._irqs_disabled = true;
> -
> if (IS_GEN2(dev)) {
> dev->max_vblank_count = 0;
> dev->driver->get_vblank_counter = i8xx_get_vblank_counter;
> @@ -4767,13 +4764,32 @@ void intel_hpd_init(struct drm_device *dev)
> spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> +int intel_irq_init_hw(struct drm_i915_private *dev_priv)
> +{
> + /*
> +* We enable some interrupt sources in our postinstall hooks, so mark
> +* interrupts as enabled _before_ actually enabling them to avoid
> +* special cases in our ordering checks.
> +*/
> + dev_priv->pm.irqs_enabled = true;
> +
> + return drm_irq_install(dev_priv->dev, dev_priv->dev->pdev->irq);
> +}
> +
> +void intel_irq_fini(struct drm_i915_private *dev_priv)
> +{
> + drm_irq_uninstall(dev_priv->dev);
> + intel_hpd_cancel_work(dev_priv);
> + dev_priv->pm.irqs_enabled = false;
> +}
> +
> /* Disable interrupts so we can allow runtime PM. */
> void intel_runtime_pm_disable_interrupts(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> dev->driver->irq_uninstall(dev);
> - dev_priv->pm._irqs_disabled = true;
> + dev_priv->pm.irqs_enabled = false;
> }
>
> /* Restore interrupts so we can recover from runtime PM. */
> @@ -4781,7 +4797,7 @@ void intel_runtime_pm_restore_interrupts(struct
> drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_
Re: [Intel-gfx] [PATCH 08/14] drm/i915: Use dev_priv instead of dev in irq setup functions
2014-09-30 5:56 GMT-03:00 Daniel Vetter :
> It's the new world order!
>
> Not going full monty on these here and rolling this out throughout the
> subsequent call chains since this is just for the kerneldoc. Later on
> we can go more crazy, especially once we've embedded drm_device
> correctly.
>
> v2: Also frob the runtime_pm functions ...
Needs rebase. If you plan to do it correctly:
Reviewed-by: Paulo Zanoni
If your rebase contains a bug: Nacked-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.c | 12 +-
> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> drivers/gpu/drm/i915/i915_irq.c | 40
> +++--
> drivers/gpu/drm/i915/intel_drv.h| 4 ++--
> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
> 6 files changed, 31 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 969f0cff9fef..f50ecb18525f 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1363,7 +1363,7 @@ static int i915_load_modeset_init(struct drm_device
> *dev)
> goto cleanup_gem;
>
> /* Only enable hotplug handling once the fbdev is fully set up. */
> - intel_hpd_init(dev);
> + intel_hpd_init(dev_priv);
>
> /*
> * Some ports require correctly set-up hpd registers for detection to
> @@ -1733,7 +1733,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_freewq;
> }
>
> - intel_irq_init(dev);
> + intel_irq_init(dev_priv);
> intel_uncore_sanitize(dev);
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f07b8518cd39..605a4c4580d5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -575,7 +575,7 @@ static int i915_drm_freeze(struct drm_device *dev)
>
> flush_delayed_work(&dev_priv->rps.delayed_resume_work);
>
> - intel_runtime_pm_disable_interrupts(dev);
> + intel_runtime_pm_disable_interrupts(dev_priv);
> intel_hpd_cancel_work(dev_priv);
>
> intel_suspend_encoders(dev_priv);
> @@ -681,7 +681,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
> restore_gtt_mappings)
> mutex_unlock(&dev->struct_mutex);
>
> /* We need working interrupts for modeset enabling ... */
> - intel_runtime_pm_restore_interrupts(dev);
> + intel_runtime_pm_enable_interrupts(dev_priv);
>
> intel_modeset_init_hw(dev);
>
> @@ -703,7 +703,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
> restore_gtt_mappings)
> * bother with the tiny race here where we might loose hotplug
> * notifications.
> * */
> - intel_hpd_init(dev);
> + intel_hpd_init(dev_priv);
> /* Config may have changed between suspend and resume */
> drm_helper_hpd_irq_event(dev);
> }
> @@ -1446,12 +1446,12 @@ static int intel_runtime_suspend(struct device
> *device)
> * intel_mark_idle().
> */
> cancel_work_sync(&dev_priv->rps.work);
> - intel_runtime_pm_disable_interrupts(dev);
> + intel_runtime_pm_disable_interrupts(dev_priv);
>
> ret = intel_suspend_complete(dev_priv);
> if (ret) {
> DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
> - intel_runtime_pm_restore_interrupts(dev);
> + intel_runtime_pm_enable_interrupts(dev_priv);
>
> return ret;
> }
> @@ -1511,7 +1511,7 @@ static int intel_runtime_resume(struct device *device)
> i915_gem_init_swizzling(dev);
> gen6_update_ring_freq(dev);
>
> - intel_runtime_pm_restore_interrupts(dev);
> + intel_runtime_pm_enable_interrupts(dev_priv);
> intel_reset_gt_powersave(dev);
>
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1eec0e81a5ca..854f1b92d3df 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2283,8 +2283,8 @@ void i915_handle_error(struct drm_device *dev, bool
> wedged,
>
> void gen6_set_pm_mask(struct drm_i915_private *dev_priv, u32 pm_iir,
> int new_delay);
> -extern void intel_irq_init(struct drm_device *dev);
> -extern void intel_hpd_init(struct drm_device *dev);
> +extern void intel_irq_init(struct drm_i915_private *dev_priv);
> +extern void intel_hpd_init(struct drm_i915_private *dev_priv);
> int intel_irq_init_hw(struct drm_i915_private *dev_priv);
> void intel_irq_fini(struct drm_i915_private *dev_pr
Re: [Intel-gfx] [PATCH 09/14] drm/i915: kerneldoc for interrupt enable/disable functions
2014-09-30 5:56 GMT-03:00 Daniel Vetter :
> Just start with the basics for now.
>
> Since there's a lot of different functionality in i915_irq.c I've
> decided to split it into different sections and pull in just the
> relevant functions. Splitting into different files looks like a lot
> more work since the interrupt handlers do an awful lot of reuse all
> over.
>
If you do the rename I suggested in patch 7, you'll have to change this patch.
Reviewed-by: Paulo Zanoni
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 9 ++
> drivers/gpu/drm/i915/i915_irq.c | 61
> +++--
> 2 files changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 69e422ab8352..e8ef0f9c7396 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3798,6 +3798,14 @@ int num_ioctls;
> !Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
> !Idrivers/gpu/drm/i915/intel_runtime_pm.c
>
> +
> +Interrupt Handling
> +!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling
> +!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw
> intel_hpd_init
> +!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_fini
> +!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
> +!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
> +
>
>
>Display Hardware Handling
> @@ -3951,5 +3959,6 @@ int num_ioctls;
>
>
>
> +!Cdrivers/gpu/drm/i915/i915_irq.c
>
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2c436e6c55b0..039625c22be4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -37,6 +37,14 @@
> #include "i915_trace.h"
> #include "intel_drv.h"
>
> +/**
> + * DOC: interrupt handling
> + *
> + * These functions provide the basic support for enabling and disabling the
> + * interrupt handling support. There's a lot more functionality in i915_irq.c
> + * and related files, but that will be described in separate chapters.
> + */
> +
> static const u32 hpd_ibx[] = {
> [HPD_CRT] = SDE_CRT_HOTPLUG,
> [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
> @@ -4631,6 +4639,13 @@ static void intel_hpd_irq_reenable_work(struct
> work_struct *work)
> intel_runtime_pm_put(dev_priv);
> }
>
> +/**
> + * intel_irq_init - initializes irq support
> + * @dev_priv: i915 device instance
> + *
> + * This function initializes all the irq support including work items, timers
> + * and all the vtables. It does not setup the interrupt itself though.
> + */
> void intel_irq_init(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> @@ -4736,6 +4751,18 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> }
> }
>
> +/**
> + * intel_hpd_init - initializes and enables hpd support
> + * @dev_priv: i915 device instance
> + *
> + * This function enables the hotplug support. It requires that interrupts
> have
> + * already been enabled with intel_irq_init_hw(). From this point on hotplug
> and
> + * poll request can run concurrently to other code, so locking rules must be
> + * obeyed.
> + *
> + * This is a separate step from interrupt enabling to simplify the locking
> rules
> + * in the driver load and resume code.
> + */
> void intel_hpd_init(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> @@ -4764,6 +4791,17 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
> spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> +/**
> + * intel_irq_init_hw - enables the hardware interrupt
> + * @dev_priv: i915 device instance
> + *
> + * This function enables the hardware interrupt handling, but leaves the
> hotplug
> + * handling still disabled. It is called after intel_irq_init().
> + *
> + * In the driver load and resume code we need working interrupts in a few
> places
> + * but don't want to deal with the hassle of concurrent probe and hotplug
> + * workers. Hence the split into this two-stage approach.
> + */
> int intel_irq_init_hw(struct drm_i915_private *dev_priv)
> {
> /*
> @@ -4776,6 +4814,13 @@ int intel_irq_init_hw(struct drm_i915_private
> *dev_priv)
> return drm_irq_install(dev_priv->dev, dev_priv->dev->pdev->irq);
> }
>
> +/**
> + * intel_irq_fini - finilizes all irq handling
> + * @dev_priv: i915 device instance
> + *
> + * This stops interrupt and hotplug handling and unregisters and frees all
> + * resources acquired in the init functions.
> + */
> void intel_irq_fini(struct drm_i915_private *dev_priv)
> {
> drm_irq_uninstall(dev_priv->dev);
> @@ -4783,14 +4828,26 @@ void intel_irq_fini(struct drm_i915_private *dev_priv)
> dev_priv->pm.irqs_enabled = false;
> }
>
> -/* Disable interrupts so we can allow runtime PM. */
> +/**
> + * intel_runtime_pm_disable_interrupts - runt
Re: [Intel-gfx] [PATCH] drm/i915: Revert "drm/i915: Reject the pin ioctl on gen6+"
On 2 October 2014 20:40, Bloomfield, Jon wrote: > On Fri, Sep 19, 2014 Daniel Vetter wrote: >> I still consider pinning stuff behind the kernels back too evil. So if people >> want that I'd like to see the use-case and why we can't do this differently. >> >> And I've never approved of the pin ioctl but really loudly complained about >> each occasion I've spotted, so I think the internal users just have to keep >> the >> pieces for a bit longer. >> -Daniel > > Daniel. All that's being asked for is a re-instatement of the old mechanism > until > a better solution can be designed and implemented. > > It may well be evil, but the mechanism was there, and was the only known > way to handle the OA buffer, so why wouldn't someone use it ? You've broken > userspace before you provided any alternative solution. > > Please, let's revert this while a more elegant solution is designed, > implemented, > reviewed, re-implemented, reviewed again, and maybe one day merged. > > Remember that it will take a while to filter down to people even after you > merge > any new solution to nightly, or even drm-next. If we have to wait for the new > design, it's not likely to reach us until next year. > > Can't we just agree that we're evil, but turn a blind eye while we're coaxed > slowly > back towards the light ? I thought we had an agreement that no features that were specific to the non-open source userspace drivers would be merged to the kernel, due to security and maintenance concerns, i.e. exactly this concern, we now have to maintain an interface that we can't regression test in public. Maybe next time who ever made the decision to force merge code will learn why its a bad idea. Personally I don't think this interface should be put back in, unless Mesa/Beigenet/libva uses it, does it even have igt tests? Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert "drm/i915: Reject the pin ioctl on gen6+"
Hi Dave, On Fri, Oct 03, 2014 at 07:12:53AM +1000, Dave Airlie wrote: > I thought we had an agreement that no features that were specific to > the non-open source userspace drivers would be merged to the kernel, > due to security and maintenance concerns, i.e. exactly this concern, > we now have to maintain an interface that we can't regression test in > public. Actually, the pin ioctl() has been here for quite some time, since the introduction of GEM, see: http://lwn.net/Articles/283798/ section 8.2 That's why one side is arguing that it's not acceptable to break user-space (open or closed , it doesn't matter at this point). Daniel is saying that's a legacy artefact and it shouldn't be used anymore, but breaking a user-space application is enough for me to at least suggest a revert. HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
