[PATCH] drm/i915: no lvds quirk for hp t5740

[Ben Mesman (Bossers & Cnossen BV)]

Hi,

Last year, a patch was made for the "HP t5740e Thin Client" (see 
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This 
device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have an 
lvds panel. This patch will add the same quirk for this device. The dmidecode 
output is attached below the patch.

Regards,
Ben Mesman.

===

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -748,6 +748,14 @@
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Hewlett-Packard hp t5740",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Hewlett-Packard HP t5740e Thin Client",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),

===

# dmidecode 2.11
SMBIOS 2.6 present.
43 structures occupying 1552 bytes.
Table at 0x000FD100.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 786R8 v1.04
Release Date: 03/22/2011
Address: 0xE
Runtime Size: 128 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 8.15

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: hp t5740
Version:
Serial Number: CNVA190LKX
UUID: 007F6E00-0BBF-E111-83A5-D5B139101A00
Wake-up Type: Power Switch
SKU Number: Climbers
Family: 103C_53302C

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 3641h
Version:
Serial Number: CNVA190LKX
Asset Tag: Climbers
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Climbers
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: Hewlett-Packard
Type: Desktop
Lock: Not Present
Version:
Serial Number: CNVA190LKX
Asset Tag: 
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: C2 06 01 00 FF FB E9 BF
Version: Intel(R) Atom(TM) CPU N280   @ 1.66GHz  
Voltage: 1.2 V
External Clock: 167 MHz
Max Speed: 1666 MHz
Current Speed: 1666 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 1
Core Enabled: 1
Thread Count: 2
Characteristics: None

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 24 kB
Maximum Size: 24 kB
   

Re: [PATCH] drm/i915: no lvds quirk for hp t5740

[Daniel Vetter]

On Fri, Apr 12, 2013 at 9:23 AM, Ben Mesman (Bossers & Cnossen BV)
 wrote:
> Hi,
>
> Last year, a patch was made for the "HP t5740e Thin Client" (see 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This 
> device reports an lvds panel, but does not really have one.
>
> The predecessor of this device is the "hp t5740", which also does not have an 
> lvds panel. This patch will add the same quirk for this device. The dmidecode 
> output is attached below the patch.

Diff is ok, but can you please resubmit this as a proper kernel patch
submission? s-o-b is missing and the mail isn't in the usual patch
layout (git format-patch  and git send-email highly recommend). But
please keep your intro here as a commit message, it's good ;-) See
Documentation/SubmittingPatches for details

Thanks, Daniel

>
> Regards,
> Ben Mesman.
>
> ===
>
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -748,6 +748,14 @@
> },
> {
> .callback = intel_no_lvds_dmi_callback,
> +   .ident = "Hewlett-Packard hp t5740",
> +   .matches = {
> +   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
> +   },
> +   },
> +   {
> +   .callback = intel_no_lvds_dmi_callback,
> .ident = "Hewlett-Packard HP t5740e Thin Client",
> .matches = {
> DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
>
> ===
>
> # dmidecode 2.11
> SMBIOS 2.6 present.
> 43 structures occupying 1552 bytes.
> Table at 0x000FD100.
>
> Handle 0x, DMI type 0, 24 bytes
> BIOS Information
> Vendor: American Megatrends Inc.
> Version: 786R8 v1.04
> Release Date: 03/22/2011
> Address: 0xE
> Runtime Size: 128 kB
> ROM Size: 1024 kB
> Characteristics:
> PCI is supported
> PNP is supported
> BIOS is upgradeable
> BIOS shadowing is allowed
> ESCD support is available
> Boot from CD is supported
> Selectable boot is supported
> EDD is supported
> 5.25"/360 kB floppy services are supported (int 13h)
> 5.25"/1.2 MB floppy services are supported (int 13h)
> 3.5"/720 kB floppy services are supported (int 13h)
> 3.5"/2.88 MB floppy services are supported (int 13h)
> Print screen service is supported (int 5h)
> 8042 keyboard services are supported (int 9h)
> Serial services are supported (int 14h)
> Printer services are supported (int 17h)
> CGA/mono video services are supported (int 10h)
> ACPI is supported
> USB legacy is supported
> LS-120 boot is supported
> ATAPI Zip drive boot is supported
> BIOS boot specification is supported
> Function key-initiated network boot is supported
> Targeted content distribution is supported
> BIOS Revision: 8.15
>
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Hewlett-Packard
> Product Name: hp t5740
> Version:
> Serial Number: CNVA190LKX
> UUID: 007F6E00-0BBF-E111-83A5-D5B139101A00
> Wake-up Type: Power Switch
> SKU Number: Climbers
> Family: 103C_53302C
>
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> Manufacturer: Hewlett-Packard
> Product Name: 3641h
> Version:
> Serial Number: CNVA190LKX
> Asset Tag: Climbers
> Features:
> Board is a hosting board
> Board is replaceable
> Location In Chassis: Climbers
> Chassis Handle: 0x0003
> Type: Motherboard
> Contained Object Handles: 0
>
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> Manufacturer: Hewlett-Packard
> Type: Desktop
> Lock: Not Present
> Version:
> Serial Number: CNVA190LKX
> Asset Tag: 
> Boot-up State: Safe
> Power Supply State: Safe
> Thermal State: Safe
> Security Status: None
> OEM Information: 0x
> Height: Unspecified
> Number Of Power Cords: 1
> Contained Elements: 0
>
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> Socket Designation: CPU 1
> Type: Central Processor
> Family: Other
> Manufacturer: Intel
> ID: C2 06 01 00 FF FB E9 BF
> Version: Intel(R) Atom(TM) CPU N280   @ 1.66GHz
> Voltage: 1.2 V
> External Clock: 167 MHz
> Max Speed: 1666 MHz
> Current Speed: 1666 MHz
> Status: Populated, Enabled
> 

Re: [PATCH Resend 1/1] Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/4/12 Sachin Kamat 

> This reverts commit 09495dda6a62c74b13412a63528093910ef80edd.
> The description is incomplete and the location of this file
> is incorrect. Based on discussion with the Samsung media and DRM subsystem
> maintainers, the documentaion of Samsung G2D bindings has been placed at:
> Documentation/devicetree/bindings/gpu/samsung-g2d.txt
>
> Signed-off-by: Sachin Kamat 
> Cc: Inki Dae 
> Cc: Sylwester Nawrocki 
> Cc: Ajay Kumar 
> ---
> The right documentation for G2D bindings has already been merged for
> 3.10-rc
> and hence we need this patch for 3.10-rc too, to avoid confusions due to
> multiple documents.
> ---
>  .../devicetree/bindings/drm/exynos/g2d.txt |   22
> 
>  1 file changed, 22 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/drm/exynos/g2d.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> deleted file mode 100644
> index 1eb124d..000
> --- a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -Samsung 2D Graphic Accelerator using DRM frame work
> -
> -Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block
> Transfer.
> -We set the drawing-context registers for configuring rendering parameters
> and
> -then start rendering.
> -This driver is for SOCs which contain G2D IPs with version 4.1.
> -
> -Required properties:
> -   -compatible:
> -   should be "samsung,exynos-g2d-41".
> -   -reg:
> -   physical base address of the controller and length
> -   of memory mapped region.
> -   -interrupts:
> -   interrupt combiner values.
> -
> -Example:
> -   g2d {
> -   compatible = "samsung,exynos-g2d-41";
> -   reg = <0x1085 0x1000>;
> -   interrupts = <0 91 0>;
> -   };
> --
> 1.7.9.5
>
> ___
> 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

Re: repost fix for a real prime issue

[Daniel Vetter]

On Wed, Apr 10, 2013 at 10:56:42AM +1000, Dave Airlie wrote:
> Please don't bikeshed this with requirements to fix problems that
> are there now anyways. This is the simplest patch to fix an obvious
> problem, it doesn't fix all the other problems.
> 
> I should have merged this months ago, but people keep wanting a
> superpatch to fix everything.

Imo same review on the semantics of the patch itself still applies:

http://lists.freedesktop.org/archives/dri-devel/2012-December/032374.html

Two main things:
- I think the dma_buf reference attached to gem handles should be dropped
  in drm_gem_object_handle_free instead of drm_gem_handle_delete.
- I still have no idea what the drm_prime_lookup_buf_handle check in
  handle_to_fd is for ...

Note that the locking review was in a 2nd mail:

http://lists.freedesktop.org/archives/dri-devel/2012-December/032376.html

Imo this is an issue with this very patch since this patch also adds the
dma_buf reference on exported objects while a handle is open.

So I don't think my original review asked for a superpatch to fix all the
issues with currently have, but only for a correct one implementing the
handle holds ref on exported obj logic ;-)

I'll try to pimp the self import testcase we have a bit to exercise these
corner cases.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Perform ioctl command validation on the stored kernel values

[Chris Wilson]

Userspace is free to pass in any command bits it feels like through the
ioctl cmd, and for example trinity likes to fuzz those bits to create
conflicting commands. So instead of relying upon userspace to pass along
the correct IN/OUT flags for the ioctl, use the flags as expected by the
kernel.

This does have a side-effect that NULL pointers can not be substituted
by userspace in place of a struct. This feature was not being used by
any driver, but instead exposed all of the command handlers to a user
triggerable OOPS.

Reported-by: Tommi Rantala 
Link: 
http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
Signed-off-by: Tommi Rantala 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_drv.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 25f91cd..0ac1991 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -408,6 +408,7 @@ long drm_ioctl(struct file *filp,
usize = asize = _IOC_SIZE(cmd);
if (drv_size > asize)
asize = drv_size;
+   cmd = ioctl->cmd_drv;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
ioctl = &drm_ioctls[nr];
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFCv2,libdrm 0/2] NVIDIA Tegra support

[Arto Merilainen]

This patch series adds application level support for host1x hardware
on Tegra SoCs. This set of patches can be used in combination with
host1x kernel patches. The most recent version of the kernel patch
series is available at [0].

An example of using 2d hardware acceleration with this library is
available at [1].

Changes in version 2:
- Instead of using assertations, the library now returns error codes
- Added a minimal set of tests to test common use cases
- The size of a stream buffer pool can be set runtime
- The library keeps track of syncpoint increments
- Added reference counting to buffer management
- Removed 2d related patches from the series
- Rebased to latest libdrm
- Updated ioctl interface
- Fixed stylish issues

[0]: http://gitorious.org/linux-host1x/linux-host1x
[1]: http://gitorious.org/linux-host1x/libdrm-host1x/commits/2d

Arto Merilainen (2):
  tegra: Add stream library
  tests: tegra: Add stream library test

 Makefile.am|6 +-
 configure.ac   |   14 +
 tegra/Makefile.am  |   25 +
 tegra/class_ids.h  |   36 ++
 tegra/host1x01_hardware.h  |  125 
 tegra/hw_host1x01_uclass.h |  155 +
 tegra/libdrm_tegra.pc.in   |   10 +
 tegra/tegra_drm.c  |  998 
 tegra/tegra_drm.h  |  136 +
 tegra/tegra_drmif.h|  110 
 tests/tegra/host1x/Makefile.am |   12 +
 tests/tegra/host1x/tegra_host1x_test.c |  893 
 12 files changed, 2519 insertions(+), 1 deletion(-)
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/class_ids.h
 create mode 100644 tegra/host1x01_hardware.h
 create mode 100644 tegra/hw_host1x01_uclass.h
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra_drm.c
 create mode 100644 tegra/tegra_drm.h
 create mode 100644 tegra/tegra_drmif.h
 create mode 100644 tests/tegra/host1x/Makefile.am
 create mode 100644 tests/tegra/host1x/tegra_host1x_test.c

-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFCv2,libdrm 1/2] tegra: Add stream library

[Arto Merilainen]

This patch introduces tegra stream library. The library is used for
buffer management, command stream construction and work
synchronization.

Signed-off-by: Arto Merilainen 
---
 Makefile.am|6 +-
 configure.ac   |   13 +
 tegra/Makefile.am  |   25 ++
 tegra/class_ids.h  |   36 ++
 tegra/host1x01_hardware.h  |  125 ++
 tegra/hw_host1x01_uclass.h |  155 +++
 tegra/libdrm_tegra.pc.in   |   10 +
 tegra/tegra_drm.c  |  998 
 tegra/tegra_drm.h  |  136 ++
 tegra/tegra_drmif.h|  110 +
 10 files changed, 1613 insertions(+), 1 deletion(-)
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/class_ids.h
 create mode 100644 tegra/host1x01_hardware.h
 create mode 100644 tegra/hw_host1x01_uclass.h
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra_drm.c
 create mode 100644 tegra/tegra_drm.h
 create mode 100644 tegra/tegra_drmif.h

diff --git a/Makefile.am b/Makefile.am
index f726036..bd942e7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,7 +51,11 @@ if HAVE_FREEDRENO
 FREEDRENO_SUBDIR = freedreno
 endif
 
-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests 
include man
+if HAVE_TEGRA
+TEGRA_SUBDIR = tegra
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) 
$(TEGRA_SUBDIR) tests include man
 
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 2786c87..e55e9c1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -103,6 +103,11 @@ AC_ARG_ENABLE(install-test-programs,
  [Install test programs (default: no)]),
  [INSTALL_TESTS=$enableval], [INSTALL_TESTS=no])
 
+AC_ARG_ENABLE(tegra,
+ AS_HELP_STRING([--enable-tegra],
+ [Enable support for tegra's API (default: disabled)]),
+ [TEGRA=$enableval], [TEGRA=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -216,6 +221,11 @@ if test "x$FREEDRENO" = xyes; then
AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support])
 fi
 
+AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes])
+if test "x$TEGRA" = xyes; then
+   AC_DEFINE(HAVE_TEGRA, 1, [Have TEGRA support])
+fi
+
 AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes])
 if test "x$INSTALL_TESTS" = xyes; then
AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs])
@@ -380,6 +390,8 @@ AC_CONFIG_FILES([
exynos/libdrm_exynos.pc
freedreno/Makefile
freedreno/libdrm_freedreno.pc
+   tegra/Makefile
+   tegra/libdrm_tegra.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -404,4 +416,5 @@ echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
 echo "  EXYNOS API $EXYNOS"
 echo "  Freedreno API  $FREEDRENO"
+echo "  TEGRA API  $TEGRA"
 echo ""
diff --git a/tegra/Makefile.am b/tegra/Makefile.am
new file mode 100644
index 000..72675e5
--- /dev/null
+++ b/tegra/Makefile.am
@@ -0,0 +1,25 @@
+AM_CFLAGS = \
+   $(WARN_CFLAGS) \
+   -I$(top_srcdir) \
+   -I$(top_srcdir)/tegra \
+   $(PTHREADSTUBS_CFLAGS) \
+   -I$(top_srcdir)/include/drm
+
+libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la
+libdrm_tegra_ladir = $(libdir)
+libdrm_tegra_la_LDFLAGS = -version-number 1:0:0 -no-undefined
+libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+
+libdrm_tegra_la_SOURCES = \
+   tegra_drm.c
+
+libdrm_tegracommonincludedir = ${includedir}/tegra
+libdrm_tegracommoninclude_HEADERS = \
+   tegra_drm.h
+
+libdrm_tegraincludedir = ${includedir}/libdrm
+libdrm_tegrainclude_HEADERS = \
+   tegra_drmif.h
+
+pkgconfigdir = @pkgconfigdir@
+pkgconfig_DATA = libdrm_tegra.pc
diff --git a/tegra/class_ids.h b/tegra/class_ids.h
new file mode 100644
index 000..b512306
--- /dev/null
+++ b/tegra/class_ids.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2012-2013 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+

[RFCv2,libdrm 2/2] tests: tegra: Add stream library test

[Arto Merilainen]

This patch adds a minimal test set for the stream library and host1x
kernel interface.

The test verifies that the driver (or library) is able to:
- Increment, read and wait for syncpoint values
- Use a host1x channel to do host1x operations
- Handle submit timeout correctly
- Do relocations to buffer
- Allocate and release memory
- Use stream pools correctly

Signed-off-by: Arto Merilainen 
---
 configure.ac   |1 +
 tests/tegra/host1x/Makefile.am |   12 +
 tests/tegra/host1x/tegra_host1x_test.c |  893 
 3 files changed, 906 insertions(+)
 create mode 100644 tests/tegra/host1x/Makefile.am
 create mode 100644 tests/tegra/host1x/tegra_host1x_test.c

diff --git a/configure.ac b/configure.ac
index e55e9c1..a678bcd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -399,6 +399,7 @@ AC_CONFIG_FILES([
tests/radeon/Makefile
tests/vbltest/Makefile
tests/exynos/Makefile
+   tests/tegra/host1x/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/tests/tegra/host1x/Makefile.am b/tests/tegra/host1x/Makefile.am
new file mode 100644
index 000..700f764
--- /dev/null
+++ b/tests/tegra/host1x/Makefile.am
@@ -0,0 +1,12 @@
+AM_CFLAGS = \
+   -I $(top_srcdir)/include/drm \
+   -I $(top_srcdir)
+
+LDADD = \
+   $(top_builddir)/libdrm.la
+
+noinst_PROGRAMS = \
+   tegra_host1x_test
+
+tegra_host1x_test_SOURCES = \
+   tegra_host1x_test.c
diff --git a/tests/tegra/host1x/tegra_host1x_test.c 
b/tests/tegra/host1x/tegra_host1x_test.c
new file mode 100644
index 000..548f422
--- /dev/null
+++ b/tests/tegra/host1x/tegra_host1x_test.c
@@ -0,0 +1,893 @@
+/*
+ * Copyright (C) 2012-2013 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Arto Merilainen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Include the code file to access the internals of the library */
+#include "tegra/tegra_drm.c"
+
+#define HOST1X_OPCODE_NOP  host1x_opcode_nonincr(0, 0)
+
+/*
+ * test_oversized_submit(channel) - Do a submit that does not fit into
+ * preallocated stream buffer
+ */
+
+int test_oversized_submit(struct tegra_channel *channel)
+{
+   struct tegra_stream *stream = NULL;
+   struct tegra_fence fence;
+   unsigned int diff_ms;
+   int i;
+
+   /* Create a really small buffer */
+   if (!(stream = tegra_stream_create(channel, 4, 0, 0)))
+   return -1;
+
+   if (tegra_stream_begin(stream, 100, NULL, 0, 0,
+   HOST1X_CLASS_HOST1X))
+   goto destroy;
+   for (i = 0; i < 100; ++i) {
+   if (tegra_stream_push(stream, HOST1X_OPCODE_NOP))
+   goto destroy;
+   }
+   if (tegra_stream_end(stream))
+   goto destroy;
+   if (tegra_stream_flush(stream, &fence))
+   goto destroy;
+   if (!tegra_fence_is_valid(&fence))
+   goto destroy;
+   if (tegra_fence_waitex(channel, &fence, 15000, NULL))
+   goto destroy;
+
+   tegra_stream_destroy(stream);
+   return 0;
+
+destroy:
+   tegra_stream_destroy(stream);
+   return -1;
+
+}
+
+/*
+ * test_huge_submit(channel) - Do single huge submit and wait for completion
+ */
+
+int test_huge_submit(struct tegra_channel *channel)
+{
+   struct tegra_stream *stream = NULL;
+   struct tegra_fence fence;
+   const unsigned int submit_count = 1000;
+   struct timespec tp_begin, tp_end;
+   unsigned int diff_ms;
+   int i;
+
+   clock_gettime(CLOCK_MONOTONIC, &tp_begin);
+
+   if (!(stream = tegra_stream_create(channel, 0, 0, 0)))
+   return -1;
+
+   /* Create many small submits */
+   for (i = 0; i < submit_count; ++i) {
+   if (tegra_stream_begin(stream, 1, NULL, 0, 0,
+ 

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #10 from udo  ---
Despite crashes for other reasons (ARUBA (Cayman) not yet ready for OpenCL) I
saw no GPU faults etc in the logs since booting into 3.8.5 with the patch.
I want to give it a few more days without OpenCL disruptions to be sure.

-- 
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 2/2] radeon: add si tiling support v5

[Michel Dänzer]

On Mit, 2013-04-10 at 18:20 -0400, j.gli...@gmail.com wrote: 
> From: Jerome Glisse 
> 
> v2: Only writte tile index if flags for it is set
> v3: Remove useless allow2d scanout flags
> v4: Split radeon_drm.h update to its own patch
> v5: update against lastest next tree for radeon
> 
> Signed-off-by: Jerome Glisse 

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: no lvds quirk for hp t5740

[Ben Mesman]

Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.

Signed-off-by: Ben Mesman 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index ca2d903..8a56d9b 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -816,6 +816,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Hewlett-Packard hp t5740",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Hewlett-Packard HP t5740e Thin Client",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: no lvds quirk for hp t5740

[Chris Wilson]

On Fri, Apr 12, 2013 at 02:24:43PM +0200, Ben Mesman wrote:
> Last year, a patch was made for the "HP t5740e Thin Client" (see
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> This device reports an lvds panel, but does not really have one.
> 
> The predecessor of this device is the "hp t5740", which also does not have
> an lvds panel. This patch will add the same quirk for this device.
> 
> Signed-off-by: Ben Mesman 
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index ca2d903..8a56d9b 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -816,6 +816,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
>   },
>   {
>   .callback = intel_no_lvds_dmi_callback,
> + .ident = "Hewlett-Packard hp t5740",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
> + },
> + },

One thing to note is that the dmi matching routine uses strstr (as
opposed to dmi_match() which uses strcmp!) so this rule should
encompass the following rule for its offspring.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #11 from Alex Deucher  ---
This is starting to look like a duplicate of bug 62959.  Can you try attachment
77608?  That seems to fix 62959, hopefully it will fix this one as well.

-- 
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 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #12 from udo  ---
So I undo the previous patch and try this new one?
(Or try them combined?)

-- 
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 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #13 from Alex Deucher  ---
(In reply to comment #12)
> So I undo the previous patch and try this new one?
> (Or try them combined?)

Try them separately, not combined.

-- 
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] udl: handle EDID failure properly.

[Alex Deucher]

On Thu, Apr 11, 2013 at 11:25 PM, Dave Airlie  wrote:
> Don't oops seems proper.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/udl/udl_connector.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c 
> b/drivers/gpu/drm/udl/udl_connector.c
> index fe5cdbc..b44d548 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -61,6 +61,10 @@ static int udl_get_modes(struct drm_connector *connector)
> int ret;
>
> edid = (struct edid *)udl_get_edid(udl);
> +   if (!edid) {
> +   drm_mode_connector_update_edid_property(connector, NULL);
> +   return 0;
> +   }
>
> /*
>  * We only read the main block, but if the monitor reports extension
> --
> 1.8.2
>
> ___
> 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

libdrm release next week ?

[Jerome Glisse]

Hi,

I would like to make a libdrm release sometime next week, does anybody have
anything they want to include ?

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 0/2] Speed Cap fixes for ppc64

[Jerome Glisse]

On Thu, Apr 11, 2013 at 9:13 AM, Lucas Kannebley Tavares <
luca...@linux.vnet.ibm.com> wrote:

> After all the comments in the last patch series, I did a refactoring of
> what I was proposing and came up with this. Basically, now:
>   1. max_bus_speed is used to set the device to gen2 speeds
>   2. on power there's no longer a conflict between the pseries call and
> other architectures, because the overwrite is done via a ppc_md hook
>   3. radeon is using bus->max_bus_speed instead of
> drm_pcie_get_speed_cap_mask for gen2 capability detection
>
> The first patch consists of some architecture changes, such as adding a
> hook on powerpc for pci_root_bridge_prepare, so that pseries will
> initialize it to a function, while all other architectures get a NULL
> pointer. So that whenever whenever pci_create_root_bus is called, we'll get
> max_bus_speed properly setup from OpenFirmware.
>
> The second patch consists of simple radeon changes not to call
> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the
> max_bus_speed property will be properly set already.
>

The radeon changes are :

Reviewed-by: Jerome Glisse 


>
> Lucas Kannebley Tavares (2):
>   ppc64: perform proper max_bus_speed detection
>   radeon: use max_bus_speed to activate gen2 speeds
>
>  arch/powerpc/include/asm/machdep.h |2 +
>  arch/powerpc/kernel/pci-common.c   |8 +
>  arch/powerpc/platforms/pseries/pci.c   |   51
> 
>  arch/powerpc/platforms/pseries/setup.c |4 ++
>  drivers/gpu/drm/radeon/evergreen.c |9 +
>  drivers/gpu/drm/radeon/r600.c  |8 +
>  drivers/gpu/drm/radeon/rv770.c |8 +
>  7 files changed, 69 insertions(+), 21 deletions(-)
>
> --
> 1.7.4.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

Re: libdrm release next week ?

[Laurent Pinchart]

Hi Jerome,

On Friday 12 April 2013 09:51:04 Jerome Glisse wrote:
> Hi,
> 
> I would like to make a libdrm release sometime next week, does anybody have
> anything they want to include ?

kms: Return a negative error code in kms_bo_create()
kms: Make libkms.h usable in C++

would be nice.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] kms: Allow compiling libkms without Intel support

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 libkms/Makefile.am | 5 -
 libkms/linux.c | 6 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libkms/Makefile.am b/libkms/Makefile.am
index 215450a..518021f 100644
--- a/libkms/Makefile.am
+++ b/libkms/Makefile.am
@@ -15,10 +15,13 @@ libkms_la_LIBADD = ../libdrm.la
 libkms_la_SOURCES = \
internal.h \
linux.c \
-   intel.c \
dumb.c \
api.c
 
+if HAVE_INTEL
+libkms_la_SOURCES += intel.c
+endif
+
 if HAVE_VMWGFX
 libkms_la_SOURCES += vmwgfx.c
 endif
diff --git a/libkms/linux.c b/libkms/linux.c
index eec0162..d160bc8 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -101,8 +101,12 @@ linux_from_sysfs(int fd, struct kms_driver **out)
if (ret)
return ret;
 
-   if (!strcmp(name, "intel"))
+   if (0)
+   {}
+#ifdef HAVE_INTEL
+   else if (!strcmp(name, "intel"))
ret = intel_create(fd, out);
+#endif
 #ifdef HAVE_VMWGFX
else if (!strcmp(name, "vmwgfx"))
ret = vmwgfx_create(fd, out);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] kms: Allow compiling libkms without Intel support

[Jakob Bornecrantz]

Oh, how very x86 centric of me, the changes are
Reviewed-by Jakob Bornecrantz 

Cheers, Jakob.


On Fri, Apr 12, 2013 at 4:07 PM, Laurent Pinchart <
laurent.pinch...@ideasonboard.com> wrote:

> Signed-off-by: Laurent Pinchart 
> ---
>  libkms/Makefile.am | 5 -
>  libkms/linux.c | 6 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libkms/Makefile.am b/libkms/Makefile.am
> index 215450a..518021f 100644
> --- a/libkms/Makefile.am
> +++ b/libkms/Makefile.am
> @@ -15,10 +15,13 @@ libkms_la_LIBADD = ../libdrm.la
>  libkms_la_SOURCES = \
> internal.h \
> linux.c \
> -   intel.c \
> dumb.c \
> api.c
>
> +if HAVE_INTEL
> +libkms_la_SOURCES += intel.c
> +endif
> +
>  if HAVE_VMWGFX
>  libkms_la_SOURCES += vmwgfx.c
>  endif
> diff --git a/libkms/linux.c b/libkms/linux.c
> index eec0162..d160bc8 100644
> --- a/libkms/linux.c
> +++ b/libkms/linux.c
> @@ -101,8 +101,12 @@ linux_from_sysfs(int fd, struct kms_driver **out)
> if (ret)
> return ret;
>
> -   if (!strcmp(name, "intel"))
> +   if (0)
> +   {}
> +#ifdef HAVE_INTEL
> +   else if (!strcmp(name, "intel"))
> ret = intel_create(fd, out);
> +#endif
>  #ifdef HAVE_VMWGFX
> else if (!strcmp(name, "vmwgfx"))
> ret = vmwgfx_create(fd, out);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> 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 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #3 from Michel Dänzer  ---
Does this still happen with xf86-video-ati 7.1? I think Git commit
53af6aa99dfb67b5223c28d5129a79694165048d might have fixed it.

Note that this probably happens because there is not enough graphics memory for
the high resolution graph, the best we can do is fail more gracefully.

-- 
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 1/3] drm: add prime helpers

[Daniel Vetter]

On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
> 
>   gem_prime_pin: callback when a buffer is created, used to pin buffers into 
> GTT
>   gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
>   gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
>   gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> 
> These hooks are optional; drivers can opt in by using drm_gem_prime_import and
> drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
> struct drm_driver.
> 
> v2:
> - Drop .begin_cpu_access.  None of the drivers this code replaces implemented
>   it.  Having it here was a leftover from when I was trying to include i915 in
>   this rework.
> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
>   did.  This patch series shouldn't change that behavior.
> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>   Rename struct sg_table* variables to 'sgt' for clarity.
> - Update drm.tmpl for these new hooks.
> 
> v3:
> - Pass the vaddr down to the driver.  This lets drivers that just call vunmap 
> on
>   the pointer avoid having to store the pointer in their GEM private 
> structures.
> - Move documentation into a /** DOC */ comment in drm_prime.c and include it 
> in
>   drm.tmpl with a !P line.  I tried to use !F lines to include documentation 
> of
>   the individual functions from drmP.h, but the docproc / kernel-doc scripts
>   barf on that file, so hopefully this is good enough for now.
> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>   ("drm/prime: drop reference on imported dma-buf come from gem")
> 
> Signed-off-by: Aaron Plattner 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
>  Documentation/DocBook/drm.tmpl |   4 +
>  drivers/gpu/drm/drm_prime.c| 186 
> -
>  include/drm/drmP.h |  12 +++
>  3 files changed, 201 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4ee2304..ed40576 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -743,6 +743,10 @@ char *date;
>These two operations are mandatory for GEM drivers that support DRM
>PRIME.
>  
> +
> +  DRM PRIME Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
> +
>
>
>  GEM Objects Mapping
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..366910d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -53,7 +53,8 @@
>   * Self-importing: if userspace is using PRIME as a replacement for flink
>   * then it will get a fd->handle request for a GEM object that it created.
>   * Drivers should detect this situation and return back the gem object
> - * from the dma-buf private.
> + * from the dma-buf private.  Prime will do this automatically for drivers 
> that
> + * use the drm_gem_prime_{import,export} helpers.
>   */
>  
>  struct drm_prime_member {
> @@ -62,6 +63,137 @@ struct drm_prime_member {
>   uint32_t handle;
>  };
>  
> +static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment 
> *attach,
> + enum dma_data_direction dir)
> +{
> + struct drm_gem_object *obj = attach->dmabuf->priv;
> + struct sg_table *sgt;
> +
> + mutex_lock(&obj->dev->struct_mutex);
> +
> + sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
> +
> + if (!IS_ERR_OR_NULL(sgt))
> + dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> +
> + mutex_unlock(&obj->dev->struct_mutex);
> + return sgt;
> +}
> +
> +static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> + struct sg_table *sgt, enum dma_data_direction dir)
> +{
> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> +
> + if (obj->export_dma_buf == dma_buf) {
> + /* drop the reference on the export fd holds */
> + obj->export_dma_buf = NULL;
> + drm_gem_object_unreference_unlocked(obj);
> + }
> +}
> +
> +static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
> +
> + return dev->driver->gem_prime_vmap(obj);
> +}
> +
> +static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
> +
> + dev->driver->g

Re: [PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2.1)

[Daniel Vetter]

On Wed, Apr 10, 2013 at 10:56:43AM +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
> 
> i915 has an imported object reference in its file priv, that isn't
> cleaned up properly until fd close. The reference gets added at step 2,
> but at step 6 we don't have enough info to clean it up.
> 
> The solution is to take a reference on the dma-buf when we export it,
> and drop the reference when the gem handle goes away.
> 
> So when we export a dma_buf from a gem object, we keep track of it
> with the handle, we take a reference to the dma_buf. When we close
> the handle (i.e. userspace is finished with the buffer), we drop
> the reference to the dma_buf, and it gets collected.
> 
> This patch isn't meant to fix any other problem or bikesheds, and it doesn't
> fix any races with other scenarios.
> 
> v1.1: move export symbol line back up.
> 
> v2: okay I had to do a bit more, as the first patch showed a leak
> on one of my tests, that I found using the dma-buf debugfs support,
> the problem case is exporting a buffer twice with the same handle,
> we'd add another export handle for it unnecessarily, however
> we now fail if we try to export the same object with a different gem handle,
> however I'm not sure if that is a case I want to support, and I've
> gotten the code to WARN_ON if we hit something like that.
> 
> v2.1: rebase this patch, write better commit msg.
> 
> Signed-off-by: Dave Airlie 

Ok, so I've figured I'll do a little exercising in laywer-thinking and I
grumpily agree that you can make the case that your patch doesn't
introduce any new races.

And with some convolution I think we can even fix the remaining ones
without undoing this patch here: The reason I've been harping about where
the unref for obj->export_dma_buf should happen is that that's currently
broken and at least my idea of fixing the below mess would have solved it
(I think), too. But we can smash the refcount fix for obj->export_dma_buf
on top of this here.

On second though it's actually a bit cleaner like that ;-)

And if I follow the legal-brainbender argument, the race I've pointed out
is also a pre-existing one. But the last issue stuck, so I want to clarify
that before smashing an r-b onto this patch. See below.

> ---
>  drivers/gpu/drm/drm_gem.c   |  2 +-
>  drivers/gpu/drm/drm_prime.c | 94 
> -
>  include/drm/drmP.h  |  3 +-
>  3 files changed, 71 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index af779ae..f0f7a86 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -209,7 +209,7 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj, 
> struct drm_file *filp)
>   obj->import_attach->dmabuf);
>   }
>   if (obj->export_dma_buf) {
> - drm_prime_remove_imported_buf_handle(&filp->prime,
> + drm_prime_remove_exported_buf_handle(&filp->prime,
>   obj->export_dma_buf);
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 366910d..05ee250 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -157,6 +157,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   .vunmap = drm_gem_dmabuf_vunmap,
>  };
>  
> +static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
> *prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
> +
>  /**
>   * DOC: PRIME Helpers
>   *
> @@ -201,6 +203,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   struct drm_gem_object *obj;
>   void *buf;
>   int ret;
> + struct dma_buf *dmabuf;
> + uint32_t exp_handle;
>  
>   obj = drm_gem_object_lookup(dev, file_priv, handle);
>   if (!obj)
> @@ -209,41 +213,52 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   mutex_lock(&file_priv->prime.lock);
>   /* re-export the original imported object */
>   if (obj->import_attach) {
> - get_dma_buf(obj->import_attach->dmabuf);
> - *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
> - drm_gem_object_unreference_unlocked(obj);
> - mutex_unlock(&file_priv->prime.lock);
> - return 0;
> + dmabuf = obj->import_attach->dmabuf;
> + goto out_have_obj;
>   }
>  
>   if (obj->export_dma_buf) {
> - get_dma_buf(obj->export_dma_buf);
> - *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
> + dmabuf = obj->export_dma_buf;
> + goto out_have_obj;
> + }
> +
> + buf = dev->driver->gem_prime_export(dev, obj, flags);
> + if (IS_ERR(buf)) {
> + /* normally the created dma-buf takes ownership 

Re: [PATCH v3 1/3] drm: add prime helpers

[Aaron Plattner]

On 04/12/13 07:58, Daniel Vetter wrote:

On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:

Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:

   gem_prime_pin: callback when a buffer is created, used to pin buffers into 
GTT
   gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
   gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
   gem_prime_vmap, gem_prime_vunmap: map and unmap an object

These hooks are optional; drivers can opt in by using drm_gem_prime_import and
drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
struct drm_driver.

v2:
- Drop .begin_cpu_access.  None of the drivers this code replaces implemented
   it.  Having it here was a leftover from when I was trying to include i915 in
   this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
   did.  This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
   Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.

v3:
- Pass the vaddr down to the driver.  This lets drivers that just call vunmap on
   the pointer avoid having to store the pointer in their GEM private 
structures.
- Move documentation into a /** DOC */ comment in drm_prime.c and include it in
   drm.tmpl with a !P line.  I tried to use !F lines to include documentation of
   the individual functions from drmP.h, but the docproc / kernel-doc scripts
   barf on that file, so hopefully this is good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
   ("drm/prime: drop reference on imported dma-buf come from gem")

Signed-off-by: Aaron Plattner 
Cc: Daniel Vetter 
Cc: David Airlie 
---
  Documentation/DocBook/drm.tmpl |   4 +
  drivers/gpu/drm/drm_prime.c| 186 -
  include/drm/drmP.h |  12 +++
  3 files changed, 201 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4ee2304..ed40576 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -743,6 +743,10 @@ char *date;
These two operations are mandatory for GEM drivers that support DRM
PRIME.
  
+
+  DRM PRIME Helper Functions Reference
+!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
+


  GEM Objects Mapping
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..366910d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -53,7 +53,8 @@
   * Self-importing: if userspace is using PRIME as a replacement for flink
   * then it will get a fd->handle request for a GEM object that it created.
   * Drivers should detect this situation and return back the gem object
- * from the dma-buf private.
+ * from the dma-buf private.  Prime will do this automatically for drivers that
+ * use the drm_gem_prime_{import,export} helpers.
   */

  struct drm_prime_member {
@@ -62,6 +63,137 @@ struct drm_prime_member {
   uint32_t handle;
  };

+static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct sg_table *sgt;
+
+ mutex_lock(&obj->dev->struct_mutex);
+
+ sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
+
+ if (!IS_ERR_OR_NULL(sgt))
+ dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+
+ mutex_unlock(&obj->dev->struct_mutex);
+ return sgt;
+}
+
+static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+ struct sg_table *sgt, enum dma_data_direction dir)
+{
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+
+ if (obj->export_dma_buf == dma_buf) {
+ /* drop the reference on the export fd holds */
+ obj->export_dma_buf = NULL;
+ drm_gem_object_unreference_unlocked(obj);
+ }
+}
+
+static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct drm_device *dev = obj->dev;
+
+ return dev->driver->gem_prime_vmap(obj);
+}
+
+static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct drm_device *dev = obj->dev;
+
+ dev->driver->gem_prime_vunmap(obj, vaddr);
+}
+
+static void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
+ unsigned long page_num)
+{
+ return NULL;
+}
+
+static void drm_gem_dmabuf_kunmap_a

[Bug 56541] New: Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=56541

   Summary: Sony VAIO VPCZ23A4R: Oops or panic on radeon in error
path
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: patra...@gmail.com
CC: aaron...@intel.com
Regression: No


Created an attachment (id=98431)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=98431)
Dmesg from 3.9-rc5

This is a fork of bug #56501 and bug #55611. A separate bug is needed because a
decision was made to limit these two bugs to non-rescanning of the PCI bus.
Feel free, however, to refer to any relevant files (e.g. kernel configs and
DSDT dump) or comments attached to these bugs.

Due to yet another bug (#56531), the kernel fails to assign PCI resources to
the radeon card in the dock station. As you can see from the attached dmesg, it
causes an oops or even a panic in the radeon driver, among other bad things.
Please fix the radeon driver so that it doesn't dereference a kernel NULL
pointer even when given bad PCI resources.

-- 
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 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #4 from aux...@gmail.com ---
xf86-ati-7.1 fixes this, I apologize for wasting your time. Xorg uses about 1GB
RAM, then returns to normal, and the image is exported as expected.

-- 
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: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

[Bjorn Helgaas]

On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
 wrote:
> radeon currently uses a drm function to get the speed capabilities for
> the bus. However, this is a non-standard method of performing this
> detection and this patch changes it to use the max_bus_speed attribute.
> ---
>  drivers/gpu/drm/radeon/evergreen.c |9 ++---
>  drivers/gpu/drm/radeon/r600.c  |8 +---
>  drivers/gpu/drm/radeon/rv770.c |8 +---
>  3 files changed, 4 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 305a657..3291f62 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
>
>  void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>  {
> -   u32 link_width_cntl, speed_cntl, mask;
> -   int ret;
> +   u32 link_width_cntl, speed_cntl;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
> *rdev)
> if (ASIC_IS_X2(rdev))
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)

For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev->bus->self is NULL on a
root bus.  (I think this is the original problem you tripped over,
Lucas.)

These patches fix that problem.  On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected.  On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).

PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.

That's why I originally suggested skipping the Gen2 stuff if
"max_bus_speed == PCI_SPEED_UNKNOWN".  I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it.  But I'm fine with this being either way.

It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
altogether.  It is exported, but I have no idea of anybody else uses
it.  Maybe it could at least be marked __deprecated now?

I don't know who should take these patches.  They don't touch
drivers/pci, but I'd be happy to push them, given the appropriate ACKs
from DRM and powerpc folks.

Bjorn

> return;
>
> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 0740db3..64b90c0 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct radeon_device 
> *rdev)
>  {
> u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
> u16 link_cntl2;
> -   u32 mask;
> -   int ret;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct radeon_device 
> *rdev)
> if (rdev->family <= CHIP_R600)
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)
> return;
>
> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index d63fe1d..c683c36 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct radeon_device 
> *rdev)
>  {
> u32 link_width_cntl, lanes, speed_cntl, tmp;
> u16 link_cntl2;
> -   u32 mask;
> -   int ret;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct 
> radeon_device *rdev)
> if (ASIC_IS_X2(rdev))
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)
> return;
>
> DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
> radeon.pcie_gen2=0\n");
> --
> 1.7.4.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li

[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60503

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Tom Stellard  ---
Fixed in commit c6a86fb5639977f37a1403012669cdee86bbd89f

Thanks for your help with testing!

-- 
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 1/3] drm: add prime helpers

[Daniel Vetter]

On Fri, Apr 12, 2013 at 5:13 PM, Aaron Plattner  wrote:
>>> @@ -117,6 +249,58 @@ int drm_gem_prime_handle_to_fd(struct drm_device
>>> *dev,
>>>   }
>>>   EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
>>>
>>> +struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
>>> + struct dma_buf *dma_buf)
>>> +{
>>> + struct dma_buf_attachment *attach;
>>> + struct sg_table *sgt;
>>> + struct drm_gem_object *obj;
>>> + int ret;
>>> +
>>> + if (!dev->driver->gem_prime_import_sg_table)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + if (dma_buf->ops == &drm_gem_prime_dmabuf_ops) {
>>
>>
>> This here breaks self-import checks since it smashes all buffers from all
>> drivers using these helpers into one set. Which means e.g. nouveau will
>> happily import a buffer from radoen as it's own. The only reason afaics
>> that shit didn't completely hit the fan is that i915 still has it's own
>> buffer ops, and everyone seems to only care about sharing with i915.
>
>
> Doesn't the (obj->dev == dev) check below guard against that?

Oh dear did I just make a big idiot out of myself ;-) Sorry for the
fuss, you're right.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #48 from Alex Deucher  ---
(In reply to comment #47)
> That works.
> 
> Will any of these four patches land in 3.9 kernel ?

Possibly.  I'm hoping to get hear back from the hw guys early next week to see
if I can get teh existing code to work as it's supposed to.  If not, I'll just
send these patches upstream for now.  If they don't make 3.9 final, they'll
show up via the stable kernel stream.

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #49 from Alexandre Demers  ---
Vladimir, do you see a page fault in your dmesg after applying the four
patches? Something that would look like:
[8.727726] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041000 flags=0x0010]
[8.727737] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800042400 flags=0x0010]
[8.727750] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041040 flags=0x0010]
[8.727753] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041080 flags=0x0010]
[8.727756] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041240 flags=0x0010]
[8.727759] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f8000410c0 flags=0x0010]
[8.727762] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041280 flags=0x0010]
[8.727764] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041100 flags=0x0010]
[8.727767] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f8000412c0 flags=0x0010]
[8.727770] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041140 flags=0x0010]


Alex, is this expected for the workaround?

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #50 from Alexandre Demers  ---
Created attachment 77915
  --> https://bugs.freedesktop.org/attachment.cgi?id=77915&action=edit
Page Fault with four patches applied

AMD-Vi -> IO PAGE FAULTS in dmesg when using 3.9-rc6 with the four patches
applied (77705, 77706, 77743, 77808).

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #51 from Alex Deucher  ---
(In reply to comment #49)
> 
> Alex, is this expected for the workaround?

No.  So it appears turning off the displays doesn't help either :/

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #52 from Vladimir  ---
I don't have these messages, all is quiet here with 3.9-rc5 + 4 patches.

6870

-- 
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 56541] Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=56541





--- Comment #1 from Alex Deucher   2013-04-12 23:19:38 
---
Created an attachment (id=98461)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=98461)
Possible fix

This should fix the issue.

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #53 from Alexandre Demers  ---
(In reply to comment #51)
> (In reply to comment #49)
> > 
> > Alex, is this expected for the workaround?
> 
> No.  So it appears turning off the displays doesn't help either :/

Well, it does help: the screen switches from GRUB to kernel correctly set
(displaying the console), then the screen flashes for a moment (one white flash
instead of one blue flash when the reported bug happens), comes back to normal
in console (where there is now the AMD-Vi IO PAGE FAULT messages) and continues
to work even after Xorg is started.

A difference between Vladimir and I is we don't have the same video card (6950
over here).

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #54 from Vladimir  ---
Just tested with 6970, still fine, no AMD-Vi messages in dmesg.

I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
difference between your and mine setups.

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #55 from Alexandre Demers  ---
(In reply to comment #54)
> Just tested with 6970, still fine, no AMD-Vi messages in dmesg.
> 
> I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
> difference between your and mine setups.

Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload used
in my grub.cfg.

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #56 from Vladimir  ---
I have a panic back on reboot tho, same as in
https://bugs.freedesktop.org/attachment.cgi?id=77625

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #57 from Alexandre Demers  ---
(In reply to comment #55)
> (In reply to comment #54)
> > Just tested with 6970, still fine, no AMD-Vi messages in dmesg.
> > 
> > I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
> > difference between your and mine setups.
> 
> Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload
> used in my grub.cfg.

Even with gfxpayload=text (which is working correctly without all the patches),
I still have the AMD-Vi IO PAGE FAULT messages.

-- 
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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #65 from Austin Lund  ---
Works for me in 3.9-rc6.

As stated above, you cannot use grub to load the firmware as the information is
only accessible before you exit the boot services in EFI.  The kernel must be
booted using EFI stub booting (that's where the code for getting the bios image
is).  I use rEFInd as this now automaigcally passes the initramfs location to
the kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/a5f7a5d9/attachment.html>

[PATCH] udl: handle EDID failure properly.

[Dave Airlie]

Don't oops seems proper.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_connector.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_connector.c 
b/drivers/gpu/drm/udl/udl_connector.c
index fe5cdbc..b44d548 100644
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -61,6 +61,10 @@ static int udl_get_modes(struct drm_connector *connector)
int ret;

edid = (struct edid *)udl_get_edid(udl);
+   if (!edid) {
+   drm_mode_connector_update_edid_property(connector, NULL);
+   return 0;
+   }

/*
 * We only read the main block, but if the monitor reports extension
-- 
1.8.2

[Bug 56041] Disabling LCD on ARUBA causes hotplug loop

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=56041





--- Comment #3 from Thomas J. Moore   2013-04-12 03:43:14 
---
Yes, that seems to have fixed it.  Thanks.

-- 
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 Resend 1/1] Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"

[Sachin Kamat]

This reverts commit 09495dda6a62c74b13412a63528093910ef80edd.
The description is incomplete and the location of this file
is incorrect. Based on discussion with the Samsung media and DRM subsystem
maintainers, the documentaion of Samsung G2D bindings has been placed at:
Documentation/devicetree/bindings/gpu/samsung-g2d.txt

Signed-off-by: Sachin Kamat 
Cc: Inki Dae 
Cc: Sylwester Nawrocki 
Cc: Ajay Kumar 
---
The right documentation for G2D bindings has already been merged for 3.10-rc
and hence we need this patch for 3.10-rc too, to avoid confusions due to
multiple documents.
---
 .../devicetree/bindings/drm/exynos/g2d.txt |   22 
 1 file changed, 22 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/exynos/g2d.txt

diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt 
b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
deleted file mode 100644
index 1eb124d..000
--- a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Samsung 2D Graphic Accelerator using DRM frame work
-
-Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
-We set the drawing-context registers for configuring rendering parameters and
-then start rendering.
-This driver is for SOCs which contain G2D IPs with version 4.1.
-
-Required properties:
-   -compatible:
-   should be "samsung,exynos-g2d-41".
-   -reg:
-   physical base address of the controller and length
-   of memory mapped region.
-   -interrupts:
-   interrupt combiner values.
-
-Example:
-   g2d {
-   compatible = "samsung,exynos-g2d-41";
-   reg = <0x1085 0x1000>;
-   interrupts = <0 91 0>;
-   };
-- 
1.7.9.5

[PATCH] drm/i915: no lvds quirk for hp t5740

[Ben Mesman (Bossers & Cnossen BV)]

Hi,

Last year, a patch was made for the "HP t5740e Thin Client" (see 
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This 
device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have an 
lvds panel. This patch will add the same quirk for this device. The dmidecode 
output is attached below the patch.

Regards,
Ben Mesman.

===

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -748,6 +748,14 @@
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Hewlett-Packard hp t5740",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Hewlett-Packard HP t5740e Thin Client",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),

===

# dmidecode 2.11
SMBIOS 2.6 present.
43 structures occupying 1552 bytes.
Table at 0x000FD100.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 786R8 v1.04
Release Date: 03/22/2011
Address: 0xE
Runtime Size: 128 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 8.15

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: hp t5740
Version:
Serial Number: CNVA190LKX
UUID: 007F6E00-0BBF-E111-83A5-D5B139101A00
Wake-up Type: Power Switch
SKU Number: Climbers
Family: 103C_53302C

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 3641h
Version:
Serial Number: CNVA190LKX
Asset Tag: Climbers
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Climbers
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: Hewlett-Packard
Type: Desktop
Lock: Not Present
Version:
Serial Number: CNVA190LKX
Asset Tag: 
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: C2 06 01 00 FF FB E9 BF
Version: Intel(R) Atom(TM) CPU N280   @ 1.66GHz  
Voltage: 1.2 V
External Clock: 167 MHz
Max Speed: 1666 MHz
Current Speed: 1666 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 1
Core Enabled: 1
Thread Count: 2
Characteristics: None

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 24 kB
Maximum Size: 24 kB
   

[PATCH] drm/i915: no lvds quirk for hp t5740

[Daniel Vetter]

On Fri, Apr 12, 2013 at 9:23 AM, Ben Mesman (Bossers & Cnossen BV)
 wrote:
> Hi,
>
> Last year, a patch was made for the "HP t5740e Thin Client" (see 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This 
> device reports an lvds panel, but does not really have one.
>
> The predecessor of this device is the "hp t5740", which also does not have an 
> lvds panel. This patch will add the same quirk for this device. The dmidecode 
> output is attached below the patch.

Diff is ok, but can you please resubmit this as a proper kernel patch
submission? s-o-b is missing and the mail isn't in the usual patch
layout (git format-patch  and git send-email highly recommend). But
please keep your intro here as a commit message, it's good ;-) See
Documentation/SubmittingPatches for details

Thanks, Daniel

>
> Regards,
> Ben Mesman.
>
> ===
>
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -748,6 +748,14 @@
> },
> {
> .callback = intel_no_lvds_dmi_callback,
> +   .ident = "Hewlett-Packard hp t5740",
> +   .matches = {
> +   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
> +   },
> +   },
> +   {
> +   .callback = intel_no_lvds_dmi_callback,
> .ident = "Hewlett-Packard HP t5740e Thin Client",
> .matches = {
> DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
>
> ===
>
> # dmidecode 2.11
> SMBIOS 2.6 present.
> 43 structures occupying 1552 bytes.
> Table at 0x000FD100.
>
> Handle 0x, DMI type 0, 24 bytes
> BIOS Information
> Vendor: American Megatrends Inc.
> Version: 786R8 v1.04
> Release Date: 03/22/2011
> Address: 0xE
> Runtime Size: 128 kB
> ROM Size: 1024 kB
> Characteristics:
> PCI is supported
> PNP is supported
> BIOS is upgradeable
> BIOS shadowing is allowed
> ESCD support is available
> Boot from CD is supported
> Selectable boot is supported
> EDD is supported
> 5.25"/360 kB floppy services are supported (int 13h)
> 5.25"/1.2 MB floppy services are supported (int 13h)
> 3.5"/720 kB floppy services are supported (int 13h)
> 3.5"/2.88 MB floppy services are supported (int 13h)
> Print screen service is supported (int 5h)
> 8042 keyboard services are supported (int 9h)
> Serial services are supported (int 14h)
> Printer services are supported (int 17h)
> CGA/mono video services are supported (int 10h)
> ACPI is supported
> USB legacy is supported
> LS-120 boot is supported
> ATAPI Zip drive boot is supported
> BIOS boot specification is supported
> Function key-initiated network boot is supported
> Targeted content distribution is supported
> BIOS Revision: 8.15
>
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Hewlett-Packard
> Product Name: hp t5740
> Version:
> Serial Number: CNVA190LKX
> UUID: 007F6E00-0BBF-E111-83A5-D5B139101A00
> Wake-up Type: Power Switch
> SKU Number: Climbers
> Family: 103C_53302C
>
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> Manufacturer: Hewlett-Packard
> Product Name: 3641h
> Version:
> Serial Number: CNVA190LKX
> Asset Tag: Climbers
> Features:
> Board is a hosting board
> Board is replaceable
> Location In Chassis: Climbers
> Chassis Handle: 0x0003
> Type: Motherboard
> Contained Object Handles: 0
>
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> Manufacturer: Hewlett-Packard
> Type: Desktop
> Lock: Not Present
> Version:
> Serial Number: CNVA190LKX
> Asset Tag: 
> Boot-up State: Safe
> Power Supply State: Safe
> Thermal State: Safe
> Security Status: None
> OEM Information: 0x
> Height: Unspecified
> Number Of Power Cords: 1
> Contained Elements: 0
>
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> Socket Designation: CPU 1
> Type: Central Processor
> Family: Other
> Manufacturer: Intel
> ID: C2 06 01 00 FF FB E9 BF
> Version: Intel(R) Atom(TM) CPU N280   @ 1.66GHz
> Voltage: 1.2 V
> External Clock: 167 MHz
> Max Speed: 1666 MHz
> Current Speed: 1666 MHz
> Status: Populated, Enabled
> 

[PATCH Resend 1/1] Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/4/12 Sachin Kamat 

> This reverts commit 09495dda6a62c74b13412a63528093910ef80edd.
> The description is incomplete and the location of this file
> is incorrect. Based on discussion with the Samsung media and DRM subsystem
> maintainers, the documentaion of Samsung G2D bindings has been placed at:
> Documentation/devicetree/bindings/gpu/samsung-g2d.txt
>
> Signed-off-by: Sachin Kamat 
> Cc: Inki Dae 
> Cc: Sylwester Nawrocki 
> Cc: Ajay Kumar 
> ---
> The right documentation for G2D bindings has already been merged for
> 3.10-rc
> and hence we need this patch for 3.10-rc too, to avoid confusions due to
> multiple documents.
> ---
>  .../devicetree/bindings/drm/exynos/g2d.txt |   22
> 
>  1 file changed, 22 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/drm/exynos/g2d.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> deleted file mode 100644
> index 1eb124d..000
> --- a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -Samsung 2D Graphic Accelerator using DRM frame work
> -
> -Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block
> Transfer.
> -We set the drawing-context registers for configuring rendering parameters
> and
> -then start rendering.
> -This driver is for SOCs which contain G2D IPs with version 4.1.
> -
> -Required properties:
> -   -compatible:
> -   should be "samsung,exynos-g2d-41".
> -   -reg:
> -   physical base address of the controller and length
> -   of memory mapped region.
> -   -interrupts:
> -   interrupt combiner values.
> -
> -Example:
> -   g2d {
> -   compatible = "samsung,exynos-g2d-41";
> -   reg = <0x1085 0x1000>;
> -   interrupts = <0 91 0>;
> -   };
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/bce90370/attachment.html>

repost fix for a real prime issue

[Daniel Vetter]

On Wed, Apr 10, 2013 at 10:56:42AM +1000, Dave Airlie wrote:
> Please don't bikeshed this with requirements to fix problems that
> are there now anyways. This is the simplest patch to fix an obvious
> problem, it doesn't fix all the other problems.
> 
> I should have merged this months ago, but people keep wanting a
> superpatch to fix everything.

Imo same review on the semantics of the patch itself still applies:

http://lists.freedesktop.org/archives/dri-devel/2012-December/032374.html

Two main things:
- I think the dma_buf reference attached to gem handles should be dropped
  in drm_gem_object_handle_free instead of drm_gem_handle_delete.
- I still have no idea what the drm_prime_lookup_buf_handle check in
  handle_to_fd is for ...

Note that the locking review was in a 2nd mail:

http://lists.freedesktop.org/archives/dri-devel/2012-December/032376.html

Imo this is an issue with this very patch since this patch also adds the
dma_buf reference on exported objects while a handle is open.

So I don't think my original review asked for a superpatch to fix all the
issues with currently have, but only for a correct one implementing the
handle holds ref on exported obj logic ;-)

I'll try to pimp the self import testcase we have a bit to exercise these
corner cases.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Perform ioctl command validation on the stored kernel values

[Chris Wilson]

Userspace is free to pass in any command bits it feels like through the
ioctl cmd, and for example trinity likes to fuzz those bits to create
conflicting commands. So instead of relying upon userspace to pass along
the correct IN/OUT flags for the ioctl, use the flags as expected by the
kernel.

This does have a side-effect that NULL pointers can not be substituted
by userspace in place of a struct. This feature was not being used by
any driver, but instead exposed all of the command handlers to a user
triggerable OOPS.

Reported-by: Tommi Rantala 
Link: 
http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow at 
mail.gmail.com
Signed-off-by: Tommi Rantala 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_drv.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 25f91cd..0ac1991 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -408,6 +408,7 @@ long drm_ioctl(struct file *filp,
usize = asize = _IOC_SIZE(cmd);
if (drv_size > asize)
asize = drv_size;
+   cmd = ioctl->cmd_drv;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
ioctl = &drm_ioctls[nr];
-- 
1.7.10.4

[RFCv2,libdrm 0/2] NVIDIA Tegra support

[Arto Merilainen]

This patch series adds application level support for host1x hardware
on Tegra SoCs. This set of patches can be used in combination with
host1x kernel patches. The most recent version of the kernel patch
series is available at [0].

An example of using 2d hardware acceleration with this library is
available at [1].

Changes in version 2:
- Instead of using assertations, the library now returns error codes
- Added a minimal set of tests to test common use cases
- The size of a stream buffer pool can be set runtime
- The library keeps track of syncpoint increments
- Added reference counting to buffer management
- Removed 2d related patches from the series
- Rebased to latest libdrm
- Updated ioctl interface
- Fixed stylish issues

[0]: http://gitorious.org/linux-host1x/linux-host1x
[1]: http://gitorious.org/linux-host1x/libdrm-host1x/commits/2d

Arto Merilainen (2):
  tegra: Add stream library
  tests: tegra: Add stream library test

 Makefile.am|6 +-
 configure.ac   |   14 +
 tegra/Makefile.am  |   25 +
 tegra/class_ids.h  |   36 ++
 tegra/host1x01_hardware.h  |  125 
 tegra/hw_host1x01_uclass.h |  155 +
 tegra/libdrm_tegra.pc.in   |   10 +
 tegra/tegra_drm.c  |  998 
 tegra/tegra_drm.h  |  136 +
 tegra/tegra_drmif.h|  110 
 tests/tegra/host1x/Makefile.am |   12 +
 tests/tegra/host1x/tegra_host1x_test.c |  893 
 12 files changed, 2519 insertions(+), 1 deletion(-)
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/class_ids.h
 create mode 100644 tegra/host1x01_hardware.h
 create mode 100644 tegra/hw_host1x01_uclass.h
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra_drm.c
 create mode 100644 tegra/tegra_drm.h
 create mode 100644 tegra/tegra_drmif.h
 create mode 100644 tests/tegra/host1x/Makefile.am
 create mode 100644 tests/tegra/host1x/tegra_host1x_test.c

-- 
1.7.9.5

[RFCv2,libdrm 1/2] tegra: Add stream library

[Arto Merilainen]

This patch introduces tegra stream library. The library is used for
buffer management, command stream construction and work
synchronization.

Signed-off-by: Arto Merilainen 
---
 Makefile.am|6 +-
 configure.ac   |   13 +
 tegra/Makefile.am  |   25 ++
 tegra/class_ids.h  |   36 ++
 tegra/host1x01_hardware.h  |  125 ++
 tegra/hw_host1x01_uclass.h |  155 +++
 tegra/libdrm_tegra.pc.in   |   10 +
 tegra/tegra_drm.c  |  998 
 tegra/tegra_drm.h  |  136 ++
 tegra/tegra_drmif.h|  110 +
 10 files changed, 1613 insertions(+), 1 deletion(-)
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/class_ids.h
 create mode 100644 tegra/host1x01_hardware.h
 create mode 100644 tegra/hw_host1x01_uclass.h
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra_drm.c
 create mode 100644 tegra/tegra_drm.h
 create mode 100644 tegra/tegra_drmif.h

diff --git a/Makefile.am b/Makefile.am
index f726036..bd942e7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,7 +51,11 @@ if HAVE_FREEDRENO
 FREEDRENO_SUBDIR = freedreno
 endif

-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests 
include man
+if HAVE_TEGRA
+TEGRA_SUBDIR = tegra
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) 
$(TEGRA_SUBDIR) tests include man

 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 2786c87..e55e9c1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -103,6 +103,11 @@ AC_ARG_ENABLE(install-test-programs,
  [Install test programs (default: no)]),
  [INSTALL_TESTS=$enableval], [INSTALL_TESTS=no])

+AC_ARG_ENABLE(tegra,
+ AS_HELP_STRING([--enable-tegra],
+ [Enable support for tegra's API (default: disabled)]),
+ [TEGRA=$enableval], [TEGRA=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -216,6 +221,11 @@ if test "x$FREEDRENO" = xyes; then
AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support])
 fi

+AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes])
+if test "x$TEGRA" = xyes; then
+   AC_DEFINE(HAVE_TEGRA, 1, [Have TEGRA support])
+fi
+
 AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes])
 if test "x$INSTALL_TESTS" = xyes; then
AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs])
@@ -380,6 +390,8 @@ AC_CONFIG_FILES([
exynos/libdrm_exynos.pc
freedreno/Makefile
freedreno/libdrm_freedreno.pc
+   tegra/Makefile
+   tegra/libdrm_tegra.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -404,4 +416,5 @@ echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
 echo "  EXYNOS API $EXYNOS"
 echo "  Freedreno API  $FREEDRENO"
+echo "  TEGRA API  $TEGRA"
 echo ""
diff --git a/tegra/Makefile.am b/tegra/Makefile.am
new file mode 100644
index 000..72675e5
--- /dev/null
+++ b/tegra/Makefile.am
@@ -0,0 +1,25 @@
+AM_CFLAGS = \
+   $(WARN_CFLAGS) \
+   -I$(top_srcdir) \
+   -I$(top_srcdir)/tegra \
+   $(PTHREADSTUBS_CFLAGS) \
+   -I$(top_srcdir)/include/drm
+
+libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la
+libdrm_tegra_ladir = $(libdir)
+libdrm_tegra_la_LDFLAGS = -version-number 1:0:0 -no-undefined
+libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+
+libdrm_tegra_la_SOURCES = \
+   tegra_drm.c
+
+libdrm_tegracommonincludedir = ${includedir}/tegra
+libdrm_tegracommoninclude_HEADERS = \
+   tegra_drm.h
+
+libdrm_tegraincludedir = ${includedir}/libdrm
+libdrm_tegrainclude_HEADERS = \
+   tegra_drmif.h
+
+pkgconfigdir = @pkgconfigdir@
+pkgconfig_DATA = libdrm_tegra.pc
diff --git a/tegra/class_ids.h b/tegra/class_ids.h
new file mode 100644
index 000..b512306
--- /dev/null
+++ b/tegra/class_ids.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2012-2013 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * F

[RFCv2,libdrm 2/2] tests: tegra: Add stream library test

[Arto Merilainen]

This patch adds a minimal test set for the stream library and host1x
kernel interface.

The test verifies that the driver (or library) is able to:
- Increment, read and wait for syncpoint values
- Use a host1x channel to do host1x operations
- Handle submit timeout correctly
- Do relocations to buffer
- Allocate and release memory
- Use stream pools correctly

Signed-off-by: Arto Merilainen 
---
 configure.ac   |1 +
 tests/tegra/host1x/Makefile.am |   12 +
 tests/tegra/host1x/tegra_host1x_test.c |  893 
 3 files changed, 906 insertions(+)
 create mode 100644 tests/tegra/host1x/Makefile.am
 create mode 100644 tests/tegra/host1x/tegra_host1x_test.c

diff --git a/configure.ac b/configure.ac
index e55e9c1..a678bcd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -399,6 +399,7 @@ AC_CONFIG_FILES([
tests/radeon/Makefile
tests/vbltest/Makefile
tests/exynos/Makefile
+   tests/tegra/host1x/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/tests/tegra/host1x/Makefile.am b/tests/tegra/host1x/Makefile.am
new file mode 100644
index 000..700f764
--- /dev/null
+++ b/tests/tegra/host1x/Makefile.am
@@ -0,0 +1,12 @@
+AM_CFLAGS = \
+   -I $(top_srcdir)/include/drm \
+   -I $(top_srcdir)
+
+LDADD = \
+   $(top_builddir)/libdrm.la
+
+noinst_PROGRAMS = \
+   tegra_host1x_test
+
+tegra_host1x_test_SOURCES = \
+   tegra_host1x_test.c
diff --git a/tests/tegra/host1x/tegra_host1x_test.c 
b/tests/tegra/host1x/tegra_host1x_test.c
new file mode 100644
index 000..548f422
--- /dev/null
+++ b/tests/tegra/host1x/tegra_host1x_test.c
@@ -0,0 +1,893 @@
+/*
+ * Copyright (C) 2012-2013 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Arto Merilainen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Include the code file to access the internals of the library */
+#include "tegra/tegra_drm.c"
+
+#define HOST1X_OPCODE_NOP  host1x_opcode_nonincr(0, 0)
+
+/*
+ * test_oversized_submit(channel) - Do a submit that does not fit into
+ * preallocated stream buffer
+ */
+
+int test_oversized_submit(struct tegra_channel *channel)
+{
+   struct tegra_stream *stream = NULL;
+   struct tegra_fence fence;
+   unsigned int diff_ms;
+   int i;
+
+   /* Create a really small buffer */
+   if (!(stream = tegra_stream_create(channel, 4, 0, 0)))
+   return -1;
+
+   if (tegra_stream_begin(stream, 100, NULL, 0, 0,
+   HOST1X_CLASS_HOST1X))
+   goto destroy;
+   for (i = 0; i < 100; ++i) {
+   if (tegra_stream_push(stream, HOST1X_OPCODE_NOP))
+   goto destroy;
+   }
+   if (tegra_stream_end(stream))
+   goto destroy;
+   if (tegra_stream_flush(stream, &fence))
+   goto destroy;
+   if (!tegra_fence_is_valid(&fence))
+   goto destroy;
+   if (tegra_fence_waitex(channel, &fence, 15000, NULL))
+   goto destroy;
+
+   tegra_stream_destroy(stream);
+   return 0;
+
+destroy:
+   tegra_stream_destroy(stream);
+   return -1;
+
+}
+
+/*
+ * test_huge_submit(channel) - Do single huge submit and wait for completion
+ */
+
+int test_huge_submit(struct tegra_channel *channel)
+{
+   struct tegra_stream *stream = NULL;
+   struct tegra_fence fence;
+   const unsigned int submit_count = 1000;
+   struct timespec tp_begin, tp_end;
+   unsigned int diff_ms;
+   int i;
+
+   clock_gettime(CLOCK_MONOTONIC, &tp_begin);
+
+   if (!(stream = tegra_stream_create(channel, 0, 0, 0)))
+   return -1;
+
+   /* Create many small submits */
+   for (i = 0; i < submit_count; ++i) {
+   if (tegra_stream_begin(stream, 1, NULL, 0, 0,
+ 

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #10 from udo  ---
Despite crashes for other reasons (ARUBA (Cayman) not yet ready for OpenCL) I
saw no GPU faults etc in the logs since booting into 3.8.5 with the patch.
I want to give it a few more days without OpenCL disruptions to be sure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/4aface01/attachment-0001.html>

[PATCH 2/2] radeon: add si tiling support v5

[Michel Dänzer]

On Mit, 2013-04-10 at 18:20 -0400, j.glisse at gmail.com wrote: 
> From: Jerome Glisse 
> 
> v2: Only writte tile index if flags for it is set
> v3: Remove useless allow2d scanout flags
> v4: Split radeon_drm.h update to its own patch
> v5: update against lastest next tree for radeon
> 
> Signed-off-by: Jerome Glisse 

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] drm/i915: no lvds quirk for hp t5740

[Ben Mesman]

Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.

Signed-off-by: Ben Mesman 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index ca2d903..8a56d9b 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -816,6 +816,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Hewlett-Packard hp t5740",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Hewlett-Packard HP t5740e Thin Client",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
-- 
1.7.10.4

[PATCH] drm/i915: no lvds quirk for hp t5740

[Chris Wilson]

On Fri, Apr 12, 2013 at 02:24:43PM +0200, Ben Mesman wrote:
> Last year, a patch was made for the "HP t5740e Thin Client" (see
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> This device reports an lvds panel, but does not really have one.
> 
> The predecessor of this device is the "hp t5740", which also does not have
> an lvds panel. This patch will add the same quirk for this device.
> 
> Signed-off-by: Ben Mesman 
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index ca2d903..8a56d9b 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -816,6 +816,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
>   },
>   {
>   .callback = intel_no_lvds_dmi_callback,
> + .ident = "Hewlett-Packard hp t5740",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "hp t5740"),
> + },
> + },

One thing to note is that the dmi matching routine uses strstr (as
opposed to dmi_match() which uses strcmp!) so this rule should
encompass the following rule for its offspring.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #11 from Alex Deucher  ---
This is starting to look like a duplicate of bug 62959.  Can you try attachment
77608?  That seems to fix 62959, hopefully it will fix this one as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/01816762/attachment.html>

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #12 from udo  ---
So I undo the previous patch and try this new one?
(Or try them combined?)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/97c7ae6b/attachment.html>

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62997

--- Comment #13 from Alex Deucher  ---
(In reply to comment #12)
> So I undo the previous patch and try this new one?
> (Or try them combined?)

Try them separately, not combined.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/ea391c9a/attachment.html>

[PATCH] udl: handle EDID failure properly.

[Alex Deucher]

On Thu, Apr 11, 2013 at 11:25 PM, Dave Airlie  wrote:
> Don't oops seems proper.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/udl/udl_connector.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c 
> b/drivers/gpu/drm/udl/udl_connector.c
> index fe5cdbc..b44d548 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -61,6 +61,10 @@ static int udl_get_modes(struct drm_connector *connector)
> int ret;
>
> edid = (struct edid *)udl_get_edid(udl);
> +   if (!edid) {
> +   drm_mode_connector_update_edid_property(connector, NULL);
> +   return 0;
> +   }
>
> /*
>  * We only read the main block, but if the monitor reports extension
> --
> 1.8.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

libdrm release next week ?

[Jerome Glisse]

Hi,

I would like to make a libdrm release sometime next week, does anybody have
anything they want to include ?

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/6ebf34a2/attachment.html>

[PATCHv3 0/2] Speed Cap fixes for ppc64

[Jerome Glisse]

On Thu, Apr 11, 2013 at 9:13 AM, Lucas Kannebley Tavares <
lucaskt at linux.vnet.ibm.com> wrote:

> After all the comments in the last patch series, I did a refactoring of
> what I was proposing and came up with this. Basically, now:
>   1. max_bus_speed is used to set the device to gen2 speeds
>   2. on power there's no longer a conflict between the pseries call and
> other architectures, because the overwrite is done via a ppc_md hook
>   3. radeon is using bus->max_bus_speed instead of
> drm_pcie_get_speed_cap_mask for gen2 capability detection
>
> The first patch consists of some architecture changes, such as adding a
> hook on powerpc for pci_root_bridge_prepare, so that pseries will
> initialize it to a function, while all other architectures get a NULL
> pointer. So that whenever whenever pci_create_root_bus is called, we'll get
> max_bus_speed properly setup from OpenFirmware.
>
> The second patch consists of simple radeon changes not to call
> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the
> max_bus_speed property will be properly set already.
>

The radeon changes are :

Reviewed-by: Jerome Glisse 


>
> Lucas Kannebley Tavares (2):
>   ppc64: perform proper max_bus_speed detection
>   radeon: use max_bus_speed to activate gen2 speeds
>
>  arch/powerpc/include/asm/machdep.h |2 +
>  arch/powerpc/kernel/pci-common.c   |8 +
>  arch/powerpc/platforms/pseries/pci.c   |   51
> 
>  arch/powerpc/platforms/pseries/setup.c |4 ++
>  drivers/gpu/drm/radeon/evergreen.c |9 +
>  drivers/gpu/drm/radeon/r600.c  |8 +
>  drivers/gpu/drm/radeon/rv770.c |8 +
>  7 files changed, 69 insertions(+), 21 deletions(-)
>
> --
> 1.7.4.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/1fdb557d/attachment.html>

libdrm release next week ?

[Laurent Pinchart]

Hi Jerome,

On Friday 12 April 2013 09:51:04 Jerome Glisse wrote:
> Hi,
> 
> I would like to make a libdrm release sometime next week, does anybody have
> anything they want to include ?

kms: Return a negative error code in kms_bo_create()
kms: Make libkms.h usable in C++

would be nice.

-- 
Regards,

Laurent Pinchart

[PATCH] kms: Allow compiling libkms without Intel support

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 libkms/Makefile.am | 5 -
 libkms/linux.c | 6 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libkms/Makefile.am b/libkms/Makefile.am
index 215450a..518021f 100644
--- a/libkms/Makefile.am
+++ b/libkms/Makefile.am
@@ -15,10 +15,13 @@ libkms_la_LIBADD = ../libdrm.la
 libkms_la_SOURCES = \
internal.h \
linux.c \
-   intel.c \
dumb.c \
api.c

+if HAVE_INTEL
+libkms_la_SOURCES += intel.c
+endif
+
 if HAVE_VMWGFX
 libkms_la_SOURCES += vmwgfx.c
 endif
diff --git a/libkms/linux.c b/libkms/linux.c
index eec0162..d160bc8 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -101,8 +101,12 @@ linux_from_sysfs(int fd, struct kms_driver **out)
if (ret)
return ret;

-   if (!strcmp(name, "intel"))
+   if (0)
+   {}
+#ifdef HAVE_INTEL
+   else if (!strcmp(name, "intel"))
ret = intel_create(fd, out);
+#endif
 #ifdef HAVE_VMWGFX
else if (!strcmp(name, "vmwgfx"))
ret = vmwgfx_create(fd, out);
-- 
Regards,

Laurent Pinchart

[PATCH] kms: Allow compiling libkms without Intel support

[Jakob Bornecrantz]

Oh, how very x86 centric of me, the changes are
Reviewed-by Jakob Bornecrantz 

Cheers, Jakob.


On Fri, Apr 12, 2013 at 4:07 PM, Laurent Pinchart <
laurent.pinchart at ideasonboard.com> wrote:

> Signed-off-by: Laurent Pinchart 
> ---
>  libkms/Makefile.am | 5 -
>  libkms/linux.c | 6 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libkms/Makefile.am b/libkms/Makefile.am
> index 215450a..518021f 100644
> --- a/libkms/Makefile.am
> +++ b/libkms/Makefile.am
> @@ -15,10 +15,13 @@ libkms_la_LIBADD = ../libdrm.la
>  libkms_la_SOURCES = \
> internal.h \
> linux.c \
> -   intel.c \
> dumb.c \
> api.c
>
> +if HAVE_INTEL
> +libkms_la_SOURCES += intel.c
> +endif
> +
>  if HAVE_VMWGFX
>  libkms_la_SOURCES += vmwgfx.c
>  endif
> diff --git a/libkms/linux.c b/libkms/linux.c
> index eec0162..d160bc8 100644
> --- a/libkms/linux.c
> +++ b/libkms/linux.c
> @@ -101,8 +101,12 @@ linux_from_sysfs(int fd, struct kms_driver **out)
> if (ret)
> return ret;
>
> -   if (!strcmp(name, "intel"))
> +   if (0)
> +   {}
> +#ifdef HAVE_INTEL
> +   else if (!strcmp(name, "intel"))
> ret = intel_create(fd, out);
> +#endif
>  #ifdef HAVE_VMWGFX
> else if (!strcmp(name, "vmwgfx"))
> ret = vmwgfx_create(fd, out);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/a49d7826/attachment.html>

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #3 from Michel D?nzer  ---
Does this still happen with xf86-video-ati 7.1? I think Git commit
53af6aa99dfb67b5223c28d5129a79694165048d might have fixed it.

Note that this probably happens because there is not enough graphics memory for
the high resolution graph, the best we can do is fail more gracefully.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/7a7a5c54/attachment.html>

[PATCH v3 1/3] drm: add prime helpers

[Daniel Vetter]

On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
> 
>   gem_prime_pin: callback when a buffer is created, used to pin buffers into 
> GTT
>   gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
>   gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
>   gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> 
> These hooks are optional; drivers can opt in by using drm_gem_prime_import and
> drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
> struct drm_driver.
> 
> v2:
> - Drop .begin_cpu_access.  None of the drivers this code replaces implemented
>   it.  Having it here was a leftover from when I was trying to include i915 in
>   this rework.
> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
>   did.  This patch series shouldn't change that behavior.
> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>   Rename struct sg_table* variables to 'sgt' for clarity.
> - Update drm.tmpl for these new hooks.
> 
> v3:
> - Pass the vaddr down to the driver.  This lets drivers that just call vunmap 
> on
>   the pointer avoid having to store the pointer in their GEM private 
> structures.
> - Move documentation into a /** DOC */ comment in drm_prime.c and include it 
> in
>   drm.tmpl with a !P line.  I tried to use !F lines to include documentation 
> of
>   the individual functions from drmP.h, but the docproc / kernel-doc scripts
>   barf on that file, so hopefully this is good enough for now.
> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>   ("drm/prime: drop reference on imported dma-buf come from gem")
> 
> Signed-off-by: Aaron Plattner 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
>  Documentation/DocBook/drm.tmpl |   4 +
>  drivers/gpu/drm/drm_prime.c| 186 
> -
>  include/drm/drmP.h |  12 +++
>  3 files changed, 201 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4ee2304..ed40576 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -743,6 +743,10 @@ char *date;
>These two operations are mandatory for GEM drivers that support DRM
>PRIME.
>  
> +
> +  DRM PRIME Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
> +
>
>
>  GEM Objects Mapping
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..366910d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -53,7 +53,8 @@
>   * Self-importing: if userspace is using PRIME as a replacement for flink
>   * then it will get a fd->handle request for a GEM object that it created.
>   * Drivers should detect this situation and return back the gem object
> - * from the dma-buf private.
> + * from the dma-buf private.  Prime will do this automatically for drivers 
> that
> + * use the drm_gem_prime_{import,export} helpers.
>   */
>  
>  struct drm_prime_member {
> @@ -62,6 +63,137 @@ struct drm_prime_member {
>   uint32_t handle;
>  };
>  
> +static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment 
> *attach,
> + enum dma_data_direction dir)
> +{
> + struct drm_gem_object *obj = attach->dmabuf->priv;
> + struct sg_table *sgt;
> +
> + mutex_lock(&obj->dev->struct_mutex);
> +
> + sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
> +
> + if (!IS_ERR_OR_NULL(sgt))
> + dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> +
> + mutex_unlock(&obj->dev->struct_mutex);
> + return sgt;
> +}
> +
> +static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> + struct sg_table *sgt, enum dma_data_direction dir)
> +{
> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> +
> + if (obj->export_dma_buf == dma_buf) {
> + /* drop the reference on the export fd holds */
> + obj->export_dma_buf = NULL;
> + drm_gem_object_unreference_unlocked(obj);
> + }
> +}
> +
> +static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
> +
> + return dev->driver->gem_prime_vmap(obj);
> +}
> +
> +static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
> +{
> + struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
> +
> + dev->driver->g

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2.1)

[Daniel Vetter]

On Wed, Apr 10, 2013 at 10:56:43AM +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
> 
> i915 has an imported object reference in its file priv, that isn't
> cleaned up properly until fd close. The reference gets added at step 2,
> but at step 6 we don't have enough info to clean it up.
> 
> The solution is to take a reference on the dma-buf when we export it,
> and drop the reference when the gem handle goes away.
> 
> So when we export a dma_buf from a gem object, we keep track of it
> with the handle, we take a reference to the dma_buf. When we close
> the handle (i.e. userspace is finished with the buffer), we drop
> the reference to the dma_buf, and it gets collected.
> 
> This patch isn't meant to fix any other problem or bikesheds, and it doesn't
> fix any races with other scenarios.
> 
> v1.1: move export symbol line back up.
> 
> v2: okay I had to do a bit more, as the first patch showed a leak
> on one of my tests, that I found using the dma-buf debugfs support,
> the problem case is exporting a buffer twice with the same handle,
> we'd add another export handle for it unnecessarily, however
> we now fail if we try to export the same object with a different gem handle,
> however I'm not sure if that is a case I want to support, and I've
> gotten the code to WARN_ON if we hit something like that.
> 
> v2.1: rebase this patch, write better commit msg.
> 
> Signed-off-by: Dave Airlie 

Ok, so I've figured I'll do a little exercising in laywer-thinking and I
grumpily agree that you can make the case that your patch doesn't
introduce any new races.

And with some convolution I think we can even fix the remaining ones
without undoing this patch here: The reason I've been harping about where
the unref for obj->export_dma_buf should happen is that that's currently
broken and at least my idea of fixing the below mess would have solved it
(I think), too. But we can smash the refcount fix for obj->export_dma_buf
on top of this here.

On second though it's actually a bit cleaner like that ;-)

And if I follow the legal-brainbender argument, the race I've pointed out
is also a pre-existing one. But the last issue stuck, so I want to clarify
that before smashing an r-b onto this patch. See below.

> ---
>  drivers/gpu/drm/drm_gem.c   |  2 +-
>  drivers/gpu/drm/drm_prime.c | 94 
> -
>  include/drm/drmP.h  |  3 +-
>  3 files changed, 71 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index af779ae..f0f7a86 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -209,7 +209,7 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj, 
> struct drm_file *filp)
>   obj->import_attach->dmabuf);
>   }
>   if (obj->export_dma_buf) {
> - drm_prime_remove_imported_buf_handle(&filp->prime,
> + drm_prime_remove_exported_buf_handle(&filp->prime,
>   obj->export_dma_buf);
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 366910d..05ee250 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -157,6 +157,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   .vunmap = drm_gem_dmabuf_vunmap,
>  };
>  
> +static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
> *prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
> +
>  /**
>   * DOC: PRIME Helpers
>   *
> @@ -201,6 +203,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   struct drm_gem_object *obj;
>   void *buf;
>   int ret;
> + struct dma_buf *dmabuf;
> + uint32_t exp_handle;
>  
>   obj = drm_gem_object_lookup(dev, file_priv, handle);
>   if (!obj)
> @@ -209,41 +213,52 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   mutex_lock(&file_priv->prime.lock);
>   /* re-export the original imported object */
>   if (obj->import_attach) {
> - get_dma_buf(obj->import_attach->dmabuf);
> - *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
> - drm_gem_object_unreference_unlocked(obj);
> - mutex_unlock(&file_priv->prime.lock);
> - return 0;
> + dmabuf = obj->import_attach->dmabuf;
> + goto out_have_obj;
>   }
>  
>   if (obj->export_dma_buf) {
> - get_dma_buf(obj->export_dma_buf);
> - *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
> + dmabuf = obj->export_dma_buf;
> + goto out_have_obj;
> + }
> +
> + buf = dev->driver->gem_prime_export(dev, obj, flags);
> + if (IS_ERR(buf)) {
> + /* normally the created dma-buf takes ownership 

[PATCH v3 1/3] drm: add prime helpers

[Aaron Plattner]

On 04/12/13 07:58, Daniel Vetter wrote:
> On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> terms of new, lower-level hook functions:
>>
>>gem_prime_pin: callback when a buffer is created, used to pin buffers 
>> into GTT
>>gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
>>gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
>>gem_prime_vmap, gem_prime_vunmap: map and unmap an object
>>
>> These hooks are optional; drivers can opt in by using drm_gem_prime_import 
>> and
>> drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
>> struct drm_driver.
>>
>> v2:
>> - Drop .begin_cpu_access.  None of the drivers this code replaces implemented
>>it.  Having it here was a leftover from when I was trying to include i915 
>> in
>>this rework.
>> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
>>did.  This patch series shouldn't change that behavior.
>> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>>Rename struct sg_table* variables to 'sgt' for clarity.
>> - Update drm.tmpl for these new hooks.
>>
>> v3:
>> - Pass the vaddr down to the driver.  This lets drivers that just call 
>> vunmap on
>>the pointer avoid having to store the pointer in their GEM private 
>> structures.
>> - Move documentation into a /** DOC */ comment in drm_prime.c and include it 
>> in
>>drm.tmpl with a !P line.  I tried to use !F lines to include 
>> documentation of
>>the individual functions from drmP.h, but the docproc / kernel-doc scripts
>>barf on that file, so hopefully this is good enough for now.
>> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>>("drm/prime: drop reference on imported dma-buf come from gem")
>>
>> Signed-off-by: Aaron Plattner 
>> Cc: Daniel Vetter 
>> Cc: David Airlie 
>> ---
>>   Documentation/DocBook/drm.tmpl |   4 +
>>   drivers/gpu/drm/drm_prime.c| 186 
>> -
>>   include/drm/drmP.h |  12 +++
>>   3 files changed, 201 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 4ee2304..ed40576 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -743,6 +743,10 @@ char *date;
>> These two operations are mandatory for GEM drivers that support 
>> DRM
>> PRIME.
>>   
>> +
>> +  DRM PRIME Helper Functions Reference
>> +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
>> +
>> 
>> 
>>   GEM Objects Mapping
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 7f12573..366910d 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>> @@ -53,7 +53,8 @@
>>* Self-importing: if userspace is using PRIME as a replacement for flink
>>* then it will get a fd->handle request for a GEM object that it created.
>>* Drivers should detect this situation and return back the gem object
>> - * from the dma-buf private.
>> + * from the dma-buf private.  Prime will do this automatically for drivers 
>> that
>> + * use the drm_gem_prime_{import,export} helpers.
>>*/
>>
>>   struct drm_prime_member {
>> @@ -62,6 +63,137 @@ struct drm_prime_member {
>>uint32_t handle;
>>   };
>>
>> +static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment 
>> *attach,
>> + enum dma_data_direction dir)
>> +{
>> + struct drm_gem_object *obj = attach->dmabuf->priv;
>> + struct sg_table *sgt;
>> +
>> + mutex_lock(&obj->dev->struct_mutex);
>> +
>> + sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
>> +
>> + if (!IS_ERR_OR_NULL(sgt))
>> + dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
>> +
>> + mutex_unlock(&obj->dev->struct_mutex);
>> + return sgt;
>> +}
>> +
>> +static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
>> + struct sg_table *sgt, enum dma_data_direction dir)
>> +{
>> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
>> + sg_free_table(sgt);
>> + kfree(sgt);
>> +}
>> +
>> +static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
>> +{
>> + struct drm_gem_object *obj = dma_buf->priv;
>> +
>> + if (obj->export_dma_buf == dma_buf) {
>> + /* drop the reference on the export fd holds */
>> + obj->export_dma_buf = NULL;
>> + drm_gem_object_unreference_unlocked(obj);
>> + }
>> +}
>> +
>> +static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
>> +{
>> + struct drm_gem_object *obj = dma_buf->priv;
>> + struct drm_device *dev = obj->dev;
>> +
>> + return dev->driver->gem_prime_vmap(obj);
>> +}
>> +

[Bug 56541] New: Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=56541

   Summary: Sony VAIO VPCZ23A4R: Oops or panic on radeon in error
path
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: patrakov at gmail.com
CC: aaron.lu at intel.com
Regression: No


Created an attachment (id=98431)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=98431)
Dmesg from 3.9-rc5

This is a fork of bug #56501 and bug #55611. A separate bug is needed because a
decision was made to limit these two bugs to non-rescanning of the PCI bus.
Feel free, however, to refer to any relevant files (e.g. kernel configs and
DSDT dump) or comments attached to these bugs.

Due to yet another bug (#56531), the kernel fails to assign PCI resources to
the radeon card in the dock station. As you can see from the attached dmesg, it
causes an oops or even a panic in the radeon driver, among other bad things.
Please fix the radeon driver so that it doesn't dereference a kernel NULL
pointer even when given bad PCI resources.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #4 from auxsvr at gmail.com ---
xf86-ati-7.1 fixes this, I apologize for wasting your time. Xorg uses about 1GB
RAM, then returns to normal, and the image is exported as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/5405df63/attachment.html>

[PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

[Bjorn Helgaas]

On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
 wrote:
> radeon currently uses a drm function to get the speed capabilities for
> the bus. However, this is a non-standard method of performing this
> detection and this patch changes it to use the max_bus_speed attribute.
> ---
>  drivers/gpu/drm/radeon/evergreen.c |9 ++---
>  drivers/gpu/drm/radeon/r600.c  |8 +---
>  drivers/gpu/drm/radeon/rv770.c |8 +---
>  3 files changed, 4 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 305a657..3291f62 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
>
>  void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>  {
> -   u32 link_width_cntl, speed_cntl, mask;
> -   int ret;
> +   u32 link_width_cntl, speed_cntl;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
> *rdev)
> if (ASIC_IS_X2(rdev))
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)

For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev->bus->self is NULL on a
root bus.  (I think this is the original problem you tripped over,
Lucas.)

These patches fix that problem.  On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected.  On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).

PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.

That's why I originally suggested skipping the Gen2 stuff if
"max_bus_speed == PCI_SPEED_UNKNOWN".  I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it.  But I'm fine with this being either way.

It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
altogether.  It is exported, but I have no idea of anybody else uses
it.  Maybe it could at least be marked __deprecated now?

I don't know who should take these patches.  They don't touch
drivers/pci, but I'd be happy to push them, given the appropriate ACKs
from DRM and powerpc folks.

Bjorn

> return;
>
> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 0740db3..64b90c0 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct radeon_device 
> *rdev)
>  {
> u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
> u16 link_cntl2;
> -   u32 mask;
> -   int ret;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct radeon_device 
> *rdev)
> if (rdev->family <= CHIP_R600)
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)
> return;
>
> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index d63fe1d..c683c36 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct radeon_device 
> *rdev)
>  {
> u32 link_width_cntl, lanes, speed_cntl, tmp;
> u16 link_cntl2;
> -   u32 mask;
> -   int ret;
>
> if (radeon_pcie_gen2 == 0)
> return;
> @@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct 
> radeon_device *rdev)
> if (ASIC_IS_X2(rdev))
> return;
>
> -   ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
> -   if (ret != 0)
> -   return;
> -
> -   if (!(mask & DRM_PCIE_SPEED_50))
> +   if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)
> return;
>
> DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
> radeon.pcie_gen2=0\n");
> --
> 1.7.4.4
>

[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60503

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Tom Stellard  ---
Fixed in commit c6a86fb5639977f37a1403012669cdee86bbd89f

Thanks for your help with testing!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/bc9f3a9e/attachment.html>

[PATCH v3 1/3] drm: add prime helpers

[Daniel Vetter]

On Fri, Apr 12, 2013 at 5:13 PM, Aaron Plattner  wrote:
>>> @@ -117,6 +249,58 @@ int drm_gem_prime_handle_to_fd(struct drm_device
>>> *dev,
>>>   }
>>>   EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
>>>
>>> +struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
>>> + struct dma_buf *dma_buf)
>>> +{
>>> + struct dma_buf_attachment *attach;
>>> + struct sg_table *sgt;
>>> + struct drm_gem_object *obj;
>>> + int ret;
>>> +
>>> + if (!dev->driver->gem_prime_import_sg_table)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + if (dma_buf->ops == &drm_gem_prime_dmabuf_ops) {
>>
>>
>> This here breaks self-import checks since it smashes all buffers from all
>> drivers using these helpers into one set. Which means e.g. nouveau will
>> happily import a buffer from radoen as it's own. The only reason afaics
>> that shit didn't completely hit the fan is that i915 still has it's own
>> buffer ops, and everyone seems to only care about sharing with i915.
>
>
> Doesn't the (obj->dev == dev) check below guard against that?

Oh dear did I just make a big idiot out of myself ;-) Sorry for the
fuss, you're right.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #48 from Alex Deucher  ---
(In reply to comment #47)
> That works.
> 
> Will any of these four patches land in 3.9 kernel ?

Possibly.  I'm hoping to get hear back from the hw guys early next week to see
if I can get teh existing code to work as it's supposed to.  If not, I'll just
send these patches upstream for now.  If they don't make 3.9 final, they'll
show up via the stable kernel stream.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/f6741a2a/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #49 from Alexandre Demers  ---
Vladimir, do you see a page fault in your dmesg after applying the four
patches? Something that would look like:
[8.727726] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041000 flags=0x0010]
[8.727737] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800042400 flags=0x0010]
[8.727750] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041040 flags=0x0010]
[8.727753] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041080 flags=0x0010]
[8.727756] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041240 flags=0x0010]
[8.727759] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f8000410c0 flags=0x0010]
[8.727762] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041280 flags=0x0010]
[8.727764] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041100 flags=0x0010]
[8.727767] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f8000412c0 flags=0x0010]
[8.727770] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x00f800041140 flags=0x0010]


Alex, is this expected for the workaround?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/4b2408b2/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #50 from Alexandre Demers  ---
Created attachment 77915
  --> https://bugs.freedesktop.org/attachment.cgi?id=77915&action=edit
Page Fault with four patches applied

AMD-Vi -> IO PAGE FAULTS in dmesg when using 3.9-rc6 with the four patches
applied (77705, 77706, 77743, 77808).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/c8ffcaf8/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #51 from Alex Deucher  ---
(In reply to comment #49)
> 
> Alex, is this expected for the workaround?

No.  So it appears turning off the displays doesn't help either :/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/965547a5/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #52 from Vladimir  ---
I don't have these messages, all is quiet here with 3.9-rc5 + 4 patches.

6870

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/1e410817/attachment.html>

[Bug 56541] Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=56541





--- Comment #1 from Alex Deucher   2013-04-12 
23:19:38 ---
Created an attachment (id=98461)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=98461)
Possible fix

This should fix the issue.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #53 from Alexandre Demers  ---
(In reply to comment #51)
> (In reply to comment #49)
> > 
> > Alex, is this expected for the workaround?
> 
> No.  So it appears turning off the displays doesn't help either :/

Well, it does help: the screen switches from GRUB to kernel correctly set
(displaying the console), then the screen flashes for a moment (one white flash
instead of one blue flash when the reported bug happens), comes back to normal
in console (where there is now the AMD-Vi IO PAGE FAULT messages) and continues
to work even after Xorg is started.

A difference between Vladimir and I is we don't have the same video card (6950
over here).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/3b2c0e17/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #54 from Vladimir  ---
Just tested with 6970, still fine, no AMD-Vi messages in dmesg.

I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the
difference between your and mine setups.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130412/669206a5/attachment-0001.html>

[3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries

[Luis Henriques]

On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
> 
> Please consider
> 
>  9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
>   the per-process entries, 2012-08-24
> 
> for application to the 3.4.y tree.

Thanks, I'll queue this for 3.5 kernel as well.

Cheers,
--
Luis

> 
> Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
> The problem is reproducible on
> 
>  * Debian's 3.2.y-based kernel with drm backported from 3.4.37
>  * a Debian kernel close to 3.4.4
>  * a Debian kernel close to 3.5.5
>  * vanilla 3.4.4
> 
> He is not able to reproduce the problem on
> 
>  * Debian's older 3.2.y-based kernels without the 3.4.y drm backport
>  * a Debian kernel close to 3.6.4; various newer kernels
>  * vanilla 3.4.4 + this patch
> 
> The patch was applied upstream during the 3.6-rc4 cycle, so newer
> kernels don't need it.
> 
> http://bugs.debian.org/703468 has details, including a screenshot of
> the boot failure ("unable to handling kernel paging request at
> c9000b7ff000" in i915_gem_init_ppgtt).
> 
> Thoughts welcome, as always.
> 
> Regards,
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries

[Greg KH]

On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
> 
> Please consider
> 
>  9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
>   the per-process entries, 2012-08-24
> 
> for application to the 3.4.y tree.
> 
> Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
> The problem is reproducible on
> 
>  * Debian's 3.2.y-based kernel with drm backported from 3.4.37
>  * a Debian kernel close to 3.4.4
>  * a Debian kernel close to 3.5.5
>  * vanilla 3.4.4
> 
> He is not able to reproduce the problem on
> 
>  * Debian's older 3.2.y-based kernels without the 3.4.y drm backport
>  * a Debian kernel close to 3.6.4; various newer kernels
>  * vanilla 3.4.4 + this patch
> 
> The patch was applied upstream during the 3.6-rc4 cycle, so newer
> kernels don't need it.
> 
> http://bugs.debian.org/703468 has details, including a screenshot of
> the boot failure ("unable to handling kernel paging request at
> c9000b7ff000" in i915_gem_init_ppgtt).

Now applied, thanks.

greg k-h

[RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

[Nishanth Menon]

From: Paul Sokolovsky 

An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.

[nm at ti.com: port forward to 3.9-rc6 and post to dri devel for feedback as 
RFC]
Signed-off-by: Paul Sokolovsky 
---
Paul, Dri devel list,
I picked up this patch from linaro tree:
https://git.linaro.org/gitweb?p=people/asac/android/kernel/lt-ti.git;a=patch;h=719fbc876740cf75e82dd082ae5a00dfcf6fff7a
Discussion thread: 
http://lists.linaro.org/pipermail/linaro-dev/2011-June/thread.html#4874
Seems to me as a valid fix even for upstream perhaps?
Regards,
Nishanth Menon

 include/uapi/drm/drm.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 8d1e2bb..73a99e4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -36,7 +36,7 @@
 #ifndef _DRM_H_
 #define _DRM_H_

-#if defined(__linux__)
+#if defined(__KERNEL__) || defined(__linux__)

 #include 
 #include 
-- 
1.7.9.5

[Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Richard Cochran]

On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
> 
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-nightly):
> 
> https://patchwork.kernel.org/patch/2428971/

Now I can confirm this works fine, with no warnings, errors, or
freezes.

Thanks,
Richard

[3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries

[Jonathan Nieder]

Hi Greg,

Please consider

 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
  the per-process entries, 2012-08-24

for application to the 3.4.y tree.

Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
The problem is reproducible on

 * Debian's 3.2.y-based kernel with drm backported from 3.4.37
 * a Debian kernel close to 3.4.4
 * a Debian kernel close to 3.5.5
 * vanilla 3.4.4

He is not able to reproduce the problem on

 * Debian's older 3.2.y-based kernels without the 3.4.y drm backport
 * a Debian kernel close to 3.6.4; various newer kernels
 * vanilla 3.4.4 + this patch

The patch was applied upstream during the 3.6-rc4 cycle, so newer
kernels don't need it.

http://bugs.debian.org/703468 has details, including a screenshot of
the boot failure ("unable to handling kernel paging request at
c9000b7ff000" in i915_gem_init_ppgtt).

Thoughts welcome, as always.

Regards,
Jonathan