Re: [PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
On Tue, Sep 18, 2012 at 03:06:36PM -0700, Eric Nelson wrote:
> Hi Sascha,
>
> On 09/12/2012 03:31 AM, Sascha Hauer wrote:
> >From: Philipp Zabel
> >
> >Signed-off-by: Philipp Zabel
> >Signed-off-by: Sascha Hauer
> >---
> > .../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
> >
> > 1 file changed, 41 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> >
> >+
> >+example:
> >+
> >+display@di0 {
> >+compatible = "fsl,imx-parallel-display";
> >+edid = [edid-data];
> >+crtc =<&ipu 0>;
> >+interface-pix-fmt = "rgb24";
> >+};
>
> Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
> display or know a good way to produce one?
No, we are using the of videomode helper, see
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg18618.html
It is not included here to not add a dependency on it. We are trying to
mainline this separately.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
runtime PM and special power switches
Sorry for the delayed response. On Wednesday, September 12, 2012, Dave Airlie wrote: > On Wed, Sep 12, 2012 at 3:13 PM, Dave Airlie wrote: > > On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki wrote: > >> On Wednesday, September 12, 2012, Dave Airlie wrote: > >>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern >>> rowland.harvard.edu> wrote: > >>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote: > >>> > > >>> >> Hi, > >>> >> > >>> >> On Tuesday, September 11, 2012, Dave Airlie wrote: > >>> >> > Hi Rafael, > >>> >> > > >>> >> > I've been investigating runtime PM support for some use-cases on > >>> >> > GPUs. > >>> >> > > >>> >> > In some laptops we have a secondary GPU (optimus) that can be powered > >>> >> > up for certain 3D tasks and then turned off when finished with. Now I > >>> >> > did an initial pass on supporting it without using the kernel runtime > >>> >> > PM stuff, but Alan said I should take a look so here I am. > >>> >> > >>> >> Alan Stern or Alan Cox? :-) > >>> >> > >>> >> > While I've started to get a handle on things, we have a bit of an > >>> >> > extra that I'm not sure we cater for. > >>> >> > > >>> >> > Currently we get called from the PCI layer which after we are > >>> >> > finished > >>> >> > with our runtime suspend callback, will go put the device into the > >>> >> > correct state etc, however on these optimus/powerxpress laptops we > >>> >> > have a separate ACPI or platform driver controlled power switch that > >>> >> > we need to call once the PCI layer is finished the job. This switch > >>> >> > effectively turns the power to the card completely off leaving it > >>> >> > drawing no power. > >>> >> > > >>> >> > No we can't hit the switch from the driver callback as the PCI layer > >>> >> > will get lost, so I'm wondering how you'd envisage we could plug this > >>> >> > in. > >>> >> > >>> >> Hmm. In principle we might modify pci_pm_runtime_suspend() so that it > >>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is > >>> >> set. That would actually make it work in analogy with > >>> >> pci_pm_suspend_noirq(), > >>> >> so perhaps it's not even too dangerous. > >>> > > >>> > This sounds more like a job for a power domain. Unless the power > >>> > switch is already in the device hierarchy as a parent to the PCI > >>> > device. > >>> > >>> I'll have to investigate power domains then, > >>> > >>> The switch is hidden in many different places, one some laptops its in > >>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other > >>> one, in some its in a different ACPI _DSM, then we have it in the ACPI > >>> ATPX method on others, and finally Apple have it in a piece of hw that > >>> isn't just on the LPC bus or somewhere like that. > >>> > >>> Currently we just hide it all inside vga_switcheroo and I'd just need > >>> an interface to call that once the layers have stopped poking > >>> registers in PCI config space, if we could fix PCI runtime suspend so > >>> the driver was the last to g 2et called then that would also not suck. > >> > >> Well, as I said, we may try to change the PCI layer so that it doesn't > >> access the device any more in pci_pm_runtime_suspend() if it sees that > >> pci_dev->state_saved has been set by the driver's callback. Then, > >> your drivers would only need to set pci_dev->state_saved in their > >> .runtime_suspend() callbacks. > >> > > > > Actually it appears I'll need this, I'd forgotten things are a bit > > messier than I thought > > > > So there are two variants on the _DSM for nvidia dual-gpu machines, > > the older pre-optimus _DSM requires > > an explicit power off call post-D3, however for optimus _DSM the D3 > > transition will flick the power switch, however > > the pci code then goes and seem to turn the device back to D0 for some > > reason. So yes after save state, > > I'd really appreciate if it the pci layer would stop poking my device. OK, so the patch for that is appended. It would be nice if you could see if that's sufficient for your use cases. > >> Alternatively, which may be less hackish but more work, you can set the > >> pm_domain pointer in the device structure to a struct dev_pm_domain whose > >> ops will just call the corresponding bus type's ops except for > >> .runtime_suspend() that will execute the additional ACPI stuff after > >> calling > >> the bus type's method. > > > > I've mostly written this, and it seems to work, I've jsut set a > > pm_domain in the vga switcheroo code that copies the dev->bus->pm > > into a private structure. I'll need this for the old nvidia and radeon > > poweroffs. > > > > > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-opt-pwr > is my current WIP branch It looks reasonable to me. Thanks, Rafael --- drivers/pci/pci-driver.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux/drivers/pci/pci-driver.c === --- linux.orig/drivers/pci/pci-driver.c +++ linux
Re: [PATCH 6/6] staging: drm/imx: Add TODO
On Wed, Sep 12, 2012 at 12:31:14PM +0200, Sascha Hauer wrote: > Signed-off-by: Sascha Hauer > --- > drivers/staging/imx-drm/TODO | 22 ++ > 1 file changed, 22 insertions(+) > create mode 100644 drivers/staging/imx-drm/TODO > > diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO > new file mode 100644 > index 000..2075646 > --- /dev/null > +++ b/drivers/staging/imx-drm/TODO > @@ -0,0 +1,22 @@ > +TODO: > +- get DRM Maintainer review for this code > +- Factor out more code to common helper functions > +- decide where to put the base driver. It is not specific to a subsystem > + and would be used by DRM/KMS and media/V4L2 > +- convert irq driver to irq_domain_add_linear > + > +Missing features (not necessarily for moving out out staging): out of? > + > +- Add KMS plane support for CRTC driver > +- Add LDB (LVDS Display Bridge) support > +- Add i.MX6 HDMI support > +- Add support for IC (Image converter) > +- Add support for CSI (CMOS Sensor interface) > +- Add support for VDIC (Video Deinterlacer) > + > +Many work-in-progress patches for the above features exist. Contact > +Sascha Hauer if you are interested in working > +on a specific feature. > + > +Please send any patches to Greg Kroah-Hartman and Greg Kroah-Hartman ? > +Sascha Hauer > -- > 1.7.10.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #19 from Tom Stellard 2012-09-19 03:17:56 UTC --- Created attachment 67362 --> https://bugs.freedesktop.org/attachment.cgi?id=67362 Fix patch #2 If you apply these two patches and run Lightsmark with RADEON_TEX_GROUP=32, does it render correctly? How about with lower values of RADEON_TEX_GROUP, like 16 or 24? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 Tom Stellard changed: What|Removed |Added Attachment #63471|0 |1 is obsolete|| Attachment #63472|0 |1 is obsolete|| --- Comment #18 from Tom Stellard 2012-09-19 03:16:18 UTC --- Created attachment 67361 --> https://bugs.freedesktop.org/attachment.cgi?id=67361 Fix patch #1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: support drm_wait_vblank feature for VIDI
this patch adds drm_wait_vblank support to Virtual Display module
so user can use DRM_IOCT_WAIT_VBLANK ioctl with this patch.
for this, you should set _DRM_VBLANK_EXYNOS_VIDI flags to
vblwait->request.type
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 22 +-
include/drm/exynos_drm.h | 10 ++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index c95f7de..54b4415 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -56,6 +56,7 @@ struct vidi_context {
unsigned intconnected;
boolvblank_on;
boolsuspended;
+ booldirect_vblank;
struct work_struct work;
struct mutexlock;
};
@@ -224,6 +225,15 @@ static int vidi_enable_vblank(struct device *dev)
if (!test_and_set_bit(0, &ctx->irq_flags))
ctx->vblank_on = true;
+ ctx->direct_vblank = true;
+
+ /*
+* in case of page flip request, vidi_finish_pageflip function
+* will not be called because direct_vblank is true and then
+* that function will be called by overlay_ops->commit callback
+*/
+ schedule_work(&ctx->work);
+
return 0;
}
@@ -425,7 +435,17 @@ static void vidi_fake_vblank_handler(struct work_struct
*work)
/* refresh rate is about 50Hz. */
usleep_range(16000, 2);
- drm_handle_vblank(subdrv->drm_dev, manager->pipe);
+ mutex_lock(&ctx->lock);
+
+ if (ctx->direct_vblank) {
+ drm_handle_vblank(subdrv->drm_dev, manager->pipe);
+ ctx->direct_vblank = false;
+ mutex_unlock(&ctx->lock);
+ return;
+ }
+
+ mutex_unlock(&ctx->lock);
+
vidi_finish_pageflip(subdrv->drm_dev, manager->pipe);
}
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index c20b001..10f91ea 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -107,6 +107,16 @@ struct drm_exynos_vidi_connection {
uint64_t edid;
};
+/* Indicate Exynos specific vblank flags */
+enum e_drm_exynos_vblank {
+ /*
+* this flags is used for Virtual Display module
+* to use DRM_IOCTL_WAIT_VBLANK feature. for this,
+* user should set this flag to vblwait->request.type
+*/
+ _DRM_VBLANK_EXYNOS_VIDI = 2,
+};
+
/* memory type definitions. */
enum e_drm_exynos_gem_mem_type {
/* Physically Continuous memory and used as default. */
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: micro optimise cache flushing
From: Dave Airlie
We hit this a lot with i915 and although we'd like to engineer things to hit
it a lot less, this commit at least makes it consume a few less cycles.
from something containing
movzwl 0x0(%rip),%r10d
to
add%r8,%rdx
I only noticed it while using perf to profile something else.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_cache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 08758e0..3dbc7f1 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -37,12 +37,13 @@ drm_clflush_page(struct page *page)
{
uint8_t *page_virtual;
unsigned int i;
+ const int size = boot_cpu_data.x86_clflush_size;
if (unlikely(page == NULL))
return;
page_virtual = kmap_atomic(page);
- for (i = 0; i < PAGE_SIZE; i += boot_cpu_data.x86_clflush_size)
+ for (i = 0; i < PAGE_SIZE; i += size)
clflush(page_virtual + i);
kunmap_atomic(page_virtual);
}
--
1.7.12
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54727] R600_LLVM, draw: LLVM ERROR: Cannot select: v4f32 = insert_vector_elt
https://bugs.freedesktop.org/show_bug.cgi?id=54727 T?r?k Edwin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from T?r?k Edwin 2012-09-18 18:01:13 UTC --- Just tried and this works in 175fdd7b86cce4e1fc945058fa2223b77edbf8a6 now. Thanks for fixing it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55006] video playback causes total freeze on RV350
https://bugs.freedesktop.org/show_bug.cgi?id=55006 --- Comment #5 from Alex Deucher 2012-09-18 17:10:24 UTC --- (In reply to comment #4) > Firmware linux-free & non-free are installed. > > I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work > for me. I put the machine under heavy load and played several vids at the same > time: no freeze so far. > > So what do you guess the problem is? And in case you solve the bug, could you > backport it to Linux 3.2 too? AGP seems to be unstable on your system. Setting radeon.agpmode=-1 should work on older kernels as well. You might also try setting other values for agpmode. Try values 1, 2, 4, or 8 and see if any work for you and if so we can add a quirk for your system. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55006] video playback causes total freeze on RV350
https://bugs.freedesktop.org/show_bug.cgi?id=55006 --- Comment #4 from spamfang1199 at yahoo.de 2012-09-18 17:06:14 UTC --- Firmware linux-free & non-free are installed. I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work for me. I put the machine under heavy load and played several vids at the same time: no freeze so far. So what do you guess the problem is? And in case you solve the bug, could you backport it to Linux 3.2 too? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #8 from Alex Deucher 2012-09-18 17:00:44 --- The commit is: drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2) As of right now, it's here: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=297a34942adb9c547e922258263cd2642ebca61b but I rebase that branch regularly so it may change. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [drm-intel:drm-intel-nightly 40/142] drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared
On Wed, 19 Sep 2012 07:40:54 +0800
Fengguang Wu wrote:
> Hi Ben,
>
> FYI, kernel build failed on
>
> tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
> head: f0db8c3e57486ae7fdbc52bc157f997394d7d11d
> commit: 8c3f929b6147e142efc58d5d03dc6fa703b14a5d [40/142] drm/i915: Enable
> some sysfs stuff without CONFIG_PM
> config: i386-randconfig-b034 (attached as .config)
>
> All related error/warning messages:
>
> drivers/gpu/drm/i915/i915_sysfs.c: In function 'i915_teardown_sysfs':
> drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared
> (first use in this function)
> drivers/gpu/drm/i915/i915_sysfs.c:228:49: note: each undeclared identifier is
> reported only once for each function it appears in
>
> vim +228 drivers/gpu/drm/i915/i915_sysfs.c
>223}
>224
>225void i915_teardown_sysfs(struct drm_device *dev)
>226{
>227device_remove_bin_file(&dev->primary->kdev,
> &dpf_attrs);
> > 228sysfs_unmerge_group(&dev->primary->kdev.kobj,
> &rc6_attr_group);
>229}
>
> ---
> 0-DAY kernel build testing backend Open Source Technology Centre
> Fengguang Wu, Yuanhan Liu Intel Corporation
Darn. I'll send a patch to the list tonight. (It's weird because I
thought I tested this).
--
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-nightly 40/142] drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared
On Wed, 19 Sep 2012 07:40:54 +0800
Fengguang Wu wrote:
> Hi Ben,
>
> FYI, kernel build failed on
>
> tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
> head: f0db8c3e57486ae7fdbc52bc157f997394d7d11d
> commit: 8c3f929b6147e142efc58d5d03dc6fa703b14a5d [40/142] drm/i915: Enable
> some sysfs stuff without CONFIG_PM
> config: i386-randconfig-b034 (attached as .config)
>
> All related error/warning messages:
>
> drivers/gpu/drm/i915/i915_sysfs.c: In function 'i915_teardown_sysfs':
> drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared
> (first use in this function)
> drivers/gpu/drm/i915/i915_sysfs.c:228:49: note: each undeclared identifier is
> reported only once for each function it appears in
>
> vim +228 drivers/gpu/drm/i915/i915_sysfs.c
>223}
>224
>225void i915_teardown_sysfs(struct drm_device *dev)
>226{
>227device_remove_bin_file(&dev->primary->kdev,
> &dpf_attrs);
> > 228sysfs_unmerge_group(&dev->primary->kdev.kobj,
> &rc6_attr_group);
>229}
>
> ---
> 0-DAY kernel build testing backend Open Source Technology Centre
> Fengguang Wu, Yuanhan Liu Intel Corporation
Darn. I'll send a patch to the list tonight. (It's weird because I
thought I tested this).
--
Ben Widawsky, Intel Open Source Technology Center
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #7 from Anisse Astier 2012-09-18 16:46:05 --- After about 180 reboots, I can confirm that this bug isn't present anymore on drm-next-3.7-wip. But I wasn't able to find commit 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 . Which commit do you think contains the fix ? I still have a seemlingly unrelated "screen off/lockup on reboot" problem (that shouldn't be a regression). But this is a story for another bug report. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/exynos: Fix potential NULL pointer dereference
drm_mode_create() returns NULL if it fails to create
a new display mode. Check the value returned to avoid NULL
pointer deferencing later.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 9dce3b9..485e984 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -149,8 +149,12 @@ static int exynos_drm_connector_get_modes(struct
drm_connector *connector)
count = drm_add_edid_modes(connector, edid);
kfree(edid);
} else {
- struct drm_display_mode *mode = drm_mode_create(connector->dev);
struct exynos_drm_panel_info *panel;
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ if (!mode) {
+ DRM_ERROR("failed to create a new display mode.\n");
+ return 0;
+ }
if (display_ops->get_panel)
panel = display_ops->get_panel(manager->dev);
--
1.7.4.1
[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
Hi Sascha,
On 09/12/2012 03:31 AM, Sascha Hauer wrote:
> From: Philipp Zabel
>
> Signed-off-by: Philipp Zabel
> Signed-off-by: Sascha Hauer
> ---
> .../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
>
> 1 file changed, 41 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
>
> diff --git
> a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> new file mode 100644
> index 000..07654f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> @@ -0,0 +1,41 @@
> +Freescale i.MX IPUv3
> +
> +
> +Required properties:
> +- compatible: Should be "fsl,-ipu"
> +- reg: should be register base and length as documented in the
> + datasheet
> +- interrupts: Should contain sync interrupt and error interrupt,
> + in this order.
> +- #crtc-cells: 1, See below
> +
> +example:
> +
> +ipu: ipu at 1800 {
> + #crtc-cells =<1>;
> + compatible = "fsl,imx53-ipu";
> + reg =<0x1800 0x08000>;
> + interrupts =<11 10>;
> +};
> +
> +Parallel display support
> +
> +
> +Required properties:
> +- compatible: Should be "fsl,imx-parallel-display"
> +- crtc: the crtc this display is connected to, see below
> +Optional properties:
> +- interface_pix_fmt: How this display is connected to the
> + crtc. Currently supported types: "rgb24", "rgb565"
> +- edid: verbatim EDID data block describing attached display.
> +- ddc: phandle describing the i2c bus handling the display data
> + channel
> +
> +example:
> +
> +display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + edid = [edid-data];
> + crtc =<&ipu 0>;
> + interface-pix-fmt = "rgb24";
> +};
Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
display or know a good way to produce one?
Thanks in advance,
Eric
Re: runtime PM and special power switches
Sorry for the delayed response. On Wednesday, September 12, 2012, Dave Airlie wrote: > On Wed, Sep 12, 2012 at 3:13 PM, Dave Airlie wrote: > > On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki wrote: > >> On Wednesday, September 12, 2012, Dave Airlie wrote: > >>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern > >>> wrote: > >>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote: > >>> > > >>> >> Hi, > >>> >> > >>> >> On Tuesday, September 11, 2012, Dave Airlie wrote: > >>> >> > Hi Rafael, > >>> >> > > >>> >> > I've been investigating runtime PM support for some use-cases on > >>> >> > GPUs. > >>> >> > > >>> >> > In some laptops we have a secondary GPU (optimus) that can be powered > >>> >> > up for certain 3D tasks and then turned off when finished with. Now I > >>> >> > did an initial pass on supporting it without using the kernel runtime > >>> >> > PM stuff, but Alan said I should take a look so here I am. > >>> >> > >>> >> Alan Stern or Alan Cox? :-) > >>> >> > >>> >> > While I've started to get a handle on things, we have a bit of an > >>> >> > extra that I'm not sure we cater for. > >>> >> > > >>> >> > Currently we get called from the PCI layer which after we are > >>> >> > finished > >>> >> > with our runtime suspend callback, will go put the device into the > >>> >> > correct state etc, however on these optimus/powerxpress laptops we > >>> >> > have a separate ACPI or platform driver controlled power switch that > >>> >> > we need to call once the PCI layer is finished the job. This switch > >>> >> > effectively turns the power to the card completely off leaving it > >>> >> > drawing no power. > >>> >> > > >>> >> > No we can't hit the switch from the driver callback as the PCI layer > >>> >> > will get lost, so I'm wondering how you'd envisage we could plug this > >>> >> > in. > >>> >> > >>> >> Hmm. In principle we might modify pci_pm_runtime_suspend() so that it > >>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is > >>> >> set. That would actually make it work in analogy with > >>> >> pci_pm_suspend_noirq(), > >>> >> so perhaps it's not even too dangerous. > >>> > > >>> > This sounds more like a job for a power domain. Unless the power > >>> > switch is already in the device hierarchy as a parent to the PCI > >>> > device. > >>> > >>> I'll have to investigate power domains then, > >>> > >>> The switch is hidden in many different places, one some laptops its in > >>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other > >>> one, in some its in a different ACPI _DSM, then we have it in the ACPI > >>> ATPX method on others, and finally Apple have it in a piece of hw that > >>> isn't just on the LPC bus or somewhere like that. > >>> > >>> Currently we just hide it all inside vga_switcheroo and I'd just need > >>> an interface to call that once the layers have stopped poking > >>> registers in PCI config space, if we could fix PCI runtime suspend so > >>> the driver was the last to g 2et called then that would also not suck. > >> > >> Well, as I said, we may try to change the PCI layer so that it doesn't > >> access the device any more in pci_pm_runtime_suspend() if it sees that > >> pci_dev->state_saved has been set by the driver's callback. Then, > >> your drivers would only need to set pci_dev->state_saved in their > >> .runtime_suspend() callbacks. > >> > > > > Actually it appears I'll need this, I'd forgotten things are a bit > > messier than I thought > > > > So there are two variants on the _DSM for nvidia dual-gpu machines, > > the older pre-optimus _DSM requires > > an explicit power off call post-D3, however for optimus _DSM the D3 > > transition will flick the power switch, however > > the pci code then goes and seem to turn the device back to D0 for some > > reason. So yes after save state, > > I'd really appreciate if it the pci layer would stop poking my device. OK, so the patch for that is appended. It would be nice if you could see if that's sufficient for your use cases. > >> Alternatively, which may be less hackish but more work, you can set the > >> pm_domain pointer in the device structure to a struct dev_pm_domain whose > >> ops will just call the corresponding bus type's ops except for > >> .runtime_suspend() that will execute the additional ACPI stuff after > >> calling > >> the bus type's method. > > > > I've mostly written this, and it seems to work, I've jsut set a > > pm_domain in the vga switcheroo code that copies the dev->bus->pm > > into a private structure. I'll need this for the old nvidia and radeon > > poweroffs. > > > > > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-opt-pwr > is my current WIP branch It looks reasonable to me. Thanks, Rafael --- drivers/pci/pci-driver.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux/drivers/pci/pci-driver.c === --- linux.orig/drivers/pci/pci-driver.c +++ linux/drivers/pci/pci-d
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #6 from Alex Deucher 2012-09-18 14:41:46 --- This bug sounds kind of like the bugs that 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 fixes. Can you see if this is fixed in my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip I have a more complete set of patches to properly disable MC clients when changing the MC. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PULL v2] SH Mobile DRM driver for v3.7
Hi Dave, Here's the second pull request for the SH Mobile DRM driver. Compared to v1, the include/drm/shmob_drm.h private header has been moved to include/linux/platform_data/. The following changes since commit 0b2443ed4e07d7973e4554a2cc166bc35447b59e: drm/edid: limit printk when facing bad edid (2012-09-17 11:16:40 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Lars-Peter Clausen (1): DRM: Add DRM KMS/FB CMA helper Laurent Pinchart (2): drm: Add NV24 and NV42 pixel formats drm: Renesas SH Mobile DRM driver Sascha Hauer (1): DRM: Add DRM GEM CMA helper drivers/gpu/drm/Kconfig| 17 + drivers/gpu/drm/Makefile |3 + drivers/gpu/drm/drm_crtc.c |6 + drivers/gpu/drm/drm_fb_cma_helper.c| 406 + drivers/gpu/drm/drm_gem_cma_helper.c | 251 drivers/gpu/drm/shmobile/Kconfig | 10 + drivers/gpu/drm/shmobile/Makefile |7 + drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++ drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 763 +++ drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++ drivers/gpu/drm/shmobile/shmob_drm_drv.c | 361 +++ drivers/gpu/drm/shmobile/shmob_drm_drv.h | 47 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 + drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 268 + drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 + drivers/gpu/drm/shmobile/shmob_drm_regs.h | 311 ++ include/drm/drm_fb_cma_helper.h| 27 + include/drm/drm_fourcc.h |2 + include/drm/drm_gem_cma_helper.h | 44 ++ include/linux/platform_data/shmob_drm.h| 99 +++ 22 files changed, 3011 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c create mode 100644 drivers/gpu/drm/shmobile/Kconfig create mode 100644 drivers/gpu/drm/shmobile/Makefile create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h create mode 100644 include/drm/drm_fb_cma_helper.h create mode 100644 include/drm/drm_gem_cma_helper.h create mode 100644 include/linux/platform_data/shmob_drm.h -- Regards, Laurent Pinchart
[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
On Tue, 2012-09-18 at 10:58 -0400, Adam Jackson wrote: > If there's no downstream device, DPCD success is good enough. If > there's a hotplug-capable downstream device, count the number of > connected sinks in DP_SINK_STATUS and return success if it's non-zero. > Otherwise, probe DDC and report appropriately. > > v2: Check DP_SINK_STATUS instead of something unrelated to sink status. Ugh, s/STATUS/COUNT/g in the summary, sorry. - ajax -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120918/5e75451b/attachment.pgp>
[Bug 54727] R600_LLVM, draw: LLVM ERROR: Cannot select: v4f32 = insert_vector_elt
https://bugs.freedesktop.org/show_bug.cgi?id=54727 Török Edwin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Török Edwin 2012-09-18 18:01:13 UTC --- Just tried and this works in 175fdd7b86cce4e1fc945058fa2223b77edbf8a6 now. Thanks for fixing it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
If there's no downstream device, DPCD success is good enough. If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.
v2: Check DP_SINK_STATUS instead of something unrelated to sink status.
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 098119e..813b771 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2088,11 +2088,44 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
}
+/* XXX this is probably wrong for multiple downstream ports */
static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
- if (intel_dp_get_dpcd(intel_dp))
+ uint8_t *dpcd = intel_dp->dpcd;
+ bool hpd;
+ uint8_t type;
+
+ if (!intel_dp_get_dpcd(intel_dp))
+ return connector_status_disconnected;
+
+ /* if there's no downstream port, we're done */
+ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return connector_status_connected;
+
+ /* If we're HPD-aware, SINK_COUNT changes dynamically */
+ hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
+ if (hpd) {
+ uint8_t sink_count;
+ if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+ &sink_count, 1))
+ return connector_status_unknown;
+ sink_count &= DP_SINK_COUNT_MASK;
+ return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+ }
+
+ /* If no HPD, poke DDC gently */
+ if (drm_probe_ddc(&intel_dp->adapter))
return connector_status_connected;
+
+ /* Well we tried, say unknown for unreliable port types */
+ type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+ if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
+ return connector_status_unknown;
+
+ /* Anything else is out of spec, warn and ignore */
+ DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
return connector_status_disconnected;
}
--
1.7.7.6
[PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..098119e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
#include "drm_dp_helper.h"
#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
#define DP_LINK_STATUS_SIZE6
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp->dpcd,
- sizeof(intel_dp->dpcd)) &&
- (intel_dp->dpcd[DP_DPCD_REV] != 0)) {
- return true;
- }
+ sizeof(intel_dp->dpcd)) == 0)
+ return false; /* aux transfer failed */
- return false;
+ if (intel_dp->dpcd[DP_DPCD_REV] == 0)
+ return false; /* DPCD not present */
+
+ if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_PRESENT))
+ return true; /* native DP sink */
+
+ if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
+ return true; /* no per-port downstream info */
+
+ if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+ intel_dp->downstream_ports,
+ DP_MAX_DOWNSTREAM_PORTS) == 0)
+ return false; /* downstream port status fetch failed */
+
+ return true;
}
static void
--
1.7.7.6
[PATCH 2/4] drm/dp: Update DPCD defines
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Tested-by: Takashi Iwai Signed-off-by: Adam Jackson --- include/drm/drm_dp_helper.h | 60 --- 1 files changed, 56 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1744b18c..f9888c3 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -69,16 +69,30 @@ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 << 3) +# define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) #define DP_MAIN_LINK_CHANNEL_CODING 0x006 #define DP_DOWN_STREAM_PORT_COUNT 0x007 -#define DP_PORT_COUNT_MASK0x0f -#define DP_OUI_SUPPORT(1 << 7) +# define DP_PORT_COUNT_MASK0x0f +# define DP_MSA_TIMING_PAR_IGNORED (1 << 6) +# define DP_OUI_SUPPORT(1 << 7) + +#define DP_I2C_SPEED_CAP 0x00c +# define DP_I2C_SPEED_1K 0x01 +# define DP_I2C_SPEED_5K 0x02 +# define DP_I2C_SPEED_10K 0x04 +# define DP_I2C_SPEED_100K 0x08 +# define DP_I2C_SPEED_400K 0x10 +# define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d #define DP_TRAINING_AUX_RD_INTERVAL 0x00e +/* Multiple stream transport */ +#define DP_MSTM_CAP0x021 +# define DP_MST_CAP(1 << 0) + #define DP_PSR_SUPPORT 0x070 # define DP_PSR_IS_SUPPORTED1 #define DP_PSR_CAPS 0x071 @@ -93,6 +107,31 @@ # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT1 +/* + * 0x80-0x8f describe downstream port capabilities, but there are two layouts + * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, + * each port's descriptor is one byte wide. If it was set, each port's is + * four bytes wide, starting with the one byte from the base info. As of + * DP interop v1.1a only VGA defines additional detail. + */ + +/* offset 0 */ +#define DP_DOWNSTREAM_PORT_0 0x80 +# define DP_DS_PORT_TYPE_MASK (7 << 0) +# define DP_DS_PORT_TYPE_DP0 +# define DP_DS_PORT_TYPE_VGA 1 +# define DP_DS_PORT_TYPE_DVI 2 +# define DP_DS_PORT_TYPE_HDMI 3 +# define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DS_PORT_HPD(1 << 3) +/* offset 1 for VGA is maximum megapixels per second / 8 */ +/* offset 2 */ +# define DP_DS_VGA_MAX_BPC_MASK(3 << 0) +# define DP_DS_VGA_8BPC0 +# define DP_DS_VGA_10BPC 1 +# define DP_DS_VGA_12BPC 2 +# define DP_DS_VGA_16BPC 3 + /* link configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_BW_1_62 0x06 @@ -148,24 +187,37 @@ #define DP_DOWNSPREAD_CTRL 0x107 # define DP_SPREAD_AMP_0_5 (1 << 4) +# define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 # define DP_SET_ANSI_8B10B (1 << 0) +#define DP_I2C_SPEED_CONTROL_STATUS0x109 +/* bitmask as for DP_I2C_SPEED_CAP */ + +#define DP_EDP_CONFIGURATION_SET0x10a + +#define DP_MSTM_CTRL 0x111 +# define DP_MST_EN (1 << 0) +# define DP_UP_REQ_EN (1 << 1) +# define DP_UPSTREAM_IS_SRC(1 << 2) + #define DP_PSR_EN_CFG 0x170 # define DP_PSR_ENABLE (1 << 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +#define DP_SINK_COUNT 0x200 +# define DP_SINK_COUNT_MASK(31 << 0) +# define DP_SINK_CP_READY (1 << 6) + #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201 # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 << 0) # define DP_AUTOMATED_TEST_REQUEST (1 << 1) # define DP_CP_IRQ (1 << 2) # define DP_SINK_SPECIFIC_IRQ (1 << 6) -#define DP_EDP_CONFIGURATION_SET0x10a - #define DP_LANE0_1_STATUS 0x202 #define DP_LANE2_3_STATUS 0x203 # define DP_LANE_CR_DONE (1 << 0) -- 1.7.7.6
[PATCH 1/4] drm: Export drm_probe_ddc()
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -376,13 +376,14 @@ out:
* \param adapter : i2c device adaptor
* \return 1 on success
*/
-static bool
+bool
drm_probe_ddc(struct i2c_adapter *adapter)
{
unsigned char out;
return (drm_do_probe_ddc_edid(adapter, &out, 0, 1) == 0);
}
+EXPORT_SYMBOL(drm_probe_ddc);
/**
* drm_get_edid - get EDID data, if available
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..f5d434b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -862,6 +862,7 @@ extern char *drm_get_tv_subconnector_name(int val);
extern char *drm_get_tv_select_name(int val);
extern void drm_fb_release(struct drm_file *file_priv);
extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct
drm_mode_group *group);
+extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
--
1.7.7.6
[Bug 55047] New: [855gm] Boots noisely with the lid close (but works!)
https://bugs.freedesktop.org/show_bug.cgi?id=55047 Bug #: 55047 Summary: [855gm] Boots noisely with the lid close (but works!) Classification: Unclassified Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: DRM/other AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: chris at chris-wilson.co.uk Created attachment 67320 --> https://bugs.freedesktop.org/attachment.cgi?id=67320 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] [RESEND] console: implement lockdep support for console_lock
On Tue, 18 Sep 2012, Daniel Vetter wrote:
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map console_lock_dep_map = {
> + .name = "console_lock"
> +};
> +#endif
static?
BR,
Jani.
[Bug 55006] video playback causes total freeze on RV350
https://bugs.freedesktop.org/show_bug.cgi?id=55006 --- Comment #5 from Alex Deucher 2012-09-18 17:10:24 UTC --- (In reply to comment #4) > Firmware linux-free & non-free are installed. > > I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work > for me. I put the machine under heavy load and played several vids at the same > time: no freeze so far. > > So what do you guess the problem is? And in case you solve the bug, could you > backport it to Linux 3.2 too? AGP seems to be unstable on your system. Setting radeon.agpmode=-1 should work on older kernels as well. You might also try setting other values for agpmode. Try values 1, 2, 4, or 8 and see if any work for you and if so we can add a quirk for your system. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[XDC 2012] Conference Update #6
Hi folks, the XDC2012 conference program (modulo updates) is now available at http://www.x.org/wiki/Events/XDC2012/Program The program will also be available in printed form on site. Please be aware that we currently have major issues with MoinMoin wiki, probably due to the massive spamming attacks Alan is trying hard to repel. If you get Guru Meditations while accessing the Wiki, chances are the watchdog has already triggered, and the Wiki should be back in approximately 15 minutes then. Have fun Matthias -- | ,_, Matthias Hopf | ( ) |__| |\/| Professor for Applied Computer Sciencematthias at hopf.in | ,) (, | | | | Georg-Simon-Ohm-University, Nurembergwww.hopf.in
[Bug 55006] video playback causes total freeze on RV350
https://bugs.freedesktop.org/show_bug.cgi?id=55006 --- Comment #4 from spamfang1...@yahoo.de 2012-09-18 17:06:14 UTC --- Firmware linux-free & non-free are installed. I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work for me. I put the machine under heavy load and played several vids at the same time: no freeze so far. So what do you guess the problem is? And in case you solve the bug, could you backport it to Linux 3.2 too? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #8 from Alex Deucher 2012-09-18 17:00:44 --- The commit is: drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2) As of right now, it's here: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=297a34942adb9c547e922258263cd2642ebca61b but I rebase that branch regularly so it may change. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #7 from Anisse Astier 2012-09-18 16:46:05 --- After about 180 reboots, I can confirm that this bug isn't present anymore on drm-next-3.7-wip. But I wasn't able to find commit 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 . Which commit do you think contains the fix ? I still have a seemlingly unrelated "screen off/lockup on reboot" problem (that shouldn't be a regression). But this is a story for another bug report. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: drm: Add match table for drm platform device
This patch adds match table for drm platform device.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d070719..18abdcc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -294,12 +294,21 @@ static int exynos_drm_platform_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id drm_device_dt_match[] = {
+ { .compatible = "samsung,exynos-drm-device"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, drm_device_dt_match);
+#endif
+
static struct platform_driver exynos_drm_platform_driver = {
.probe = exynos_drm_platform_probe,
.remove = __devexit_p(exynos_drm_platform_remove),
.driver = {
.owner = THIS_MODULE,
.name = "exynos-drm",
+ .of_match_table = of_match_ptr(drm_device_dt_match),
},
};
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Fix potential NULL pointer dereference
drm_mode_create() returns NULL if it fails to create
a new display mode. Check the value returned to avoid NULL
pointer deferencing later.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 9dce3b9..485e984 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -149,8 +149,12 @@ static int exynos_drm_connector_get_modes(struct
drm_connector *connector)
count = drm_add_edid_modes(connector, edid);
kfree(edid);
} else {
- struct drm_display_mode *mode = drm_mode_create(connector->dev);
struct exynos_drm_panel_info *panel;
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ if (!mode) {
+ DRM_ERROR("failed to create a new display mode.\n");
+ return 0;
+ }
if (display_ops->get_panel)
panel = display_ops->get_panel(manager->dev);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.6
From: Alex Deucher The pll fix ended up causing some regressions. Drop it for 3.6. I've fixed it properly in 3.7, but the fix is too invasive for 3.6. The following changes since commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc: drm/nouveau: fix booting with plymouth + dumb support (2012-09-14 15:45:01 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 Alex Deucher (1): Revert "drm/radeon: rework pll selection (v3)" drivers/gpu/drm/radeon/atombios_crtc.c | 163 +++- 1 files changed, 34 insertions(+), 129 deletions(-)
Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
On Tue, 2012-09-18 at 10:58 -0400, Adam Jackson wrote: > If there's no downstream device, DPCD success is good enough. If > there's a hotplug-capable downstream device, count the number of > connected sinks in DP_SINK_STATUS and return success if it's non-zero. > Otherwise, probe DDC and report appropriately. > > v2: Check DP_SINK_STATUS instead of something unrelated to sink status. Ugh, s/STATUS/COUNT/g in the summary, sorry. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
If there's no downstream device, DPCD success is good enough. If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.
v2: Check DP_SINK_STATUS instead of something unrelated to sink status.
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 098119e..813b771 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2088,11 +2088,44 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
}
+/* XXX this is probably wrong for multiple downstream ports */
static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
- if (intel_dp_get_dpcd(intel_dp))
+ uint8_t *dpcd = intel_dp->dpcd;
+ bool hpd;
+ uint8_t type;
+
+ if (!intel_dp_get_dpcd(intel_dp))
+ return connector_status_disconnected;
+
+ /* if there's no downstream port, we're done */
+ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return connector_status_connected;
+
+ /* If we're HPD-aware, SINK_COUNT changes dynamically */
+ hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
+ if (hpd) {
+ uint8_t sink_count;
+ if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+ &sink_count, 1))
+ return connector_status_unknown;
+ sink_count &= DP_SINK_COUNT_MASK;
+ return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+ }
+
+ /* If no HPD, poke DDC gently */
+ if (drm_probe_ddc(&intel_dp->adapter))
return connector_status_connected;
+
+ /* Well we tried, say unknown for unreliable port types */
+ type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+ if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
+ return connector_status_unknown;
+
+ /* Anything else is out of spec, warn and ignore */
+ DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
return connector_status_disconnected;
}
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..098119e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
#include "drm_dp_helper.h"
#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
#define DP_LINK_STATUS_SIZE6
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp->dpcd,
- sizeof(intel_dp->dpcd)) &&
- (intel_dp->dpcd[DP_DPCD_REV] != 0)) {
- return true;
- }
+ sizeof(intel_dp->dpcd)) == 0)
+ return false; /* aux transfer failed */
- return false;
+ if (intel_dp->dpcd[DP_DPCD_REV] == 0)
+ return false; /* DPCD not present */
+
+ if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_PRESENT))
+ return true; /* native DP sink */
+
+ if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
+ return true; /* no per-port downstream info */
+
+ if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+ intel_dp->downstream_ports,
+ DP_MAX_DOWNSTREAM_PORTS) == 0)
+ return false; /* downstream port status fetch failed */
+
+ return true;
}
static void
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/dp: Update DPCD defines
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Tested-by: Takashi Iwai Signed-off-by: Adam Jackson --- include/drm/drm_dp_helper.h | 60 --- 1 files changed, 56 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1744b18c..f9888c3 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -69,16 +69,30 @@ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 << 3) +# define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) #define DP_MAIN_LINK_CHANNEL_CODING 0x006 #define DP_DOWN_STREAM_PORT_COUNT 0x007 -#define DP_PORT_COUNT_MASK0x0f -#define DP_OUI_SUPPORT(1 << 7) +# define DP_PORT_COUNT_MASK0x0f +# define DP_MSA_TIMING_PAR_IGNORED (1 << 6) +# define DP_OUI_SUPPORT(1 << 7) + +#define DP_I2C_SPEED_CAP 0x00c +# define DP_I2C_SPEED_1K 0x01 +# define DP_I2C_SPEED_5K 0x02 +# define DP_I2C_SPEED_10K 0x04 +# define DP_I2C_SPEED_100K 0x08 +# define DP_I2C_SPEED_400K 0x10 +# define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d #define DP_TRAINING_AUX_RD_INTERVAL 0x00e +/* Multiple stream transport */ +#define DP_MSTM_CAP0x021 +# define DP_MST_CAP(1 << 0) + #define DP_PSR_SUPPORT 0x070 # define DP_PSR_IS_SUPPORTED1 #define DP_PSR_CAPS 0x071 @@ -93,6 +107,31 @@ # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT1 +/* + * 0x80-0x8f describe downstream port capabilities, but there are two layouts + * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, + * each port's descriptor is one byte wide. If it was set, each port's is + * four bytes wide, starting with the one byte from the base info. As of + * DP interop v1.1a only VGA defines additional detail. + */ + +/* offset 0 */ +#define DP_DOWNSTREAM_PORT_0 0x80 +# define DP_DS_PORT_TYPE_MASK (7 << 0) +# define DP_DS_PORT_TYPE_DP0 +# define DP_DS_PORT_TYPE_VGA 1 +# define DP_DS_PORT_TYPE_DVI 2 +# define DP_DS_PORT_TYPE_HDMI 3 +# define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DS_PORT_HPD(1 << 3) +/* offset 1 for VGA is maximum megapixels per second / 8 */ +/* offset 2 */ +# define DP_DS_VGA_MAX_BPC_MASK(3 << 0) +# define DP_DS_VGA_8BPC0 +# define DP_DS_VGA_10BPC 1 +# define DP_DS_VGA_12BPC 2 +# define DP_DS_VGA_16BPC 3 + /* link configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_BW_1_62 0x06 @@ -148,24 +187,37 @@ #define DP_DOWNSPREAD_CTRL 0x107 # define DP_SPREAD_AMP_0_5 (1 << 4) +# define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 # define DP_SET_ANSI_8B10B (1 << 0) +#define DP_I2C_SPEED_CONTROL_STATUS0x109 +/* bitmask as for DP_I2C_SPEED_CAP */ + +#define DP_EDP_CONFIGURATION_SET0x10a + +#define DP_MSTM_CTRL 0x111 +# define DP_MST_EN (1 << 0) +# define DP_UP_REQ_EN (1 << 1) +# define DP_UPSTREAM_IS_SRC(1 << 2) + #define DP_PSR_EN_CFG 0x170 # define DP_PSR_ENABLE (1 << 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +#define DP_SINK_COUNT 0x200 +# define DP_SINK_COUNT_MASK(31 << 0) +# define DP_SINK_CP_READY (1 << 6) + #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201 # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 << 0) # define DP_AUTOMATED_TEST_REQUEST (1 << 1) # define DP_CP_IRQ (1 << 2) # define DP_SINK_SPECIFIC_IRQ (1 << 6) -#define DP_EDP_CONFIGURATION_SET0x10a - #define DP_LANE0_1_STATUS 0x202 #define DP_LANE2_3_STATUS 0x203 # define DP_LANE_CR_DONE (1 << 0) -- 1.7.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Export drm_probe_ddc()
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -376,13 +376,14 @@ out:
* \param adapter : i2c device adaptor
* \return 1 on success
*/
-static bool
+bool
drm_probe_ddc(struct i2c_adapter *adapter)
{
unsigned char out;
return (drm_do_probe_ddc_edid(adapter, &out, 0, 1) == 0);
}
+EXPORT_SYMBOL(drm_probe_ddc);
/**
* drm_get_edid - get EDID data, if available
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..f5d434b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -862,6 +862,7 @@ extern char *drm_get_tv_subconnector_name(int val);
extern char *drm_get_tv_select_name(int val);
extern void drm_fb_release(struct drm_file *file_priv);
extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct
drm_mode_group *group);
+extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #6 from Alex Deucher 2012-09-18 14:41:46 --- This bug sounds kind of like the bugs that 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 fixes. Can you see if this is fixed in my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip I have a more complete set of patches to properly disable MC clients when changing the MC. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #42 from Steve Smith 2012-09-18 07:02:43 UTC --- Created attachment 67314 --> https://bugs.freedesktop.org/attachment.cgi?id=67314 EFI stub boot, 3.6-rc6 This doesn't work for me either, using EFI stub booting direct from Refind. dmesg attached. Some additional details: * MacBook Pro 8,3 * Arch Linux * Kernel 3.6rc6 * Kernel command-line: vmlinuz-linux-mainline-3.x.efi root=/dev/disk/by-label/Root ro add_efi_memmap radeon.modeset=1 i915.modeset=1 i915.lvds_channel_mode=2 initrd=\EFI\arch\initramfs-linux-mainline-3.x.img Relevent log lines: [5.146024] vga_switcheroo: enabled [5.146064] radeon :01:00.0: Invalid ROM contents [5.146127] radeon :01:00.0: Invalid ROM contents [5.146156] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [5.146190] radeon :01:00.0: Fatal error during GPU init [5.146221] [drm] radeon: finishing device. [5.146222] [TTM] Memory type 2 has not been initialized [5.147271] vga_switcheroo: disabled [5.147416] radeon: probe of :01:00.0 failed with error -22 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[pull] radeon drm-fixes-3.6
From: Alex Deucher The pll fix ended up causing some regressions. Drop it for 3.6. I've fixed it properly in 3.7, but the fix is too invasive for 3.6. The following changes since commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc: drm/nouveau: fix booting with plymouth + dumb support (2012-09-14 15:45:01 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 Alex Deucher (1): Revert "drm/radeon: rework pll selection (v3)" drivers/gpu/drm/radeon/atombios_crtc.c | 163 +++- 1 files changed, 34 insertions(+), 129 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #41 from Austin Lund 2012-09-18 05:55:27 UTC --- (In reply to comment #40) > (In reply to comment #39) > > From what I've been told, you need to boot using the EFI stub method and > > not a > > boot-loader. Also, you may need to pass some kernel options (eg initrd) so > > the > > easiest way to do this is from within an EFI shell. > Do you have any more details on that? I'd like to try it! Make sure you have CONFIG_EFI and CONFIG_EFI_STUB set for your kernel. Put the kernel image in a filesystem that can be read by the EFI firmware or has a driver for it. Boot into the EFI shell. I do this via rEFIt. cd to the location of the kernel then execute it by typing it's name. Kernel parameters can be listed after the kernel name. > > How are you booting the kernel? > linux /boot/vmlinuz root=/dev/sda3 > I have never needed an initrd, all required modules are built in... OK. So you haven't actually said, but you must be booting via Grub either in EFI mode or BIOS compatiability mode. Neither of those will work in extracting the AtomBIOS from the configurations. It needs to be done before calling ExitBootServices() in EFI mode and Grub isn't set up to do anything this tricky. Hence you have to use the inbuilt kernel loader in the EFI stub code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55047] New: [855gm] Boots noisely with the lid close (but works!)
https://bugs.freedesktop.org/show_bug.cgi?id=55047 Bug #: 55047 Summary: [855gm] Boots noisely with the lid close (but works!) Classification: Unclassified Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ch...@chris-wilson.co.uk Created attachment 67320 --> https://bugs.freedesktop.org/attachment.cgi?id=67320 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL v2] SH Mobile DRM driver for v3.7
Hi Dave, Here's the second pull request for the SH Mobile DRM driver. Compared to v1, the include/drm/shmob_drm.h private header has been moved to include/linux/platform_data/. The following changes since commit 0b2443ed4e07d7973e4554a2cc166bc35447b59e: drm/edid: limit printk when facing bad edid (2012-09-17 11:16:40 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Lars-Peter Clausen (1): DRM: Add DRM KMS/FB CMA helper Laurent Pinchart (2): drm: Add NV24 and NV42 pixel formats drm: Renesas SH Mobile DRM driver Sascha Hauer (1): DRM: Add DRM GEM CMA helper drivers/gpu/drm/Kconfig| 17 + drivers/gpu/drm/Makefile |3 + drivers/gpu/drm/drm_crtc.c |6 + drivers/gpu/drm/drm_fb_cma_helper.c| 406 + drivers/gpu/drm/drm_gem_cma_helper.c | 251 drivers/gpu/drm/shmobile/Kconfig | 10 + drivers/gpu/drm/shmobile/Makefile |7 + drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++ drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 763 +++ drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++ drivers/gpu/drm/shmobile/shmob_drm_drv.c | 361 +++ drivers/gpu/drm/shmobile/shmob_drm_drv.h | 47 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 + drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 268 + drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 + drivers/gpu/drm/shmobile/shmob_drm_regs.h | 311 ++ include/drm/drm_fb_cma_helper.h| 27 + include/drm/drm_fourcc.h |2 + include/drm/drm_gem_cma_helper.h | 44 ++ include/linux/platform_data/shmob_drm.h| 99 +++ 22 files changed, 3011 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c create mode 100644 drivers/gpu/drm/shmobile/Kconfig create mode 100644 drivers/gpu/drm/shmobile/Makefile create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h create mode 100644 include/drm/drm_fb_cma_helper.h create mode 100644 include/drm/drm_gem_cma_helper.h create mode 100644 include/linux/platform_data/shmob_drm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[XDC 2012] Conference Update #6
Hi folks, the XDC2012 conference program (modulo updates) is now available at http://www.x.org/wiki/Events/XDC2012/Program The program will also be available in printed form on site. Please be aware that we currently have major issues with MoinMoin wiki, probably due to the massive spamming attacks Alan is trying hard to repel. If you get Guru Meditations while accessing the Wiki, chances are the watchdog has already triggered, and the Wiki should be back in approximately 15 minutes then. Have fun Matthias -- | ,_, Matthias Hopf | ( ) |__| |\/| Professor for Applied Computer Sciencematth...@hopf.in | ,) (, | | | | Georg-Simon-Ohm-University, Nurembergwww.hopf.in ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] [RESEND] console: implement lockdep support for console_lock
On Tue, 18 Sep 2012, Daniel Vetter wrote:
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map console_lock_dep_map = {
> + .name = "console_lock"
> +};
> +#endif
static?
BR,
Jani.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #42 from Steve Smith 2012-09-18 07:02:43 UTC --- Created attachment 67314 --> https://bugs.freedesktop.org/attachment.cgi?id=67314 EFI stub boot, 3.6-rc6 This doesn't work for me either, using EFI stub booting direct from Refind. dmesg attached. Some additional details: * MacBook Pro 8,3 * Arch Linux * Kernel 3.6rc6 * Kernel command-line: vmlinuz-linux-mainline-3.x.efi root=/dev/disk/by-label/Root ro add_efi_memmap radeon.modeset=1 i915.modeset=1 i915.lvds_channel_mode=2 initrd=\EFI\arch\initramfs-linux-mainline-3.x.img Relevent log lines: [5.146024] vga_switcheroo: enabled [5.146064] radeon :01:00.0: Invalid ROM contents [5.146127] radeon :01:00.0: Invalid ROM contents [5.146156] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [5.146190] radeon :01:00.0: Fatal error during GPU init [5.146221] [drm] radeon: finishing device. [5.146222] [TTM] Memory type 2 has not been initialized [5.147271] vga_switcheroo: disabled [5.147416] radeon: probe of :01:00.0 failed with error -22 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] of: Add videomode helper
On Mon, Sep 17, 2012 at 06:35:43PM +, Tabi Timur-B04825 wrote:
> On Fri, Sep 14, 2012 at 11:24 AM, Steffen Trumtrar
> wrote:
>
> > +/* FIXME */
> > +static u32 of_video_get_value(struct mode_property *prop)
> > +{
> > + return (prop->min >= prop->typ) ? prop->min : prop->typ;
> > +}
> > +
> > +/* read property into new mode_property */
> > +static int of_video_parse_property(struct device_node *np, char *name,
> > + struct mode_property *result)
> > +{
> > + struct property *prop;
> > + int length;
> > + int cells;
> > + int ret;
> > +
> > + prop = of_find_property(np, name, &length);
> > + if (!prop)
> > + return -EINVAL;
> > +
> > + cells = length / sizeof(u32);
> > +
> > + memset(result, 0, sizeof(*result));
> > +
> > + ret = of_property_read_u32_array(np, name, &result->min, cells);
> > + of_video_get_value(result);
>
> What's the point of calling of_video_get_value() here? It doesn't do
> anything.
>
You're right. That definitely does not belong there.
> > + return ret;
> > +}
> > +
> > +int videomode_to_display_mode(struct display *disp, struct
> > drm_display_mode *dmode, int index)
> > +{
> > + struct videomode *vm;
> > +
> > +memset(dmode, 0, sizeof(*dmode));
>
> Indentation problem.
>
Okay.
> > +int of_get_video_mode(struct device_node *np, struct display *disp)
> > +{
> > + struct device_node *display_np;
> > + struct device_node *mode_np;
> > + struct device_node *modes_np;
> > + char *default_mode;
> > +
> > + int ret = 0;
> > +
> > + memset(disp, 0, sizeof(*disp));
> > + disp->modes = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
> > + if (!np)
> > + return -EINVAL;
> > +
> > + display_np = of_parse_phandle(np, "display", 0);
> > +
> > + if (!display_np)
> > + return -EINVAL;
> > +
> > + of_property_read_u32(display_np, "width-mm", &disp->width_mm);
> > + of_property_read_u32(display_np, "height-mm", &disp->height_mm);
> > +
> > + mode_np = of_parse_phandle(np, "default-mode", 0);
> > +
> > + if (!mode_np)
> > + mode_np = of_find_node_by_name(np, "mode");
> > +
> > + if (!mode_np)
> > + return -EINVAL;
> > +
> > + default_mode = (char *)mode_np->full_name;
> > +
> > + modes_np = of_find_node_by_name(np, "modes");
> > + for_each_child_of_node(modes_np, mode_np) {
> > + struct videomode *vm;
>
> Blank line after variable declarations, please.
>
> > + vm = kmalloc(sizeof(struct videomode), GFP_KERNEL);
> > + disp->modes[disp->num_modes] = kmalloc(sizeof(struct
> > videomode*), GFP_KERNEL);
>
> Are you sure this is right?
>
I implemented disp->modes as "struct videomode** modes". So I guess the first
kmalloc is wrong. Right?!
> > + ret |= of_video_parse_property(mode_np, "hback-porch",
> > &vm->hback_porch);
> > + ret |= of_video_parse_property(mode_np, "hfront-porch",
> > &vm->hfront_porch);
> > + ret |= of_video_parse_property(mode_np, "hactive",
> > &vm->hactive);
> > + ret |= of_video_parse_property(mode_np, "hsync-len",
> > &vm->hsync_len);
> > + ret |= of_video_parse_property(mode_np, "vback-porch",
> > &vm->vback_porch);
> > + ret |= of_video_parse_property(mode_np, "vfront-porch",
> > &vm->vfront_porch);
> > + ret |= of_video_parse_property(mode_np, "vactive",
> > &vm->vactive);
> > + ret |= of_video_parse_property(mode_np, "vsync-len",
> > &vm->vsync_len);
> > + ret |= of_video_parse_property(mode_np, "clock",
> > &vm->clock);
> > +
> > + if (ret)
> > + return -EINVAL;
> > +
> > + vm->hah = of_property_read_bool(mode_np,
> > "hsync-active-high");
> > + vm->vah = of_property_read_bool(mode_np,
> > "vsync-active-high");
> > + vm->interlaced = of_property_read_bool(mode_np,
> > "interlaced");
> > + vm->doublescan = of_property_read_bool(mode_np,
> > "doublescan");
> > +
> > + if (strcmp(default_mode,mode_np->full_name) == 0) {
> > + printk("%s: default_node = %d\n", __func__,
> > disp->num_modes);
>
> Please use a KERN_ macro here, or a pr_xxx function. Even better
> would be to use a dev_xxx function.
>
> In general, I'd like to see more error reporting of bad device tree
> properties, to help debugging.
>
Okay. Actually, the printk also was not supposed to be in the final patch.
I can fix that and add some dev_xxx.
> > + disp->default_mode = disp->num_modes;
> > + }
> > +
> > + disp->modes[disp->num_modes] = vm;
>
> Isn't this a memory leak?
>
I think I get you. I will fix that.
> > + disp->num_modes
Re: [PATCH v3] of: Add videomode helper
On Fri, Sep 14, 2012 at 11:24 AM, Steffen Trumtrar
wrote:
> +/* FIXME */
> +static u32 of_video_get_value(struct mode_property *prop)
> +{
> + return (prop->min >= prop->typ) ? prop->min : prop->typ;
> +}
> +
> +/* read property into new mode_property */
> +static int of_video_parse_property(struct device_node *np, char *name,
> + struct mode_property *result)
> +{
> + struct property *prop;
> + int length;
> + int cells;
> + int ret;
> +
> + prop = of_find_property(np, name, &length);
> + if (!prop)
> + return -EINVAL;
> +
> + cells = length / sizeof(u32);
> +
> + memset(result, 0, sizeof(*result));
> +
> + ret = of_property_read_u32_array(np, name, &result->min, cells);
> + of_video_get_value(result);
What's the point of calling of_video_get_value() here? It doesn't do anything.
> + return ret;
> +}
> +
> +int videomode_to_display_mode(struct display *disp, struct drm_display_mode
> *dmode, int index)
> +{
> + struct videomode *vm;
> +
> +memset(dmode, 0, sizeof(*dmode));
Indentation problem.
> +int of_get_video_mode(struct device_node *np, struct display *disp)
> +{
> + struct device_node *display_np;
> + struct device_node *mode_np;
> + struct device_node *modes_np;
> + char *default_mode;
> +
> + int ret = 0;
> +
> + memset(disp, 0, sizeof(*disp));
> + disp->modes = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
> + if (!np)
> + return -EINVAL;
> +
> + display_np = of_parse_phandle(np, "display", 0);
> +
> + if (!display_np)
> + return -EINVAL;
> +
> + of_property_read_u32(display_np, "width-mm", &disp->width_mm);
> + of_property_read_u32(display_np, "height-mm", &disp->height_mm);
> +
> + mode_np = of_parse_phandle(np, "default-mode", 0);
> +
> + if (!mode_np)
> + mode_np = of_find_node_by_name(np, "mode");
> +
> + if (!mode_np)
> + return -EINVAL;
> +
> + default_mode = (char *)mode_np->full_name;
> +
> + modes_np = of_find_node_by_name(np, "modes");
> + for_each_child_of_node(modes_np, mode_np) {
> + struct videomode *vm;
Blank line after variable declarations, please.
> + vm = kmalloc(sizeof(struct videomode), GFP_KERNEL);
> + disp->modes[disp->num_modes] = kmalloc(sizeof(struct
> videomode*), GFP_KERNEL);
Are you sure this is right?
> + ret |= of_video_parse_property(mode_np, "hback-porch",
> &vm->hback_porch);
> + ret |= of_video_parse_property(mode_np, "hfront-porch",
> &vm->hfront_porch);
> + ret |= of_video_parse_property(mode_np, "hactive",
> &vm->hactive);
> + ret |= of_video_parse_property(mode_np, "hsync-len",
> &vm->hsync_len);
> + ret |= of_video_parse_property(mode_np, "vback-porch",
> &vm->vback_porch);
> + ret |= of_video_parse_property(mode_np, "vfront-porch",
> &vm->vfront_porch);
> + ret |= of_video_parse_property(mode_np, "vactive",
> &vm->vactive);
> + ret |= of_video_parse_property(mode_np, "vsync-len",
> &vm->vsync_len);
> + ret |= of_video_parse_property(mode_np, "clock", &vm->clock);
> +
> + if (ret)
> + return -EINVAL;
> +
> + vm->hah = of_property_read_bool(mode_np, "hsync-active-high");
> + vm->vah = of_property_read_bool(mode_np, "vsync-active-high");
> + vm->interlaced = of_property_read_bool(mode_np, "interlaced");
> + vm->doublescan = of_property_read_bool(mode_np, "doublescan");
> +
> + if (strcmp(default_mode,mode_np->full_name) == 0) {
> + printk("%s: default_node = %d\n", __func__,
> disp->num_modes);
Please use a KERN_ macro here, or a pr_xxx function. Even better
would be to use a dev_xxx function.
In general, I'd like to see more error reporting of bad device tree
properties, to help debugging.
> + disp->default_mode = disp->num_modes;
> + }
> +
> + disp->modes[disp->num_modes] = vm;
Isn't this a memory leak?
> + disp->num_modes++;
> + }
> + of_node_put(display_np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_get_video_mode);
--
Timur Tabi
Linux kernel developer at Freescale
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
Hi, On Monday, September 17, 2012 04:24:08 PM Deucher, Alexander wrote: > > On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote: > > > > While debugging another issue I upgraded from v3.6-rc4 to latest git > > > > (which exactly is v3.6-rc6). After X started up one of my three > > > > monitors blacked out. A look into the kernel log revealed: > > > > [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL > > > > > > What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are > > > only 2 PLLs for non-DP monitors, so if you are trying to use more than > > > 2 non-DP monitors, it's not supported right now and if it worked > > > before, it was random luck. If you want to use 3+ monitors, only 2 > > > can be non-DP, the rest need to be DP. If you use a DP to DVI/HDMI > > > adapter, it must be active (looks like DP to the GPU), passive > > > adapters just pass through native DVI/HDMI. That said, I've got a set > > > of patches for 3.7 to allow PLL sharing properly for non-DP displays, > > > but it's too invasive for -fixes. > > > > 2DVI, 1DP via an supposedly active converter. I can try a native DP > > cable, its just too short, so I will have to move the monitor to the > > ground ;) > > > > Can I check its really an active connector? > > Try the attached debugging patch. It will tell us what PPLLs are getting > allocated and what type of sink we detect on the DP port (DP or non-DP) [1.844382] [drm] Initialized drm 1.1.0 20060810 [1.867560] [drm] radeon defaulting to kernel modesetting. [1.890474] [drm] radeon kernel modesetting enabled. [1.913006] fb: conflicting fb hw usage radeondrmfb vs VGA16 VGA - removing generic driver [1.981793] [drm] initializing kernel modesetting (BARTS 0x1002:0x6738 0x174B:0x174B). [1.982323] [drm] register mmio base: 0xFBEC [1.982522] [drm] register mmio size: 131072 [1.983880] [drm] Detected VRAM RAM=1024M, BAR=256M [1.984072] [drm] RAM width 256bits DDR [1.985141] [drm] radeon: 1024M of VRAM memory ready [1.985345] [drm] radeon: 512M of GTT memory ready. [1.985575] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.985779] [drm] Driver supports precise vblank timestamp query. [1.986252] [drm] radeon: irq initialized. [1.986454] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.987226] [drm] probing gen 2 caps for device 8086:340a = 2/0 [1.987426] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [1.987930] [drm] Loading BARTS Microcode [1.990807] [drm] PCIE GART of 512M enabled (table at 0x0004). [2.008503] [drm] ring test on 0 succeeded in 3 usecs [2.009029] [drm] ib test on ring 0 succeeded in 0 usecs [2.009728] [drm] Radeon Display Connectors [2.009914] [drm] Connector 0: [2.010103] [drm] DP-1 [2.010283] [drm] HPD4 [2.010464] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [2.010734] [drm] Encoders: [2.010921] [drm] DFP1: INTERNAL_UNIPHY2 [2.02] [drm] Connector 1: [2.011295] [drm] HDMI-A-1 [2.011478] [drm] HPD3 [2.011662] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [2.011932] [drm] Encoders: [2.012119] [drm] DFP2: INTERNAL_UNIPHY2 [2.012324] [drm] Connector 2: [2.012512] [drm] DVI-D-1 [2.012695] [drm] HPD1 [2.012881] [drm] DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 0x648c [2.013152] [drm] Encoders: [2.013340] [drm] DFP3: INTERNAL_UNIPHY1 [2.013528] [drm] Connector 3: [2.013712] [drm] DVI-I-1 [2.013898] [drm] HPD6 [2.014082] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c [2.014352] [drm] Encoders: [2.014538] [drm] DFP4: INTERNAL_UNIPHY [2.014724] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [2.015014] [drm] Internal thermal controller with fan control [2.016370] [drm] radeon: power management initialized [2.022137] [drm] DP sink type 0x13 [2.133666] [drm] fb mappable at 0xD0142000 [2.133793] [drm] vram apper at 0xD000 [2.133919] [drm] size 16384000 [2.134044] [drm] fb depth is 24 [2.134170] [drm]pitch is 10240 [2.134358] fbcon: radeondrmfb (fb0) is primary device [2.134901] [drm] crtc 0 using pll 0x2 [2.362257] [drm] crtc 1 using pll 0x1 [2.386709] [drm] crtc 2 using pll 0x0 [2.472275] fb0: radeondrmfb frame buffer device [2.472300] drm: registered panic notifier [2.472325] [drm] Initialized radeon 2.22.0 20080528 for :08:00.0 on minor 0 [ 60.056358] [drm] DP sink type 0x13 [ 60.205905] [drm] DP sink type 0x13 [ 60.679305] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL [ 60.679310] [drm] crtc 0 using pll 0xff [ 60.789183] [drm] crtc 1 using pll 0x2 [ 60.819594] [drm] crtc 2 using pll 0x1 [ 61.926401] [drm] DP sink type 0x13 [ 73.022055] [drm] DP sink type 0x13 [ 73.567827
Re: [PATCH] i915: Quirk out disconnected backlight
On Mon, Sep 17, 2012 at 9:03 AM, Jani Nikula wrote: > Hi Grant, please try v3.6-rc6 that does exactly that with: > > commit 28dcc2d60cb570d9f549c329b2f51400553412a1 > Author: Jani Nikula > Date: Mon Sep 3 16:25:12 2012 +0300 > > drm/i915: do not expose a dysfunctional backlight interface to userspace > > Does that fix it for you? Yes, thanks. g. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote: > > -Original Message- > > From: Andres Freund [mailto:and...@anarazel.de] > > Sent: Monday, September 17, 2012 7:29 AM > > To: LKML; Deucher, Alexander; David Airlie; > > dri-devel@lists.freedesktop.org Subject: radeon: Regression between > > v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL > > > > Hi, > > > > While debugging another issue I upgraded from v3.6-rc4 to latest git > > (which exactly is v3.6-rc6). After X started up one of my three monitors > > blacked out. A look into the kernel log revealed: > > [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL > > What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are > only 2 PLLs for non-DP monitors, so if you are trying to use more than 2 > non-DP monitors, it's not supported right now and if it worked before, it > was random luck. If you want to use 3+ monitors, only 2 can be non-DP, > the rest need to be DP. If you use a DP to DVI/HDMI adapter, it must be > active (looks like DP to the GPU), passive adapters just pass through > native DVI/HDMI. That said, I've got a set of patches for 3.7 to allow > PLL sharing properly for non-DP displays, but it's too invasive for > -fixes. 2DVI, 1DP via an supposedly active converter. I can try a native DP cable, its just too short, so I will have to move the monitor to the ground ;) Can I check its really an active connector? The patchset you referenced is in alexdeucher/drm-next-3.7-wip if I saw that correctly? Will test it with a passive connector I have lying arround. The only somewhat relevant thing in the log seems to be [2.011401] [drm] ring test on 0 succeeded in 3 usecs [2.011897] [drm] ib test on ring 0 succeeded in 0 usecs [2.012596] [drm] Radeon Display Connectors [2.012784] [drm] Connector 0: [2.012972] [drm] DP-1 [2.013157] [drm] HPD4 [2.013340] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [2.013608] [drm] Encoders: [2.013787] [drm] DFP1: INTERNAL_UNIPHY2 [2.013978] [drm] Connector 1: [2.014163] [drm] HDMI-A-1 [2.014346] [drm] HPD3 [2.014548] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [2.014816] [drm] Encoders: [2.015005] [drm] DFP2: INTERNAL_UNIPHY2 [2.015194] [drm] Connector 2: [2.015376] [drm] DVI-D-1 [2.015561] [drm] HPD1 [2.015745] [drm] DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 0x648c [2.016015] [drm] Encoders: [2.016203] [drm] DFP3: INTERNAL_UNIPHY1 [2.016389] [drm] Connector 3: [2.016574] [drm] DVI-I-1 [2.016759] [drm] HPD6 [2.016942] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c [2.017214] [drm] Encoders: [2.017401] [drm] DFP4: INTERNAL_UNIPHY xrand doesn't seem to have anything relevant: $ xrandr --verbose|grep -E 'Screen|connected|CRTC' Screen 0: minimum 320 x 200, current 4960 x 1920, maximum 16384 x 16384 DVI-1 connected 2560x1600+1200+0 (0x59) normal (normal left inverted right x axis y axis) 641mm x 401mm CRTC: 0 CRTCs: 1 2 0 3 4 5 DisplayPort-0 connected 1200x1920+0+0 (0x60) left (normal left inverted right x axis y axis) 518mm x 324mm CRTC: 1 CRTCs: 1 2 0 3 4 5 HDMI-0 disconnected (normal left inverted right x axis y axis) CRTCs: 1 2 0 3 4 5 DVI-0 connected 1200x1920+3760+0 (0x60) left (normal left inverted right x axis y axis) 518mm x 324mm CRTC: 2 CRTCs: 1 2 0 3 4 5 Greetings, Andres ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] Add 2-level GPUVM pagetables support to radeon v3
PDE/PTE update code uses CP ring for memory writes.
All page table entries are preallocated for now in alloc_pt().
It is made as whole because it's hard to divide it to several patches
that compile and doesn't break anything being applied separately.
Tested on cayman card.
v3 changes:
* rebased on top of "refactor set_page chipset interface v3"
* switched offsets calc macros to inline funcs where possible
* remove pd_addr from radeon_vm
* switched RADEON_BLOCK_SIZE define to 9 (and PTE_COUNT to 1 << BLOCK_SIZE)
Signed-off-by: Dmitry Cherkasov
---
drivers/gpu/drm/radeon/ni.c |5 +-
drivers/gpu/drm/radeon/radeon.h | 12 ++-
drivers/gpu/drm/radeon/radeon_gart.c | 148 +++---
drivers/gpu/drm/radeon/si.c |4 +-
4 files changed, 153 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index cea8aea..9f442df 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -782,7 +782,7 @@ static int cayman_pcie_gart_enable(struct radeon_device
*rdev)
(u32)(rdev->dummy_page.addr >> 12));
WREG32(VM_CONTEXT1_CNTL2, 0);
WREG32(VM_CONTEXT1_CNTL, 0);
- WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(0) |
+ WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
RANGE_PROTECTION_FAULT_ENABLE_DEFAULT);
cayman_pcie_gart_tlb_flush(rdev);
@@ -1523,6 +1523,7 @@ uint32_t cayman_vm_page_flags(struct radeon_device *rdev,
uint32_t flags)
* @pe: addr of the page entry
* @addr: dst addr to write into pe
* @count: number of page entries to update
+ * @incr: increase next addr by incr bytes
* @flags: access flags
*
* Update the page tables using the CP (cayman-si).
@@ -1579,7 +1580,7 @@ void cayman_vm_flush(struct radeon_device *rdev, struct
radeon_ib *ib)
radeon_ring_write(ring, vm->last_pfn);
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR +
(vm->id << 2), 0));
- radeon_ring_write(ring, vm->pt_gpu_addr >> 12);
+ radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
/* flush hdp cache */
radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 0eaa434..53cd03e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -655,8 +655,7 @@ struct radeon_vm {
struct list_headva;
unsignedid;
unsignedlast_pfn;
- u64 pt_gpu_addr;
- u64 *pt;
+ u64 pd_gpu_addr;
struct radeon_sa_bo *sa_bo;
struct mutexmutex;
/* last fence for cs using this vm */
@@ -665,6 +664,15 @@ struct radeon_vm {
struct radeon_fence *last_flush;
};
+/* GPUVM defines */
+
+/* We consider the case where PAGE_TABLE_BLOCK_SIZE is 0 */
+/* So PDE is 19 bits long, PTE is 9 and OFFSET is 12 */
+#define RADEON_VM_BLOCK_SIZE 9
+
+/* number of PTEs in Page Table */
+#define RADEON_PTE_COUNT (1 << RADEON_VM_BLOCK_SIZE)
+
struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index bb9fc59..ebca931 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -50,6 +50,64 @@
* This file handles the common internal GART management.
*/
+/* GPUVM defines */
+
+/* current distance in bytes between two adjacent page tables */
+#define RADEON_PT_DISTANCE \
+ (RADEON_PTE_COUNT * RADEON_PTE_SIZE)
+
+#define RADEON_PTE_SIZE 8
+#define RADEON_PDE_SIZE 8
+
+/* Get last PDE number containing nth PTE */
+static __inline__ uint32_t radeon_get_pde_for_pfn(uint32_t n)
+{
+ return n / RADEON_PTE_COUNT;
+}
+
+/* Get PTE number to containing nth pfn */
+static __inline__ uint32_t radeon_get_pte_for_pfn(uint32_t n)
+{
+ return n % RADEON_PTE_COUNT;
+}
+
+
+/* Number of PDE tables to cover n PTEs */
+static __inline__ uint32_t radeon_pde_count_for_n_pages(uint32_t n)
+{
+ return (n + RADEON_PTE_COUNT - 1) / RADEON_PTE_COUNT;
+}
+
+
+/* Number of PDE tables to cover max_pfn (maximum number of PTEs) */
+static __inline__ uint32_t radeon_total_pde_count(struct radeon_device *rdev)
+{
+ return radeon_pde_count_for_n_pages(rdev->vm_manager.max_pfn);
+}
+
+/* offset for npde-th PDE starting from beginning of PDE table */
+static __inline__ uint64_t radeon_pde_offset(struct radeon_device *rdev,
uint32_t npde)
+{
+ return npde * RADEON_PDE_SIZE;
+}
+
+/* offset for page tables start */
+static __inline__ uint64_t radeon_pt_offset(struct radeon_device *rdev)
+{
+ return RADEON_GPU_PAGE_AL
[PATCH 1/2] drm/radeon: refactor set_page chipset interface v3
From: Christian König
Cleanup the interface in preparation for hierarchical page tables.
v3: * add incr parameter to set_page for simple scattered PTs uptates
* added PDE-specific flags to r600_flags and radeon_drm.h
* removed superflous value masking with 0x
* removed superflous bo_va->valid checking
* changed R600_PTE_VALID to R600_ENTRY_VALID to handle PDE too
Signed-off-by: Christian König
Signed-off-by: Dmitry Cherkassov
---
i've decided to unite R600_PDE_VALID and R600_PTE_VALID in R600_ENTRY_VALID.
not sure if that's the right name. any suggestions?
drivers/gpu/drm/radeon/ni.c | 46 +
drivers/gpu/drm/radeon/radeon.h | 13
drivers/gpu/drm/radeon/radeon_asic.h |6 ++--
drivers/gpu/drm/radeon/radeon_gart.c | 54 +-
4 files changed, 56 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index b238216..cea8aea 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1497,7 +1497,7 @@ void cayman_vm_fini(struct radeon_device *rdev)
{
}
-#define R600_PTE_VALID (1 << 0)
+#define R600_ENTRY_VALID (1 << 0)
#define R600_PTE_SYSTEM(1 << 1)
#define R600_PTE_SNOOPED (1 << 2)
#define R600_PTE_READABLE (1 << 5)
@@ -1506,8 +1506,7 @@ void cayman_vm_fini(struct radeon_device *rdev)
uint32_t cayman_vm_page_flags(struct radeon_device *rdev, uint32_t flags)
{
uint32_t r600_flags = 0;
-
- r600_flags |= (flags & RADEON_VM_PAGE_VALID) ? R600_PTE_VALID : 0;
+ r600_flags |= (flags & RADEON_VM_PAGE_VALID) ? R600_ENTRY_VALID : 0;
r600_flags |= (flags & RADEON_VM_PAGE_READABLE) ? R600_PTE_READABLE : 0;
r600_flags |= (flags & RADEON_VM_PAGE_WRITEABLE) ? R600_PTE_WRITEABLE :
0;
if (flags & RADEON_VM_PAGE_SYSTEM) {
@@ -1521,30 +1520,39 @@ uint32_t cayman_vm_page_flags(struct radeon_device
*rdev, uint32_t flags)
* cayman_vm_set_page - update the page tables using the CP
*
* @rdev: radeon_device pointer
+ * @pe: addr of the page entry
+ * @addr: dst addr to write into pe
+ * @count: number of page entries to update
+ * @flags: access flags
*
* Update the page tables using the CP (cayman-si).
*/
-void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
- unsigned pfn, struct ttm_mem_reg *mem,
- unsigned npages, uint32_t flags)
+void cayman_vm_set_page(struct radeon_device *rdev, uint64_t pe,
+ uint64_t addr, unsigned count,
+ uint32_t incr, uint32_t flags)
{
struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
- uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
+ uint32_t r600_flags = cayman_vm_page_flags(rdev, flags);
int i;
- addr = flags = cayman_vm_page_flags(rdev, flags);
-
- radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
- radeon_ring_write(ring, pt & 0x);
- radeon_ring_write(ring, (pt >> 32) & 0xff);
- for (i = 0; i < npages; ++i) {
- if (mem) {
- addr = radeon_vm_get_addr(rdev, mem, i);
- addr = addr & 0xF000ULL;
- addr |= flags;
+ radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + count * 2));
+ radeon_ring_write(ring, pe & 0x);
+ radeon_ring_write(ring, (pe >> 32) & 0xff);
+ for (i = 0; i < count; ++i) {
+ uint64_t value = 0;
+ if (flags & RADEON_VM_PAGE_SYSTEM) {
+ value = radeon_vm_map_gart(rdev, addr);
+ value &= 0xF000ULL;
+ addr += RADEON_GPU_PAGE_SIZE;
+
+ } else if (flags & RADEON_VM_PAGE_VALID) {
+ value = addr;
+ addr += incr;
}
- radeon_ring_write(ring, addr & 0x);
- radeon_ring_write(ring, (addr >> 32) & 0x);
+
+ value |= r600_flags;
+ radeon_ring_write(ring, value);
+ radeon_ring_write(ring, (value >> 32));
}
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 4d67f0f..0eaa434 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1141,9 +1141,10 @@ struct radeon_asic {
void (*fini)(struct radeon_device *rdev);
u32 pt_ring_index;
- void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
-unsigned pfn, struct ttm_mem_reg *mem,
-unsigned npages, uint32_t flags);
+ void (*set_page)
+ (struct radeon_device *rdev, uint64_t pe,
+uint64_t addr, unsigned count,
+uint32_t incr, uint32_t flags);
radeon error on resume: "cp failed to get scratch reg" - anyone interested?
Hi, I've noticed that on resume from suspend, dmesg reports: [21895.997536] [drm] radeon: 1 quad pipes, 2 z pipes initialized. [21896.012072] [drm] PCIE GART of 512M enabled (table at 0x0004). [21896.012082] radeon :01:00.0: WB enabled [21896.012085] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x1000 and cpu addr 0xffccb000 [21896.012138] [drm] radeon: ring at 0x10001000 [21896.012157] [drm:r100_ring_test] *ERROR* radeon: cp failed to get scratch reg (-22). [21896.012158] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [21896.012160] radeon :01:00.0: failed initializing CP (-22). Graphics still seems to work fine though. Is this info of interest to anyone? I'm happy to do additional testing if that is useful. System: Radeon Mobility X1600 RV530 (about 5 year old laptop), kernel 3.6.0-rc5+ 32-bit Cheers, Simon ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
Hi, While debugging another issue I upgraded from v3.6-rc4 to latest git (which exactly is v3.6-rc6). After X started up one of my three monitors blacked out. A look into the kernel log revealed: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL During that first start I tried to correct that using xrand, which failed. After restarting X (gdm) once more the monitor was still blank, the error was still logged, but could be enabled by using xrandr. A bit strange. A quick look into git revealed: $ git log --pretty=short v3.6-rc4.. drivers/gpu/drm/radeon/ commit f492c171a38d77fc13a8998a0721f2da50835224 Author: Christian König drm/radeon: make 64bit fences more robust v3 commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 Author: Alex Deucher drm/radeon: rework pll selection (v3) The latter seems to be a probably cause. Anything I can do to diagnose the issue? $ xrandr|grep -E 'connected|Screen' Screen 0: minimum 320 x 200, current 4960 x 1920, maximum 16384 x 16384 DVI-1 connected 2560x1600+1200+0 (normal left inverted right x axis y axis) 641mm x 401mm DisplayPort-0 connected 1200x1920+0+0 left (normal left inverted right x axis y axis) 518mm x 324mm HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1200x1920+3760+0 left (normal left inverted right x axis y axis) 518mm x 324mm # lspci -v -s 08:00.0 08:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts XT [Radeon HD 6800 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device 174b Flags: bus master, fast devsel, latency 0, IRQ 76 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fbec (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fbea [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Greetings, Andres ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm-intel-next
On Thu, Sep 13, 2012 at 04:18:41PM +0200, Daniel Vetter wrote: > Hi Dave, > > The big ticket item here is the new i915 modeset infrastructure. > Shockingly it didn't not blow up all over the place (i.e. I've managed to > fix the ugly issues before merging). 1-2 smaller corner cases broke, but > we have patches. Also, there's tons of patches on top of this that clean > out cruft and fix a few bugs that couldn't be fixed with the crtc helper > based stuff. So more stuff to come ;-) > > Also a few other things: > - Tiny fix in the fb helper to go through the official dpms interface > instead of calling the crtc helper code. > - forcewake code frobbery from Ben, code should be more in-line with > what Windows does now. > - fixes for the render ring flush on hsw (Paulo) > - gpu frequency tracepoint > - vlv forcewake changes to better align it with our understanding of the > forcewake magic. > - a few smaller cleanups Updated pull request with the 2 bugfixers cherry-picked from my -next queue on top. Since I'll be travelling around for the next two weeks, rebasing things around will take a bit longer. Cheers, Daniel The following changes since commit 85f9e50d815a70780699752c4f2dc1198c2c0b61: drm/i915: move i915_get_extra_insdone out of CONFIG_DEBUG_FS block (2012-09-03 18:06:37 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to 3b7a89fce3e3dc96b549d6d829387b4439044d0d: drm/i915: fix OOPS in lid_notify (2012-09-18 00:59:37 +0200) Ben Widawsky (5): drm/i915: Extract forcewake ack timeout drm/i915: use cpu_relax() in wait_for_atomic drm/i915: Change forcewake timeout to 2ms drm/i915: Never read FORCEWAKE drm/i915: Enable some sysfs stuff without CONFIG_PM Chris Wilson (1): drm/i915: Convert remaining debugfs iterators over rings to for_each_ring() Daniel Vetter (68): drm/ips: move drps/ips/ilk related variables into dev_priv->ips drm/i915: add a tracepoint for gpu frequency changes drm/i915: align vlv forcewake with common lore drm/i915: differ error message between forcwake timeouts drm/i915: add crtc->enable/disable vfuncs insted of dpms drm/i915: rip out crtc prepare/commit indirection drm/i915: add direct encoder disable/enable infrastructure drm/i915/hdmi: convert to encoder->disable/enable drm/i915/tv: convert to encoder enable/disable drm/i915/lvds: convert to encoder disable/enable drm/i915/dp: convert to encoder disable/enable drm/i915/crt: convert to encoder disable/enable drm/i915/sdvo: convert to encoder disable/enable drm/i915/dvo: convert to encoder disable/enable drm/i915: convert dpms functions of dvo/sdvo/crt drm/i915: rip out encoder->disable/enable checks drm/i915: clean up encoder_prepare/commit drm/i915: copy&paste drm_crtc_helper_set_config drm/i915: call set_base directly drm/i915: inline intel_best_encoder drm/i915: copy&paste drm_crtc_helper_set_mode drm/i915: simplify intel_crtc_prepare_encoders drm/i915: rip out encoder->prepare/commit drm/i915: call crtc functions directly drm/i915: WARN when trying to enabled an unused crtc drm/i915: Add interfaces to read out encoder/connector hw state drm/i915/dp: implement get_hw_state drm/i915/hdmi: implement get_hw_state drm/i915/tv: implement get_hw_state drm/i915/lvds: implement get_hw_state drm/i915/crt: implement get_hw_state drm/i915/sdvo: implement get_hw_state drm/i915/dvo: implement get_hw_state drm/i915: read out the modeset hw state at load and resume time drm/i915: check connector hw/sw state drm/i915: rip out intel_crtc->dpms_mode drm/i915: rip out intel_dp->dpms_mode drm/i915: ensure the force pipe A quirk is actually followed drm/i915: introduce struct intel_set_config drm/i915: extract modeset config save/restore code drm/i915: extract intel_set_config_compute_mode_changes drm/i915: extract intel_set_config_update_output_state drm/i915: implement crtc helper semantics relied upon by the fb helper drm/i915: don't update the fb base if there is no fb drm/i915: convert pointless error checks in set_config to BUGs drm/i915: don't save all the encoder/crtc state in set_config drm/i915: stage modeset output changes drm/i915: push crtc->fb update into pipe_set_base drm/i915: remove crtc disabling special case drm/i915: move output commit and crtc disabling into set_mode drm/i915: extract adjusted mode computation drm/i915: use staged outuput config in tv->mode_fixup drm/i915: use staged outuput config in lvds->mode_fixup drm/i915: compute masks of crtcs affected in set_mode drm/i915: implement new set_mode c
[PATCH 2/2] [RESEND] console: implement lockdep support for console_lock
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.
Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.
Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.
There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
grabbed/dropped at _lock/_unlock time. But the suspend/resume code
drops the semaphore without dropping the console_lock (see
suspend_console/resume_console). But since the same thread that did
the suspend will do the resume, we don't need to fix up anything.
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
- The console_lock can also be acquired form irq context (but only
with a trylock). lockdep already handles that.
This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.
And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:
==
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
---
kms-reload/3577 is trying to acquire lock:
((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
but task is already holding lock:
(console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x95/0x105
[] console_lock+0x59/0x5b
[] fb_flashcursor+0x2e/0x12c
[] process_one_work+0x1d9/0x3b4
[] worker_thread+0x1a7/0x24b
[] kthread+0x7f/0x87
[] kernel_thread_helper+0x4/0x10
-> #0 ((&info->queue)){+.+...}:
[] __lock_acquire+0x999/0xcf6
[] lock_acquire+0x95/0x105
[] wait_on_work+0x3b/0xa7
[] __cancel_work_timer+0xbf/0x102
[] cancel_work_sync+0xb/0xd
[] fbcon_deinit+0x11c/0x1dc
[] bind_con_driver+0x145/0x263
[] unbind_con_driver+0x14f/0x195
[] store_bind+0x1ad/0x1c1
[] dev_attr_store+0x13/0x1f
[] sysfs_write_file+0xe9/0x121
[] vfs_write+0x9b/0xfd
[] sys_write+0x3e/0x6b
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((&info->queue));
lock(console_lock);
lock((&info->queue));
*** DEADLOCK ***
Cc: Dave Airlie
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
kernel/printk.c |9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index ed9af6a..ab2ab24 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map console_lock_dep_map = {
+ .name = "console_lock"
+};
+#endif
+
/*
* This is used for debugging the mess that is the VT code by
* keeping track if we have the console semaphore held. It's
@@ -1916,6 +1922,7 @@ void console_lock(void)
return;
console_locked = 1;
console_may_schedule = 1;
+ mutex_acquire(&console_lock_dep_map, 0, 0, _RET_IP_);
}
EXPORT_SYMBOL(console_lock);
@@ -1937,6 +1944,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
+ mutex_acquire(&console_lock_dep_map, 0, 1, _RET_IP_);
return 1;
}
EXPORT_SYMBOL(console_trylock);
@@ -2097,6 +2105,7 @@ skip:
local_irq_restore(flags);
}
console_locked = 0;
+ mutex_release(&console_lock_dep_map, 1, _RET_IP_);
/* Release the exclusive_console once it is used */
if (unlikely(exclusive_console))
--
1.7.10.4
[PATCH 1/2] [RESEND] console: use might_sleep in console_lock
Instead of BUG_ON(in_interrupt()), since that doesn't check for all
the newfangled stuff like preempt.
Note that this is valid since the console_sem is essentially used like
a real mutex with only two twists:
- we allow trylock from hardirq context
- across suspend/resume we lock the logical console_lock, but drop the
semaphore protecting the locking state.
Now that doesn't guarantee that no one is playing tricks in
single-thread atomic contexts at suspend/resume/boot time, but
- I couldn't find anything suspicious with some grepping,
- might_sleep shouldn't die,
- and I think the upside of catching more potential issues is worth
the risk of getting a might_sleep backtrace that would have been
save (and then dealing with that fallout).
Cc: Dave Airlie
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
kernel/printk.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..ed9af6a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1909,7 +1909,8 @@ static int __cpuinit console_cpu_notify(struct
notifier_block *self,
*/
void console_lock(void)
{
- BUG_ON(in_interrupt());
+ might_sleep();
+
down(&console_sem);
if (console_suspended)
return;
--
1.7.10.4
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #41 from Austin Lund 2012-09-18 05:55:27 UTC --- (In reply to comment #40) > (In reply to comment #39) > > From what I've been told, you need to boot using the EFI stub method and > > not a > > boot-loader. Also, you may need to pass some kernel options (eg initrd) so > > the > > easiest way to do this is from within an EFI shell. > Do you have any more details on that? I'd like to try it! Make sure you have CONFIG_EFI and CONFIG_EFI_STUB set for your kernel. Put the kernel image in a filesystem that can be read by the EFI firmware or has a driver for it. Boot into the EFI shell. I do this via rEFIt. cd to the location of the kernel then execute it by typing it's name. Kernel parameters can be listed after the kernel name. > > How are you booting the kernel? > linux /boot/vmlinuz root=/dev/sda3 > I have never needed an initrd, all required modules are built in... OK. So you haven't actually said, but you must be booting via Grub either in EFI mode or BIOS compatiability mode. Neither of those will work in extracting the AtomBIOS from the configurations. It needs to be done before calling ExitBootServices() in EFI mode and Grub isn't set up to do anything this tricky. Hence you have to use the inbuilt kernel loader in the EFI stub code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
