Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm
Dear Chris, Am Sonntag, den 10.02.2013, 23:21 + schrieb Chris Wilson: On Sun, Feb 10, 2013 at 11:37:03PM +0100, Paul Menzel wrote: Am Sonntag, den 10.02.2013, 19:38 + schrieb Chris Wilson: Reading the cspec pays dividends once again, as I found the 'Base of Stolen Memory' config register so that we can skip the fragile computation from Top of Usable Draw and use the real value provided by the BIOS. Nice find. What is the expected functionality change as the code beforehand was a no-op due to the `if 0`? It enables the driver to use stolen memory - memory that is hidden from the system and only available, in principal, to the gfx device. ah, nice. Thank you for the explanation. Should it be backported to the stable Linux kernel releases then, by adding the following line to the commit message? CC: sta...@vger.kernel.org If testing is needed, how can this be tested? Boot a 915g/945g. The driver will utilize stolen memory for its ringbuffers and fbcon. Any messages which will get logged to see if it works correctly? - /* Stolen is immediately below Top of Low Usable DRAM */ - pci_read_config_byte(pdev, 0x9c, val); - base = val 3 27; - base -= dev_priv-mm.gtt-stolen_size; + /* Read D2:F0 Base of Stolen Memory directly */ + pci_read_config_dword(dev-pdev, 0x5c, base); Should macros be defined for the register names? My argument is basically where else are you planning to use this value. Each chipset calls it something different and uses a different register, so DRY is not violated and instead of hiding the value in a header, we can define it locally and clearly. Makes adapting it for the next generation much easier as you only have the single location to worry about. (The normal argument for the macro, but in reverse.) Sounds reasonable. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes
At Sun, 10 Feb 2013 02:16:14 +0100, David Härdeman wrote: On Thu, Feb 07, 2013 at 11:00:13AM +0100, Daniel Vetter wrote: On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote: I'll break etiquette here and include the entire original message below (and top-post!) since I'm sending this to intel-gfx as well. Since the previous mail I've tested a more recent kernel (3.8-rc6), swapping HDMI cables and a firmware update on the receiver, none of it helped. I've also noticed that: a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make the sound go away (higher frame rates) or work (1080p30). So, it has nothing to do with interlacing. The only difference between the output of all the intel*dump tools when running 1080p30 and 1080p60 is included below. It's interesting to note that all the modes that don't work have fdi_lanes = 2 while the working ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak). I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su sure where the problem lies anymore...suggestions? I'm far away from an hdmi/snd expert, but iirc the bandwidth to squeeze hdmi sound packets between the video frames is limited. And atm our code does not bother with checking for that at all (and updating the capabilities of the hdmi snd widget). But that's just an idea, I have no idea how much bandwidth there actually is. I should add that I've now installed Win7 on a separate HD. Windows has no problems at all with audio over HDMI, no matter which resolution and/or refresh rate, so I think cabling and other HW issues can be ruled out. The problem is Linux-specific. And, as I mentioned before, the TV *is* willing to accept and decode the audio signal, so it appears that the audio stream is therebut it's probably incompatible in some minor way...and the receiver is being picky. That's my guess. Anyway, how should I proceed? File a bug? In the kernel bugzilla or ALSA bugtracker or somewhere else? FYI, ALSA bug tracker is down (and I hope it's no longer used), so put it in either freedesktop or kernel bugzilla. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ctx: Remove bad invariant
It's not that the assertion is incorrect, but rather that we can call do_destroy early in loading, and we will falsely BUG(). Since contexts have been in for a while now, and in the internal APIs are pretty stable, it should be fairly safe to remove this. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_context.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 13cada0..9893095 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -145,8 +145,6 @@ static void do_destroy(struct i915_hw_context *ctx) if (ctx-file_priv) idr_remove(ctx-file_priv-context_idr, ctx-id); - else - BUG_ON(ctx != dev_priv-ring[RCS].default_context); drm_gem_object_unreference(ctx-obj-base); kfree(ctx); -- 1.8.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/ctx: Remove bad invariant
It's not that the assertion is incorrect, but rather that we can call
do_destroy early in loading, and we will falsely BUG().
Since contexts have been in for a while now, and in the internal APIs
are pretty stable, it should be fairly safe to remove this.
v2: Remove unused dev_priv, and dev
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2c9a6bc..2a79749 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -135,9 +135,6 @@ static int get_context_size(struct drm_device *dev, bool
advanced)
static void do_destroy(struct i915_hw_context *ctx)
{
- struct drm_device *dev = ctx-obj-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
-
if (ctx-ring_obj) {
i915_gem_object_unpin(ctx-ring_obj);
drm_gem_object_unreference(ctx-ring_obj-base);
@@ -145,8 +142,6 @@ static void do_destroy(struct i915_hw_context *ctx)
if (ctx-file_priv)
idr_remove(ctx-file_priv-context_idr, ctx-id);
- else
- BUG_ON(ctx != dev_priv-ring[RCS].default_context);
drm_gem_object_unreference(ctx-obj-base);
kfree(ctx);
--
1.8.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ERROR: pm_vt_switch_unregister [drivers/video/fb.ko] undefined!
On Fri, 8 Feb 2013 10:51:48 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Fri, Feb 8, 2013 at 10:30 AM, kbuild test robot
fengguang...@intel.com wrote:
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
head: 69f0d09dfd2d0579241389aee18ba50aa39d0de2
commit: d6bc5b0603e5bea1b5a214d21c0aba8518f1a01f fb: add support for
drivers not needing VT switch at suspend/resume time
date: 2 days ago
config: i386-randconfig-b031 (attached as .config)
All error/warnings:
ERROR: pm_vt_switch_unregister [drivers/video/fb.ko] undefined!
ERROR: pm_vt_switch_required [drivers/video/fb.ko] undefined!
I guess there's a select CONFIG_VT_CONSOLE_SLEEP missing somewhere ...
Or at least a few stubs in headers if that's not selected. The
offending config option itself was created itself to fix compile fail:
commit 37cce26b32142f09a8967f6d238178af654b20de
Author: H Hartley Sweeten hartl...@visionengravers.com
Date: Wed Sep 21 22:47:55 2011 +0200
PM / VT: Cleanup #if defined uglyness and fix compile error
Jesse, Rafael?
I think this should work, but I don't build with PM_SLEEP disabled...
Jesse
From 0941d71fac64cb208b4cfb89a1698991c3902862 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Mon, 11 Feb 2013 14:25:43 -0800
Subject: [PATCH] pm: provide stubs for PM VT console switch routines
If PM_SLEEP is disabled, we need stub versions of these functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/linux/pm.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 98310eb..02e404b 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -35,9 +35,18 @@ extern void (*pm_idle)(void);
extern void (*pm_power_off)(void);
extern void (*pm_power_off_prepare)(void);
+#ifdef CONFIG_VT_CONSOLE_SLEEP
struct device; /* we have a circular dep with device.h */
extern void pm_vt_switch_required(struct device *dev, bool required);
extern void pm_vt_switch_unregister(struct device *dev);
+#else
+static inline void pm_vt_switch_required(struct device *dev, bool required)
+{
+}
+static inline void pm_vt_switch_unregister(struct device *dev)
+{
+}
+#endif /* CONFIG_VT_CONSOLE_SLEEP */
/*
* Device power management
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ERROR: pm_vt_switch_unregister [drivers/video/fb.ko] undefined!
On Mon, 11 Feb 2013 14:27:08 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 8 Feb 2013 10:51:48 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Fri, Feb 8, 2013 at 10:30 AM, kbuild test robot
fengguang...@intel.com wrote:
tree: git://people.freedesktop.org/~danvet/drm-intel.git
drm-intel-nightly
head: 69f0d09dfd2d0579241389aee18ba50aa39d0de2
commit: d6bc5b0603e5bea1b5a214d21c0aba8518f1a01f fb: add support for
drivers not needing VT switch at suspend/resume time
date: 2 days ago
config: i386-randconfig-b031 (attached as .config)
All error/warnings:
ERROR: pm_vt_switch_unregister [drivers/video/fb.ko] undefined!
ERROR: pm_vt_switch_required [drivers/video/fb.ko] undefined!
I guess there's a select CONFIG_VT_CONSOLE_SLEEP missing somewhere ...
Or at least a few stubs in headers if that's not selected. The
offending config option itself was created itself to fix compile fail:
commit 37cce26b32142f09a8967f6d238178af654b20de
Author: H Hartley Sweeten hartl...@visionengravers.com
Date: Wed Sep 21 22:47:55 2011 +0200
PM / VT: Cleanup #if defined uglyness and fix compile error
Jesse, Rafael?
I think this should work, but I don't build with PM_SLEEP disabled...
Jesse
From 0941d71fac64cb208b4cfb89a1698991c3902862 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Mon, 11 Feb 2013 14:25:43 -0800
Subject: [PATCH] pm: provide stubs for PM VT console switch routines
If PM_SLEEP is disabled, we need stub versions of these functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/linux/pm.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 98310eb..02e404b 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -35,9 +35,18 @@ extern void (*pm_idle)(void);
extern void (*pm_power_off)(void);
extern void (*pm_power_off_prepare)(void);
+#ifdef CONFIG_VT_CONSOLE_SLEEP
struct device; /* we have a circular dep with device.h */
extern void pm_vt_switch_required(struct device *dev, bool required);
extern void pm_vt_switch_unregister(struct device *dev);
+#else
+static inline void pm_vt_switch_required(struct device *dev, bool required)
+{
+}
+static inline void pm_vt_switch_unregister(struct device *dev)
+{
+}
+#endif /* CONFIG_VT_CONSOLE_SLEEP */
/*
* Device power management
Moving the struct device forward decl above the ifdef would be even
better...
--
Jesse Barnes, 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] intel_chipset: Merge igt chipsets
On Sun, 10 Feb 2013 09:54:57 -0800 Ben Widawsky b...@bwidawsk.net wrote: IGT is newer and arguably better. This change doesn't completely merge the files because it's a bit simpler if we move the I9XX macro over to IGT, and don't move over a few macros from IGT that libdrm doesn't care about. The advantage is being able to easily synchronize between the two definitions. It has been discussed, and would seem even easier if IGT simply used the libdrm header files, however since we want to keep IGT as isolated as possible, and many tests don't rely on libdrm, this isn't a good idea. This patch has been sitting around on an internal tree for a while, but because Jesse recently pushed VLV ID updates it painfully made me realize that I should probably try to upstream it sooner rather than later. Cc: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Ben Widawsky b...@bwidawsk.net --- Yeah it's fine with me. Making merging less painful and spurious differences fewer is an improvement. However, consolidating our PCI ID lists would be the best option. If we can't use libdrm for that, what should we use? -- Jesse Barnes, 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] intel_chipset: Merge igt chipsets
On Sun, 10 Feb 2013 09:54:57 -0800 Ben Widawsky b...@bwidawsk.net wrote: IGT is newer and arguably better. This change doesn't completely merge the files because it's a bit simpler if we move the I9XX macro over to IGT, and don't move over a few macros from IGT that libdrm doesn't care about. The advantage is being able to easily synchronize between the two definitions. It has been discussed, and would seem even easier if IGT simply used the libdrm header files, however since we want to keep IGT as isolated as possible, and many tests don't rely on libdrm, this isn't a good idea. This patch has been sitting around on an internal tree for a while, but because Jesse recently pushed VLV ID updates it painfully made me realize that I should probably try to upstream it sooner rather than later. Cc: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Ben Widawsky b...@bwidawsk.net --- intel/intel_chipset.h | 176 +- 1 file changed, 101 insertions(+), 75 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index ebec2f8..3123a90 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -28,6 +28,48 @@ #ifndef _INTEL_CHIPSET_H #define _INTEL_CHIPSET_H +#define PCI_CHIP_I8100x7121 +#define PCI_CHIP_I810_DC100 0x7123 +#define PCI_CHIP_I810_E 0x7125 +#define PCI_CHIP_I8150x1132 + +#define PCI_CHIP_I830_M 0x3577 +#define PCI_CHIP_845_G 0x2562 +#define PCI_CHIP_I855_GM 0x3582 +#define PCI_CHIP_I865_G 0x2572 + +#define PCI_CHIP_I915_G 0x2582 +#define PCI_CHIP_E7221_G 0x258A +#define PCI_CHIP_I915_GM 0x2592 +#define PCI_CHIP_I945_G 0x2772 +#define PCI_CHIP_I945_GM 0x27A2 +#define PCI_CHIP_I945_GME0x27AE + +#define PCI_CHIP_Q35_G 0x29B2 +#define PCI_CHIP_G33_G 0x29C2 +#define PCI_CHIP_Q33_G 0x29D2 + +#define PCI_CHIP_IGD_GM 0xA011 +#define PCI_CHIP_IGD_G 0xA001 + +#define IS_IGDGM(devid) (devid == PCI_CHIP_IGD_GM) +#define IS_IGDG(devid) (devid == PCI_CHIP_IGD_G) +#define IS_IGD(devid) (IS_IGDG(devid) || IS_IGDGM(devid)) + +#define PCI_CHIP_I965_G 0x29A2 +#define PCI_CHIP_I965_Q 0x2992 +#define PCI_CHIP_I965_G_10x2982 +#define PCI_CHIP_I946_GZ 0x2972 +#define PCI_CHIP_I965_GM0x2A02 +#define PCI_CHIP_I965_GME 0x2A12 + +#define PCI_CHIP_GM45_GM0x2A42 + +#define PCI_CHIP_IGD_E_G0x2E02 +#define PCI_CHIP_Q45_G 0x2E12 +#define PCI_CHIP_G45_G 0x2E22 +#define PCI_CHIP_G41_G 0x2E32 + #define PCI_CHIP_ILD_G 0x0042 #define PCI_CHIP_ILM_G 0x0046 @@ -83,96 +125,87 @@ #define PCI_CHIP_HASWELL_CRW_S_GT2 0x0D2A #define PCI_CHIP_HASWELL_CRW_S_GT2_PLUS 0x0D3A -#define PCI_CHIP_VALLEYVIEW_PO 0x0f30 /* power on board */ +#define PCI_CHIP_VALLEYVIEW_PO 0x0f30 /* VLV PO board */ #define PCI_CHIP_VALLEYVIEW_10x0f31 #define PCI_CHIP_VALLEYVIEW_20x0f32 #define PCI_CHIP_VALLEYVIEW_30x0f33 -#define IS_830(dev) (dev == 0x3577) -#define IS_845(dev) (dev == 0x2562) -#define IS_85X(dev) (dev == 0x3582) -#define IS_865(dev) (dev == 0x2572) +#define IS_MOBILE(devid) (devid == PCI_CHIP_I855_GM || \ + devid == PCI_CHIP_I915_GM || \ + devid == PCI_CHIP_I945_GM || \ + devid == PCI_CHIP_I945_GME || \ + devid == PCI_CHIP_I965_GM || \ + devid == PCI_CHIP_I965_GME || \ + devid == PCI_CHIP_GM45_GM || IS_IGD(devid) || \ + devid == PCI_CHIP_IVYBRIDGE_M_GT1 || \ + devid == PCI_CHIP_IVYBRIDGE_M_GT2) -#define IS_GEN2(dev) (IS_830(dev) || \ - IS_845(dev) ||\ - IS_85X(dev) ||\ - IS_865(dev)) +#define IS_G45(devid) (devid == PCI_CHIP_IGD_E_G || \ + devid == PCI_CHIP_Q45_G || \ + devid == PCI_CHIP_G45_G || \ + devid == PCI_CHIP_G41_G) +#define IS_GM45(devid) (devid == PCI_CHIP_GM45_GM) +#define IS_G4X(devid)(IS_G45(devid) || IS_GM45(devid)) -#define IS_915G(dev) (dev == 0x2582 || \ -
Re: [Intel-gfx] [PATCH] intel_chipset: Merge igt chipsets
On Mon, Feb 11, 2013 at 03:05:19PM -0800, Jesse Barnes wrote: On Sun, 10 Feb 2013 09:54:57 -0800 Ben Widawsky b...@bwidawsk.net wrote: IGT is newer and arguably better. This change doesn't completely merge the files because it's a bit simpler if we move the I9XX macro over to IGT, and don't move over a few macros from IGT that libdrm doesn't care about. The advantage is being able to easily synchronize between the two definitions. It has been discussed, and would seem even easier if IGT simply used the libdrm header files, however since we want to keep IGT as isolated as possible, and many tests don't rely on libdrm, this isn't a good idea. This patch has been sitting around on an internal tree for a while, but because Jesse recently pushed VLV ID updates it painfully made me realize that I should probably try to upstream it sooner rather than later. Cc: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Ben Widawsky b...@bwidawsk.net --- Yeah it's fine with me. Making merging less painful and spurious differences fewer is an improvement. However, consolidating our PCI ID lists would be the best option. If we can't use libdrm for that, what should we use? I won't argue whether or not we should use libdrm as a default place for chipset ids. I think we can agree that whether or not we make that decision, this is beneficial. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
