Re: [PATCH 1/3] pci_regs: define LNKSTA2 pcie cap + bits.
Hi, 2012-06-27 09:35 keltezéssel, Dave Airlie írta: From: Dave Airlie We need these for detecting the max link speed for drm drivers. Signed-off-by: Dave Airlie I have reported this in March: http://lists.freedesktop.org/archives/dri-devel/2012-March/019731.html Since then, this motherboard received 3 BIOS upgrades (latest is version 1208) and the system was upgraded to Fedora 17. With kernel 3.5-rc4+ (commit 47b514cd476db2eca066a2ad31501b079d6c9cce) plus this series of patches, the reported problem doesn't appear anymore. lspci reports PCIe gen2 speed for my Radeon HD6570 and gen1 speed for my 3ware 9650SE: [zozo@localhost ~]$ sudo lspci -vvv -s 01:00.0 01:00.0 VGA compatible controller: ATI Technologies Inc NI Turks [AMD Radeon HD 6500] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e193 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >SERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 88 Region 0: Memory at c000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fea2 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fea0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta:Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: feeff00c Data: 419a Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon [zozo@localhost ~]$ sudo lspci -vvv -s 08:00.0 08:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01) Subsystem: 3ware Inc 9650SE SATA-II RAID PCIe Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >SERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d000 (64-bit, prefetchable) [size=32M] Region 2: Memory at fe42 (64-bit, non-prefetchable) [size=4K] Region 4: I/O ports at 9000 [size=256] Expansion ROM at fe40 [disabled] [size=128K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ Address: Data: Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00 DevCap:MaxPayload 512 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsuppor
[PATCH 0/4] drm/exynos: add exceptions to framebuffer module
this patch sets fixes some minor issues to exynos drm framebuffer module. when user sent wrong gem memory type, framebuffer size and so on to driver side, the driver has to check if those data are valid or not properly. Thanks. Inki Dae (4): drm/exynos: fixed a comment to gem size. drm/exynos: add packed_size not aligned in page unit. drm/exynos: check if gem type is valid or not for fb. drm/exynos: check if framebuffer and gem size are valid or not. drivers/gpu/drm/exynos/exynos_drm_fb.c | 86 ++- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 + drivers/gpu/drm/exynos/exynos_drm_gem.h |6 ++- 3 files changed, 91 insertions(+), 3 deletions(-) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/exynos: fixed a comment to gem size.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 14d038b..085b2a5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -63,7 +63,8 @@ struct exynos_drm_gem_buf {
* by user request or at framebuffer creation.
* continuous memory region allocated by user request
* or at framebuffer creation.
- * @size: total memory size to physically non-continuous memory region.
+ * @size: size requested from user, in bytes and this size is aligned
+ * in page unit.
* @flags: indicate memory type to allocated buffer and cache attruibute.
*
* P.S. this object would be transfered to user as kms_bo.handle so
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/exynos: check if gem type is valid or not for fb.
physically non-contiguous memory can't be used for framebuffer yet.
so this patch checks if the gem memory type is valid or not for the
framebuffer.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..6aba1e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -31,6 +31,7 @@
#include "drm_crtc_helper.h"
#include "drm_fb_helper.h"
+#include "exynos_drm.h"
#include "exynos_drm_drv.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
@@ -48,6 +49,22 @@ struct exynos_drm_fb {
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
+static int check_fb_gem_memory_type(struct drm_device *drm_dev,
+ struct exynos_drm_gem_obj *exynos_gem_obj)
+{
+ unsigned int flags;
+
+ flags = exynos_gem_obj->flags;
+
+ /* not support physically non-continuous memory for fb yet. TODO */
+ if (IS_NONCONTIG_BUFFER(flags)) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
{
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
@@ -107,8 +124,17 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_gem_object *obj)
{
struct exynos_drm_fb *exynos_fb;
+ struct exynos_drm_gem_obj *exynos_gem_obj;
int ret;
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+
+ ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
+ if (ret < 0) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ return ERR_PTR(-EINVAL);
+ }
+
exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
if (!exynos_fb) {
DRM_ERROR("failed to allocate exynos drm framebuffer\n");
@@ -155,6 +181,9 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
nr = exynos_drm_format_num_buffers(fb->pixel_format);
for (i = 1; i < nr; i++) {
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ int ret;
+
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
@@ -163,6 +192,15 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+
+ ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
+ if (ret < 0) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ exynos_drm_fb_destroy(fb);
+ return ERR_PTR(ret);
+ }
+
exynos_fb->exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/exynos: add packed_size not aligned in page unit.
this patch adds packed_size variable in exynos_drm_gem_obj struct
and this variable is used to check for valid framebuffer and gem size.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |2 ++
drivers/gpu/drm/exynos/exynos_drm_gem.h |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 411d82b..94e8137 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -345,6 +345,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
{
struct exynos_drm_gem_obj *exynos_gem_obj;
struct exynos_drm_gem_buf *buf;
+ unsigned long packed_size = size;
int ret;
if (!size) {
@@ -369,6 +370,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
goto err_fini_buf;
}
+ exynos_gem_obj->packed_size = packed_size;
exynos_gem_obj->buffer = buf;
/* set memory type and cache attribute from user side. */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 085b2a5..1d80cb2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -65,6 +65,8 @@ struct exynos_drm_gem_buf {
* or at framebuffer creation.
* @size: size requested from user, in bytes and this size is aligned
* in page unit.
+ * @packed_size: real size of the gem object, in bytes and
+ * this size isn't aligned in page unit.
* @flags: indicate memory type to allocated buffer and cache attruibute.
*
* P.S. this object would be transfered to user as kms_bo.handle so
@@ -74,6 +76,7 @@ struct exynos_drm_gem_obj {
struct drm_gem_object base;
struct exynos_drm_gem_buf *buffer;
unsigned long size;
+ unsigned long packed_size;
unsigned intflags;
};
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/exynos: check if framebuffer and gem size are valid or not.
with addfb request by user, wrong framebuffer or gem size could be sent
to kernel side so this could induce invalid memory access by dma of a device.
this patch checks if framebuffer and gem size are valid or not to avoid
this issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 48 ++-
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 6aba1e5..ce0f18d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -65,6 +65,45 @@ static int check_fb_gem_memory_type(struct drm_device
*drm_dev,
return 0;
}
+static int check_fb_gem_size(struct drm_device *drm_dev,
+ struct drm_framebuffer *fb,
+ unsigned int nr)
+{
+ unsigned long fb_size;
+ struct drm_gem_object *obj;
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
+
+ /* in case of RGB format, only one plane is used. */
+ if (nr < 2) {
+ exynos_gem_obj = exynos_fb->exynos_gem_obj[0];
+ obj = &exynos_gem_obj->base;
+ fb_size = fb->width * ((fb->bits_per_pixel + 7) >> 3)
+ * fb->height;
+
+ if (fb_size != exynos_gem_obj->packed_size) {
+ DRM_ERROR("invalid fb or gem size.\n");
+ return -EINVAL;
+ }
+ /* in case of NV12MT, YUV420M and so on, two and three planes. */
+ } else {
+ unsigned int i;
+
+ for (i = 0; i < nr; i++) {
+ exynos_gem_obj = exynos_fb->exynos_gem_obj[i];
+ obj = &exynos_gem_obj->base;
+ fb_size = fb->pitches[i] * fb->height;
+
+ if (fb_size != exynos_gem_obj->packed_size) {
+ DRM_ERROR("invalid fb or gem size.\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+
static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
{
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
@@ -160,8 +199,7 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
- int i;
+ int nr, i, ret;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -204,6 +242,12 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
exynos_fb->exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}
+ ret = check_fb_gem_size(dev, fb, nr);
+ if (ret < 0) {
+ exynos_drm_fb_destroy(fb);
+ return ERR_PTR(ret);
+ }
+
return fb;
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lf_driver_backport] [ANN] compat-drm tree
> Given that the compat module is shared, and a quite a bit of other > code / style is shared, and I'd love to see us start to formalize > documenting collateral evolutions on the kernel in one place I'd like > to propose to you merging this into compat-wirless and we then rename > the project to compat-drivers, with you maintaining the drm > components. This also gives us an already established quick outlet for > redistribution as well. What do you think? Okay, this makes sense. > > Some comments: > > In the patches/ directory if you can add a description on the top of > each patch explaining *why* that collateral evolution was not > backportable through compat it would help. It sets the standard for > others introducing similar types of patches. Ah I forgot about this :) > > For patches/00-vga_switcheroo_client_ops.patch: > > I wonder if you may be able to get rid of this patch. The attached > patch is an RFC patch for compat.git which explains how I'm thinking > this may be possible, I don't have time to test it but let me know > what you think. Okay will test and try to drop the patch as well. Thanks :) -- Ozan Çağlayan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: drm/omap: add rotation properties
On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: > From: Rob Clark > > Use tiled buffers for rotated/reflected scanout, with CRTC and plane > properties as the interface for userspace to configure rotation. > > Signed-off-by: Rob Clark > +/* this should probably be in drm-core to standardize amongst drivers */ > +#define DRM_ROTATE_0 0 > +#define DRM_ROTATE_901 > +#define DRM_ROTATE_180 2 > +#define DRM_ROTATE_270 3 > +#define DRM_REFLECT_X4 > +#define DRM_REFLECT_Y5 Are both reflect X and Y needed? You can get all the possible orientations with just one of the reflects. And I think the word "mirror" represents nicely what the reflect does, i.e. if you look at the mirror, the image you see is flipped horizontally. Tomi signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: drm/omap: add rotation properties
On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen wrote: > On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: >> From: Rob Clark >> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane >> properties as the interface for userspace to configure rotation. >> >> Signed-off-by: Rob Clark > >> +/* this should probably be in drm-core to standardize amongst drivers */ >> +#define DRM_ROTATE_0 0 >> +#define DRM_ROTATE_90 1 >> +#define DRM_ROTATE_180 2 >> +#define DRM_ROTATE_270 3 >> +#define DRM_REFLECT_X 4 >> +#define DRM_REFLECT_Y 5 > > Are both reflect X and Y needed? You can get all the possible > orientations with just one of the reflects. > > And I think the word "mirror" represents nicely what the reflect does, > i.e. if you look at the mirror, the image you see is flipped > horizontally. fwiw these values are aligned with what is used in userspace xrandr.. an earlier version of this patch used just 3 bits, which where aligned with what the omap hw uses and can describe all possible combinations of mirroring and isomorphic rotation (x-invert, y-invert, and xy-flip). But the advantage of the xrandr approach is you can more easily leave out bits for rotation/mirroring modes that your hw does not support.. for example if some hw supports only certain rotations or does not support mirror/reflect. BR, -R > Tomi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51557] New: Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51557 Bug #: 51557 Summary: Ubuntu[12.04]: X server crashes on running any command in xterm window Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created attachment 63606 --> https://bugs.freedesktop.org/attachment.cgi?id=63606 Xorg.log Driver Stack Details: = 1)Kernel-3.4.0-030400-generic-pae 2)drm-2.4.35 3)Mesa-8.1-devel (git-93a42d1) 4)Xorg-server-1.11.3 5)xf86-video-ati- master System Environment: === Asic : RV635XT O.S. : Ubuntu-12.04 (32 bit) Processor: Intel(R) Xeon(R) @ 2.40 GHz Memory : 2 GB #startx #open a Terminal and run any command Xserver crashes. Backtarce is in Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] New: Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Bug #: 51558 Summary: Ubuntu[12.04]: X server crashes on running any command in xterm window Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created attachment 63607 --> https://bugs.freedesktop.org/attachment.cgi?id=63607 Xorg.log Driver Stack Details: = 1)Kernel-3.4.0-030400-generic-pae 2)drm-2.4.35 3)Mesa-8.1-devel (git-93a42d1) 4)Xorg-server-1.11.3 5)xf86-video-ati- master System Environment: === Asic : RV635XT O.S. : Ubuntu-12.04 (32 bit) Processor: Intel(R) Xeon(R) @ 2.40 GHz Memory : 2 GB #startx #open a Terminal and run any command Xserver crashes. Backtarce is in Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #1 from samit vats 2012-06-29 05:27:59 PDT --- Created attachment 63608 --> https://bugs.freedesktop.org/attachment.cgi?id=63608 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #2 from samit vats 2012-06-29 05:28:30 PDT --- Created attachment 63609 --> https://bugs.freedesktop.org/attachment.cgi?id=63609 xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51557] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51557 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michel Dänzer 2012-06-29 06:18:33 PDT --- *** This bug has been marked as a duplicate of bug 51558 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #3 from Michel Dänzer 2012-06-29 06:18:33 PDT --- *** Bug 51557 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Michel Dänzer changed: What|Removed |Added Attachment #63607|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Michel Dänzer 2012-06-29 06:26:18 PDT --- [ 2910.364] (II) LoadModule: "mouse" [ 2910.364] (II) Loading /root/install/lib/xorg/modules/input/mouse_drv.so [ 2910.364] (II) Module mouse: vendor="X.Org Foundation" [ 2910.364] compiled for 1.11.3, module version = 1.7.1 [ 2910.364] Module class: X.Org XInput Driver [ 2910.364] ABI class: X.Org XInput driver, version 16.0 [ 2910.364] (WW) module ABI major version (16) doesn't match the server's version (13) [ 2910.366] (II) LoadModule: "kbd" [ 2910.366] (II) Loading /root/install/lib/xorg/modules/input/kbd_drv.so [ 2910.366] (II) Module kbd: vendor="X.Org Foundation" [ 2910.366] compiled for 1.11.3, module version = 1.6.1 [ 2910.366] Module class: X.Org XInput Driver [ 2910.366] ABI class: X.Org XInput driver, version 16.0 [ 2910.366] (WW) module ABI major version (16) doesn't match the server's version (13) Looks like the X mouse/kbd drivers were built / installed incorrectly. BTW, it's recommended to use the evdev driver for input instead of these two drivers on Linux. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Tegra DRM device tree bindings
On 28.06.2012 20:19, Lucas Stach wrote: > TTM though solves more advanced matters, like buffer synchronisation > between 3D and 2D block of hardware or syncing buffer access between GPU > and CPU. > One of the most interesting things of TTM is the ability to purge the > GPU DMA buffers to scattered sysmem or even swap them out, if they are > not currently used by the GPU. It then makes sure to move them in the > contig space again when the GPU really needs them and fix up the GPU > command stream with the new buffer address. We preferably should choose dma_buf as a common interface towards buffers. That way whatever we choose as the memory manager, all dma_buf aware drivers will be able to use buffers allocated by other drivers. We probably need to accommodate multiple memory managers to take care of legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we have the possibility to do zero-copy video without forcing everybody to use the same memory manager. As I understand, TTM is good for platforms where we have a separate frame buffer memory, as is the case with most of the graphics cards. In Tegra, graphics and CPU occupy the same memory, so I'm not sure if we require the level of functionality that TTM provides. I guess the level of functionality and the complexity that it brings is one reason why TTM hasn't really caught on in the ARM world. The synchronization primitives attached to TTM are slightly confusing. At the bottom level, it's operations which need to be synchronized between each other. That's the API level that we should to export from kernel to user space. It's then up to libdrm level (or whatever is doing the rendering in user space) to decide which operations it wants to have completed before a buffer can be reused/read/passed on to the next stage. Anyway, if we hide the memory manager behind dma_buf, we're free to muck around with multiple of them and see what works best. Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] Start documenting the radeon drm better
From: Alex Deucher This is something I've been wanting to do for a while and I finally spent a little time getting a start on it. There is still a lot to do and not all of my descriptions are great, but I think we can document the rest in bits and pieces. I also added a note about what asics the function is applicable to. I tried to start with the more common and complex code. I was thinking it would make sense to have an informal documentation policy something like the following: 1. If you edit an undocumented function, add documentation 2. If you edit a documented function and change how it works, update the documentation 3. All new functions added should be documented Fulfulling all of these for stable fixes could pose problems so obviously there is some leeway. Thoughts? Alex Deucher (10): drm/radeon: document radeon_device.c drm/radeon: document radeon_kms.c drm/radeon: document radeon_irq_kms.c drm/radeon: document radeon_asic.c drm/radeon: document radeon_fence.c drm/radeon: document radeon_ring.c drm/radeon: document non-VM functions in radeon_gart.c drm/radeon: document VM functions in radeon_gart.c drm/radeon: start to document the functions r100.c drm/radeon: start to document evergreen.c drivers/gpu/drm/radeon/evergreen.c | 120 ++ drivers/gpu/drm/radeon/r100.c | 127 ++- drivers/gpu/drm/radeon/radeon_asic.c| 46 drivers/gpu/drm/radeon/radeon_device.c | 344 +++- drivers/gpu/drm/radeon/radeon_fence.c | 373 + drivers/gpu/drm/radeon/radeon_gart.c| 391 ++- drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ drivers/gpu/drm/radeon/radeon_ring.c| 374 +- 9 files changed, 2041 insertions(+), 10 deletions(-) -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/10] drm/radeon: document radeon_device.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_device.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_device.c | 344 +++-
1 files changed, 341 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index f654ba8..4cce4f4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -96,8 +96,12 @@ static const char radeon_family_name[][16] = {
"LAST",
};
-/*
- * Clear GPU surface registers.
+/**
+ * radeon_surface_init - Clear GPU surface registers.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clear GPU surface registers (r1xx-r5xx).
*/
void radeon_surface_init(struct radeon_device *rdev)
{
@@ -119,6 +123,13 @@ void radeon_surface_init(struct radeon_device *rdev)
/*
* GPU scratch registers helpers function.
*/
+/**
+ * radeon_scratch_init - Init scratch register driver information.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init CP scratch register driver information (r1xx-r5xx)
+ */
void radeon_scratch_init(struct radeon_device *rdev)
{
int i;
@@ -136,6 +147,15 @@ void radeon_scratch_init(struct radeon_device *rdev)
}
}
+/**
+ * radeon_scratch_get - Allocate a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Allocate a CP scratch register for use by the driver (all asics).
+ * Returns 0 on success or -EINVAL on failure.
+ */
int radeon_scratch_get(struct radeon_device *rdev, uint32_t *reg)
{
int i;
@@ -150,6 +170,14 @@ int radeon_scratch_get(struct radeon_device *rdev,
uint32_t *reg)
return -EINVAL;
}
+/**
+ * radeon_scratch_free - Free a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Free a CP scratch register allocated for use by the driver (all asics)
+ */
void radeon_scratch_free(struct radeon_device *rdev, uint32_t reg)
{
int i;
@@ -162,6 +190,16 @@ void radeon_scratch_free(struct radeon_device *rdev,
uint32_t reg)
}
}
+/**
+ * radeon_wb_disable - Disable Writeback
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback (all asics). Used for suspend.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
void radeon_wb_disable(struct radeon_device *rdev)
{
int r;
@@ -177,6 +215,17 @@ void radeon_wb_disable(struct radeon_device *rdev)
rdev->wb.enabled = false;
}
+/**
+ * radeon_wb_fini - Disable Writeback and free memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver shutdown.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
void radeon_wb_fini(struct radeon_device *rdev)
{
radeon_wb_disable(rdev);
@@ -187,6 +236,18 @@ void radeon_wb_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_wb_init- Init Writeback driver info and allocate memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver startup.
+ * Returns 0 on success or an -error on failure.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
int radeon_wb_init(struct radeon_device *rdev)
{
int r;
@@ -355,6 +416,15 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
/*
* GPU helpers function.
*/
+/**
+ * radeon_card_posted - check if the hw has already been initialized
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic has been initialized (all asics).
+ * Used at driver startup.
+ * Returns true if initialized or false if not.
+ */
bool radeon_card_posted(struct radeon_device *rdev)
{
uint32_t reg;
@@ -404,6 +474,14 @@ bool radeon_card_posted(struct radeon_device *rdev)
}
+/**
+ * radeon_update_bandwidth_info - update display bandwidth params
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Used when sclk/mclk are switched or display modes are set.
+ * params are used to calculate display watermarks (all asics)
+ */
void radeon_update_bandwidth_info(struct radeon_device *rdev)
{
fixed20_12 a;
@@ -424,6 +502,15 @@ void radeon_update_bandwidth_info(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_boot_test_post_card - check and possibly initialize the hw
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic is initialized and if not, attempt to initialize
+ * it (all asics).
+ * Returns true if initialized or false if not.
+ */
bool radeon_boot_test_post_card(struct radeon_device *rdev)
{
if (radeon_card_posted(rdev))
@@ -442,6 +5
[PATCH 02/10] drm/radeon: document radeon_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 126 +++
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 18b81d6..1d73f16 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -33,6 +33,17 @@
#include
#include
+/**
+ * radeon_driver_unload_kms - Main unload function for KMS.
+ *
+ * @dev: drm dev pointer
+ *
+ * This is the main unload function for KMS (all asics).
+ * It calls radeon_modeset_fini() to tear down the
+ * displays, and radeon_device_fini() to tear down
+ * the rest of the device (CP, writeback, etc.).
+ * Returns 0 on success.
+ */
int radeon_driver_unload_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -46,6 +57,19 @@ int radeon_driver_unload_kms(struct drm_device *dev)
return 0;
}
+/**
+ * radeon_driver_load_kms - Main load function for KMS.
+ *
+ * @dev: drm dev pointer
+ * @flags: device flags
+ *
+ * This is the main load function for KMS (all asics).
+ * It calls radeon_device_init() to set up the non-display
+ * parts of the chip (asic init, CP, writeback, etc.), and
+ * radeon_modeset_init() to set up the display parts
+ * (crtcs, encoders, hotplug detect, etc.).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags)
{
struct radeon_device *rdev;
@@ -96,6 +120,16 @@ out:
return r;
}
+/**
+ * radeon_set_filp_rights - Set filp right.
+ *
+ * @dev: drm dev pointer
+ * @owner: drm file
+ * @applier: drm file
+ * @value: value
+ *
+ * Sets the filp rights for the device (all asics).
+ */
static void radeon_set_filp_rights(struct drm_device *dev,
struct drm_file **owner,
struct drm_file *applier,
@@ -118,6 +152,18 @@ static void radeon_set_filp_rights(struct drm_device *dev,
/*
* Userspace get information ioctl
*/
+/**
+ * radeon_info_ioctl - answer a device specific request.
+ *
+ * @rdev: radeon device pointer
+ * @data: request object
+ * @filp: drm filp
+ *
+ * This function is used to pass device specific parameters to the userspace
+ * drivers. Examples include: pci device id, pipeline parms, tiling params,
+ * etc. (all asics).
+ * Returns 0 on success, -EINVAL on failure.
+ */
int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp)
{
struct radeon_device *rdev = dev->dev_private;
@@ -301,16 +347,40 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
/*
* Outdated mess for old drm with Xorg being in charge (void function now).
*/
+/**
+ * radeon_driver_firstopen_kms - drm callback for first open
+ *
+ * @dev: drm dev pointer
+ *
+ * Nothing to be done for KMS (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_firstopen_kms(struct drm_device *dev)
{
return 0;
}
+/**
+ * radeon_driver_firstopen_kms - drm callback for last close
+ *
+ * @dev: drm dev pointer
+ *
+ * Switch vga switcheroo state after last close (all asics).
+ */
void radeon_driver_lastclose_kms(struct drm_device *dev)
{
vga_switcheroo_process_delayed_switch();
}
+/**
+ * radeon_driver_open_kms - drm callback for open
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device open, init vm on cayman+ (all asics).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
{
struct radeon_device *rdev = dev->dev_private;
@@ -339,6 +409,14 @@ int radeon_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
return 0;
}
+/**
+ * radeon_driver_postclose_kms - drm callback for post close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device post close, tear down vm on cayman+ (all asics).
+ */
void radeon_driver_postclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -354,6 +432,15 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
}
}
+/**
+ * radeon_driver_preclose_kms - drm callback for pre close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device pre close, tear down hyperz and cmask filps on r1xx-r5xx
+ * (all asics).
+ */
void radeon_driver_preclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -367,6 +454,15 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
/*
* VBlank related functions.
*/
+/**
+ * radeon_get_vblank_counter_kms - get frame count
+ *
+ * @dev: drm dev pointer
+ * @crtc: crtc to get the frame count from
+ *
+ * Gets the frame count on the requested crtc (all asics).
+ * Returns frame count on success, -EINVAL on failure
[PATCH 03/10] drm/radeon: document radeon_irq_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_irq_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 +++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 6664514..afaa172 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -34,6 +34,15 @@
#define RADEON_WAIT_IDLE_TIMEOUT 200
+/**
+ * radeon_driver_irq_handler_kms - irq handler for KMS
+ *
+ * @DRM_IRQ_ARGS: args
+ *
+ * This is the irq handler for the radeon KMS driver (all asics).
+ * radeon_irq_process is a macro that points to the per-asic
+ * irq handler callback.
+ */
irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
@@ -45,6 +54,17 @@ irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
/*
* Handle hotplug events outside the interrupt handler proper.
*/
+/**
+ * radeon_hotplug_work_func - display hotplug work handler
+ *
+ * @work: work struct
+ *
+ * This is the hot plug event work handler (all asics).
+ * The work gets scheduled from the irq handler if there
+ * was a hot plug interrupt. It walks the connector table
+ * and calls the hotplug handler for each one, then sends
+ * a drm hotplug event to alert userspace.
+ */
static void radeon_hotplug_work_func(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
@@ -61,6 +81,14 @@ static void radeon_hotplug_work_func(struct work_struct
*work)
drm_helper_hpd_irq_event(dev);
}
+/**
+ * radeon_driver_irq_preinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Gets the hw ready to enable irqs (all asics).
+ * This function disables all interrupt sources on the GPU.
+ */
void radeon_driver_irq_preinstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -85,12 +113,27 @@ void radeon_driver_irq_preinstall_kms(struct drm_device
*dev)
radeon_irq_process(rdev);
}
+/**
+ * radeon_driver_irq_postinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Handles stuff to be done after enabling irqs (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_irq_postinstall_kms(struct drm_device *dev)
{
dev->max_vblank_count = 0x001f;
return 0;
}
+/**
+ * radeon_driver_irq_uninstall_kms - drm irq uninstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * This function disables all interrupt sources on the GPU (all asics).
+ */
void radeon_driver_irq_uninstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -116,6 +159,16 @@ void radeon_driver_irq_uninstall_kms(struct drm_device
*dev)
spin_unlock_irqrestore(&rdev->irq.lock, irqflags);
}
+/**
+ * radeon_msi_ok - asic specific msi checks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Handles asic specific MSI checks to determine if
+ * MSIs should be enabled on a particular chip (all asics).
+ * Returns true if MSIs should be enabled, false if MSIs
+ * should not be enabled.
+ */
static bool radeon_msi_ok(struct radeon_device *rdev)
{
/* RV370/RV380 was first asic with MSI support */
@@ -168,6 +221,14 @@ static bool radeon_msi_ok(struct radeon_device *rdev)
return true;
}
+/**
+ * radeon_irq_kms_init - init driver interrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the work irq handlers, vblank init, MSIs, etc. (all asics).
+ * Returns 0 for success, error for failure.
+ */
int radeon_irq_kms_init(struct radeon_device *rdev)
{
int r = 0;
@@ -200,6 +261,13 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_irq_kms_fini - tear down driver interrrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Tears down the work irq handlers, vblank handlers, MSIs, etc. (all asics).
+ */
void radeon_irq_kms_fini(struct radeon_device *rdev)
{
drm_vblank_cleanup(rdev->ddev);
@@ -212,6 +280,16 @@ void radeon_irq_kms_fini(struct radeon_device *rdev)
flush_work_sync(&rdev->hotplug_work);
}
+/**
+ * radeon_irq_kms_sw_irq_get - enable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to enable
+ *
+ * Enables the software interrupt for a specific ring (all asics).
+ * The software interrupt is generally used to signal a fence on
+ * a particular ring.
+ */
void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring)
{
unsigned long irqflags;
@@ -226,6 +304,16 @@ void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev,
int ring)
}
}
+/**
+ * radeon_irq_kms_sw_irq_put - disable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to disable
+ *
+ * Disables the software interrupt for a speci
[PATCH 04/10] drm/radeon: document radeon_asic.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_asic.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index f533df5..973417c 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -40,6 +40,16 @@
/*
* Registers accessors functions.
*/
+/**
+ * radeon_invalid_rreg - dummy reg read function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ * Returns the value in the register.
+ */
static uint32_t radeon_invalid_rreg(struct radeon_device *rdev, uint32_t reg)
{
DRM_ERROR("Invalid callback to read register 0x%04X\n", reg);
@@ -47,6 +57,16 @@ static uint32_t radeon_invalid_rreg(struct radeon_device
*rdev, uint32_t reg)
return 0;
}
+/**
+ * radeon_invalid_wreg - dummy reg write function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ * @v: value to write to the register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ */
static void radeon_invalid_wreg(struct radeon_device *rdev, uint32_t reg,
uint32_t v)
{
DRM_ERROR("Invalid callback to write register 0x%04X with 0x%08X\n",
@@ -54,6 +74,14 @@ static void radeon_invalid_wreg(struct radeon_device *rdev,
uint32_t reg, uint32
BUG_ON(1);
}
+/**
+ * radeon_register_accessor_init - sets up the register accessor callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the register accessor callbacks for various register
+ * apertures. Not all asics have all apertures (all asics).
+ */
static void radeon_register_accessor_init(struct radeon_device *rdev)
{
rdev->mc_rreg = &radeon_invalid_rreg;
@@ -102,6 +130,14 @@ static void radeon_register_accessor_init(struct
radeon_device *rdev)
/* helper to disable agp */
+/**
+ * radeon_agp_disable - AGP disable helper function
+ *
+ * @rdev: radeon device pointer
+ *
+ * Removes AGP flags and changes the gart callbacks on AGP
+ * cards when using the internal gart rather than AGP (all asics).
+ */
void radeon_agp_disable(struct radeon_device *rdev)
{
rdev->flags &= ~RADEON_IS_AGP;
@@ -1608,6 +1644,16 @@ static struct radeon_asic si_asic = {
},
};
+/**
+ * radeon_asic_init - register asic specific callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Registers the appropriate asic specific callbacks for each
+ * chip family. Also sets other asics specific info like the number
+ * of crtcs and the register aperture accessors (all asics).
+ * Returns 0 for success.
+ */
int radeon_asic_init(struct radeon_device *rdev)
{
radeon_register_accessor_init(rdev);
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] drm/radeon: document radeon_fence.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_fence.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c | 373 +
1 files changed, 373 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 67f6fa9..604352e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -40,6 +40,22 @@
#include "radeon.h"
#include "radeon_trace.h"
+/**
+ * radeon_fence_write - write a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @seq: sequence number to write
+ * @ring: ring index the fence is associated with
+ *
+ * Writes a fence value to memory or a scratch register (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static void radeon_fence_write(struct radeon_device *rdev, u32 seq, int ring)
{
if (rdev->wb.enabled) {
@@ -49,6 +65,22 @@ static void radeon_fence_write(struct radeon_device *rdev,
u32 seq, int ring)
}
}
+/**
+ * radeon_fence_read - read a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Reads a fence value from memory or a scratch register (all asics).
+ * Returns the value of the fence read from memory or register.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static u32 radeon_fence_read(struct radeon_device *rdev, int ring)
{
u32 seq = 0;
@@ -61,6 +93,23 @@ static u32 radeon_fence_read(struct radeon_device *rdev, int
ring)
return seq;
}
+/**
+ * radeon_fence_emit - emit a fence on the requested ring
+ *
+ * @rdev: radeon_device pointer
+ * @fence: radeon fence object
+ * @ring: ring index the fence is associated with
+ *
+ * Emits a fence command on the requested ring (all asics).
+ * Returns 0 on success, -ENOMEM on failure.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
@@ -79,6 +128,22 @@ int radeon_fence_emit(struct radeon_device *rdev,
return 0;
}
+/**
+ * radeon_fence_process - process a fence
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Checks the current fence value and wakes the fence queue
+ * if the sequence number has increased (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
void radeon_fence_process(struct radeon_device *rdev, int ring)
{
uint64_t seq, last_seq;
@@ -139,6 +204,20 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
}
+/**
+ * radeon_fence_destroy - destroy a fence
+ *
+ * @kref: fence kref
+ *
+ * Frees the fence object (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static void radeon_fence_destroy(struct kref *kref)
{
struct radeon_fence *fence;
@@ -147,6 +226,27 @@ static void radeon_fence_destroy(struct kref *kref)
kfree(fence);
}
+/**
+ * radeon_fence_seq_signaled - check if a fence sequeuce number has signaled
+ *
+ * @rdev: radeon device p
[PATCH 06/10] drm/radeon: document radeon_ring.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_ring.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 374 +-
1 files changed, 373 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 0826e77..2a0febf 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -39,6 +39,24 @@
*/
int radeon_debugfs_sa_init(struct radeon_device *rdev);
+/**
+ * radeon_ib_get - request an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the IB is associated with
+ * @ib: IB object returned
+ * @size: requested IB size
+ *
+ * Request an IB (all asics). IBs are allocated using the
+ * suballocator.
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_get(struct radeon_device *rdev, int ring,
struct radeon_ib *ib, unsigned size)
{
@@ -67,6 +85,20 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
return 0;
}
+/**
+ * radeon_ib_free - free an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to free
+ *
+ * Free an IB (all asics).
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib)
{
radeon_semaphore_free(rdev, &ib->semaphore, ib->fence);
@@ -74,6 +106,21 @@ void radeon_ib_free(struct radeon_device *rdev, struct
radeon_ib *ib)
radeon_fence_unref(&ib->fence);
}
+/**
+ * radeon_ib_schedule - schedule an IB (Indirect Buffer) on the ring
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to schedule
+ *
+ * Schedule an IB on the associated ring (all asics).
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib)
{
struct radeon_ring *ring = &rdev->ring[ib->ring];
@@ -116,6 +163,21 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib)
return 0;
}
+/**
+ * radeon_ib_pool_init - Init the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the suballocator to manage a pool of memory
+ * for use as IBs (all asics).
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_pool_init(struct radeon_device *rdev)
{
int r;
@@ -136,6 +198,20 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_ib_pool_fini - Free the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the suballocator managing the pool of memory
+ * for use as IBs (all asics).
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
void radeon_ib_pool_fini(struct radeon_device *rdev)
{
if (rdev->ib_pool_ready) {
@@ -144,16 +220,64 @@ void radeon_ib_pool_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_ib_pool_start - Start the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator that manages pool of memory
+ * used for IBs (all asics). Used to start the IB pool on
+ * device startup and resume.
+ * Returns 0 on success, error on failure.
+ * IBs (Indirec
[PATCH 07/10] drm/radeon: document non-VM functions in radeon_gart.c
From: Alex Deucher
Document the non-VM functions in radeon_gart.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 154 +-
1 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8c44d1d..d9e29d5 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -33,6 +33,20 @@
/*
* Common GART table functions.
*/
+/**
+ * radeon_gart_table_ram_alloc - allocate system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400).
+ * Returns 0 for success, -ENOMEM for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
{
void *ptr;
@@ -54,6 +68,19 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_ram_free - free system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_ram_free(struct radeon_device *rdev)
{
if (rdev->gart.ptr == NULL) {
@@ -73,6 +100,20 @@ void radeon_gart_table_ram_free(struct radeon_device *rdev)
rdev->gart.table_addr = 0;
}
+/**
+ * radeon_gart_table_vram_alloc - allocate vram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate video memory for GART page table
+ * (pcie r4xx, r5xx+).
+ * Returns 0 for success, error for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
{
int r;
@@ -88,6 +129,20 @@ int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_vram_pin - pin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Pin the GART page table in vram so it will not be moved
+ * by the memory manager (pcie r4xx, r5xx+).
+ * Returns 0 for success, error for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_vram_pin(struct radeon_device *rdev)
{
uint64_t gpu_addr;
@@ -110,6 +165,18 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
return r;
}
+/**
+ * radeon_gart_table_vram_unpin - unpin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unpin the GART page table in vram (pcie r4xx, r5xx+).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_vram_unpin(struct radeon_device *rdev)
{
int r;
@@ -126,6 +193,19 @@ void radeon_gart_table_vram_unpin(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_gart_table_vram_free - free gart page table vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free the video memory used for the GART page table
+ * (pcie r4xx, r5xx+).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_vram_free(struct radeon_device *rdev)
{
if (rdev->gart.robj == NULL) {
@@ -135,12 +215,24 @@ void radeon_gart_table_vram_free(struct radeon_device
*rdev)
radeon_bo_unref(&rdev->gart.robj);
}
-
-
-
/*
* Common gart functions.
*/
+/**
+ * radeon_gart_unbind - unbind pages from the gart page table
+ *
+ * @rdev: radeon_device pointer
+
[PATCH 09/10] drm/radeon: start to document the functions r100.c
From: Alex Deucher
Still a lot more to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 127 -
1 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index d06c8dd..84477dc 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -65,6 +65,19 @@ MODULE_FIRMWARE(FIRMWARE_R520);
#include "r100_track.h"
+/* This files gather functions specifics to:
+ * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+ * and others in some cases.
+ */
+
+/**
+ * r100_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (r1xx-r4xx).
+ */
void r100_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -99,22 +112,49 @@ void r100_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
-/* This files gather functions specifics to:
- * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+/**
+ * r100_pre_page_flip - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (r1xx-r4xx).
+ * Enables the pageflip irq (vblank irq).
*/
-
void r100_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * r100_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (r1xx-r4xx).
+ * Disables the pageflip irq (vblank irq).
+ */
void r100_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * r100_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (r1xx-r4xx).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 r100_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -141,6 +181,15 @@ u32 r100_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base)
return RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) &
RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET;
}
+/**
+ * r100_pm_get_dynpm_state - look up dynpm power state callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Look up the optimal power state based on the
+ * current state of the GPU (r1xx-r5xx).
+ * Used for dynpm only.
+ */
void r100_pm_get_dynpm_state(struct radeon_device *rdev)
{
int i;
@@ -223,6 +272,15 @@ void r100_pm_get_dynpm_state(struct radeon_device *rdev)
pcie_lanes);
}
+/**
+ * r100_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (r1xx-r3xx).
+ * Used for profile mode only.
+ */
void r100_pm_init_profile(struct radeon_device *rdev)
{
/* default */
@@ -262,6 +320,14 @@ void r100_pm_init_profile(struct radeon_device *rdev)
rdev->pm.profiles[PM_PROFILE_HIGH_MH_IDX].dpms_on_cm_idx = 0;
}
+/**
+ * r100_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, pcie lanes, etc.) (r1xx-r4xx).
+ */
void r100_pm_misc(struct radeon_device *rdev)
{
int requested_index = rdev->pm.requested_power_state_index;
@@ -353,6 +419,13 @@ void r100_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (r1xx-r4xx).
+ */
void r100_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -377,6 +450,13 @@ void r100_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (r1xx-r4xx).
+ */
void r100_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -401,6 +481,14 @@ void r100_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * r100_gui_idle - gui idle callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check of the GUI (2D/3D engines) are idle (r1xx-r5xx).
+ * Returns true if idle, false if not.
+ */
bool r100_gui_idle(struct radeon_device *rdev)
{
if (RREG32(RADEON_RBBM_STATUS) & RADEON_RBBM_ACT
[PATCH 08/10] drm/radeon: document VM functions in radeon_gart.c
From: Alex Deucher
Document the VM functions in radeon_gart.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 237 ++
1 files changed, 237 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index d9e29d5..c37b501 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -430,6 +430,21 @@ void radeon_gart_fini(struct radeon_device *rdev)
*
* TODO bind a default page at vm initialization for default address
*/
+/**
+ * radeon_vm_manager_init - init the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init the vm manager (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_init(struct radeon_device *rdev)
{
int r;
@@ -455,6 +470,23 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
}
/* global mutex must be lock */
+/**
+ * radeon_vm_unbind_locked - unbind a specific vm
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Unbind the requested vm (cayman+).
+ * Wait for use of the VM to finish, then unbind the page table,
+ * and free the page table memory.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
static void radeon_vm_unbind_locked(struct radeon_device *rdev,
struct radeon_vm *vm)
{
@@ -483,6 +515,20 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
}
}
+/**
+ * radeon_vm_manager_fini - tear down the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the VM manager (cayman+).
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
void radeon_vm_manager_fini(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL)
@@ -493,6 +539,21 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
rdev->vm_manager.enabled = false;
}
+/**
+ * radeon_vm_manager_start - start the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_start(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL) {
@@ -501,6 +562,22 @@ int radeon_vm_manager_start(struct radeon_device *rdev)
return radeon_sa_bo_manager_start(rdev, &rdev->vm_manager.sa_manager);
}
+/**
+ * radeon_vm_manager_suspend - suspend the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unbind all the VM page tables and suspend the suballocator
+ * instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_suspend(struct radeon_device *rdev)
{
struct radeon_vm *vm, *tmp;
@@ -516,6 +593,21 @@ int radeon_vm_manager_suspend(struct radeon_device *rdev)
}
/* global mutex must be locked */
+/**
+ * radeon_vm_unbind - locked version of unbind
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Locked version that wraps radeon_vm_unbind_locked (cayman+).
+ * GPUVM is similar to the legacy
[PATCH 10/10] drm/radeon: start to document evergreen.c
From: Alex Deucher
Still a lot to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 120
1 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f716e08..0fc68a7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -99,6 +99,14 @@ void evergreen_fix_pci_max_read_req_size(struct
radeon_device *rdev)
}
}
+/**
+ * dce4_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (evergreen+).
+ */
void dce4_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -118,18 +126,49 @@ void dce4_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
+/**
+ * radeon_irq_kms_pflip_irq_get - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (evergreen+).
+ * Enables the pageflip irq (vblank irq).
+ */
void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * evergreen_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (evergreen+).
+ * Disables the pageflip irq (vblank irq).
+ */
void evergreen_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * evergreen_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (evergreen+).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 evergreen_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -214,6 +253,15 @@ int sumo_get_temp(struct radeon_device *rdev)
return actual_temp * 1000;
}
+/**
+ * sumo_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (sumo, trinity, SI).
+ * Used for profile mode only.
+ */
void sumo_pm_init_profile(struct radeon_device *rdev)
{
int idx;
@@ -265,6 +313,14 @@ void sumo_pm_init_profile(struct radeon_device *rdev)
rdev->pm.power_state[idx].num_clock_modes - 1;
}
+/**
+ * evergreen_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, etc.) (evergreen+).
+ */
void evergreen_pm_misc(struct radeon_device *rdev)
{
int req_ps_idx = rdev->pm.requested_power_state_index;
@@ -292,6 +348,13 @@ void evergreen_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (evergreen+).
+ */
void evergreen_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -310,6 +373,13 @@ void evergreen_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (evergreen+).
+ */
void evergreen_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -328,6 +398,15 @@ void evergreen_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_hpd_sense - hpd sense callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Checks if a digital monitor is connected (evergreen+).
+ * Returns true if connected, false if not connected.
+ */
bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd)
{
bool connected = false;
@@ -364,6 +443,14 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum
radeon_hpd_id hpd)
return connected;
}
+/**
+ * evergreen_hpd_set_polarity - hpd set polarity callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Set the polarity of the hpd pin (evergreen+).
+ */
void evergreen_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd)
{
@@ -424,6 +511,14 @@ void evergreen_hpd_set_polarity(struct radeon_device *rdev,
}
}
+/**
+ * evergreen_hpd_init - hpd setup callback.
+ *
+ *
Re: [PATCH 00/10] Start documenting the radeon drm better
On 29.06.2012 16:28, alexdeuc...@gmail.com wrote: From: Alex Deucher This is something I've been wanting to do for a while and I finally spent a little time getting a start on it. There is still a lot to do and not all of my descriptions are great, but I think we can document the rest in bits and pieces. I also added a note about what asics the function is applicable to. I tried to start with the more common and complex code. I was thinking it would make sense to have an informal documentation policy something like the following: 1. If you edit an undocumented function, add documentation 2. If you edit a documented function and change how it works, update the documentation 3. All new functions added should be documented Fulfulling all of these for stable fixes could pose problems so obviously there is some leeway. Thoughts? Sounds like a good idea to me, but could we move the old and deprecated non KMS code into it's own subdirectory or something like that first? Also for some files it might be a good idea to spread them into separate ones first, like the gart and vm and/or the ring and ib stuff. Cheers, Christian. Alex Deucher (10): drm/radeon: document radeon_device.c drm/radeon: document radeon_kms.c drm/radeon: document radeon_irq_kms.c drm/radeon: document radeon_asic.c drm/radeon: document radeon_fence.c drm/radeon: document radeon_ring.c drm/radeon: document non-VM functions in radeon_gart.c drm/radeon: document VM functions in radeon_gart.c drm/radeon: start to document the functions r100.c drm/radeon: start to document evergreen.c drivers/gpu/drm/radeon/evergreen.c | 120 ++ drivers/gpu/drm/radeon/r100.c | 127 ++- drivers/gpu/drm/radeon/radeon_asic.c| 46 drivers/gpu/drm/radeon/radeon_device.c | 344 +++- drivers/gpu/drm/radeon/radeon_fence.c | 373 + drivers/gpu/drm/radeon/radeon_gart.c| 391 ++- drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ drivers/gpu/drm/radeon/radeon_ring.c| 374 +- 9 files changed, 2041 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: add error handling to fence_wait_empty_locked
Instead of returning the error handle it directly
and while at it fix the comments about the ring lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 33 +
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 77b4519b..5861ec8 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -239,7 +239,7 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring);
bool radeon_fence_signaled(struct radeon_fence *fence);
int radeon_fence_wait(struct radeon_fence *fence, bool interruptible);
int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring);
-int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
+void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
int radeon_fence_wait_any(struct radeon_device *rdev,
struct radeon_fence **fences,
bool intr);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7b55625..be4e4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -440,14 +440,11 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
return 0;
}
+/* caller must hold ring lock */
int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring)
{
uint64_t seq;
- /* We are not protected by ring lock when reading current seq but
-* it's ok as worst case is we return to early while we could have
-* wait.
-*/
seq = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL;
if (seq >= rdev->fence_drv[ring].sync_seq[ring]) {
/* nothing to wait for, last_seq is
@@ -457,15 +454,27 @@ int radeon_fence_wait_next_locked(struct radeon_device
*rdev, int ring)
return radeon_fence_wait_seq(rdev, seq, ring, false, false);
}
-int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
+/* caller must hold ring lock */
+void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
{
- /* We are not protected by ring lock when reading current seq
-* but it's ok as wait empty is call from place where no more
-* activity can be scheduled so there won't be concurrent access
-* to seq value.
-*/
- return radeon_fence_wait_seq(rdev, rdev->fence_drv[ring].sync_seq[ring],
-ring, false, false);
+ uint64_t seq = rdev->fence_drv[ring].sync_seq[ring];
+
+ while(1) {
+ int r;
+ r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+ if (r == -EDEADLK) {
+ mutex_unlock(&rdev->ring_lock);
+ r = radeon_gpu_reset(rdev);
+ mutex_lock(&rdev->ring_lock);
+ if (!r)
+ continue;
+ }
+ if (r) {
+ dev_err(rdev->dev, "error waiting for ring to become"
+ " idle (%d)\n", r);
+ }
+ return;
+ }
}
struct radeon_fence *radeon_fence_ref(struct radeon_fence *fence)
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/radeon: move ring locking out of reset path
Hold the ring lock the whole time the reset is in progress,
otherwise another process can submit new jobs.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |8
drivers/gpu/drm/radeon/ni.c|8
drivers/gpu/drm/radeon/r100.c |8
drivers/gpu/drm/radeon/r300.c |4 ++--
drivers/gpu/drm/radeon/r420.c |8
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/radeon_device.c | 14 --
drivers/gpu/drm/radeon/rv515.c |4 ++--
drivers/gpu/drm/radeon/si.c| 12 ++--
9 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f716e08..09e6da8 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1418,7 +1418,7 @@ static int evergreen_cp_start(struct radeon_device *rdev)
int r, i;
uint32_t cp_me;
- r = radeon_ring_lock(rdev, ring, 7);
+ r = radeon_ring_alloc(rdev, ring, 7);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -1430,12 +1430,12 @@ static int evergreen_cp_start(struct radeon_device
*rdev)
radeon_ring_write(ring, PACKET3_ME_INITIALIZE_DEVICE_ID(1));
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
cp_me = 0xff;
WREG32(CP_ME_CNTL, cp_me);
- r = radeon_ring_lock(rdev, ring, evergreen_default_size + 19);
+ r = radeon_ring_alloc(rdev, ring, evergreen_default_size + 19);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -1473,7 +1473,7 @@ static int evergreen_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, 0x000e); /* VGT_VERTEX_REUSE_BLOCK_CNTL */
radeon_ring_write(ring, 0x0010); /* */
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 2366be3..7e516ce 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -918,7 +918,7 @@ static int cayman_cp_start(struct radeon_device *rdev)
struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
int r, i;
- r = radeon_ring_lock(rdev, ring, 7);
+ r = radeon_ring_alloc(rdev, ring, 7);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -930,11 +930,11 @@ static int cayman_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, PACKET3_ME_INITIALIZE_DEVICE_ID(1));
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
cayman_cp_enable(rdev, true);
- r = radeon_ring_lock(rdev, ring, cayman_default_size + 19);
+ r = radeon_ring_alloc(rdev, ring, cayman_default_size + 19);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -972,7 +972,7 @@ static int cayman_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, 0x000e); /* VGT_VERTEX_REUSE_BLOCK_CNTL */
radeon_ring_write(ring, 0x0010); /* */
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
/* XXX init other rings */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 35825bf..3901a68 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -955,7 +955,7 @@ void r100_ring_start(struct radeon_device *rdev, struct
radeon_ring *ring)
{
int r;
- r = radeon_ring_lock(rdev, ring, 2);
+ r = radeon_ring_alloc(rdev, ring, 2);
if (r) {
return;
}
@@ -965,7 +965,7 @@ void r100_ring_start(struct radeon_device *rdev, struct
radeon_ring *ring)
RADEON_ISYNC_ANY3D_IDLE2D |
RADEON_ISYNC_WAIT_IDLEGUI |
RADEON_ISYNC_CPSCRATCH_IDLEGUI);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
}
@@ -3631,7 +3631,7 @@ int r100_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ring_lock(rdev, ring, 2);
+ r = radeon_ring_alloc(rdev, ring, 2);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
radeon_scratch_free(rdev, scratch);
@@ -3639,7 +3639,7 @@ int r100_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring)
}
radeon_ring_write(ring, PACKE
[PATCH 3/3] drm/radeon: add error handling to radeon_vm_unbind_locked
Waiting for a fence can fail for different reasons,
the most common is a deadlock.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gart.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2b34c1a..ee11c50 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -316,10 +316,21 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
}
/* wait for vm use to end */
- if (vm->fence) {
- radeon_fence_wait(vm->fence, false);
- radeon_fence_unref(&vm->fence);
+ while (vm->fence) {
+ int r;
+ r = radeon_fence_wait(vm->fence, false);
+ if (r)
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ if (r == -EDEADLK) {
+ mutex_unlock(&rdev->vm_manager.lock);
+ r = radeon_gpu_reset(rdev);
+ mutex_lock(&rdev->vm_manager.lock);
+ if (!r)
+ continue;
+ }
+ break;
}
+ radeon_fence_unref(&vm->fence);
/* hw unbind */
rdev->vm_manager.funcs->unbind(rdev, vm);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: initialize CADL in opregion
On Thu, Jun 28, 2012 at 01:05:58PM +0200, Daniel Vetter wrote: > On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn wrote: > > Thank you, I've now written a partial analysis which is available at > > https://github.com/Lekensteyn/acpi- > > stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is > > cut in > > two parts in this mail, concat them as needed). > > > > Question: can you try disabling the asus-laptop module and try booting again > > w/ and w/o the CADL patch applied? > > - Does it boot in both cases? > > - Do the brightness hotkeys work? > > - Can you change brightness via /sys/class/backlight? > > Can you SSH in it and check the logs? Any ACPI warnings/errors or messages > > from the asus-laptop module? (or whatever asus module(s) is/are loaded) > > > > Can you also generate dmidecode.txt? (peek in > > http://lekensteyn.nl/files/get- > > acpi-info.sh, you do not have to run all of the commands since I already > > have > > your acpidump) > > Ok, because I have an ecrypted root fs I've tried to reload the > i915.ko with CADL after booting. Test-results: > - asus_wmi.ko doesn't seem to have any effect whatsoever on the endresult. > - asus_nb_wmi.ko doesn't load (ENODEV). > - brightness-keys (and also sound control) don't work, but controlling > the backlight with /sys/class/backlight/acpi_video0/brightness works > (if I can turn the panel on somehow, see below). > - When loading the i915.ko with the CADL patch the screen went black > (like at boot), but with some excessive vt-switching and X restarting > I've managed to light it up. Although it is flickery as hell, > especially the lower part of the screen. And if the screen is somewhat > stable, I just get the upper part of the screen duplicated in the > lower part. > - dmidecode is attached. > - no errors in the logs anywhere (if you ignore some ACPI resource > conflicts because ACPI reserves some pch stuff itself, which then > conflicts with the native gpio, sensors, whatever drivers). > > So I think this might be simply a timing issue that with CADL enabled > we expose a pre-existing bug somewhere in our modeset sequence. I'm > already chasing two issues on this machine: > - edp refuses to light up crtc 1/2, only works after having switched > back to crtc 0. > - disabled pipes get stuck in the active state once having been used be edp. > > I have a feeling that all these issues are related, so I guess until > I've tracked down the above the things we won't make much progress > with this CADL patch. Good news: I've fixed my edp issues (switching crtcs works reliable now and nothing gets stuck in a half-disabled state) and now I don't get a black/flashing screen any more when applying your patch. Bad news: We need to refactor a big chunk of our driver to properly fix this issue. Which means I can't merge your patch right away :( Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix VM page table setup on SI
On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Cayman and trinity allow for variable sized VM page > tables, but SI requires that all page tables be the > same size. The current code assumes variablely sized > VM page tables so SI may end up with part of each page > table overlapping with other memory which could end > up being interpreted by the VM hw as garbage. > > Change the code to better accomodate SI. Allocate enough > space for at least 2 full page tables and always set > last_pfn to max_pfn on SI so each VM is backed by a full > page table. This limits us to only 2 VMs active at any > given time on SI. This will be rectified and the code can > be reunified once we move to two level page tables. > > Signed-off-by: Alex Deucher This change breaks the radeonsi driver for me. egltri_screen (the 'golden' test for radeonsi at least basically working) locks up the GPU. I don't have any details about the lockup yet, as the GPU reset attempt hangs the machine. Any ideas offhand what radeonsi might be doing wrong? -- 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
Re: [PATCH 00/10] Start documenting the radeon drm better
On Fri, Jun 29, 2012 at 10:42 AM, Tom Stellard wrote: > On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeuc...@gmail.com wrote: >> From: Alex Deucher >> >> This is something I've been wanting to do for a while and >> I finally spent a little time getting a start on it. There >> is still a lot to do and not all of my descriptions are great, >> but I think we can document the rest in bits and pieces. I >> also added a note about what asics the function is applicable >> to. I tried to start with the more common and complex code. >> I was thinking it would make sense to have an informal >> documentation policy something like the following: >> 1. If you edit an undocumented function, add documentation >> 2. If you edit a documented function and change how it works, >> update the documentation >> 3. All new functions added should be documented >> >> Fulfulling all of these for stable fixes could pose problems >> so obviously there is some leeway. >> >> Thoughts? >> > I think this is a good policy. You might also want to specify the > documentation style to use. It looks like you are using some form of > Doxygen comments. I would also be in favor of a similar policy for > userspace code. I just copied the existing documentation bits in radeon and the drm in general. I'm open to other suggestions. Alex > > -Tom > >> Alex Deucher (10): >> drm/radeon: document radeon_device.c >> drm/radeon: document radeon_kms.c >> drm/radeon: document radeon_irq_kms.c >> drm/radeon: document radeon_asic.c >> drm/radeon: document radeon_fence.c >> drm/radeon: document radeon_ring.c >> drm/radeon: document non-VM functions in radeon_gart.c >> drm/radeon: document VM functions in radeon_gart.c >> drm/radeon: start to document the functions r100.c >> drm/radeon: start to document evergreen.c >> >> drivers/gpu/drm/radeon/evergreen.c | 120 ++ >> drivers/gpu/drm/radeon/r100.c | 127 ++- >> drivers/gpu/drm/radeon/radeon_asic.c | 46 >> drivers/gpu/drm/radeon/radeon_device.c | 344 +++- >> drivers/gpu/drm/radeon/radeon_fence.c | 373 + >> drivers/gpu/drm/radeon/radeon_gart.c | 391 >> ++- >> drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 >> drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ >> drivers/gpu/drm/radeon/radeon_ring.c | 374 >> +- >> 9 files changed, 2041 insertions(+), 10 deletions(-) >> >> -- >> 1.7.7.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: [PATCH 00/10] Start documenting the radeon drm better
On Fri, Jun 29, 2012 at 10:39 AM, Christian König wrote: > On 29.06.2012 16:28, alexdeuc...@gmail.com wrote: >> >> From: Alex Deucher >> >> This is something I've been wanting to do for a while and >> I finally spent a little time getting a start on it. There >> is still a lot to do and not all of my descriptions are great, >> but I think we can document the rest in bits and pieces. I >> also added a note about what asics the function is applicable >> to. I tried to start with the more common and complex code. >> I was thinking it would make sense to have an informal >> documentation policy something like the following: >> 1. If you edit an undocumented function, add documentation >> 2. If you edit a documented function and change how it works, >> update the documentation >> 3. All new functions added should be documented >> >> Fulfulling all of these for stable fixes could pose problems >> so obviously there is some leeway. >> >> Thoughts? > > Sounds like a good idea to me, but could we move the old and deprecated non > KMS code into it's own subdirectory or something like that first? That would be nice. Maybe add a new ums folder in radeon? > > Also for some files it might be a good idea to spread them into separate > ones first, like the gart and vm and/or the ring and ib stuff. Yeah, there is a lot of room of clean up. r100.c could be split into about 3 files to match newer asics. Alex > > Cheers, > Christian. > > >> >> Alex Deucher (10): >> drm/radeon: document radeon_device.c >> drm/radeon: document radeon_kms.c >> drm/radeon: document radeon_irq_kms.c >> drm/radeon: document radeon_asic.c >> drm/radeon: document radeon_fence.c >> drm/radeon: document radeon_ring.c >> drm/radeon: document non-VM functions in radeon_gart.c >> drm/radeon: document VM functions in radeon_gart.c >> drm/radeon: start to document the functions r100.c >> drm/radeon: start to document evergreen.c >> >> drivers/gpu/drm/radeon/evergreen.c | 120 ++ >> drivers/gpu/drm/radeon/r100.c | 127 ++- >> drivers/gpu/drm/radeon/radeon_asic.c | 46 >> drivers/gpu/drm/radeon/radeon_device.c | 344 >> +++- >> drivers/gpu/drm/radeon/radeon_fence.c | 373 >> + >> drivers/gpu/drm/radeon/radeon_gart.c | 391 >> ++- >> drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 >> drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ >> drivers/gpu/drm/radeon/radeon_ring.c | 374 >> +- >> 9 files changed, 2041 insertions(+), 10 deletions(-) >> > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Start documenting the radeon drm better
On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > This is something I've been wanting to do for a while and > I finally spent a little time getting a start on it. There > is still a lot to do and not all of my descriptions are great, > but I think we can document the rest in bits and pieces. I > also added a note about what asics the function is applicable > to. I tried to start with the more common and complex code. > I was thinking it would make sense to have an informal > documentation policy something like the following: > 1. If you edit an undocumented function, add documentation > 2. If you edit a documented function and change how it works, >update the documentation > 3. All new functions added should be documented > > Fulfulling all of these for stable fixes could pose problems > so obviously there is some leeway. > > Thoughts? > I think this is a good policy. You might also want to specify the documentation style to use. It looks like you are using some form of Doxygen comments. I would also be in favor of a similar policy for userspace code. -Tom > Alex Deucher (10): > drm/radeon: document radeon_device.c > drm/radeon: document radeon_kms.c > drm/radeon: document radeon_irq_kms.c > drm/radeon: document radeon_asic.c > drm/radeon: document radeon_fence.c > drm/radeon: document radeon_ring.c > drm/radeon: document non-VM functions in radeon_gart.c > drm/radeon: document VM functions in radeon_gart.c > drm/radeon: start to document the functions r100.c > drm/radeon: start to document evergreen.c > > drivers/gpu/drm/radeon/evergreen.c | 120 ++ > drivers/gpu/drm/radeon/r100.c | 127 ++- > drivers/gpu/drm/radeon/radeon_asic.c| 46 > drivers/gpu/drm/radeon/radeon_device.c | 344 +++- > drivers/gpu/drm/radeon/radeon_fence.c | 373 + > drivers/gpu/drm/radeon/radeon_gart.c| 391 > ++- > drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 > drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ > drivers/gpu/drm/radeon/radeon_ring.c| 374 +- > 9 files changed, 2041 insertions(+), 10 deletions(-) > > -- > 1.7.7.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: [PATCH 05/10] drm/radeon: document radeon_fence.c
Some minor comments spread over the whole file, see below:
On 29.06.2012 16:28, alexdeuc...@gmail.com wrote:
From: Alex Deucher
Adds documentation to most of the functions in
radeon_fence.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c | 373 +
1 files changed, 373 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 67f6fa9..604352e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -40,6 +40,22 @@
#include "radeon.h"
#include "radeon_trace.h"
+/**
+ * radeon_fence_write - write a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @seq: sequence number to write
+ * @ring: ring index the fence is associated with
+ *
+ * Writes a fence value to memory or a scratch register (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
We should not repeat the description what a fence is for every function,
instead a general comment over the whole file should be better. Also I
would only mention the "all asics" stuff just once in the header of the
file.
+ */
static void radeon_fence_write(struct radeon_device *rdev, u32 seq, int ring)
{
if (rdev->wb.enabled) {
@@ -49,6 +65,22 @@ static void radeon_fence_write(struct radeon_device *rdev,
u32 seq, int ring)
}
}
+/**
+ * radeon_fence_read - read a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Reads a fence value from memory or a scratch register (all asics).
+ * Returns the value of the fence read from memory or register.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static u32 radeon_fence_read(struct radeon_device *rdev, int ring)
{
u32 seq = 0;
@@ -61,6 +93,23 @@ static u32 radeon_fence_read(struct radeon_device *rdev, int
ring)
return seq;
}
+/**
+ * radeon_fence_emit - emit a fence on the requested ring
+ *
+ * @rdev: radeon_device pointer
+ * @fence: radeon fence object
+ * @ring: ring index the fence is associated with
+ *
+ * Emits a fence command on the requested ring (all asics).
+ * Returns 0 on success, -ENOMEM on failure.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
@@ -79,6 +128,22 @@ int radeon_fence_emit(struct radeon_device *rdev,
return 0;
}
+/**
+ * radeon_fence_process - process a fence
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Checks the current fence value and wakes the fence queue
+ * if the sequence number has increased (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
void radeon_fence_process(struct radeon_device *rdev, int ring)
{
uint64_t seq, last_seq;
@@ -139,6 +204,20 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
}
+/**
+ * radeon_fence_destroy - destroy a fence
+ *
+ * @kref: fence kref
+ *
+ * Frees the fence object (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location dep
Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path
On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: > Hold the ring lock the whole time the reset is in progress, > otherwise another process can submit new jobs. Sounds good, but doesn't this create other paths (e.g. initialization, resume) where the ring is being accessed without holding the lock? Isn't that a problem? -- 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
Re: [PATCH 3/3] drm/radeon: add error handling to radeon_vm_unbind_locked
On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: > Waiting for a fence can fail for different reasons, > the most common is a deadlock. > > Signed-off-by: Christian König 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
Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path
On 29.06.2012 17:09, Michel Dänzer wrote: On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: Hold the ring lock the whole time the reset is in progress, otherwise another process can submit new jobs. Sounds good, but doesn't this create other paths (e.g. initialization, resume) where the ring is being accessed without holding the lock? Isn't that a problem? Thought about that also. For init I'm pretty sure that no application can submit commands before we are done, otherwise we are doomed anyway. For resume I'm not really sure, but I think that applications are resumed after the hardware driver had a chance of doing so. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: add error handling to fence_wait_empty_locked
On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: > Instead of returning the error handle it directly > and while at it fix the comments about the ring lock. Sounds like this should really be two separate changes? > Signed-off-by: Christian König Either way, 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
Re: [PATCH] drm/radeon: fix VM page table setup on SI
On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote: > On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote: >> From: Alex Deucher >> >> Cayman and trinity allow for variable sized VM page >> tables, but SI requires that all page tables be the >> same size. The current code assumes variablely sized >> VM page tables so SI may end up with part of each page >> table overlapping with other memory which could end >> up being interpreted by the VM hw as garbage. >> >> Change the code to better accomodate SI. Allocate enough >> space for at least 2 full page tables and always set >> last_pfn to max_pfn on SI so each VM is backed by a full >> page table. This limits us to only 2 VMs active at any >> given time on SI. This will be rectified and the code can >> be reunified once we move to two level page tables. >> >> Signed-off-by: Alex Deucher > > This change breaks the radeonsi driver for me. egltri_screen (the > 'golden' test for radeonsi at least basically working) locks up the > GPU. > > I don't have any details about the lockup yet, as the GPU reset attempt > hangs the machine. Any ideas offhand what radeonsi might be doing wrong? Maybe trying to access an unmapped page that happened to work by accident before and now causes a fault in the VM which halts the MC? Alex > > > -- > 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
Re: [PATCH] drm/radeon: fix VM page table setup on SI
On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher wrote: > On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote: >> On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote: >>> From: Alex Deucher >>> >>> Cayman and trinity allow for variable sized VM page >>> tables, but SI requires that all page tables be the >>> same size. The current code assumes variablely sized >>> VM page tables so SI may end up with part of each page >>> table overlapping with other memory which could end >>> up being interpreted by the VM hw as garbage. >>> >>> Change the code to better accomodate SI. Allocate enough >>> space for at least 2 full page tables and always set >>> last_pfn to max_pfn on SI so each VM is backed by a full >>> page table. This limits us to only 2 VMs active at any >>> given time on SI. This will be rectified and the code can >>> be reunified once we move to two level page tables. >>> >>> Signed-off-by: Alex Deucher >> >> This change breaks the radeonsi driver for me. egltri_screen (the >> 'golden' test for radeonsi at least basically working) locks up the >> GPU. >> >> I don't have any details about the lockup yet, as the GPU reset attempt >> hangs the machine. Any ideas offhand what radeonsi might be doing wrong? > > Maybe trying to access an unmapped page that happened to work by > accident before and now causes a fault in the VM which halts the MC? > > Alex > Yeah only thing i can think of, can you get dump of various mc fault reg after lockup ? Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Start documenting the radeon drm better
2012/6/29 : > From: Alex Deucher > > This is something I've been wanting to do for a while and > I finally spent a little time getting a start on it. There > is still a lot to do and not all of my descriptions are great, > but I think we can document the rest in bits and pieces. I > also added a note about what asics the function is applicable > to. I tried to start with the more common and complex code. > I was thinking it would make sense to have an informal > documentation policy something like the following: > 1. If you edit an undocumented function, add documentation > 2. If you edit a documented function and change how it works, > update the documentation > 3. All new functions added should be documented > > Fulfulling all of these for stable fixes could pose problems > so obviously there is some leeway. > > Thoughts? I'd try to avoid repeating definitions over and over, but generally THIS IS GREAT. Thanks a lot for doing that! -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix VM page table setup on SI
On Fre, 2012-06-29 at 11:28 -0400, Jerome Glisse wrote: > On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher wrote: > > On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote: > >> On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote: > >>> From: Alex Deucher > >>> > >>> Cayman and trinity allow for variable sized VM page > >>> tables, but SI requires that all page tables be the > >>> same size. The current code assumes variablely sized > >>> VM page tables so SI may end up with part of each page > >>> table overlapping with other memory which could end > >>> up being interpreted by the VM hw as garbage. > >>> > >>> Change the code to better accomodate SI. Allocate enough > >>> space for at least 2 full page tables and always set > >>> last_pfn to max_pfn on SI so each VM is backed by a full > >>> page table. This limits us to only 2 VMs active at any > >>> given time on SI. This will be rectified and the code can > >>> be reunified once we move to two level page tables. > >>> > >>> Signed-off-by: Alex Deucher > >> > >> This change breaks the radeonsi driver for me. egltri_screen (the > >> 'golden' test for radeonsi at least basically working) locks up the > >> GPU. > >> > >> I don't have any details about the lockup yet, as the GPU reset attempt > >> hangs the machine. Any ideas offhand what radeonsi might be doing wrong? > > > > Maybe trying to access an unmapped page that happened to work by > > accident before and now causes a fault in the VM which halts the MC? Indeed, looks like it: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000FF01B radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0202400C Oddly, while I have seen similar errors before (so at least some access to unmapped pages was caught even before your patch), I hadn't noticed them for a while with egltri_screen... Anyway, some more experimentation shows that it doesn't happen if I skip the clear, and it still happens when doing only a clear. I'll look into what might be wrong with the clears next week. > Yeah only thing i can think of, can you get dump of various mc fault > reg after lockup ? Did you have any particular registers in mind? -- 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
Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path
On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: > On 29.06.2012 17:09, Michel Dänzer wrote: > > On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: > >> Hold the ring lock the whole time the reset is in progress, > >> otherwise another process can submit new jobs. > > Sounds good, but doesn't this create other paths (e.g. initialization, > > resume) where the ring is being accessed without holding the lock? Isn't > > that a problem? > > Thought about that also. > > For init I'm pretty sure that no application can submit commands before > we are done, otherwise we are doomed anyway. > > For resume I'm not really sure, but I think that applications are > resumed after the hardware driver had a chance of doing so. I hope you're right... but if it's not too much trouble, it might be better to be safe than sorry and take the lock for those paths as well. -- 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 01/10] drm/radeon: document radeon_device.c (v2)
From: Alex Deucher
Adds documentation to most of the functions in
radeon_device.c
v2: split out general descriptions as per Christian's
comments.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_device.c | 313 +++-
1 files changed, 310 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index f654ba8..926d7e8 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -96,8 +96,12 @@ static const char radeon_family_name[][16] = {
"LAST",
};
-/*
- * Clear GPU surface registers.
+/**
+ * radeon_surface_init - Clear GPU surface registers.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clear GPU surface registers (r1xx-r5xx).
*/
void radeon_surface_init(struct radeon_device *rdev)
{
@@ -119,6 +123,13 @@ void radeon_surface_init(struct radeon_device *rdev)
/*
* GPU scratch registers helpers function.
*/
+/**
+ * radeon_scratch_init - Init scratch register driver information.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init CP scratch register driver information (r1xx-r5xx)
+ */
void radeon_scratch_init(struct radeon_device *rdev)
{
int i;
@@ -136,6 +147,15 @@ void radeon_scratch_init(struct radeon_device *rdev)
}
}
+/**
+ * radeon_scratch_get - Allocate a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Allocate a CP scratch register for use by the driver (all asics).
+ * Returns 0 on success or -EINVAL on failure.
+ */
int radeon_scratch_get(struct radeon_device *rdev, uint32_t *reg)
{
int i;
@@ -150,6 +170,14 @@ int radeon_scratch_get(struct radeon_device *rdev,
uint32_t *reg)
return -EINVAL;
}
+/**
+ * radeon_scratch_free - Free a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Free a CP scratch register allocated for use by the driver (all asics)
+ */
void radeon_scratch_free(struct radeon_device *rdev, uint32_t reg)
{
int i;
@@ -162,6 +190,20 @@ void radeon_scratch_free(struct radeon_device *rdev,
uint32_t reg)
}
}
+/*
+ * radeon_wb_*()
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
+
+/**
+ * radeon_wb_disable - Disable Writeback
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback (all asics). Used for suspend.
+ */
void radeon_wb_disable(struct radeon_device *rdev)
{
int r;
@@ -177,6 +219,14 @@ void radeon_wb_disable(struct radeon_device *rdev)
rdev->wb.enabled = false;
}
+/**
+ * radeon_wb_fini - Disable Writeback and free memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver shutdown.
+ */
void radeon_wb_fini(struct radeon_device *rdev)
{
radeon_wb_disable(rdev);
@@ -187,6 +237,15 @@ void radeon_wb_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_wb_init- Init Writeback driver info and allocate memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver startup.
+ * Returns 0 on success or an -error on failure.
+ */
int radeon_wb_init(struct radeon_device *rdev)
{
int r;
@@ -355,6 +414,15 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
/*
* GPU helpers function.
*/
+/**
+ * radeon_card_posted - check if the hw has already been initialized
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic has been initialized (all asics).
+ * Used at driver startup.
+ * Returns true if initialized or false if not.
+ */
bool radeon_card_posted(struct radeon_device *rdev)
{
uint32_t reg;
@@ -404,6 +472,14 @@ bool radeon_card_posted(struct radeon_device *rdev)
}
+/**
+ * radeon_update_bandwidth_info - update display bandwidth params
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Used when sclk/mclk are switched or display modes are set.
+ * params are used to calculate display watermarks (all asics)
+ */
void radeon_update_bandwidth_info(struct radeon_device *rdev)
{
fixed20_12 a;
@@ -424,6 +500,15 @@ void radeon_update_bandwidth_info(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_boot_test_post_card - check and possibly initialize the hw
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic is initialized and if not, attempt to initialize
+ * it (all asics).
+ * Returns true if initialized or false if not.
+ */
bool radeon_boot_test_post_card(struct radeon_device *rdev)
{
if (radeon_card_posted(rdev))
@@ -442,6 +527,16 @@ bool radeon_boot_test_post_card(struct radeon_device *rdev)
}
}
+/**
+ * radeon_dummy_page_init - init dummy page used by the driver
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate the dummy page used by
[PATCH 02/10] drm/radeon: document radeon_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 126 +++
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 18b81d6..1d73f16 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -33,6 +33,17 @@
#include
#include
+/**
+ * radeon_driver_unload_kms - Main unload function for KMS.
+ *
+ * @dev: drm dev pointer
+ *
+ * This is the main unload function for KMS (all asics).
+ * It calls radeon_modeset_fini() to tear down the
+ * displays, and radeon_device_fini() to tear down
+ * the rest of the device (CP, writeback, etc.).
+ * Returns 0 on success.
+ */
int radeon_driver_unload_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -46,6 +57,19 @@ int radeon_driver_unload_kms(struct drm_device *dev)
return 0;
}
+/**
+ * radeon_driver_load_kms - Main load function for KMS.
+ *
+ * @dev: drm dev pointer
+ * @flags: device flags
+ *
+ * This is the main load function for KMS (all asics).
+ * It calls radeon_device_init() to set up the non-display
+ * parts of the chip (asic init, CP, writeback, etc.), and
+ * radeon_modeset_init() to set up the display parts
+ * (crtcs, encoders, hotplug detect, etc.).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags)
{
struct radeon_device *rdev;
@@ -96,6 +120,16 @@ out:
return r;
}
+/**
+ * radeon_set_filp_rights - Set filp right.
+ *
+ * @dev: drm dev pointer
+ * @owner: drm file
+ * @applier: drm file
+ * @value: value
+ *
+ * Sets the filp rights for the device (all asics).
+ */
static void radeon_set_filp_rights(struct drm_device *dev,
struct drm_file **owner,
struct drm_file *applier,
@@ -118,6 +152,18 @@ static void radeon_set_filp_rights(struct drm_device *dev,
/*
* Userspace get information ioctl
*/
+/**
+ * radeon_info_ioctl - answer a device specific request.
+ *
+ * @rdev: radeon device pointer
+ * @data: request object
+ * @filp: drm filp
+ *
+ * This function is used to pass device specific parameters to the userspace
+ * drivers. Examples include: pci device id, pipeline parms, tiling params,
+ * etc. (all asics).
+ * Returns 0 on success, -EINVAL on failure.
+ */
int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp)
{
struct radeon_device *rdev = dev->dev_private;
@@ -301,16 +347,40 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
/*
* Outdated mess for old drm with Xorg being in charge (void function now).
*/
+/**
+ * radeon_driver_firstopen_kms - drm callback for first open
+ *
+ * @dev: drm dev pointer
+ *
+ * Nothing to be done for KMS (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_firstopen_kms(struct drm_device *dev)
{
return 0;
}
+/**
+ * radeon_driver_firstopen_kms - drm callback for last close
+ *
+ * @dev: drm dev pointer
+ *
+ * Switch vga switcheroo state after last close (all asics).
+ */
void radeon_driver_lastclose_kms(struct drm_device *dev)
{
vga_switcheroo_process_delayed_switch();
}
+/**
+ * radeon_driver_open_kms - drm callback for open
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device open, init vm on cayman+ (all asics).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
{
struct radeon_device *rdev = dev->dev_private;
@@ -339,6 +409,14 @@ int radeon_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
return 0;
}
+/**
+ * radeon_driver_postclose_kms - drm callback for post close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device post close, tear down vm on cayman+ (all asics).
+ */
void radeon_driver_postclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -354,6 +432,15 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
}
}
+/**
+ * radeon_driver_preclose_kms - drm callback for pre close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device pre close, tear down hyperz and cmask filps on r1xx-r5xx
+ * (all asics).
+ */
void radeon_driver_preclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -367,6 +454,15 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
/*
* VBlank related functions.
*/
+/**
+ * radeon_get_vblank_counter_kms - get frame count
+ *
+ * @dev: drm dev pointer
+ * @crtc: crtc to get the frame count from
+ *
+ * Gets the frame count on the requested crtc (all asics).
+ * Returns frame count on success, -EINVAL on failure
[PATCH 03/10] drm/radeon: document radeon_irq_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_irq_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 +++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 6664514..afaa172 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -34,6 +34,15 @@
#define RADEON_WAIT_IDLE_TIMEOUT 200
+/**
+ * radeon_driver_irq_handler_kms - irq handler for KMS
+ *
+ * @DRM_IRQ_ARGS: args
+ *
+ * This is the irq handler for the radeon KMS driver (all asics).
+ * radeon_irq_process is a macro that points to the per-asic
+ * irq handler callback.
+ */
irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
@@ -45,6 +54,17 @@ irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
/*
* Handle hotplug events outside the interrupt handler proper.
*/
+/**
+ * radeon_hotplug_work_func - display hotplug work handler
+ *
+ * @work: work struct
+ *
+ * This is the hot plug event work handler (all asics).
+ * The work gets scheduled from the irq handler if there
+ * was a hot plug interrupt. It walks the connector table
+ * and calls the hotplug handler for each one, then sends
+ * a drm hotplug event to alert userspace.
+ */
static void radeon_hotplug_work_func(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
@@ -61,6 +81,14 @@ static void radeon_hotplug_work_func(struct work_struct
*work)
drm_helper_hpd_irq_event(dev);
}
+/**
+ * radeon_driver_irq_preinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Gets the hw ready to enable irqs (all asics).
+ * This function disables all interrupt sources on the GPU.
+ */
void radeon_driver_irq_preinstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -85,12 +113,27 @@ void radeon_driver_irq_preinstall_kms(struct drm_device
*dev)
radeon_irq_process(rdev);
}
+/**
+ * radeon_driver_irq_postinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Handles stuff to be done after enabling irqs (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_irq_postinstall_kms(struct drm_device *dev)
{
dev->max_vblank_count = 0x001f;
return 0;
}
+/**
+ * radeon_driver_irq_uninstall_kms - drm irq uninstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * This function disables all interrupt sources on the GPU (all asics).
+ */
void radeon_driver_irq_uninstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -116,6 +159,16 @@ void radeon_driver_irq_uninstall_kms(struct drm_device
*dev)
spin_unlock_irqrestore(&rdev->irq.lock, irqflags);
}
+/**
+ * radeon_msi_ok - asic specific msi checks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Handles asic specific MSI checks to determine if
+ * MSIs should be enabled on a particular chip (all asics).
+ * Returns true if MSIs should be enabled, false if MSIs
+ * should not be enabled.
+ */
static bool radeon_msi_ok(struct radeon_device *rdev)
{
/* RV370/RV380 was first asic with MSI support */
@@ -168,6 +221,14 @@ static bool radeon_msi_ok(struct radeon_device *rdev)
return true;
}
+/**
+ * radeon_irq_kms_init - init driver interrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the work irq handlers, vblank init, MSIs, etc. (all asics).
+ * Returns 0 for success, error for failure.
+ */
int radeon_irq_kms_init(struct radeon_device *rdev)
{
int r = 0;
@@ -200,6 +261,13 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_irq_kms_fini - tear down driver interrrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Tears down the work irq handlers, vblank handlers, MSIs, etc. (all asics).
+ */
void radeon_irq_kms_fini(struct radeon_device *rdev)
{
drm_vblank_cleanup(rdev->ddev);
@@ -212,6 +280,16 @@ void radeon_irq_kms_fini(struct radeon_device *rdev)
flush_work_sync(&rdev->hotplug_work);
}
+/**
+ * radeon_irq_kms_sw_irq_get - enable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to enable
+ *
+ * Enables the software interrupt for a specific ring (all asics).
+ * The software interrupt is generally used to signal a fence on
+ * a particular ring.
+ */
void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring)
{
unsigned long irqflags;
@@ -226,6 +304,16 @@ void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev,
int ring)
}
}
+/**
+ * radeon_irq_kms_sw_irq_put - disable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to disable
+ *
+ * Disables the software interrupt for a speci
[PATCH 04/10] drm/radeon: document radeon_asic.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_asic.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index f533df5..973417c 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -40,6 +40,16 @@
/*
* Registers accessors functions.
*/
+/**
+ * radeon_invalid_rreg - dummy reg read function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ * Returns the value in the register.
+ */
static uint32_t radeon_invalid_rreg(struct radeon_device *rdev, uint32_t reg)
{
DRM_ERROR("Invalid callback to read register 0x%04X\n", reg);
@@ -47,6 +57,16 @@ static uint32_t radeon_invalid_rreg(struct radeon_device
*rdev, uint32_t reg)
return 0;
}
+/**
+ * radeon_invalid_wreg - dummy reg write function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ * @v: value to write to the register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ */
static void radeon_invalid_wreg(struct radeon_device *rdev, uint32_t reg,
uint32_t v)
{
DRM_ERROR("Invalid callback to write register 0x%04X with 0x%08X\n",
@@ -54,6 +74,14 @@ static void radeon_invalid_wreg(struct radeon_device *rdev,
uint32_t reg, uint32
BUG_ON(1);
}
+/**
+ * radeon_register_accessor_init - sets up the register accessor callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the register accessor callbacks for various register
+ * apertures. Not all asics have all apertures (all asics).
+ */
static void radeon_register_accessor_init(struct radeon_device *rdev)
{
rdev->mc_rreg = &radeon_invalid_rreg;
@@ -102,6 +130,14 @@ static void radeon_register_accessor_init(struct
radeon_device *rdev)
/* helper to disable agp */
+/**
+ * radeon_agp_disable - AGP disable helper function
+ *
+ * @rdev: radeon device pointer
+ *
+ * Removes AGP flags and changes the gart callbacks on AGP
+ * cards when using the internal gart rather than AGP (all asics).
+ */
void radeon_agp_disable(struct radeon_device *rdev)
{
rdev->flags &= ~RADEON_IS_AGP;
@@ -1608,6 +1644,16 @@ static struct radeon_asic si_asic = {
},
};
+/**
+ * radeon_asic_init - register asic specific callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Registers the appropriate asic specific callbacks for each
+ * chip family. Also sets other asics specific info like the number
+ * of crtcs and the register aperture accessors (all asics).
+ * Returns 0 for success.
+ */
int radeon_asic_init(struct radeon_device *rdev)
{
radeon_register_accessor_init(rdev);
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] drm/radeon: document radeon_fence.c (v2)
From: Alex Deucher
Adds documentation to most of the functions in
radeon_fence.c
v2: address Christian's comments:
- split common concept description into it's own comment
- fix description of intr parameter
- Improve description of -EDEADLK error
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c | 238 +
1 files changed, 238 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 67f6fa9..32284e7 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -40,6 +40,26 @@
#include "radeon.h"
#include "radeon_trace.h"
+/*
+ * Fences
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
+
+/**
+ * radeon_fence_write - write a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @seq: sequence number to write
+ * @ring: ring index the fence is associated with
+ *
+ * Writes a fence value to memory or a scratch register (all asics).
+ */
static void radeon_fence_write(struct radeon_device *rdev, u32 seq, int ring)
{
if (rdev->wb.enabled) {
@@ -49,6 +69,15 @@ static void radeon_fence_write(struct radeon_device *rdev,
u32 seq, int ring)
}
}
+/**
+ * radeon_fence_read - read a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Reads a fence value from memory or a scratch register (all asics).
+ * Returns the value of the fence read from memory or register.
+ */
static u32 radeon_fence_read(struct radeon_device *rdev, int ring)
{
u32 seq = 0;
@@ -61,6 +90,16 @@ static u32 radeon_fence_read(struct radeon_device *rdev, int
ring)
return seq;
}
+/**
+ * radeon_fence_emit - emit a fence on the requested ring
+ *
+ * @rdev: radeon_device pointer
+ * @fence: radeon fence object
+ * @ring: ring index the fence is associated with
+ *
+ * Emits a fence command on the requested ring (all asics).
+ * Returns 0 on success, -ENOMEM on failure.
+ */
int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
@@ -79,6 +118,15 @@ int radeon_fence_emit(struct radeon_device *rdev,
return 0;
}
+/**
+ * radeon_fence_process - process a fence
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Checks the current fence value and wakes the fence queue
+ * if the sequence number has increased (all asics).
+ */
void radeon_fence_process(struct radeon_device *rdev, int ring)
{
uint64_t seq, last_seq;
@@ -139,6 +187,13 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
}
+/**
+ * radeon_fence_destroy - destroy a fence
+ *
+ * @kref: fence kref
+ *
+ * Frees the fence object (all asics).
+ */
static void radeon_fence_destroy(struct kref *kref)
{
struct radeon_fence *fence;
@@ -147,6 +202,20 @@ static void radeon_fence_destroy(struct kref *kref)
kfree(fence);
}
+/**
+ * radeon_fence_seq_signaled - check if a fence sequeuce number has signaled
+ *
+ * @rdev: radeon device pointer
+ * @seq: sequence number
+ * @ring: ring index the fence is associated with
+ *
+ * Check if the last singled fence sequnce number is >= the requested
+ * sequence number (all asics).
+ * Returns true if the fence has signaled (current fence value
+ * is >= requested value) or false if it has not (current fence
+ * value is < the requested value. Helper function for
+ * radeon_fence_signaled().
+ */
static bool radeon_fence_seq_signaled(struct radeon_device *rdev,
u64 seq, unsigned ring)
{
@@ -161,6 +230,14 @@ static bool radeon_fence_seq_signaled(struct radeon_device
*rdev,
return false;
}
+/**
+ * radeon_fence_signaled - check if a fence has signaled
+ *
+ * @fence: radeon fence object
+ *
+ * Check if the requested fence has signaled (all asics).
+ * Returns true if the fence has signaled or false if it has not.
+ */
bool radeon_fence_signaled(struct radeon_fence *fence)
{
if (!fence) {
@@ -176,6 +253,24 @@ bool radeon_fence_signaled(struct radeon_fence *fence)
return false;
}
+/**
+ * radeon_fence_wait_seq - wait for a specific sequence number
+ *
+ * @rdev: radeon device pointer
+ * @target_seq: sequence number we want to wait for
+ * @ring: ring index the fence is associated with
+ * @intr: use interruptable sleep
+ * @lock_ring: whether the ring should be locked or not
+ *
+ * Wait for the requested sequence number to be written (all asics).
+ * @intr selects whether to
[PATCH 06/10] drm/radeon: document radeon_ring.c (v2)
From: Alex Deucher
Adds documentation to most of the functions in
radeon_ring.c
v2: adjust per Christian's suggestions
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 216 +-
1 files changed, 213 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 0826e77..cec80fa 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -35,10 +35,28 @@
#include "atom.h"
/*
- * IB.
+ * IB
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
*/
int radeon_debugfs_sa_init(struct radeon_device *rdev);
+/**
+ * radeon_ib_get - request an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the IB is associated with
+ * @ib: IB object returned
+ * @size: requested IB size
+ *
+ * Request an IB (all asics). IBs are allocated using the
+ * suballocator.
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_get(struct radeon_device *rdev, int ring,
struct radeon_ib *ib, unsigned size)
{
@@ -67,6 +85,14 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
return 0;
}
+/**
+ * radeon_ib_free - free an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to free
+ *
+ * Free an IB (all asics).
+ */
void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib)
{
radeon_semaphore_free(rdev, &ib->semaphore, ib->fence);
@@ -74,6 +100,15 @@ void radeon_ib_free(struct radeon_device *rdev, struct
radeon_ib *ib)
radeon_fence_unref(&ib->fence);
}
+/**
+ * radeon_ib_schedule - schedule an IB (Indirect Buffer) on the ring
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to schedule
+ *
+ * Schedule an IB on the associated ring (all asics).
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib)
{
struct radeon_ring *ring = &rdev->ring[ib->ring];
@@ -116,6 +151,15 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib)
return 0;
}
+/**
+ * radeon_ib_pool_init - Init the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the suballocator to manage a pool of memory
+ * for use as IBs (all asics).
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_pool_init(struct radeon_device *rdev)
{
int r;
@@ -136,6 +180,14 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_ib_pool_fini - Free the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the suballocator managing the pool of memory
+ * for use as IBs (all asics).
+ */
void radeon_ib_pool_fini(struct radeon_device *rdev)
{
if (rdev->ib_pool_ready) {
@@ -144,16 +196,46 @@ void radeon_ib_pool_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_ib_pool_start - Start the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator that manages pool of memory
+ * used for IBs (all asics). Used to start the IB pool on
+ * device startup and resume.
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_pool_start(struct radeon_device *rdev)
{
return radeon_sa_bo_manager_start(rdev, &rdev->ring_tmp_bo);
}
+/**
+ * radeon_ib_pool_suspend - Suspend the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Stop the suballocator that manages the pool of memory
+ * used as IBs (all asics). Used to stop the IB pool on
+ * device suspend.
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_pool_suspend(struct radeon_device *rdev)
{
return radeon_sa_bo_manager_suspend(rdev, &rdev->ring_tmp_bo);
}
+/**
+ * radeon_ib_ring_tests - Test IBs (Indirect Buffer) on all
+ * relevant rings
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Execute a test IB on the rings (all asics). Used to test
+ * if IBs are working on the rings at device startup and resume.
+ * Returns 0 on success, error on failure.
+ */
int radeon_ib_ring_tests(struct radeon_device *rdev)
{
unsigned i;
@@ -185,10 +267,28 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)
}
/*
- * Ring.
+ * Rings
+ * Most engines on the GPU are fed via ring buffers. Ring
+ * buffers are areas of GPU accessible memory that the host
+ * writes commands into and the GPU reads commands out of.
+ * There is a rptr (read pointer) that determines where the
+ * GPU is currently reading, and a wptr (write pointer)
+ * which determines where the host has written. When the
+ * pointers are equ
[PATCH 07/10] drm/radeon: document non-VM functions in radeon_gart.c (v2)
From: Alex Deucher
Document the non-VM functions in radeon_gart.c
v2: adjust per Christian's suggestions
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 125 +-
1 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8c44d1d..f6a9dab 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -31,8 +31,38 @@
#include "radeon_reg.h"
/*
+ * GART
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ *
+ * Radeon GPUs support both an internal GART, as described above,
+ * and AGP. AGP works similarly, but the GART table is configured
+ * and maintained by the northbridge rather than the driver.
+ * Radeon hw has a separate AGP aperture that is programmed to
+ * point to the AGP aperture provided by the northbridge and the
+ * requests are passed through to the northbridge aperture.
+ * Both AGP and internal GART can be used at the same time, however
+ * that is not currently supported by the driver.
+ *
+ * This file handles the common internal GART management.
+ */
+
+/*
* Common GART table functions.
*/
+/**
+ * radeon_gart_table_ram_alloc - allocate system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400). These asics require the
+ * gart table to be in system memory.
+ * Returns 0 for success, -ENOMEM for failure.
+ */
int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
{
void *ptr;
@@ -54,6 +84,15 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_ram_free - free system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400). These asics require the
+ * gart table to be in system memory.
+ */
void radeon_gart_table_ram_free(struct radeon_device *rdev)
{
if (rdev->gart.ptr == NULL) {
@@ -73,6 +112,16 @@ void radeon_gart_table_ram_free(struct radeon_device *rdev)
rdev->gart.table_addr = 0;
}
+/**
+ * radeon_gart_table_vram_alloc - allocate vram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate video memory for GART page table
+ * (pcie r4xx, r5xx+). These asics require the
+ * gart table to be in video memory.
+ * Returns 0 for success, error for failure.
+ */
int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
{
int r;
@@ -88,6 +137,16 @@ int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_vram_pin - pin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Pin the GART page table in vram so it will not be moved
+ * by the memory manager (pcie r4xx, r5xx+). These asics require the
+ * gart table to be in video memory.
+ * Returns 0 for success, error for failure.
+ */
int radeon_gart_table_vram_pin(struct radeon_device *rdev)
{
uint64_t gpu_addr;
@@ -110,6 +169,14 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
return r;
}
+/**
+ * radeon_gart_table_vram_unpin - unpin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unpin the GART page table in vram (pcie r4xx, r5xx+).
+ * These asics require the gart table to be in video memory.
+ */
void radeon_gart_table_vram_unpin(struct radeon_device *rdev)
{
int r;
@@ -126,6 +193,15 @@ void radeon_gart_table_vram_unpin(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_gart_table_vram_free - free gart page table vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free the video memory used for the GART page table
+ * (pcie r4xx, r5xx+). These asics require the gart table to
+ * be in video memory.
+ */
void radeon_gart_table_vram_free(struct radeon_device *rdev)
{
if (rdev->gart.robj == NULL) {
@@ -135,12 +211,19 @@ void radeon_gart_table_vram_free(struct radeon_device
*rdev)
radeon_bo_unref(&rdev->gart.robj);
}
-
-
-
/*
* Common gart functions.
*/
+/**
+ * radeon_gart_unbind - unbind pages from the gart page table
+ *
+ * @rdev: radeon_device pointer
+ * @offset: offset into the GPU's gart aperture
+ * @pages: number of pages to unbind
+ *
+ * Unbinds the requested pages from the gart page table and
+ * replaces them with the dummy page (all asics).
+ */
void radeon_gart_unbind(struct radeon_device *rdev, unsigned offset,
int pages)
{
@@ -172,6 +255,19 @@ void radeon_gart_unbind(struct radeon_device *rdev,
unsigned offset,
radeon_gart_tlb_flush(rdev);
}
+/**
+ * radeon_gart_bind - bin
[PATCH 08/10] drm/radeon: document VM functions in radeon_gart.c (v2)
From: Alex Deucher
Document the VM functions in radeon_gart.c
v2: adjust per Christian's suggestions
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 159 ++
1 files changed, 159 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index f6a9dab..2b842ba 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -397,10 +397,38 @@ void radeon_gart_fini(struct radeon_device *rdev)
}
/*
+ * GPUVM
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ * Each VM has an ID associated with it and there is a page table
+ * associated with each VMID. When execting a command buffer,
+ * the kernel tells the the ring what VMID to use for that command
+ * buffer. VMIDs are allocated dynamically as commands are submitted.
+ * The userspace drivers maintain their own address space and the kernel
+ * sets up their pages tables accordingly when they submit their
+ * command buffers and a VMID is assigned.
+ * Cayman/Trinity support up to 8 active VMs at any given time;
+ * SI supports 16.
+ */
+
+/*
* vm helpers
*
* TODO bind a default page at vm initialization for default address
*/
+/**
+ * radeon_vm_manager_init - init the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init the vm manager (cayman+).
+ * Returns 0 for success, error for failure.
+ */
int radeon_vm_manager_init(struct radeon_device *rdev)
{
int r;
@@ -426,6 +454,16 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
}
/* global mutex must be lock */
+/**
+ * radeon_vm_unbind_locked - unbind a specific vm
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Unbind the requested vm (cayman+).
+ * Wait for use of the VM to finish, then unbind the page table,
+ * and free the page table memory.
+ */
static void radeon_vm_unbind_locked(struct radeon_device *rdev,
struct radeon_vm *vm)
{
@@ -454,6 +492,13 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
}
}
+/**
+ * radeon_vm_manager_fini - tear down the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the VM manager (cayman+).
+ */
void radeon_vm_manager_fini(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL)
@@ -464,6 +509,14 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
rdev->vm_manager.enabled = false;
}
+/**
+ * radeon_vm_manager_start - start the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ */
int radeon_vm_manager_start(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL) {
@@ -472,6 +525,15 @@ int radeon_vm_manager_start(struct radeon_device *rdev)
return radeon_sa_bo_manager_start(rdev, &rdev->vm_manager.sa_manager);
}
+/**
+ * radeon_vm_manager_suspend - suspend the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unbind all the VM page tables and suspend the suballocator
+ * instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ */
int radeon_vm_manager_suspend(struct radeon_device *rdev)
{
struct radeon_vm *vm, *tmp;
@@ -487,6 +549,14 @@ int radeon_vm_manager_suspend(struct radeon_device *rdev)
}
/* global mutex must be locked */
+/**
+ * radeon_vm_unbind - locked version of unbind
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Locked version that wraps radeon_vm_unbind_locked (cayman+).
+ */
void radeon_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
{
mutex_lock(&vm->mutex);
@@ -495,6 +565,18 @@ void radeon_vm_unbind(struct radeon_device *rdev, struct
radeon_vm *vm)
}
/* global and local mutex must be locked */
+/**
+ * radeon_vm_bind - bind a page table to a VMID
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to bind
+ *
+ * Bind the requested vm (cayman+).
+ * Suballocate memory for the page table, allocate a VMID
+ * and bind the page table to it, and finally start to populate
+ * the page table.
+ * Returns 0 for success, error for failure.
+ */
int radeon_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm)
{
struct radeon_vm *vm_evict;
@@ -557,6 +639,20 @@ retry_id:
}
/* object have to be reserved */
+/**
+ * radeon_vm_bo_add - add a bo to a specific vm
+ *
+ * @rdev: radeon_device pointer
+ * @vm: requested vm
+ * @bo: radeon buffer object
+ * @offset: requested offset of the buffer in the VM address space
+ * @flags: attrib
[PATCH 09/10] drm/radeon: start to document the functions r100.c
From: Alex Deucher
Still a lot more to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 127 -
1 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index d06c8dd..84477dc 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -65,6 +65,19 @@ MODULE_FIRMWARE(FIRMWARE_R520);
#include "r100_track.h"
+/* This files gather functions specifics to:
+ * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+ * and others in some cases.
+ */
+
+/**
+ * r100_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (r1xx-r4xx).
+ */
void r100_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -99,22 +112,49 @@ void r100_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
-/* This files gather functions specifics to:
- * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+/**
+ * r100_pre_page_flip - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (r1xx-r4xx).
+ * Enables the pageflip irq (vblank irq).
*/
-
void r100_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * r100_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (r1xx-r4xx).
+ * Disables the pageflip irq (vblank irq).
+ */
void r100_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * r100_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (r1xx-r4xx).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 r100_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -141,6 +181,15 @@ u32 r100_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base)
return RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) &
RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET;
}
+/**
+ * r100_pm_get_dynpm_state - look up dynpm power state callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Look up the optimal power state based on the
+ * current state of the GPU (r1xx-r5xx).
+ * Used for dynpm only.
+ */
void r100_pm_get_dynpm_state(struct radeon_device *rdev)
{
int i;
@@ -223,6 +272,15 @@ void r100_pm_get_dynpm_state(struct radeon_device *rdev)
pcie_lanes);
}
+/**
+ * r100_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (r1xx-r3xx).
+ * Used for profile mode only.
+ */
void r100_pm_init_profile(struct radeon_device *rdev)
{
/* default */
@@ -262,6 +320,14 @@ void r100_pm_init_profile(struct radeon_device *rdev)
rdev->pm.profiles[PM_PROFILE_HIGH_MH_IDX].dpms_on_cm_idx = 0;
}
+/**
+ * r100_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, pcie lanes, etc.) (r1xx-r4xx).
+ */
void r100_pm_misc(struct radeon_device *rdev)
{
int requested_index = rdev->pm.requested_power_state_index;
@@ -353,6 +419,13 @@ void r100_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (r1xx-r4xx).
+ */
void r100_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -377,6 +450,13 @@ void r100_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (r1xx-r4xx).
+ */
void r100_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -401,6 +481,14 @@ void r100_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * r100_gui_idle - gui idle callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check of the GUI (2D/3D engines) are idle (r1xx-r5xx).
+ * Returns true if idle, false if not.
+ */
bool r100_gui_idle(struct radeon_device *rdev)
{
if (RREG32(RADEON_RBBM_STATUS) & RADEON_RBBM_ACT
[PATCH 10/10] drm/radeon: start to document evergreen.c
From: Alex Deucher
Still a lot to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 120
1 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f716e08..0fc68a7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -99,6 +99,14 @@ void evergreen_fix_pci_max_read_req_size(struct
radeon_device *rdev)
}
}
+/**
+ * dce4_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (evergreen+).
+ */
void dce4_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -118,18 +126,49 @@ void dce4_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
+/**
+ * radeon_irq_kms_pflip_irq_get - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (evergreen+).
+ * Enables the pageflip irq (vblank irq).
+ */
void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * evergreen_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (evergreen+).
+ * Disables the pageflip irq (vblank irq).
+ */
void evergreen_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * evergreen_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (evergreen+).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 evergreen_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -214,6 +253,15 @@ int sumo_get_temp(struct radeon_device *rdev)
return actual_temp * 1000;
}
+/**
+ * sumo_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (sumo, trinity, SI).
+ * Used for profile mode only.
+ */
void sumo_pm_init_profile(struct radeon_device *rdev)
{
int idx;
@@ -265,6 +313,14 @@ void sumo_pm_init_profile(struct radeon_device *rdev)
rdev->pm.power_state[idx].num_clock_modes - 1;
}
+/**
+ * evergreen_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, etc.) (evergreen+).
+ */
void evergreen_pm_misc(struct radeon_device *rdev)
{
int req_ps_idx = rdev->pm.requested_power_state_index;
@@ -292,6 +348,13 @@ void evergreen_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (evergreen+).
+ */
void evergreen_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -310,6 +373,13 @@ void evergreen_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (evergreen+).
+ */
void evergreen_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -328,6 +398,15 @@ void evergreen_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_hpd_sense - hpd sense callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Checks if a digital monitor is connected (evergreen+).
+ * Returns true if connected, false if not connected.
+ */
bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd)
{
bool connected = false;
@@ -364,6 +443,14 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum
radeon_hpd_id hpd)
return connected;
}
+/**
+ * evergreen_hpd_set_polarity - hpd set polarity callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Set the polarity of the hpd pin (evergreen+).
+ */
void evergreen_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd)
{
@@ -424,6 +511,14 @@ void evergreen_hpd_set_polarity(struct radeon_device *rdev,
}
}
+/**
+ * evergreen_hpd_init - hpd setup callback.
+ *
+ *
Re: [PATCH] drm/radeon: fix VM page table setup on SI
On Fri, Jun 29, 2012 at 12:14 PM, Michel Dänzer wrote: > On Fre, 2012-06-29 at 11:28 -0400, Jerome Glisse wrote: >> On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher wrote: >> > On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote: >> >> On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote: >> >>> From: Alex Deucher >> >>> >> >>> Cayman and trinity allow for variable sized VM page >> >>> tables, but SI requires that all page tables be the >> >>> same size. The current code assumes variablely sized >> >>> VM page tables so SI may end up with part of each page >> >>> table overlapping with other memory which could end >> >>> up being interpreted by the VM hw as garbage. >> >>> >> >>> Change the code to better accomodate SI. Allocate enough >> >>> space for at least 2 full page tables and always set >> >>> last_pfn to max_pfn on SI so each VM is backed by a full >> >>> page table. This limits us to only 2 VMs active at any >> >>> given time on SI. This will be rectified and the code can >> >>> be reunified once we move to two level page tables. >> >>> >> >>> Signed-off-by: Alex Deucher >> >> >> >> This change breaks the radeonsi driver for me. egltri_screen (the >> >> 'golden' test for radeonsi at least basically working) locks up the >> >> GPU. >> >> >> >> I don't have any details about the lockup yet, as the GPU reset attempt >> >> hangs the machine. Any ideas offhand what radeonsi might be doing wrong? >> > >> > Maybe trying to access an unmapped page that happened to work by >> > accident before and now causes a fault in the VM which halts the MC? > > Indeed, looks like it: > > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000FF01B > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0202400C > > Oddly, while I have seen similar errors before (so at > least some access to unmapped pages was caught even before your patch), > I hadn't noticed them for a while with egltri_screen... > > > Anyway, some more experimentation shows that it doesn't happen if I skip > the clear, and it still happens when doing only a clear. I'll look into > what might be wrong with the clears next week. > > >> Yeah only thing i can think of, can you get dump of various mc fault >> reg after lockup ? > > Did you have any particular registers in mind? > I am guessing it's related to default page behavior, previously to this patch you would likely ended up writting/reading to the dummy page and thus not getting the segfault you deserved. With this patch you get the segfault you deserve ;) Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Fw: [ANNOUNCE] libdrm 2.4.37
git send-email doesn't appear to be doing the right thing. Begin forwarded message: Date: Fri, 29 Jun 2012 11:17:47 -0700 From: Ben Widawsky To: xorg-annou...@lists.freedesktop.org Cc: mesa-...@lists.freedesktop.org, intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: [ANNOUNCE] libdrm 2.4.37 I botched the 2.3.36 release quite royally. Here is 2.6.37 this time with the proper context APIs in place. Ben Widawsky (2): intel/context: create/destroy implementation configure: bump version for release Kristian Høgsberg (1): modetest: Dump bit field names git tag: libdrm-2.4.37 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.bz2 MD5: 9765919c28d4a54887576db3680137cc libdrm-2.4.37.tar.bz2 SHA1: fa8463e390eee9b589dc369abc4cbe3e4ef16d16 libdrm-2.4.37.tar.bz2 SHA256: e4ea39a901d4a8e59064f10f413bb037dad7790f7c16a5986e7cc1453b36488f libdrm-2.4.37.tar.bz2 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.gz MD5: 7f762bfa0bdaa7216c926d0dc9629e87 libdrm-2.4.37.tar.gz SHA1: b086dc3f64570ac9aa9eccd23a1e8156e9038995 libdrm-2.4.37.tar.gz SHA256: b530d71ff9a7f5252f450a386540fe8512bde033e8283fa6a1bbcd3c62fc91e4 libdrm-2.4.37.tar.gz ___ xorg-announce mailing list xorg-annou...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce -- Ben Widawsky, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] Fw: [ANNOUNCE] libdrm 2.4.37
On Fri, 29 Jun 2012 11:48:29 -0700 Ben Widawsky wrote: > git send-email doesn't appear to be doing the right thing. > > Begin forwarded message: > > Date: Fri, 29 Jun 2012 11:17:47 -0700 > From: Ben Widawsky > To: xorg-annou...@lists.freedesktop.org > Cc: mesa-...@lists.freedesktop.org, intel-...@lists.freedesktop.org, > dri-devel@lists.freedesktop.org Subject: [ANNOUNCE] libdrm 2.4.37 > > > I botched the 2.3.36 release quite royally. Here is 2.6.37 this time > with the proper context APIs in place. > Damn I suck. 2.4.36, and 2.4.37 respectively. Y'all knew what I meant. > Ben Widawsky (2): > intel/context: create/destroy implementation > configure: bump version for release > > Kristian Høgsberg (1): > modetest: Dump bit field names > > git tag: libdrm-2.4.37 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.bz2 > MD5: 9765919c28d4a54887576db3680137cc libdrm-2.4.37.tar.bz2 > SHA1: fa8463e390eee9b589dc369abc4cbe3e4ef16d16 libdrm-2.4.37.tar.bz2 > SHA256: > e4ea39a901d4a8e59064f10f413bb037dad7790f7c16a5986e7cc1453b36488f > libdrm-2.4.37.tar.bz2 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.gz > MD5: 7f762bfa0bdaa7216c926d0dc9629e87 libdrm-2.4.37.tar.gz > SHA1: b086dc3f64570ac9aa9eccd23a1e8156e9038995 libdrm-2.4.37.tar.gz > SHA256: > b530d71ff9a7f5252f450a386540fe8512bde033e8283fa6a1bbcd3c62fc91e4 > libdrm-2.4.37.tar.gz > > ___ > xorg-announce mailing list > xorg-annou...@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-announce > > -- Ben Widawsky, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: make a few SI functions static
From: Alex Deucher
Not used outside of si.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4071858..148471c 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2334,7 +2334,7 @@ void si_pcie_gart_tlb_flush(struct radeon_device *rdev)
WREG32(VM_INVALIDATE_REQUEST, 1);
}
-int si_pcie_gart_enable(struct radeon_device *rdev)
+static int si_pcie_gart_enable(struct radeon_device *rdev)
{
int r, i;
@@ -2407,7 +2407,7 @@ int si_pcie_gart_enable(struct radeon_device *rdev)
return 0;
}
-void si_pcie_gart_disable(struct radeon_device *rdev)
+static void si_pcie_gart_disable(struct radeon_device *rdev)
{
/* Disable all tables */
WREG32(VM_CONTEXT0_CNTL, 0);
@@ -2426,7 +2426,7 @@ void si_pcie_gart_disable(struct radeon_device *rdev)
radeon_gart_table_vram_unpin(rdev);
}
-void si_pcie_gart_fini(struct radeon_device *rdev)
+static void si_pcie_gart_fini(struct radeon_device *rdev)
{
si_pcie_gart_disable(rdev);
radeon_gart_table_vram_free(rdev);
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Mesa-dev] [libdrm PATCH 4/4] xf86drm.c: Make more code UDEV unrelevant and fix a memory leak.
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
> ---
> xf86drm.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 6ea068f..798f1fd 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char
> *id2, int pci_domain_ok)
> return 0;
> }
>
> +#if !defined(UDEV)
> /**
> * Handles error checking for chown call.
> *
> @@ -284,6 +285,7 @@ static int chown_check_return(const char *path, uid_t
> owner, gid_t group)
> path, errno, strerror(errno));
> return -1;
> }
> +#endif
>
> /**
> * Open the DRM device, creating it if necessary.
> @@ -303,13 +305,15 @@ static int drmOpenDevice(long dev, int minor, int type)
> stat_t st;
> charbuf[64];
> int fd;
> +
> +sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> +drmMsg("drmOpenDevice: node name is %s\n", buf);
> +
> +#if !defined(UDEV)
> mode_t devmode = DRM_DEV_MODE, serv_mode;
> int isroot = !geteuid();
> uid_t user= DRM_DEV_UID;
> gid_t group = DRM_DEV_GID, serv_group;
> -
> -sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> -drmMsg("drmOpenDevice: node name is %s\n", buf);
>
> if (drm_server_info) {
> drm_server_info->get_perms(&serv_group, &serv_mode);
> @@ -318,7 +322,6 @@ static int drmOpenDevice(long dev, int minor, int type)
> group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> }
>
> -#if !defined(UDEV)
> if (stat(DRM_DIR_NAME, &st)) {
> if (!isroot)
> return DRM_ERR_NOT_ROOT;
You should not mix code with declarations.
However, UDEV and non-UDEV codepaths share very little code. I'm wondering
whether it would be better to organize it like:
static int drmOpenDevice(long dev, int minor, int type)
{
#if defined(UDEV)
...
#else
...
#endif
}
> @@ -1395,8 +1398,10 @@ drm_context_t *drmGetReservedContextList(int fd, int
> *count)
> }
>
> res.contexts = list;
> -if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res))
> +if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res)) {
> + drmFree(retval);
> return NULL;
> +}
>
> for (i = 0; i < res.count; i++)
> retval[i] = list[i].handle;
> --
This is not enough. list will leak too.
Make it a separate patch please.
Marcin
Tegra DRM device tree bindings
> Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren: > > On 06/28/2012 05:12 AM, Thierry Reding wrote: > > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote: > > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding: > > ... > > >>> In the ideal case I would want to not have a carveout size at all. > > >>> However there may be situations where you need to make sure some > > >>> driver can allocate a given amount of memory. Having to specify > > >>> this using a kernel command-line parameter is cumbersome because > > >>> it may require changes to the bootloader or whatever. So if you > > >>> know that a particular board always needs > > >>> 128 MiB of carveout, then it makes sense to specify it on a > > >>> per-board basis. > > >> > > >> If we go with CMA, this is a non-issue, as CMA allows to use the > > >> contig area for normal allocations and only purges them if it > > >> really needs the space for contig allocs. > > > > > > CMA certainly sounds like the most simple approach. While it may not > > > be suited for 3D graphics or multimedia processing later on, I think > > > we could use it at a starting point to get basic framebuffer and X > > > support up and running. We can always move to something more > > > advanced like TTM later. > > > > I thought the whole purpose of CMA was to act as the infra-structure > > to provide buffers to 3D, camera, etc. in particular allowing sharing > > of buffers between them. In other words, isn't CMA the memory manager? > > If there's some deficiency with CMA for 3D graphics, it seems like > > that should be raised with those designing CMA. Or, am I way off base > > with my expectations of CMA? > > > CMA is just a way of providing large contiguous address space blocks in a > dynamic > fashion. The problem CMA solves is: we have a system with relatively low > amounts of sysmem (like 512MB), now to ensure we can always get large > contiguous buffers for use by GPU or VIDEO blocks, we need to set aside a > relatively large contiguous pool (like 128MB). So we are stealing 128MB of > memory from the system while we may or may not use it, which is bad. > Now CMA allows to say: I may need 128MB of contig space, but the system is > free > to use it as normal memory as long as I don't really need it. If the space is > really > needed, CMA purges pages from the area and may even swap them out. So yes > CMA is a memory allocator for contig memory. > > TTM though solves more advanced matters, like buffer synchronisation between > 3D and 2D block of hardware or syncing buffer access between GPU and CPU. > One of the most interesting things of TTM is the ability to purge the GPU DMA > buffers to scattered sysmem or even swap them out, if they are not currently > used by the GPU. It then makes sure to move them in the contig space again > when the GPU really needs them and fix up the GPU command stream with the > new buffer address. > > IMHO the best solution would be to use CMA as a flexible replacement of the > static carveout area and put TTM on top of this to solve the needs of graphics > drivers. We certainly don't want to reinvent the wheel inside CMA. We have > solutions for all those things in the kernel right now, we just have to glue > them > together in a sane way. > That is a great explanation. So could you explain what's the relation between IOMMU api and TTM(or GEM)? Terje said DMABUF api sits on top of IOMMU api. So for normal device drivers(such as drm), can forget iommu apis, just use dmabuf api is OK. If so, I wanna know does TTM/GEM and IOMMU are related? Or TTM/GEM uses dmabuf apis which calls iommu api to do memory allocation/mapping? > Thanks, > Lucas > > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the > body > of a message to majordomo at vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
Tegra DRM device tree bindings
> > Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren: > > > On 06/28/2012 05:12 AM, Thierry Reding wrote: > > > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote: > > > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding: > > > ... > > > >>> In the ideal case I would want to not have a carveout size at all. > > > >>> However there may be situations where you need to make sure some > > > >>> driver can allocate a given amount of memory. Having to specify > > > >>> this using a kernel command-line parameter is cumbersome because > > > >>> it may require changes to the bootloader or whatever. So if you > > > >>> know that a particular board always needs > > > >>> 128 MiB of carveout, then it makes sense to specify it on a > > > >>> per-board basis. > > > >> > > > >> If we go with CMA, this is a non-issue, as CMA allows to use the > > > >> contig area for normal allocations and only purges them if it > > > >> really needs the space for contig allocs. > > > > > > > > CMA certainly sounds like the most simple approach. While it may > > > > not be suited for 3D graphics or multimedia processing later on, I > > > > think we could use it at a starting point to get basic framebuffer > > > > and X support up and running. We can always move to something more > > > > advanced like TTM later. > > > > > > I thought the whole purpose of CMA was to act as the infra-structure > > > to provide buffers to 3D, camera, etc. in particular allowing > > > sharing of buffers between them. In other words, isn't CMA the memory > manager? > > > If there's some deficiency with CMA for 3D graphics, it seems like > > > that should be raised with those designing CMA. Or, am I way off > > > base with my expectations of CMA? > > > > > CMA is just a way of providing large contiguous address space blocks > > in a dynamic fashion. The problem CMA solves is: we have a system with > > relatively low amounts of sysmem (like 512MB), now to ensure we can > > always get large contiguous buffers for use by GPU or VIDEO blocks, we > > need to set aside a relatively large contiguous pool (like 128MB). So > > we are stealing 128MB of memory from the system while we may or may not > use it, which is bad. > > Now CMA allows to say: I may need 128MB of contig space, but the > > system is free to use it as normal memory as long as I don't really > > need it. If the space is really needed, CMA purges pages from the area > > and may even swap them out. So yes CMA is a memory allocator for contig > memory. > > > > TTM though solves more advanced matters, like buffer synchronisation > > between 3D and 2D block of hardware or syncing buffer access between GPU > and CPU. > > One of the most interesting things of TTM is the ability to purge the > > GPU DMA buffers to scattered sysmem or even swap them out, if they are > > not currently used by the GPU. It then makes sure to move them in the > > contig space again when the GPU really needs them and fix up the GPU > > command stream with the new buffer address. > > > > IMHO the best solution would be to use CMA as a flexible replacement > > of the static carveout area and put TTM on top of this to solve the > > needs of graphics drivers. We certainly don't want to reinvent the > > wheel inside CMA. We have solutions for all those things in the kernel > > right now, we just have to glue them together in a sane way. > > > > That is a great explanation. So could you explain what's the relation between > IOMMU api and TTM(or GEM)? > Terje said DMABUF api sits on top of IOMMU api. So for normal device > drivers(such as drm), can forget iommu apis, just use dmabuf api is OK. If > so, I > wanna know does TTM/GEM and IOMMU are related? Or TTM/GEM uses > dmabuf apis which calls iommu api to do memory allocation/mapping? > Sorry for my stupid question. DMA mapping api sits on top of IOMMU api, not DMABUF. DMABUF is used to share buffers. So please ignore what I said. > > Thanks, > > Lucas > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-tegra" > > in the body of a message to majordomo at vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pci_regs: define LNKSTA2 pcie cap + bits.
Hi, 2012-06-27 09:35 keltez?ssel, Dave Airlie ?rta: > From: Dave Airlie > > We need these for detecting the max link speed for drm drivers. > > Signed-off-by: Dave Airlie I have reported this in March: http://lists.freedesktop.org/archives/dri-devel/2012-March/019731.html Since then, this motherboard received 3 BIOS upgrades (latest is version 1208) and the system was upgraded to Fedora 17. With kernel 3.5-rc4+ (commit 47b514cd476db2eca066a2ad31501b079d6c9cce) plus this series of patches, the reported problem doesn't appear anymore. lspci reports PCIe gen2 speed for my Radeon HD6570 and gen1 speed for my 3ware 9650SE: [zozo at localhost ~]$ sudo lspci -vvv -s 01:00.0 01:00.0 VGA compatible controller: ATI Technologies Inc NI Turks [AMD Radeon HD 6500] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e193 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon [zozo at localhost ~]$ sudo lspci -vvv -s 08:00.0 08:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01) Subsystem: 3ware Inc 9650SE SATA-II RAID PCIe Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- > --- > include/linux/pci_regs.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h > index 4b608f5..7f04132 100644 > --- a/include/linux/pci_regs.h > +++ b/include/linux/pci_regs.h > @@ -521,6 +521,11 @@ > #define PCI_EXP_OBFF_MSGA_EN 0x2000 /* OBFF enable with Message > type A */ > #define PCI_EXP_OBFF_MSGB_EN 0x4000 /* OBFF enable with Message > type B */ > #define PCI_EXP_OBFF_WAKE_EN 0x6000 /* OBFF using WAKE# signaling */ > +#define PCI_EXP_LNKCAP2 44 /* Link Capability 2 */ > +#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x01 /* Current Link Speed 2.5GT/s */ > +#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x02 /* Current Link Speed 5.0GT/s */ > +#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x04 /* Current Link Speed 8.0GT/s */ > +#define PCI_EXP_LNKCAP2_CROSSLINK 0x100 /* Crosslink supported */ > #define PCI_EXP_LNKCTL2 48 /* Link Control 2 */ > #define PCI_EXP_SLTCTL2 56 /* Slot Control 2 */ >
[PATCH 3/4] drm/exynos: check if gem type is valid or not for fb.
physically non-contiguous memory can't be used for framebuffer yet.
so this patch checks if the gem memory type is valid or not for the
framebuffer.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..6aba1e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -31,6 +31,7 @@
#include "drm_crtc_helper.h"
#include "drm_fb_helper.h"
+#include "exynos_drm.h"
#include "exynos_drm_drv.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
@@ -48,6 +49,22 @@ struct exynos_drm_fb {
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
+static int check_fb_gem_memory_type(struct drm_device *drm_dev,
+ struct exynos_drm_gem_obj *exynos_gem_obj)
+{
+ unsigned int flags;
+
+ flags = exynos_gem_obj->flags;
+
+ /* not support physically non-continuous memory for fb yet. TODO */
+ if (IS_NONCONTIG_BUFFER(flags)) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
{
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
@@ -107,8 +124,17 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_gem_object *obj)
{
struct exynos_drm_fb *exynos_fb;
+ struct exynos_drm_gem_obj *exynos_gem_obj;
int ret;
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+
+ ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
+ if (ret < 0) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ return ERR_PTR(-EINVAL);
+ }
+
exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
if (!exynos_fb) {
DRM_ERROR("failed to allocate exynos drm framebuffer\n");
@@ -155,6 +181,9 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
nr = exynos_drm_format_num_buffers(fb->pixel_format);
for (i = 1; i < nr; i++) {
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ int ret;
+
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
@@ -163,6 +192,15 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+
+ ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
+ if (ret < 0) {
+ DRM_ERROR("cannot use this gem memory type for fb.\n");
+ exynos_drm_fb_destroy(fb);
+ return ERR_PTR(ret);
+ }
+
exynos_fb->exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}
--
1.7.4.1
[PATCH 0/4] drm/exynos: add exceptions to framebuffer module
this patch sets fixes some minor issues to exynos drm framebuffer module. when user sent wrong gem memory type, framebuffer size and so on to driver side, the driver has to check if those data are valid or not properly. Thanks. Inki Dae (4): drm/exynos: fixed a comment to gem size. drm/exynos: add packed_size not aligned in page unit. drm/exynos: check if gem type is valid or not for fb. drm/exynos: check if framebuffer and gem size are valid or not. drivers/gpu/drm/exynos/exynos_drm_fb.c | 86 ++- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 + drivers/gpu/drm/exynos/exynos_drm_gem.h |6 ++- 3 files changed, 91 insertions(+), 3 deletions(-) -- 1.7.4.1
[PATCH 1/4] drm/exynos: fixed a comment to gem size.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 14d038b..085b2a5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -63,7 +63,8 @@ struct exynos_drm_gem_buf {
* by user request or at framebuffer creation.
* continuous memory region allocated by user request
* or at framebuffer creation.
- * @size: total memory size to physically non-continuous memory region.
+ * @size: size requested from user, in bytes and this size is aligned
+ * in page unit.
* @flags: indicate memory type to allocated buffer and cache attruibute.
*
* P.S. this object would be transfered to user as kms_bo.handle so
--
1.7.4.1
[PATCH 2/4] drm/exynos: add packed_size not aligned in page unit.
this patch adds packed_size variable in exynos_drm_gem_obj struct
and this variable is used to check for valid framebuffer and gem size.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |2 ++
drivers/gpu/drm/exynos/exynos_drm_gem.h |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 411d82b..94e8137 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -345,6 +345,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
{
struct exynos_drm_gem_obj *exynos_gem_obj;
struct exynos_drm_gem_buf *buf;
+ unsigned long packed_size = size;
int ret;
if (!size) {
@@ -369,6 +370,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
goto err_fini_buf;
}
+ exynos_gem_obj->packed_size = packed_size;
exynos_gem_obj->buffer = buf;
/* set memory type and cache attribute from user side. */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 085b2a5..1d80cb2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -65,6 +65,8 @@ struct exynos_drm_gem_buf {
* or at framebuffer creation.
* @size: size requested from user, in bytes and this size is aligned
* in page unit.
+ * @packed_size: real size of the gem object, in bytes and
+ * this size isn't aligned in page unit.
* @flags: indicate memory type to allocated buffer and cache attruibute.
*
* P.S. this object would be transfered to user as kms_bo.handle so
@@ -74,6 +76,7 @@ struct exynos_drm_gem_obj {
struct drm_gem_object base;
struct exynos_drm_gem_buf *buffer;
unsigned long size;
+ unsigned long packed_size;
unsigned intflags;
};
--
1.7.4.1
[PATCH 4/4] drm/exynos: check if framebuffer and gem size are valid or not.
with addfb request by user, wrong framebuffer or gem size could be sent
to kernel side so this could induce invalid memory access by dma of a device.
this patch checks if framebuffer and gem size are valid or not to avoid
this issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 48 ++-
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 6aba1e5..ce0f18d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -65,6 +65,45 @@ static int check_fb_gem_memory_type(struct drm_device
*drm_dev,
return 0;
}
+static int check_fb_gem_size(struct drm_device *drm_dev,
+ struct drm_framebuffer *fb,
+ unsigned int nr)
+{
+ unsigned long fb_size;
+ struct drm_gem_object *obj;
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
+
+ /* in case of RGB format, only one plane is used. */
+ if (nr < 2) {
+ exynos_gem_obj = exynos_fb->exynos_gem_obj[0];
+ obj = &exynos_gem_obj->base;
+ fb_size = fb->width * ((fb->bits_per_pixel + 7) >> 3)
+ * fb->height;
+
+ if (fb_size != exynos_gem_obj->packed_size) {
+ DRM_ERROR("invalid fb or gem size.\n");
+ return -EINVAL;
+ }
+ /* in case of NV12MT, YUV420M and so on, two and three planes. */
+ } else {
+ unsigned int i;
+
+ for (i = 0; i < nr; i++) {
+ exynos_gem_obj = exynos_fb->exynos_gem_obj[i];
+ obj = &exynos_gem_obj->base;
+ fb_size = fb->pitches[i] * fb->height;
+
+ if (fb_size != exynos_gem_obj->packed_size) {
+ DRM_ERROR("invalid fb or gem size.\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+
static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
{
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
@@ -160,8 +199,7 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
- int i;
+ int nr, i, ret;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -204,6 +242,12 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
exynos_fb->exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}
+ ret = check_fb_gem_size(dev, fb, nr);
+ if (ret < 0) {
+ exynos_drm_fb_destroy(fb);
+ return ERR_PTR(ret);
+ }
+
return fb;
}
--
1.7.4.1
[Lf_driver_backport] [ANN] compat-drm tree
> Given that the compat module is shared, and a quite a bit of other > code / style is shared, and I'd love to see us start to formalize > documenting collateral evolutions on the kernel in one place I'd like > to propose to you merging this into compat-wirless and we then rename > the project to compat-drivers, with you maintaining the drm > components. This also gives us an already established quick outlet for > redistribution as well. What do you think? Okay, this makes sense. > > Some comments: > > In the patches/ directory if you can add a description on the top of > each patch explaining *why* that collateral evolution was not > backportable through compat it would help. It sets the standard for > others introducing similar types of patches. Ah I forgot about this :) > > For patches/00-vga_switcheroo_client_ops.patch: > > I wonder if you may be able to get rid of this patch. The attached > patch is an RFC patch for compat.git which explains how I'm thinking > this may be possible, I don't have time to test it but let me know > what you think. Okay will test and try to drop the patch as well. Thanks :) -- Ozan ?a?layan
[PATCH] staging: drm/omap: add rotation properties
On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: > From: Rob Clark > > Use tiled buffers for rotated/reflected scanout, with CRTC and plane > properties as the interface for userspace to configure rotation. > > Signed-off-by: Rob Clark > +/* this should probably be in drm-core to standardize amongst drivers */ > +#define DRM_ROTATE_0 0 > +#define DRM_ROTATE_901 > +#define DRM_ROTATE_180 2 > +#define DRM_ROTATE_270 3 > +#define DRM_REFLECT_X4 > +#define DRM_REFLECT_Y5 Are both reflect X and Y needed? You can get all the possible orientations with just one of the reflects. And I think the word "mirror" represents nicely what the reflect does, i.e. if you look at the mirror, the image you see is flipped horizontally. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120629/8c147b25/attachment.pgp>
[PATCH] staging: drm/omap: add rotation properties
On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen wrote: > On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: >> From: Rob Clark >> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane >> properties as the interface for userspace to configure rotation. >> >> Signed-off-by: Rob Clark > >> +/* this should probably be in drm-core to standardize amongst drivers */ >> +#define DRM_ROTATE_0 0 >> +#define DRM_ROTATE_90 ? ? ? ?1 >> +#define DRM_ROTATE_180 ? ? ? 2 >> +#define DRM_ROTATE_270 ? ? ? 3 >> +#define DRM_REFLECT_X ? ? ? ?4 >> +#define DRM_REFLECT_Y ? ? ? ?5 > > Are both reflect X and Y needed? You can get all the possible > orientations with just one of the reflects. > > And I think the word "mirror" represents nicely what the reflect does, > i.e. if you look at the mirror, the image you see is flipped > horizontally. fwiw these values are aligned with what is used in userspace xrandr.. an earlier version of this patch used just 3 bits, which where aligned with what the omap hw uses and can describe all possible combinations of mirroring and isomorphic rotation (x-invert, y-invert, and xy-flip). But the advantage of the xrandr approach is you can more easily leave out bits for rotation/mirroring modes that your hw does not support.. for example if some hw supports only certain rotations or does not support mirror/reflect. BR, -R > ?Tomi >
[Bug 51557] New: Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51557 Bug #: 51557 Summary: Ubuntu[12.04]: X server crashes on running any command in xterm window Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hysvats at gmail.com Created attachment 63606 --> https://bugs.freedesktop.org/attachment.cgi?id=63606 Xorg.log Driver Stack Details: = 1)Kernel-3.4.0-030400-generic-pae 2)drm-2.4.35 3)Mesa-8.1-devel (git-93a42d1) 4)Xorg-server-1.11.3 5)xf86-video-ati- master System Environment: === Asic : RV635XT O.S. : Ubuntu-12.04 (32 bit) Processor: Intel(R) Xeon(R) @ 2.40 GHz Memory : 2 GB #startx #open a Terminal and run any command Xserver crashes. Backtarce is in Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] New: Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Bug #: 51558 Summary: Ubuntu[12.04]: X server crashes on running any command in xterm window Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hysvats at gmail.com Created attachment 63607 --> https://bugs.freedesktop.org/attachment.cgi?id=63607 Xorg.log Driver Stack Details: = 1)Kernel-3.4.0-030400-generic-pae 2)drm-2.4.35 3)Mesa-8.1-devel (git-93a42d1) 4)Xorg-server-1.11.3 5)xf86-video-ati- master System Environment: === Asic : RV635XT O.S. : Ubuntu-12.04 (32 bit) Processor: Intel(R) Xeon(R) @ 2.40 GHz Memory : 2 GB #startx #open a Terminal and run any command Xserver crashes. Backtarce is in Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #1 from samit vats 2012-06-29 05:27:59 PDT --- Created attachment 63608 --> https://bugs.freedesktop.org/attachment.cgi?id=63608 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #2 from samit vats 2012-06-29 05:28:30 PDT --- Created attachment 63609 --> https://bugs.freedesktop.org/attachment.cgi?id=63609 xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51557] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51557 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michel D?nzer 2012-06-29 06:18:33 PDT --- *** This bug has been marked as a duplicate of bug 51558 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 --- Comment #3 from Michel D?nzer 2012-06-29 06:18:33 PDT --- *** Bug 51557 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Michel D?nzer changed: What|Removed |Added Attachment #63607|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51558] Ubuntu[12.04]: X server crashes on running any command in xterm window
https://bugs.freedesktop.org/show_bug.cgi?id=51558 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Michel D?nzer 2012-06-29 06:26:18 PDT --- [ 2910.364] (II) LoadModule: "mouse" [ 2910.364] (II) Loading /root/install/lib/xorg/modules/input/mouse_drv.so [ 2910.364] (II) Module mouse: vendor="X.Org Foundation" [ 2910.364] compiled for 1.11.3, module version = 1.7.1 [ 2910.364] Module class: X.Org XInput Driver [ 2910.364] ABI class: X.Org XInput driver, version 16.0 [ 2910.364] (WW) module ABI major version (16) doesn't match the server's version (13) [ 2910.366] (II) LoadModule: "kbd" [ 2910.366] (II) Loading /root/install/lib/xorg/modules/input/kbd_drv.so [ 2910.366] (II) Module kbd: vendor="X.Org Foundation" [ 2910.366] compiled for 1.11.3, module version = 1.6.1 [ 2910.366] Module class: X.Org XInput Driver [ 2910.366] ABI class: X.Org XInput driver, version 16.0 [ 2910.366] (WW) module ABI major version (16) doesn't match the server's version (13) Looks like the X mouse/kbd drivers were built / installed incorrectly. BTW, it's recommended to use the evdev driver for input instead of these two drivers on Linux. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Tegra DRM device tree bindings
On 28.06.2012 20:19, Lucas Stach wrote: > TTM though solves more advanced matters, like buffer synchronisation > between 3D and 2D block of hardware or syncing buffer access between GPU > and CPU. > One of the most interesting things of TTM is the ability to purge the > GPU DMA buffers to scattered sysmem or even swap them out, if they are > not currently used by the GPU. It then makes sure to move them in the > contig space again when the GPU really needs them and fix up the GPU > command stream with the new buffer address. We preferably should choose dma_buf as a common interface towards buffers. That way whatever we choose as the memory manager, all dma_buf aware drivers will be able to use buffers allocated by other drivers. We probably need to accommodate multiple memory managers to take care of legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we have the possibility to do zero-copy video without forcing everybody to use the same memory manager. As I understand, TTM is good for platforms where we have a separate frame buffer memory, as is the case with most of the graphics cards. In Tegra, graphics and CPU occupy the same memory, so I'm not sure if we require the level of functionality that TTM provides. I guess the level of functionality and the complexity that it brings is one reason why TTM hasn't really caught on in the ARM world. The synchronization primitives attached to TTM are slightly confusing. At the bottom level, it's operations which need to be synchronized between each other. That's the API level that we should to export from kernel to user space. It's then up to libdrm level (or whatever is doing the rendering in user space) to decide which operations it wants to have completed before a buffer can be reused/read/passed on to the next stage. Anyway, if we hide the memory manager behind dma_buf, we're free to muck around with multiple of them and see what works best. Terje
[PATCH 00/10] Start documenting the radeon drm better
From: Alex Deucher This is something I've been wanting to do for a while and I finally spent a little time getting a start on it. There is still a lot to do and not all of my descriptions are great, but I think we can document the rest in bits and pieces. I also added a note about what asics the function is applicable to. I tried to start with the more common and complex code. I was thinking it would make sense to have an informal documentation policy something like the following: 1. If you edit an undocumented function, add documentation 2. If you edit a documented function and change how it works, update the documentation 3. All new functions added should be documented Fulfulling all of these for stable fixes could pose problems so obviously there is some leeway. Thoughts? Alex Deucher (10): drm/radeon: document radeon_device.c drm/radeon: document radeon_kms.c drm/radeon: document radeon_irq_kms.c drm/radeon: document radeon_asic.c drm/radeon: document radeon_fence.c drm/radeon: document radeon_ring.c drm/radeon: document non-VM functions in radeon_gart.c drm/radeon: document VM functions in radeon_gart.c drm/radeon: start to document the functions r100.c drm/radeon: start to document evergreen.c drivers/gpu/drm/radeon/evergreen.c | 120 ++ drivers/gpu/drm/radeon/r100.c | 127 ++- drivers/gpu/drm/radeon/radeon_asic.c| 46 drivers/gpu/drm/radeon/radeon_device.c | 344 +++- drivers/gpu/drm/radeon/radeon_fence.c | 373 + drivers/gpu/drm/radeon/radeon_gart.c| 391 ++- drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ drivers/gpu/drm/radeon/radeon_ring.c| 374 +- 9 files changed, 2041 insertions(+), 10 deletions(-) -- 1.7.7.5
[PATCH 01/10] drm/radeon: document radeon_device.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_device.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_device.c | 344 +++-
1 files changed, 341 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index f654ba8..4cce4f4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -96,8 +96,12 @@ static const char radeon_family_name[][16] = {
"LAST",
};
-/*
- * Clear GPU surface registers.
+/**
+ * radeon_surface_init - Clear GPU surface registers.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clear GPU surface registers (r1xx-r5xx).
*/
void radeon_surface_init(struct radeon_device *rdev)
{
@@ -119,6 +123,13 @@ void radeon_surface_init(struct radeon_device *rdev)
/*
* GPU scratch registers helpers function.
*/
+/**
+ * radeon_scratch_init - Init scratch register driver information.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init CP scratch register driver information (r1xx-r5xx)
+ */
void radeon_scratch_init(struct radeon_device *rdev)
{
int i;
@@ -136,6 +147,15 @@ void radeon_scratch_init(struct radeon_device *rdev)
}
}
+/**
+ * radeon_scratch_get - Allocate a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Allocate a CP scratch register for use by the driver (all asics).
+ * Returns 0 on success or -EINVAL on failure.
+ */
int radeon_scratch_get(struct radeon_device *rdev, uint32_t *reg)
{
int i;
@@ -150,6 +170,14 @@ int radeon_scratch_get(struct radeon_device *rdev,
uint32_t *reg)
return -EINVAL;
}
+/**
+ * radeon_scratch_free - Free a scratch register
+ *
+ * @rdev: radeon_device pointer
+ * @reg: scratch register mmio offset
+ *
+ * Free a CP scratch register allocated for use by the driver (all asics)
+ */
void radeon_scratch_free(struct radeon_device *rdev, uint32_t reg)
{
int i;
@@ -162,6 +190,16 @@ void radeon_scratch_free(struct radeon_device *rdev,
uint32_t reg)
}
}
+/**
+ * radeon_wb_disable - Disable Writeback
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback (all asics). Used for suspend.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
void radeon_wb_disable(struct radeon_device *rdev)
{
int r;
@@ -177,6 +215,17 @@ void radeon_wb_disable(struct radeon_device *rdev)
rdev->wb.enabled = false;
}
+/**
+ * radeon_wb_fini - Disable Writeback and free memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver shutdown.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
void radeon_wb_fini(struct radeon_device *rdev)
{
radeon_wb_disable(rdev);
@@ -187,6 +236,18 @@ void radeon_wb_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_wb_init- Init Writeback driver info and allocate memory
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Disables Writeback and frees the Writeback memory (all asics).
+ * Used at driver startup.
+ * Returns 0 on success or an -error on failure.
+ * Writeback is the the method by which the the GPU updates special pages
+ * in memory with the status of certain GPU events (fences, ring pointers,
+ * etc.).
+ */
int radeon_wb_init(struct radeon_device *rdev)
{
int r;
@@ -355,6 +416,15 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
/*
* GPU helpers function.
*/
+/**
+ * radeon_card_posted - check if the hw has already been initialized
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic has been initialized (all asics).
+ * Used at driver startup.
+ * Returns true if initialized or false if not.
+ */
bool radeon_card_posted(struct radeon_device *rdev)
{
uint32_t reg;
@@ -404,6 +474,14 @@ bool radeon_card_posted(struct radeon_device *rdev)
}
+/**
+ * radeon_update_bandwidth_info - update display bandwidth params
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Used when sclk/mclk are switched or display modes are set.
+ * params are used to calculate display watermarks (all asics)
+ */
void radeon_update_bandwidth_info(struct radeon_device *rdev)
{
fixed20_12 a;
@@ -424,6 +502,15 @@ void radeon_update_bandwidth_info(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_boot_test_post_card - check and possibly initialize the hw
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check if the asic is initialized and if not, attempt to initialize
+ * it (all asics).
+ * Returns true if initialized or false if not.
+ */
bool radeon_boot_test_post_card(struct radeon_device *rdev)
{
if (radeon_card_posted(rdev))
@@ -442,6 +529,16 @@
[PATCH 02/10] drm/radeon: document radeon_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 126 +++
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 18b81d6..1d73f16 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -33,6 +33,17 @@
#include
#include
+/**
+ * radeon_driver_unload_kms - Main unload function for KMS.
+ *
+ * @dev: drm dev pointer
+ *
+ * This is the main unload function for KMS (all asics).
+ * It calls radeon_modeset_fini() to tear down the
+ * displays, and radeon_device_fini() to tear down
+ * the rest of the device (CP, writeback, etc.).
+ * Returns 0 on success.
+ */
int radeon_driver_unload_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -46,6 +57,19 @@ int radeon_driver_unload_kms(struct drm_device *dev)
return 0;
}
+/**
+ * radeon_driver_load_kms - Main load function for KMS.
+ *
+ * @dev: drm dev pointer
+ * @flags: device flags
+ *
+ * This is the main load function for KMS (all asics).
+ * It calls radeon_device_init() to set up the non-display
+ * parts of the chip (asic init, CP, writeback, etc.), and
+ * radeon_modeset_init() to set up the display parts
+ * (crtcs, encoders, hotplug detect, etc.).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags)
{
struct radeon_device *rdev;
@@ -96,6 +120,16 @@ out:
return r;
}
+/**
+ * radeon_set_filp_rights - Set filp right.
+ *
+ * @dev: drm dev pointer
+ * @owner: drm file
+ * @applier: drm file
+ * @value: value
+ *
+ * Sets the filp rights for the device (all asics).
+ */
static void radeon_set_filp_rights(struct drm_device *dev,
struct drm_file **owner,
struct drm_file *applier,
@@ -118,6 +152,18 @@ static void radeon_set_filp_rights(struct drm_device *dev,
/*
* Userspace get information ioctl
*/
+/**
+ * radeon_info_ioctl - answer a device specific request.
+ *
+ * @rdev: radeon device pointer
+ * @data: request object
+ * @filp: drm filp
+ *
+ * This function is used to pass device specific parameters to the userspace
+ * drivers. Examples include: pci device id, pipeline parms, tiling params,
+ * etc. (all asics).
+ * Returns 0 on success, -EINVAL on failure.
+ */
int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp)
{
struct radeon_device *rdev = dev->dev_private;
@@ -301,16 +347,40 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
/*
* Outdated mess for old drm with Xorg being in charge (void function now).
*/
+/**
+ * radeon_driver_firstopen_kms - drm callback for first open
+ *
+ * @dev: drm dev pointer
+ *
+ * Nothing to be done for KMS (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_firstopen_kms(struct drm_device *dev)
{
return 0;
}
+/**
+ * radeon_driver_firstopen_kms - drm callback for last close
+ *
+ * @dev: drm dev pointer
+ *
+ * Switch vga switcheroo state after last close (all asics).
+ */
void radeon_driver_lastclose_kms(struct drm_device *dev)
{
vga_switcheroo_process_delayed_switch();
}
+/**
+ * radeon_driver_open_kms - drm callback for open
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device open, init vm on cayman+ (all asics).
+ * Returns 0 on success, error on failure.
+ */
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
{
struct radeon_device *rdev = dev->dev_private;
@@ -339,6 +409,14 @@ int radeon_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
return 0;
}
+/**
+ * radeon_driver_postclose_kms - drm callback for post close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device post close, tear down vm on cayman+ (all asics).
+ */
void radeon_driver_postclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -354,6 +432,15 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
}
}
+/**
+ * radeon_driver_preclose_kms - drm callback for pre close
+ *
+ * @dev: drm dev pointer
+ * @file_priv: drm file
+ *
+ * On device pre close, tear down hyperz and cmask filps on r1xx-r5xx
+ * (all asics).
+ */
void radeon_driver_preclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
{
@@ -367,6 +454,15 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
/*
* VBlank related functions.
*/
+/**
+ * radeon_get_vblank_counter_kms - get frame count
+ *
+ * @dev: drm dev pointer
+ * @crtc: crtc to get the frame count from
+ *
+ * Gets the frame count on the requested crtc (all asics).
+ * Returns frame count on success, -EINVAL on failure.
+ */
[PATCH 03/10] drm/radeon: document radeon_irq_kms.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_irq_kms.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 +++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 6664514..afaa172 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -34,6 +34,15 @@
#define RADEON_WAIT_IDLE_TIMEOUT 200
+/**
+ * radeon_driver_irq_handler_kms - irq handler for KMS
+ *
+ * @DRM_IRQ_ARGS: args
+ *
+ * This is the irq handler for the radeon KMS driver (all asics).
+ * radeon_irq_process is a macro that points to the per-asic
+ * irq handler callback.
+ */
irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
@@ -45,6 +54,17 @@ irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS)
/*
* Handle hotplug events outside the interrupt handler proper.
*/
+/**
+ * radeon_hotplug_work_func - display hotplug work handler
+ *
+ * @work: work struct
+ *
+ * This is the hot plug event work handler (all asics).
+ * The work gets scheduled from the irq handler if there
+ * was a hot plug interrupt. It walks the connector table
+ * and calls the hotplug handler for each one, then sends
+ * a drm hotplug event to alert userspace.
+ */
static void radeon_hotplug_work_func(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
@@ -61,6 +81,14 @@ static void radeon_hotplug_work_func(struct work_struct
*work)
drm_helper_hpd_irq_event(dev);
}
+/**
+ * radeon_driver_irq_preinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Gets the hw ready to enable irqs (all asics).
+ * This function disables all interrupt sources on the GPU.
+ */
void radeon_driver_irq_preinstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -85,12 +113,27 @@ void radeon_driver_irq_preinstall_kms(struct drm_device
*dev)
radeon_irq_process(rdev);
}
+/**
+ * radeon_driver_irq_postinstall_kms - drm irq preinstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * Handles stuff to be done after enabling irqs (all asics).
+ * Returns 0 on success.
+ */
int radeon_driver_irq_postinstall_kms(struct drm_device *dev)
{
dev->max_vblank_count = 0x001f;
return 0;
}
+/**
+ * radeon_driver_irq_uninstall_kms - drm irq uninstall callback
+ *
+ * @dev: drm dev pointer
+ *
+ * This function disables all interrupt sources on the GPU (all asics).
+ */
void radeon_driver_irq_uninstall_kms(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
@@ -116,6 +159,16 @@ void radeon_driver_irq_uninstall_kms(struct drm_device
*dev)
spin_unlock_irqrestore(&rdev->irq.lock, irqflags);
}
+/**
+ * radeon_msi_ok - asic specific msi checks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Handles asic specific MSI checks to determine if
+ * MSIs should be enabled on a particular chip (all asics).
+ * Returns true if MSIs should be enabled, false if MSIs
+ * should not be enabled.
+ */
static bool radeon_msi_ok(struct radeon_device *rdev)
{
/* RV370/RV380 was first asic with MSI support */
@@ -168,6 +221,14 @@ static bool radeon_msi_ok(struct radeon_device *rdev)
return true;
}
+/**
+ * radeon_irq_kms_init - init driver interrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the work irq handlers, vblank init, MSIs, etc. (all asics).
+ * Returns 0 for success, error for failure.
+ */
int radeon_irq_kms_init(struct radeon_device *rdev)
{
int r = 0;
@@ -200,6 +261,13 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_irq_kms_fini - tear down driver interrrupt info
+ *
+ * @rdev: radeon device pointer
+ *
+ * Tears down the work irq handlers, vblank handlers, MSIs, etc. (all asics).
+ */
void radeon_irq_kms_fini(struct radeon_device *rdev)
{
drm_vblank_cleanup(rdev->ddev);
@@ -212,6 +280,16 @@ void radeon_irq_kms_fini(struct radeon_device *rdev)
flush_work_sync(&rdev->hotplug_work);
}
+/**
+ * radeon_irq_kms_sw_irq_get - enable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to enable
+ *
+ * Enables the software interrupt for a specific ring (all asics).
+ * The software interrupt is generally used to signal a fence on
+ * a particular ring.
+ */
void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring)
{
unsigned long irqflags;
@@ -226,6 +304,16 @@ void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev,
int ring)
}
}
+/**
+ * radeon_irq_kms_sw_irq_put - disable software interrupt
+ *
+ * @rdev: radeon device pointer
+ * @ring: ring whose interrupt you want to disable
+ *
+ * Disables the software interrupt for a specific ring (
[PATCH 04/10] drm/radeon: document radeon_asic.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_asic.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index f533df5..973417c 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -40,6 +40,16 @@
/*
* Registers accessors functions.
*/
+/**
+ * radeon_invalid_rreg - dummy reg read function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ * Returns the value in the register.
+ */
static uint32_t radeon_invalid_rreg(struct radeon_device *rdev, uint32_t reg)
{
DRM_ERROR("Invalid callback to read register 0x%04X\n", reg);
@@ -47,6 +57,16 @@ static uint32_t radeon_invalid_rreg(struct radeon_device
*rdev, uint32_t reg)
return 0;
}
+/**
+ * radeon_invalid_wreg - dummy reg write function
+ *
+ * @rdev: radeon device pointer
+ * @reg: offset of register
+ * @v: value to write to the register
+ *
+ * Dummy register read function. Used for register blocks
+ * that certain asics don't have (all asics).
+ */
static void radeon_invalid_wreg(struct radeon_device *rdev, uint32_t reg,
uint32_t v)
{
DRM_ERROR("Invalid callback to write register 0x%04X with 0x%08X\n",
@@ -54,6 +74,14 @@ static void radeon_invalid_wreg(struct radeon_device *rdev,
uint32_t reg, uint32
BUG_ON(1);
}
+/**
+ * radeon_register_accessor_init - sets up the register accessor callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Sets up the register accessor callbacks for various register
+ * apertures. Not all asics have all apertures (all asics).
+ */
static void radeon_register_accessor_init(struct radeon_device *rdev)
{
rdev->mc_rreg = &radeon_invalid_rreg;
@@ -102,6 +130,14 @@ static void radeon_register_accessor_init(struct
radeon_device *rdev)
/* helper to disable agp */
+/**
+ * radeon_agp_disable - AGP disable helper function
+ *
+ * @rdev: radeon device pointer
+ *
+ * Removes AGP flags and changes the gart callbacks on AGP
+ * cards when using the internal gart rather than AGP (all asics).
+ */
void radeon_agp_disable(struct radeon_device *rdev)
{
rdev->flags &= ~RADEON_IS_AGP;
@@ -1608,6 +1644,16 @@ static struct radeon_asic si_asic = {
},
};
+/**
+ * radeon_asic_init - register asic specific callbacks
+ *
+ * @rdev: radeon device pointer
+ *
+ * Registers the appropriate asic specific callbacks for each
+ * chip family. Also sets other asics specific info like the number
+ * of crtcs and the register aperture accessors (all asics).
+ * Returns 0 for success.
+ */
int radeon_asic_init(struct radeon_device *rdev)
{
radeon_register_accessor_init(rdev);
--
1.7.7.5
[PATCH 05/10] drm/radeon: document radeon_fence.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_fence.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c | 373 +
1 files changed, 373 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 67f6fa9..604352e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -40,6 +40,22 @@
#include "radeon.h"
#include "radeon_trace.h"
+/**
+ * radeon_fence_write - write a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @seq: sequence number to write
+ * @ring: ring index the fence is associated with
+ *
+ * Writes a fence value to memory or a scratch register (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static void radeon_fence_write(struct radeon_device *rdev, u32 seq, int ring)
{
if (rdev->wb.enabled) {
@@ -49,6 +65,22 @@ static void radeon_fence_write(struct radeon_device *rdev,
u32 seq, int ring)
}
}
+/**
+ * radeon_fence_read - read a fence value
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Reads a fence value from memory or a scratch register (all asics).
+ * Returns the value of the fence read from memory or register.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static u32 radeon_fence_read(struct radeon_device *rdev, int ring)
{
u32 seq = 0;
@@ -61,6 +93,23 @@ static u32 radeon_fence_read(struct radeon_device *rdev, int
ring)
return seq;
}
+/**
+ * radeon_fence_emit - emit a fence on the requested ring
+ *
+ * @rdev: radeon_device pointer
+ * @fence: radeon fence object
+ * @ring: ring index the fence is associated with
+ *
+ * Emits a fence command on the requested ring (all asics).
+ * Returns 0 on success, -ENOMEM on failure.
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
@@ -79,6 +128,22 @@ int radeon_fence_emit(struct radeon_device *rdev,
return 0;
}
+/**
+ * radeon_fence_process - process a fence
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Checks the current fence value and wakes the fence queue
+ * if the sequence number has increased (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
void radeon_fence_process(struct radeon_device *rdev, int ring)
{
uint64_t seq, last_seq;
@@ -139,6 +204,20 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
}
+/**
+ * radeon_fence_destroy - destroy a fence
+ *
+ * @kref: fence kref
+ *
+ * Frees the fence object (all asics).
+ * Fences mark an event in the GPUs pipeline and are used
+ * for GPU/CPU synchronization. When the fence is written,
+ * it is expected that all buffers associated with that fence
+ * are no longer in use by the associated ring on the GPU and
+ * that the the relevant GPU caches have been flushed. Whether
+ * we use a scratch register or memory location depends on the asic
+ * and whether writeback is enabled.
+ */
static void radeon_fence_destroy(struct kref *kref)
{
struct radeon_fence *fence;
@@ -147,6 +226,27 @@ static void radeon_fence_destroy(struct kref *kref)
kfree(fence);
}
+/**
+ * radeon_fence_seq_signaled - check if a fence sequeuce number has signaled
+ *
+ * @rdev: radeon device pointer
[PATCH 06/10] drm/radeon: document radeon_ring.c
From: Alex Deucher
Adds documentation to most of the functions in
radeon_ring.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 374 +-
1 files changed, 373 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 0826e77..2a0febf 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -39,6 +39,24 @@
*/
int radeon_debugfs_sa_init(struct radeon_device *rdev);
+/**
+ * radeon_ib_get - request an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the IB is associated with
+ * @ib: IB object returned
+ * @size: requested IB size
+ *
+ * Request an IB (all asics). IBs are allocated using the
+ * suballocator.
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_get(struct radeon_device *rdev, int ring,
struct radeon_ib *ib, unsigned size)
{
@@ -67,6 +85,20 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
return 0;
}
+/**
+ * radeon_ib_free - free an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to free
+ *
+ * Free an IB (all asics).
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib)
{
radeon_semaphore_free(rdev, &ib->semaphore, ib->fence);
@@ -74,6 +106,21 @@ void radeon_ib_free(struct radeon_device *rdev, struct
radeon_ib *ib)
radeon_fence_unref(&ib->fence);
}
+/**
+ * radeon_ib_schedule - schedule an IB (Indirect Buffer) on the ring
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to schedule
+ *
+ * Schedule an IB on the associated ring (all asics).
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib)
{
struct radeon_ring *ring = &rdev->ring[ib->ring];
@@ -116,6 +163,21 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib)
return 0;
}
+/**
+ * radeon_ib_pool_init - Init the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the suballocator to manage a pool of memory
+ * for use as IBs (all asics).
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
int radeon_ib_pool_init(struct radeon_device *rdev)
{
int r;
@@ -136,6 +198,20 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_ib_pool_fini - Free the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the suballocator managing the pool of memory
+ * for use as IBs (all asics).
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored. You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them. Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
void radeon_ib_pool_fini(struct radeon_device *rdev)
{
if (rdev->ib_pool_ready) {
@@ -144,16 +220,64 @@ void radeon_ib_pool_fini(struct radeon_device *rdev)
}
}
+/**
+ * radeon_ib_pool_start - Start the IB (Indirect Buffer) pool
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator that manages pool of memory
+ * used for IBs (all asics). Used to start the IB pool on
+ * device startup and resume.
+ * Returns 0 on success, error on failure.
+ * IBs (Indirect Buff
[PATCH 07/10] drm/radeon: document non-VM functions in radeon_gart.c
From: Alex Deucher
Document the non-VM functions in radeon_gart.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 154 +-
1 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8c44d1d..d9e29d5 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -33,6 +33,20 @@
/*
* Common GART table functions.
*/
+/**
+ * radeon_gart_table_ram_alloc - allocate system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400).
+ * Returns 0 for success, -ENOMEM for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
{
void *ptr;
@@ -54,6 +68,19 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_ram_free - free system ram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free system memory for GART page table
+ * (r1xx-r3xx, non-pcie r4xx, rs400).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_ram_free(struct radeon_device *rdev)
{
if (rdev->gart.ptr == NULL) {
@@ -73,6 +100,20 @@ void radeon_gart_table_ram_free(struct radeon_device *rdev)
rdev->gart.table_addr = 0;
}
+/**
+ * radeon_gart_table_vram_alloc - allocate vram for gart page table
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Allocate video memory for GART page table
+ * (pcie r4xx, r5xx+).
+ * Returns 0 for success, error for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
{
int r;
@@ -88,6 +129,20 @@ int radeon_gart_table_vram_alloc(struct radeon_device *rdev)
return 0;
}
+/**
+ * radeon_gart_table_vram_pin - pin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Pin the GART page table in vram so it will not be moved
+ * by the memory manager (pcie r4xx, r5xx+).
+ * Returns 0 for success, error for failure.
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
int radeon_gart_table_vram_pin(struct radeon_device *rdev)
{
uint64_t gpu_addr;
@@ -110,6 +165,18 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
return r;
}
+/**
+ * radeon_gart_table_vram_unpin - unpin gart page table in vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unpin the GART page table in vram (pcie r4xx, r5xx+).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_vram_unpin(struct radeon_device *rdev)
{
int r;
@@ -126,6 +193,19 @@ void radeon_gart_table_vram_unpin(struct radeon_device
*rdev)
}
}
+/**
+ * radeon_gart_table_vram_free - free gart page table vram
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Free the video memory used for the GART page table
+ * (pcie r4xx, r5xx+).
+ * The GART (Graphics Aperture Remapping Table) is an aperture
+ * in the GPU's address space. System pages can be mapped into
+ * the aperture and look like contiguous pages from the GPU's
+ * perspective. A page table maps the pages in the aperture
+ * to the actual backing pages in system memory.
+ */
void radeon_gart_table_vram_free(struct radeon_device *rdev)
{
if (rdev->gart.robj == NULL) {
@@ -135,12 +215,24 @@ void radeon_gart_table_vram_free(struct radeon_device
*rdev)
radeon_bo_unref(&rdev->gart.robj);
}
-
-
-
/*
* Common gart functions.
*/
+/**
+ * radeon_gart_unbind - unbind pages from the gart page table
+ *
+ * @rdev: radeon_device pointer
+ * @of
[PATCH 09/10] drm/radeon: start to document the functions r100.c
From: Alex Deucher
Still a lot more to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 127 -
1 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index d06c8dd..84477dc 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -65,6 +65,19 @@ MODULE_FIRMWARE(FIRMWARE_R520);
#include "r100_track.h"
+/* This files gather functions specifics to:
+ * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+ * and others in some cases.
+ */
+
+/**
+ * r100_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (r1xx-r4xx).
+ */
void r100_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -99,22 +112,49 @@ void r100_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
-/* This files gather functions specifics to:
- * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
+/**
+ * r100_pre_page_flip - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (r1xx-r4xx).
+ * Enables the pageflip irq (vblank irq).
*/
-
void r100_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * r100_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (r1xx-r4xx).
+ * Disables the pageflip irq (vblank irq).
+ */
void r100_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * r100_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (r1xx-r4xx).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 r100_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -141,6 +181,15 @@ u32 r100_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base)
return RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) &
RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET;
}
+/**
+ * r100_pm_get_dynpm_state - look up dynpm power state callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Look up the optimal power state based on the
+ * current state of the GPU (r1xx-r5xx).
+ * Used for dynpm only.
+ */
void r100_pm_get_dynpm_state(struct radeon_device *rdev)
{
int i;
@@ -223,6 +272,15 @@ void r100_pm_get_dynpm_state(struct radeon_device *rdev)
pcie_lanes);
}
+/**
+ * r100_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (r1xx-r3xx).
+ * Used for profile mode only.
+ */
void r100_pm_init_profile(struct radeon_device *rdev)
{
/* default */
@@ -262,6 +320,14 @@ void r100_pm_init_profile(struct radeon_device *rdev)
rdev->pm.profiles[PM_PROFILE_HIGH_MH_IDX].dpms_on_cm_idx = 0;
}
+/**
+ * r100_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, pcie lanes, etc.) (r1xx-r4xx).
+ */
void r100_pm_misc(struct radeon_device *rdev)
{
int requested_index = rdev->pm.requested_power_state_index;
@@ -353,6 +419,13 @@ void r100_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (r1xx-r4xx).
+ */
void r100_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -377,6 +450,13 @@ void r100_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * r100_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (r1xx-r4xx).
+ */
void r100_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -401,6 +481,14 @@ void r100_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * r100_gui_idle - gui idle callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Check of the GUI (2D/3D engines) are idle (r1xx-r5xx).
+ * Returns true if idle, false if not.
+ */
bool r100_gui_idle(struct radeon_device *rdev)
{
if (RREG32(RADEON_RBBM_STATUS) & RADEON_RBBM_ACTIVE)
@@ -41
[PATCH 08/10] drm/radeon: document VM functions in radeon_gart.c
From: Alex Deucher
Document the VM functions in radeon_gart.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_gart.c | 237 ++
1 files changed, 237 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index d9e29d5..c37b501 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -430,6 +430,21 @@ void radeon_gart_fini(struct radeon_device *rdev)
*
* TODO bind a default page at vm initialization for default address
*/
+/**
+ * radeon_vm_manager_init - init the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Init the vm manager (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_init(struct radeon_device *rdev)
{
int r;
@@ -455,6 +470,23 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
}
/* global mutex must be lock */
+/**
+ * radeon_vm_unbind_locked - unbind a specific vm
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Unbind the requested vm (cayman+).
+ * Wait for use of the VM to finish, then unbind the page table,
+ * and free the page table memory.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
static void radeon_vm_unbind_locked(struct radeon_device *rdev,
struct radeon_vm *vm)
{
@@ -483,6 +515,20 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
}
}
+/**
+ * radeon_vm_manager_fini - tear down the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Tear down the VM manager (cayman+).
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
void radeon_vm_manager_fini(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL)
@@ -493,6 +539,21 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
rdev->vm_manager.enabled = false;
}
+/**
+ * radeon_vm_manager_start - start the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Start the suballocator instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_start(struct radeon_device *rdev)
{
if (rdev->vm_manager.sa_manager.bo == NULL) {
@@ -501,6 +562,22 @@ int radeon_vm_manager_start(struct radeon_device *rdev)
return radeon_sa_bo_manager_start(rdev, &rdev->vm_manager.sa_manager);
}
+/**
+ * radeon_vm_manager_suspend - suspend the vm manager
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Unbind all the VM page tables and suspend the suballocator
+ * instance used for VM (cayman+).
+ * Returns 0 for success, error for failure.
+ * GPUVM is similar to the legacy gart on older asics, however
+ * rather than there being a single global gart table
+ * for the entire GPU, there are multiple VM page tables active
+ * at any given time. The VM page tables can contain a mix
+ * vram pages and system memory pages and system memory pages
+ * can be mapped as snooped (cached system pages) or unsnooped
+ * (uncached system pages).
+ */
int radeon_vm_manager_suspend(struct radeon_device *rdev)
{
struct radeon_vm *vm, *tmp;
@@ -516,6 +593,21 @@ int radeon_vm_manager_suspend(struct radeon_device *rdev)
}
/* global mutex must be locked */
+/**
+ * radeon_vm_unbind - locked version of unbind
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to unbind
+ *
+ * Locked version that wraps radeon_vm_unbind_locked (cayman+).
+ * GPUVM is similar to the legacy gart
[PATCH 10/10] drm/radeon: start to document evergreen.c
From: Alex Deucher
Still a lot to do.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 120
1 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f716e08..0fc68a7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -99,6 +99,14 @@ void evergreen_fix_pci_max_read_req_size(struct
radeon_device *rdev)
}
}
+/**
+ * dce4_wait_for_vblank - vblank wait asic callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to wait for vblank on
+ *
+ * Wait for vblank on the requested crtc (evergreen+).
+ */
void dce4_wait_for_vblank(struct radeon_device *rdev, int crtc)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
@@ -118,18 +126,49 @@ void dce4_wait_for_vblank(struct radeon_device *rdev, int
crtc)
}
}
+/**
+ * radeon_irq_kms_pflip_irq_get - pre-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to prepare for pageflip on
+ *
+ * Pre-pageflip callback (evergreen+).
+ * Enables the pageflip irq (vblank irq).
+ */
void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc)
{
/* enable the pflip int */
radeon_irq_kms_pflip_irq_get(rdev, crtc);
}
+/**
+ * evergreen_post_page_flip - pos-pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc: crtc to cleanup pageflip on
+ *
+ * Post-pageflip callback (evergreen+).
+ * Disables the pageflip irq (vblank irq).
+ */
void evergreen_post_page_flip(struct radeon_device *rdev, int crtc)
{
/* disable the pflip int */
radeon_irq_kms_pflip_irq_put(rdev, crtc);
}
+/**
+ * evergreen_page_flip - pageflip callback.
+ *
+ * @rdev: radeon_device pointer
+ * @crtc_id: crtc to cleanup pageflip on
+ * @crtc_base: new address of the crtc (GPU MC address)
+ *
+ * Does the actual pageflip (evergreen+).
+ * During vblank we take the crtc lock and wait for the update_pending
+ * bit to go high, when it does, we release the lock, and allow the
+ * double buffered update to take place.
+ * Returns the current update pending status.
+ */
u32 evergreen_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
@@ -214,6 +253,15 @@ int sumo_get_temp(struct radeon_device *rdev)
return actual_temp * 1000;
}
+/**
+ * sumo_pm_init_profile - Initialize power profiles callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Initialize the power states used in profile mode
+ * (sumo, trinity, SI).
+ * Used for profile mode only.
+ */
void sumo_pm_init_profile(struct radeon_device *rdev)
{
int idx;
@@ -265,6 +313,14 @@ void sumo_pm_init_profile(struct radeon_device *rdev)
rdev->pm.power_state[idx].num_clock_modes - 1;
}
+/**
+ * evergreen_pm_misc - set additional pm hw parameters callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Set non-clock parameters associated with a power state
+ * (voltage, etc.) (evergreen+).
+ */
void evergreen_pm_misc(struct radeon_device *rdev)
{
int req_ps_idx = rdev->pm.requested_power_state_index;
@@ -292,6 +348,13 @@ void evergreen_pm_misc(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_prepare - pre-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Prepare for a power state change (evergreen+).
+ */
void evergreen_pm_prepare(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -310,6 +373,13 @@ void evergreen_pm_prepare(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_pm_finish - post-power state change callback.
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Clean up after a power state change (evergreen+).
+ */
void evergreen_pm_finish(struct radeon_device *rdev)
{
struct drm_device *ddev = rdev->ddev;
@@ -328,6 +398,15 @@ void evergreen_pm_finish(struct radeon_device *rdev)
}
}
+/**
+ * evergreen_hpd_sense - hpd sense callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Checks if a digital monitor is connected (evergreen+).
+ * Returns true if connected, false if not connected.
+ */
bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd)
{
bool connected = false;
@@ -364,6 +443,14 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum
radeon_hpd_id hpd)
return connected;
}
+/**
+ * evergreen_hpd_set_polarity - hpd set polarity callback.
+ *
+ * @rdev: radeon_device pointer
+ * @hpd: hpd (hotplug detect) pin
+ *
+ * Set the polarity of the hpd pin (evergreen+).
+ */
void evergreen_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd)
{
@@ -424,6 +511,14 @@ void evergreen_hpd_set_polarity(struct radeon_device *rdev,
}
}
+/**
+ * evergreen_hpd_init - hpd setup callback.
+ *
+ * @rdev: rade
[PATCH 00/10] Start documenting the radeon drm better
On 29.06.2012 16:28, alexdeucher at gmail.com wrote: > From: Alex Deucher > > This is something I've been wanting to do for a while and > I finally spent a little time getting a start on it. There > is still a lot to do and not all of my descriptions are great, > but I think we can document the rest in bits and pieces. I > also added a note about what asics the function is applicable > to. I tried to start with the more common and complex code. > I was thinking it would make sense to have an informal > documentation policy something like the following: > 1. If you edit an undocumented function, add documentation > 2. If you edit a documented function and change how it works, > update the documentation > 3. All new functions added should be documented > > Fulfulling all of these for stable fixes could pose problems > so obviously there is some leeway. > > Thoughts? Sounds like a good idea to me, but could we move the old and deprecated non KMS code into it's own subdirectory or something like that first? Also for some files it might be a good idea to spread them into separate ones first, like the gart and vm and/or the ring and ib stuff. Cheers, Christian. > > Alex Deucher (10): >drm/radeon: document radeon_device.c >drm/radeon: document radeon_kms.c >drm/radeon: document radeon_irq_kms.c >drm/radeon: document radeon_asic.c >drm/radeon: document radeon_fence.c >drm/radeon: document radeon_ring.c >drm/radeon: document non-VM functions in radeon_gart.c >drm/radeon: document VM functions in radeon_gart.c >drm/radeon: start to document the functions r100.c >drm/radeon: start to document evergreen.c > > drivers/gpu/drm/radeon/evergreen.c | 120 ++ > drivers/gpu/drm/radeon/r100.c | 127 ++- > drivers/gpu/drm/radeon/radeon_asic.c| 46 > drivers/gpu/drm/radeon/radeon_device.c | 344 +++- > drivers/gpu/drm/radeon/radeon_fence.c | 373 + > drivers/gpu/drm/radeon/radeon_gart.c| 391 > ++- > drivers/gpu/drm/radeon/radeon_irq_kms.c | 150 > drivers/gpu/drm/radeon/radeon_kms.c | 126 ++ > drivers/gpu/drm/radeon/radeon_ring.c| 374 > +- > 9 files changed, 2041 insertions(+), 10 deletions(-) >
[PATCH 2/3] drm/radeon: add error handling to fence_wait_empty_locked
Instead of returning the error handle it directly
and while at it fix the comments about the ring lock.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 33 +
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 77b4519b..5861ec8 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -239,7 +239,7 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring);
bool radeon_fence_signaled(struct radeon_fence *fence);
int radeon_fence_wait(struct radeon_fence *fence, bool interruptible);
int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring);
-int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
+void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
int radeon_fence_wait_any(struct radeon_device *rdev,
struct radeon_fence **fences,
bool intr);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7b55625..be4e4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -440,14 +440,11 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
return 0;
}
+/* caller must hold ring lock */
int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring)
{
uint64_t seq;
- /* We are not protected by ring lock when reading current seq but
-* it's ok as worst case is we return to early while we could have
-* wait.
-*/
seq = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL;
if (seq >= rdev->fence_drv[ring].sync_seq[ring]) {
/* nothing to wait for, last_seq is
@@ -457,15 +454,27 @@ int radeon_fence_wait_next_locked(struct radeon_device
*rdev, int ring)
return radeon_fence_wait_seq(rdev, seq, ring, false, false);
}
-int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
+/* caller must hold ring lock */
+void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
{
- /* We are not protected by ring lock when reading current seq
-* but it's ok as wait empty is call from place where no more
-* activity can be scheduled so there won't be concurrent access
-* to seq value.
-*/
- return radeon_fence_wait_seq(rdev, rdev->fence_drv[ring].sync_seq[ring],
-ring, false, false);
+ uint64_t seq = rdev->fence_drv[ring].sync_seq[ring];
+
+ while(1) {
+ int r;
+ r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+ if (r == -EDEADLK) {
+ mutex_unlock(&rdev->ring_lock);
+ r = radeon_gpu_reset(rdev);
+ mutex_lock(&rdev->ring_lock);
+ if (!r)
+ continue;
+ }
+ if (r) {
+ dev_err(rdev->dev, "error waiting for ring to become"
+ " idle (%d)\n", r);
+ }
+ return;
+ }
}
struct radeon_fence *radeon_fence_ref(struct radeon_fence *fence)
--
1.7.9.5
[PATCH 1/3] drm/radeon: move ring locking out of reset path
Hold the ring lock the whole time the reset is in progress,
otherwise another process can submit new jobs.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |8
drivers/gpu/drm/radeon/ni.c|8
drivers/gpu/drm/radeon/r100.c |8
drivers/gpu/drm/radeon/r300.c |4 ++--
drivers/gpu/drm/radeon/r420.c |8
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/radeon_device.c | 14 --
drivers/gpu/drm/radeon/rv515.c |4 ++--
drivers/gpu/drm/radeon/si.c| 12 ++--
9 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f716e08..09e6da8 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1418,7 +1418,7 @@ static int evergreen_cp_start(struct radeon_device *rdev)
int r, i;
uint32_t cp_me;
- r = radeon_ring_lock(rdev, ring, 7);
+ r = radeon_ring_alloc(rdev, ring, 7);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -1430,12 +1430,12 @@ static int evergreen_cp_start(struct radeon_device
*rdev)
radeon_ring_write(ring, PACKET3_ME_INITIALIZE_DEVICE_ID(1));
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
cp_me = 0xff;
WREG32(CP_ME_CNTL, cp_me);
- r = radeon_ring_lock(rdev, ring, evergreen_default_size + 19);
+ r = radeon_ring_alloc(rdev, ring, evergreen_default_size + 19);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -1473,7 +1473,7 @@ static int evergreen_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, 0x000e); /* VGT_VERTEX_REUSE_BLOCK_CNTL */
radeon_ring_write(ring, 0x0010); /* */
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 2366be3..7e516ce 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -918,7 +918,7 @@ static int cayman_cp_start(struct radeon_device *rdev)
struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
int r, i;
- r = radeon_ring_lock(rdev, ring, 7);
+ r = radeon_ring_alloc(rdev, ring, 7);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -930,11 +930,11 @@ static int cayman_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, PACKET3_ME_INITIALIZE_DEVICE_ID(1));
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
cayman_cp_enable(rdev, true);
- r = radeon_ring_lock(rdev, ring, cayman_default_size + 19);
+ r = radeon_ring_alloc(rdev, ring, cayman_default_size + 19);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
return r;
@@ -972,7 +972,7 @@ static int cayman_cp_start(struct radeon_device *rdev)
radeon_ring_write(ring, 0x000e); /* VGT_VERTEX_REUSE_BLOCK_CNTL */
radeon_ring_write(ring, 0x0010); /* */
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
/* XXX init other rings */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 35825bf..3901a68 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -955,7 +955,7 @@ void r100_ring_start(struct radeon_device *rdev, struct
radeon_ring *ring)
{
int r;
- r = radeon_ring_lock(rdev, ring, 2);
+ r = radeon_ring_alloc(rdev, ring, 2);
if (r) {
return;
}
@@ -965,7 +965,7 @@ void r100_ring_start(struct radeon_device *rdev, struct
radeon_ring *ring)
RADEON_ISYNC_ANY3D_IDLE2D |
RADEON_ISYNC_WAIT_IDLEGUI |
RADEON_ISYNC_CPSCRATCH_IDLEGUI);
- radeon_ring_unlock_commit(rdev, ring);
+ radeon_ring_commit(rdev, ring);
}
@@ -3631,7 +3631,7 @@ int r100_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ring_lock(rdev, ring, 2);
+ r = radeon_ring_alloc(rdev, ring, 2);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
radeon_scratch_free(rdev, scratch);
@@ -3639,7 +3639,7 @@ int r100_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring)
}
radeon_ring_write(ring, PACKET0(scratch, 0)
[PATCH 3/3] drm/radeon: add error handling to radeon_vm_unbind_locked
Waiting for a fence can fail for different reasons,
the most common is a deadlock.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2b34c1a..ee11c50 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -316,10 +316,21 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
}
/* wait for vm use to end */
- if (vm->fence) {
- radeon_fence_wait(vm->fence, false);
- radeon_fence_unref(&vm->fence);
+ while (vm->fence) {
+ int r;
+ r = radeon_fence_wait(vm->fence, false);
+ if (r)
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ if (r == -EDEADLK) {
+ mutex_unlock(&rdev->vm_manager.lock);
+ r = radeon_gpu_reset(rdev);
+ mutex_lock(&rdev->vm_manager.lock);
+ if (!r)
+ continue;
+ }
+ break;
}
+ radeon_fence_unref(&vm->fence);
/* hw unbind */
rdev->vm_manager.funcs->unbind(rdev, vm);
--
1.7.9.5
[PATCH] i915: initialize CADL in opregion
On Thu, Jun 28, 2012 at 01:05:58PM +0200, Daniel Vetter wrote: > On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn wrote: > > Thank you, I've now written a partial analysis which is available at > > https://github.com/Lekensteyn/acpi- > > stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is > > cut in > > two parts in this mail, concat them as needed). > > > > Question: can you try disabling the asus-laptop module and try booting again > > w/ and w/o the CADL patch applied? > > - Does it boot in both cases? > > - Do the brightness hotkeys work? > > - Can you change brightness via /sys/class/backlight? > > Can you SSH in it and check the logs? Any ACPI warnings/errors or messages > > from the asus-laptop module? (or whatever asus module(s) is/are loaded) > > > > Can you also generate dmidecode.txt? (peek in > > http://lekensteyn.nl/files/get- > > acpi-info.sh, you do not have to run all of the commands since I already > > have > > your acpidump) > > Ok, because I have an ecrypted root fs I've tried to reload the > i915.ko with CADL after booting. Test-results: > - asus_wmi.ko doesn't seem to have any effect whatsoever on the endresult. > - asus_nb_wmi.ko doesn't load (ENODEV). > - brightness-keys (and also sound control) don't work, but controlling > the backlight with /sys/class/backlight/acpi_video0/brightness works > (if I can turn the panel on somehow, see below). > - When loading the i915.ko with the CADL patch the screen went black > (like at boot), but with some excessive vt-switching and X restarting > I've managed to light it up. Although it is flickery as hell, > especially the lower part of the screen. And if the screen is somewhat > stable, I just get the upper part of the screen duplicated in the > lower part. > - dmidecode is attached. > - no errors in the logs anywhere (if you ignore some ACPI resource > conflicts because ACPI reserves some pch stuff itself, which then > conflicts with the native gpio, sensors, whatever drivers). > > So I think this might be simply a timing issue that with CADL enabled > we expose a pre-existing bug somewhere in our modeset sequence. I'm > already chasing two issues on this machine: > - edp refuses to light up crtc 1/2, only works after having switched > back to crtc 0. > - disabled pipes get stuck in the active state once having been used be edp. > > I have a feeling that all these issues are related, so I guess until > I've tracked down the above the things we won't make much progress > with this CADL patch. Good news: I've fixed my edp issues (switching crtcs works reliable now and nothing gets stuck in a half-disabled state) and now I don't get a black/flashing screen any more when applying your patch. Bad news: We need to refactor a big chunk of our driver to properly fix this issue. Which means I can't merge your patch right away :( Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/radeon: fix VM page table setup on SI
On Don, 2012-06-28 at 17:53 -0400, alexdeucher at gmail.com wrote: > From: Alex Deucher > > Cayman and trinity allow for variable sized VM page > tables, but SI requires that all page tables be the > same size. The current code assumes variablely sized > VM page tables so SI may end up with part of each page > table overlapping with other memory which could end > up being interpreted by the VM hw as garbage. > > Change the code to better accomodate SI. Allocate enough > space for at least 2 full page tables and always set > last_pfn to max_pfn on SI so each VM is backed by a full > page table. This limits us to only 2 VMs active at any > given time on SI. This will be rectified and the code can > be reunified once we move to two level page tables. > > Signed-off-by: Alex Deucher This change breaks the radeonsi driver for me. egltri_screen (the 'golden' test for radeonsi at least basically working) locks up the GPU. I don't have any details about the lockup yet, as the GPU reset attempt hangs the machine. Any ideas offhand what radeonsi might be doing wrong? -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
