Re: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Dear Chen, thanks for your patch. Firstly, is Chen your first or last name? If it is your first name, your From address should be switched. Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: > When SWIOTLB is configured, if without this patch kernel compilation > fails. Secondly, could you please always paste part of the error message into the commit message so that people hitting this problem and searching for it on the WWW have a higher chance finding your patch. Thirdly, do you know why this was not caught beforehand and compilation worked before? > Signed-off-by: Huacai Chen Lastly, the addresses in your From line and Signed-off-by line disagree. You can easily fix that, by adding From: Huacai Chen to the beginning of your message. > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/radeon/radeon_ttm.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index 5b71c71..fc3ac22 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -41,6 +41,10 @@ > #include "radeon_reg.h" > #include "radeon.h" > > +#ifdef CONFIG_SWIOTLB > +#include > +#endif > + > #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) > > static int radeon_ttm_debugfs_init(struct radeon_device *rdev); With the clarification above Acked-by: Paul Menzel can be added to your patch. Thanks, Paul 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] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > Dear Chen, > > > thanks for your patch. > > Firstly, is Chen your first or last name? If it is your first name, your > From address should be switched. Chen is may last name. > > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: >> When SWIOTLB is configured, if without this patch kernel compilation >> fails. > > Secondly, could you please always paste part of the error message into > the commit message so that people hitting this problem and searching for > it on the WWW have a higher chance finding your patch. > OK, I'll paste error message. > Thirdly, do you know why this was not caught beforehand and compilation > worked before? Maybe radeon is mostly used on X86 and swiotlb.h is included indirectly on X86 platform. This patch is split from my MIPS patchset, on MIPS machines compilation always failed. > >> Signed-off-by: Huacai Chen > > Lastly, the addresses in your From line and Signed-off-by line disagree. > You can easily fix that, by adding My patch is generated by git format-patch and there is surely a From line in the beginning (from che...@lemote.com), but the mail is sent out by gmail, so I don't know how to make From line and Signed-off-by agree. > > From: Huacai Chen > > to the beginning of your message. > >> Signed-off-by: Hongliang Tao >> Signed-off-by: Hua Yan >> Cc: dri-devel@lists.freedesktop.org >> --- >> drivers/gpu/drm/radeon/radeon_ttm.c |4 >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >> b/drivers/gpu/drm/radeon/radeon_ttm.c >> index 5b71c71..fc3ac22 100644 >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c >> @@ -41,6 +41,10 @@ >> #include "radeon_reg.h" >> #include "radeon.h" >> >> +#ifdef CONFIG_SWIOTLB >> +#include >> +#endif >> + >> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) >> >> static int radeon_ttm_debugfs_init(struct radeon_device *rdev); > > With the clarification above > > Acked-by: Paul Menzel > > can be added to your patch. > > > Thanks, > > Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Dear Huacai, Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: > On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > > thanks for your patch. > > > > Firstly, is Chen your first or last name? If it is your first name, your > > From address should be switched. > Chen is may last name. I am sorry then. > > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: > >> When SWIOTLB is configured, if without this patch kernel compilation > >> fails. > > > > Secondly, could you please always paste part of the error message into > > the commit message so that people hitting this problem and searching for > > it on the WWW have a higher chance finding your patch. > > > OK, I'll paste error message. > > > Thirdly, do you know why this was not caught beforehand and compilation > > worked before? > Maybe radeon is mostly used on X86 and swiotlb.h is included > indirectly on X86 platform. This patch is split from my MIPS patchset, > on MIPS machines compilation always failed. Ah, I thought your patches had already been submitted. > >> Signed-off-by: Huacai Chen > > > > Lastly, the addresses in your From line and Signed-off-by line disagree. > > You can easily fix that, by adding > My patch is generated by git format-patch and there is surely a From > line in the beginning (from che...@lemote.com), It should be `From: Huacai Chen `. > but the mail is sent out by gmail, so I don't know how to make From > line and Signed-off-by agree. Do you copy the content of the file created by `git format-patch` into the Gmail Web compositor? If yes, just do not delete the `From` *and* `Date` lines from the beginning as for example Alex Deucher is doing [1]. […] Thanks, Paul [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html 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] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel wrote: > Dear Huacai, > > > Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: >> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > >> > thanks for your patch. >> > >> > Firstly, is Chen your first or last name? If it is your first name, your >> > From address should be switched. >> Chen is may last name. > > I am sorry then. > >> > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: >> >> When SWIOTLB is configured, if without this patch kernel compilation >> >> fails. >> > >> > Secondly, could you please always paste part of the error message into >> > the commit message so that people hitting this problem and searching for >> > it on the WWW have a higher chance finding your patch. >> > >> OK, I'll paste error message. >> >> > Thirdly, do you know why this was not caught beforehand and compilation >> > worked before? >> Maybe radeon is mostly used on X86 and swiotlb.h is included >> indirectly on X86 platform. This patch is split from my MIPS patchset, >> on MIPS machines compilation always failed. > > Ah, I thought your patches had already been submitted. My MIPS patchset is under review (not accepted now), I think this drm patch is important and should be accept first, so sent it independently. > >> >> Signed-off-by: Huacai Chen >> > >> > Lastly, the addresses in your From line and Signed-off-by line disagree. >> > You can easily fix that, by adding >> My patch is generated by git format-patch and there is surely a From >> line in the beginning (from che...@lemote.com), > > It should be `From: Huacai Chen `. Yes, git format-patch generate `From: Huacai Chen ` > >> but the mail is sent out by gmail, so I don't know how to make From >> line and Signed-off-by agree. > > Do you copy the content of the file created by `git format-patch` into > the Gmail Web compositor? > > If yes, just do not delete the `From` *and* `Date` lines from the > beginning as for example Alex Deucher is doing [1]. No, I use git send-email to send the patch but use gmail's server (mail server of lemote.com is too weak). The original patch is begin with: - >From 70e1e058da3d39c52b7dba3e8fa754e7ed41828c Mon Sep 17 00:00:00 2001 From: Huacai Chen Date: Thu, 2 Aug 2012 17:02:59 +0800 Subject: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured. When SWIOTLB is configured, if without this patch kernel compilation fails with error messages: Do you means I need to copy the From line and paste it after the Subject line? > > […] > > > Thanks, > > Paul > > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Am Montag, den 13.08.2012, 16:04 +0800 schrieb Huacai Chen: > On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel wrote: > > Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: > >> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: […] > >> > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: […] > >> >> Signed-off-by: Huacai Chen > >> > > >> > Lastly, the addresses in your From line and Signed-off-by line disagree. > >> > You can easily fix that, by adding > >> My patch is generated by git format-patch and there is surely a From > >> line in the beginning (from che...@lemote.com), > > > > It should be `From: Huacai Chen `. > Yes, git format-patch generate `From: Huacai Chen ` > > > > >> but the mail is sent out by gmail, so I don't know how to make From > >> line and Signed-off-by agree. > > > > Do you copy the content of the file created by `git format-patch` into > > the Gmail Web compositor? > > > > If yes, just do not delete the `From` *and* `Date` lines from the > > beginning as for example Alex Deucher is doing [1]. > No, I use git send-email to send the patch but use gmail's server > (mail server of lemote.com is too weak). The original patch is begin > with: > - > From 70e1e058da3d39c52b7dba3e8fa754e7ed41828c Mon Sep 17 00:00:00 2001 > From: Huacai Chen > Date: Thu, 2 Aug 2012 17:02:59 +0800 > Subject: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured. > > When SWIOTLB is configured, if without this patch kernel compilation > fails with error messages: > > Do you means I need to copy the From line and paste it after the Subject line? wereHamster on #git suggested to use git send-email --from 'Huacai Chen ' and it should do the right thing. Thanks, Paul > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails with such error messages: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of function 'swiotlb_nr_tbl' drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 'ttm_dma_populate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but argument is of type 'struct device *' drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 'ttm_dma_unpopulate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but argument is of type 'struct device *' Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Consistently name interlaced modes
At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:
x
eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.
However, timings parsed using the tables in drm_edid_modes.h do not
have the 'i' suffix. You are left to deduce that they're interlaced
from xrandr's output by the lower vertical refresh frequencies.
This patch changes the interlaced mode names in drm_edid_modes.h to
follow the style set by drm_mode_set_name(), which makes it clear
in xrandr which modes are interlaced and which are not (as xrandr
groups the refresh rates on a line according to the name field.)
Signed-off-by: Russell King
---
drivers/gpu/drm/drm_edid_modes.h | 42 +++
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ff98a7e..57459b3 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -89,7 +89,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
976, 1088, 0, 480, 486, 494, 517, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1024x768@43Hz, interlace */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
+ { DRM_MODE("1024x768i", DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
1208, 1264, 0, 768, 768, 772, 817, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) },
@@ -395,7 +395,7 @@ static const struct drm_display_mode edid_est_modes[] = {
{ DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
1184, 1344, 0, 768, 771, 777, 806, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /*
1024x768@60Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER,44900, 1024, 1032,
+ { DRM_MODE("1024x768i", DRM_MODE_TYPE_DRIVER,44900, 1024, 1032,
1208, 1264, 0, 768, 768, 776, 817, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) }, /* 1024x768@43Hz */
{ DRM_MODE("832x624", DRM_MODE_TYPE_DRIVER, 57284, 832, 864,
@@ -506,17 +506,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
1430, 1650, 0, 720, 725, 730, 750, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 5 - 1920x1080i@60Hz */
- { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+ { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) },
/* 6 - 1440x480i@60Hz */
- { DRM_MODE("1440x480", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK) },
/* 7 - 1440x480i@60Hz */
- { DRM_MODE("1440x480", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK) },
@@ -531,12 +531,12 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK) },
/* 10 - 2880x480i@60Hz */
- { DRM_MODE("2880x480", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
+ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE) },
/* 11 - 2880x480i@60Hz */
- { DRM_MODE("2880x480", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
+ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE) },
@@ -573,17 +573,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
1760, 1980, 0, 720, 725, 730, 750, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 20 - 1920x1080i@50Hz */
- { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+ { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
2492, 2640, 0, 1080, 1084, 1094, 1125, 0
[BUG] EDID leaks kernel memory
Hi, While looking at the kernel DRM code, I've noticed that in many places we kmalloc() memory to store the raw EDID information, whether it be from a DDC adapter, or loaded from firmware. Nowhere can I find where this memory is freed. It seems in several places that we assign it into connector->display_info.raw_edid, and next time we obtain EDID information, we re-kmalloc and overwrite this pointer. Note that some drivers do kfree() this memory themselves after blindly setting connector->display_info.raw_edid to NULL... Can someone please point me to where this memory is freed? If not, I'll cook up a patch to add some kfree's. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Mon, Aug 06, 2012 at 07:44:16AM +1000, Dave Airlie wrote:
> >> The "correct" approach is clearly to just have the drm core change the
> >> i2c mux before requesting edid, but that's made difficult because of the
> >> absence of ordering guarantees in initialisation. I don't like quirking
> >> this, since we're then back to the situation of potentially having to
> >> add every new piece of related hardware to the quirk list.
> >
> > The "correct" approach of switching the mux before we fetch the edid is
> > actualy the one I fear will result in fragile code: Only run on few
> > machines, and as you say with tons of funky interactions with the init
> > sequence ordering. And I guess people will bitch&moan about the flickering
> > this will cause ;-)
> >
> > As long as it's only apple shipping multi-gpu machines with
> > broken/non-existing vbt, I'll happily stomach the quirk list entries.
> > They're bad, but imo the lesser evil.
>
> Well in theory you can switch the ddc lines without switching the other lines,
> so we could do a mutex protected mux switch around edid retrival,
>
> Of course someone would have to code it up first then we could see how
> ugly it would be.
I coded it up, and it's not really too bad. I've put a dump of my local
changes below. But there are a couple of problems.
First, I don't have a solution for the ordering of initialization. It
just happens to work out for me right now.
Even so, the code only works if I delay loading i915. apple-gmux is
definitely initializing first so the i2c mux should be getting switched,
but the transactions are failing.
[ 19.445658] [drm:gmbus_xfer], GMBUS [i915 gmbus panel] timed out after NAK
[ 19.445672] [drm:gmbus_xfer], GMBUS [i915 gmbus panel] NAK for addr: 0050
r(1)
But if I prevent i915 from being auto-loaded and load later on it works
fine. I haven't been able to figure out what's going on. Any ideas?
Thanks,
Seth
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..3f18e8a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_edid_modes.h"
@@ -82,6 +83,8 @@ struct detailed_mode_closure {
#define LEVEL_GTF2 2
#define LEVEL_CVT 3
+static DEFINE_MUTEX(drm_edid_mutex);
+
static struct edid_quirk {
char vendor[4];
int product_id;
@@ -395,12 +398,25 @@ struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid = NULL;
+ struct pci_dev *pdev = connector->dev->pdev;
+ struct pci_dev *active_pdev = NULL;
+
+ mutex_lock(&drm_edid_mutex);
+
+ if (pdev) {
+ active_pdev = vga_switcheroo_get_active_client();
+ vga_switcheroo_switch_ddc(pdev);
+ }
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (active_pdev)
+ vga_switcheroo_switch_ddc(active_pdev);
+
connector->display_info.raw_edid = (char *)edid;
+ mutex_unlock(&drm_edid_mutex);
return edid;
}
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e25cf31..e53f67d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -205,6 +205,20 @@ find_active_client(struct list_head *head)
return NULL;
}
+struct pci_dev *vga_switcheroo_get_active_client(void)
+{
+ struct vga_switcheroo_client *client;
+ struct pci_dev *pdev = NULL;
+
+ mutex_lock(&vgasr_mutex);
+ client = find_active_client(&vgasr_priv.clients);
+ if (client)
+ pdev = client->pdev;
+ mutex_unlock(&vgasr_mutex);
+ return pdev;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_active_client);
+
int vga_switcheroo_get_client_state(struct pci_dev *pdev)
{
struct vga_switcheroo_client *client;
@@ -252,6 +266,29 @@ void vga_switcheroo_client_fb_set(struct pci_dev *pdev,
}
EXPORT_SYMBOL(vga_switcheroo_client_fb_set);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev)
+{
+ int ret = 0;
+ int id;
+
+ mutex_lock(&vgasr_mutex);
+
+ if (!vgasr_priv.handler) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (vgasr_priv.handler->switch_ddc) {
+ id = vgasr_priv.handler->get_client_id(pdev);
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+
+out:
+ mutex_unlock(&vgasr_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(vga_switcheroo_switch_ddc);
+
static int vga_switcheroo_show(struct seq_file *m, void *v)
{
struct vga_switcheroo_client *client;
@@ -342,9 +379,15 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
}
+ if (vgasr_priv.handler->switch_d
[Patch v2 1/4] Replace i2f() in r600_blit.c with an optimized version.
We use __fls() to find the most significant bit. Using that, the
loop can be avoided. A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.
The routine is now exact up to 2^24. Above that, we truncate which
is equivalent to rounding towards zero.
Signed-off-by: Steven Fuerst
---
drivers/gpu/drm/radeon/r600_blit.c | 50
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit.c
b/drivers/gpu/drm/radeon/r600_blit.c
index 3c031a4..326a8da 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -489,29 +489,35 @@ set_default_state(drm_radeon_private_t *dev_priv)
ADVANCE_RING();
}
-static uint32_t i2f(uint32_t input)
+/* 23 bits of float fractional data */
+#define I2F_FRAC_BITS 23
+#define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)
+
+/*
+ * Converts unsigned integer into 32-bit IEEE floating point representation.
+ * Will be exact from 0 to 2^24. Above that, we round towards zero
+ * as the fractional bits will not fit in a float. (It would be better to
+ * round towards even as the fpu does, but that is slower.)
+ */
+static uint32_t i2f(uint32_t x)
{
- u32 result, i, exponent, fraction;
-
- if ((input & 0x3fff) == 0)
- result = 0; /* 0 is a special case */
- else {
- exponent = 140; /* exponent biased by 127; */
- fraction = (input & 0x3fff) << 10; /* cheat and only
- handle numbers below
2^^15 */
- for (i = 0; i < 14; i++) {
- if (fraction & 0x80)
- break;
- else {
- fraction = fraction << 1; /* keep
-shifting left
until top bit = 1 */
- exponent = exponent - 1;
- }
- }
- result = exponent << 23 | (fraction & 0x7f); /* mask
- off top
bit; assumed 1 */
- }
- return result;
+ uint32_t msb, exponent, fraction;
+
+ /* Zero is special */
+ if (!x) return 0;
+
+ /* Get location of the most significant bit */
+ msb = __fls(x);
+
+ /*
+* Use a rotate instead of a shift because that works both leftwards
+* and rightwards due to the mod(32) behaviour. This means we don't
+* need to check to see if we are above 2^24 or not.
+*/
+ fraction = ror32(x, (msb - I2F_FRAC_BITS) & 0x1f) & I2F_MASK;
+ exponent = (127 + msb) << I2F_FRAC_BITS;
+
+ return fraction + exponent;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch v2 2/4] Replace i2f() in r600_blit_kms.c with an optimized version.
We use __fls() to find the most significant bit. Using that, the
loop can be avoided. A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.
The routine is now exact up to 2^24. Above that, we truncate which
is equivalent to rounding towards zero.
Signed-off-by: Steven Fuerst
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 51 +---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 2bef854..e5a40ca 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -455,44 +455,35 @@ set_default_state(struct radeon_device *rdev)
radeon_ring_write(ring, sq_stack_resource_mgmt_2);
}
-#define I2F_MAX_BITS 15
-#define I2F_MAX_INPUT ((1 << I2F_MAX_BITS) - 1)
-#define I2F_SHIFT (24 - I2F_MAX_BITS)
+/* 23 bits of float fractional data */
+#define I2F_FRAC_BITS 23
+#define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)
/*
* Converts unsigned integer into 32-bit IEEE floating point representation.
- * Conversion is not universal and only works for the range from 0
- * to 2^I2F_MAX_BITS-1. Currently we only use it with inputs between
- * 0 and 16384 (inclusive), so I2F_MAX_BITS=15 is enough. If necessary,
- * I2F_MAX_BITS can be increased, but that will add to the loop iterations
- * and slow us down. Conversion is done by shifting the input and counting
- * down until the first 1 reaches bit position 23. The resulting counter
- * and the shifted input are, respectively, the exponent and the fraction.
- * The sign is always zero.
+ * Will be exact from 0 to 2^24. Above that, we round towards zero
+ * as the fractional bits will not fit in a float. (It would be better to
+ * round towards even as the fpu does, but that is slower.)
*/
-static uint32_t i2f(uint32_t input)
+static uint32_t i2f(uint32_t x)
{
- u32 result, i, exponent, fraction;
+ uint32_t msb, exponent, fraction;
- WARN_ON_ONCE(input > I2F_MAX_INPUT);
+ /* Zero is special */
+ if (!x) return 0;
- if ((input & I2F_MAX_INPUT) == 0)
- result = 0;
- else {
- exponent = 126 + I2F_MAX_BITS;
- fraction = (input & I2F_MAX_INPUT) << I2F_SHIFT;
+ /* Get location of the most significant bit */
+ msb = __fls(x);
- for (i = 0; i < I2F_MAX_BITS; i++) {
- if (fraction & 0x80)
- break;
- else {
- fraction = fraction << 1;
- exponent = exponent - 1;
- }
- }
- result = exponent << 23 | (fraction & 0x7f);
- }
- return result;
+ /*
+* Use a rotate instead of a shift because that works both leftwards
+* and rightwards due to the mod(32) behaviour. This means we don't
+* need to check to see if we are above 2^24 or not.
+*/
+ fraction = ror32(x, (msb - I2F_FRAC_BITS) & 0x1f) & I2F_MASK;
+ exponent = (127 + msb) << I2F_FRAC_BITS;
+
+ return fraction + exponent;
}
int r600_blit_init(struct radeon_device *rdev)
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch v2 3/4] Rename i2f() to int2float(), and make it global so one copy can be removed.
Remove the copy of i2f() in r600_blit_kms.c
We rename the function to something longer now that it is a global
symbol. This reduces the likelyhood of unintended clashes later.
This might be a candidate for inclusion inside general drm infrastructure.
However, at the moment only the radeon driver uses it.
Signed-off-by: Steven Fuerst
Conflicts:
drivers/gpu/drm/radeon/r600_blit_kms.c
---
drivers/gpu/drm/radeon/r600_blit.c | 67 ++--
drivers/gpu/drm/radeon/r600_blit_kms.c | 43 +++---
drivers/gpu/drm/radeon/r600_blit_shaders.h |1 +
3 files changed, 40 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit.c
b/drivers/gpu/drm/radeon/r600_blit.c
index 326a8da..54980d8 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -499,7 +499,7 @@ set_default_state(drm_radeon_private_t *dev_priv)
* as the fractional bits will not fit in a float. (It would be better to
* round towards even as the fpu does, but that is slower.)
*/
-static uint32_t i2f(uint32_t x)
+uint32_t int2float(uint32_t x)
{
uint32_t msb, exponent, fraction;
@@ -520,7 +520,6 @@ static uint32_t i2f(uint32_t x)
return fraction + exponent;
}
-
static int r600_nomm_get_vb(struct drm_device *dev)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
@@ -638,20 +637,20 @@ r600_blit_copy(struct drm_device *dev,
vb = r600_nomm_get_vb_ptr(dev);
}
- vb[0] = i2f(dst_x);
+ vb[0] = int2float(dst_x);
vb[1] = 0;
- vb[2] = i2f(src_x);
+ vb[2] = int2float(src_x);
vb[3] = 0;
- vb[4] = i2f(dst_x);
- vb[5] = i2f(h);
- vb[6] = i2f(src_x);
- vb[7] = i2f(h);
+ vb[4] = int2float(dst_x);
+ vb[5] = int2float(h);
+ vb[6] = int2float(src_x);
+ vb[7] = int2float(h);
- vb[8] = i2f(dst_x + cur_size);
- vb[9] = i2f(h);
- vb[10] = i2f(src_x + cur_size);
- vb[11] = i2f(h);
+ vb[8] = int2float(dst_x + cur_size);
+ vb[9] = int2float(h);
+ vb[10] = int2float(src_x + cur_size);
+ vb[11] = int2float(h);
/* src */
set_tex_resource(dev_priv, FMT_8,
@@ -727,20 +726,20 @@ r600_blit_copy(struct drm_device *dev,
vb = r600_nomm_get_vb_ptr(dev);
}
- vb[0] = i2f(dst_x / 4);
+ vb[0] = int2float(dst_x / 4);
vb[1] = 0;
- vb[2] = i2f(src_x / 4);
+ vb[2] = int2float(src_x / 4);
vb[3] = 0;
- vb[4] = i2f(dst_x / 4);
- vb[5] = i2f(h);
- vb[6] = i2f(src_x / 4);
- vb[7] = i2f(h);
+ vb[4] = int2float(dst_x / 4);
+ vb[5] = int2float(h);
+ vb[6] = int2float(src_x / 4);
+ vb[7] = int2float(h);
- vb[8] = i2f((dst_x + cur_size) / 4);
- vb[9] = i2f(h);
- vb[10] = i2f((src_x + cur_size) / 4);
- vb[11] = i2f(h);
+ vb[8] = int2float((dst_x + cur_size) / 4);
+ vb[9] = int2float(h);
+ vb[10] = int2float((src_x + cur_size) / 4);
+ vb[11] = int2float(h);
/* src */
set_tex_resource(dev_priv, FMT_8_8_8_8,
@@ -810,20 +809,20 @@ r600_blit_swap(struct drm_device *dev,
dx2 = dx + w;
dy2 = dy + h;
- vb[0] = i2f(dx);
- vb[1] = i2f(dy);
- vb[2] = i2f(sx);
- vb[3] = i2f(sy);
+ vb[0] = int2float(dx);
+ vb[1] = int2float(dy);
+ vb[2] = int2float(sx);
+ vb[3] = int2float(sy);
- vb[4] = i2f(dx);
- vb[5] = i2f(dy2);
- vb[6] = i2f(sx);
- vb[7] = i2f(sy2);
+ vb[4] = int2float(dx);
+ vb[5] = int2float(dy2);
+ vb[6] = int2float(sx);
+ vb[7] = int2float(sy2);
- vb[8] = i2f(dx2);
- vb[9] = i2f(dy2);
- vb[10] = i2f(sx2);
- vb[11] = i2f(sy2);
+ vb[8] = int2float(dx2);
+ vb[9] = int2float(dy2);
+ vb[10] = int2float(sx2);
+ vb[11] = int2float(sy2);
switch(cpp) {
case 4:
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index e5a40ca..1c7ed3a 100644
--- a/drivers/gpu/drm/radeon/r
[Patch v2 4/4] Annotate int2float() as being a pure function.
This allows gcc to fold duplicate calls into a single call. Since
the current users do actually call it multiple times with the
same arguments, this is an obvious win.
---
drivers/gpu/drm/radeon/r600_blit.c |2 +-
drivers/gpu/drm/radeon/r600_blit_shaders.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit.c
b/drivers/gpu/drm/radeon/r600_blit.c
index 54980d8..b4304288 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -499,7 +499,7 @@ set_default_state(drm_radeon_private_t *dev_priv)
* as the fractional bits will not fit in a float. (It would be better to
* round towards even as the fpu does, but that is slower.)
*/
-uint32_t int2float(uint32_t x)
+__pure uint32_t int2float(uint32_t x)
{
uint32_t msb, exponent, fraction;
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.h
b/drivers/gpu/drm/radeon/r600_blit_shaders.h
index e17c2cb..2f3ce7a 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.h
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.h
@@ -35,5 +35,5 @@ extern const u32 r6xx_default_state[];
extern const u32 r6xx_ps_size, r6xx_vs_size;
extern const u32 r6xx_default_size, r7xx_default_size;
-uint32_t int2float(uint32_t x);
+__pure uint32_t int2float(uint32_t x);
#endif
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Fix hw_i2c option for RV280 and RV350.
Hi,
I've been carrying this fix privately for far too long; without it, I
cannot enable the hardware I2C for either of my Radeons RV280 or RV350.
It does not fix the I2C for my rv100, which remains broken.
The nature of the failure is that the display fails completely:
[ 35.067825] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 230
[ 35.076023] Raw EDID:
[ 35.078315] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 35.084067] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 35.089820] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 35.095574] ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff ff
[ 35.101328] ff ff 1e 1e ff ff ff ff ff ff ff 6d 6d ff ff ff
[ 35.107080] ff ff ff ff 3e 3e ff ff ff ff ff ff ff 4e 4e ff
[ 35.112833] ff ff ff ff ff ff 9a 9a ff ff ff ff ff ff ff f7
[ 35.118587] f7 ff ff ff ff ff ff ff ff ff ff 02 02 ff ff ff
[ 35.167737] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 142
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux-3.5/drivers/gpu/drm/radeon/radeon_i2c.c.orig 2012-06-07 12:41:09.0 +0100
+++ linux-3.5/drivers/gpu/drm/radeon/radeon_i2c.c 2012-08-11 23:00:00.0 +0100
@@ -245,7 +245,7 @@
case CHIP_R300:
case CHIP_R350:
case CHIP_RV350:
- i2c_clock = 60;
+ i2c_clock = 100;
nm = (sclk * 10) / (i2c_clock * 4);
for (loop = 1; loop < 255; loop++) {
if ((nm / loop) < loop)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG] Intel xorg driver 2.20.2 overlay off-by-one bug
While reading through the Intel driver code, I spotted this in
I830SetPortAttributeOverlay:
} else if (attribute == xvPipe) {
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
if ((value < -1) || (value > xf86_config->num_crtc))
return BadValue;
if (value < 0)
adaptor_priv->desired_crtc = NULL;
else
adaptor_priv->desired_crtc = xf86_config->crtc[value];
This allows value == xf86_config->num_crtc to be valid, which would be
the CRTC number _after_ the last one in the array. Presumably this is
not desired, and the test should be ">=".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[UDL] general protection fault in fb_deferred_io_mkwrite()
Hi,
guilty driver is probably udl_fb.c
any ideas?
[ 42.890551] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 42.890585] released /dev/fb1 user=1 count=0
[ 42.890702] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 43.053034] type=1400 audit(1344698343.496:9): avc: denied { execmem } for
pid=631 comm="java" scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=process
[ 43.093084] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 43.140051] [drm] write mode info 144
[ 43.140786] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 43.164482] asix 2-1.3:1.0: eth1: link down
[ 44.791884] asix 2-1.3:1.0: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
[ 45.289464] general protection fault: [#1]
[ 45.289512] CPU 0
[ 45.289529] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl
syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4
btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211
snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore
wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan]
[ 45.290003]
[ 45.290003] Pid: 629, comm: X Not tainted 3.5.1 #3 Acer Aspire 1810T/JM11-MS
[ 45.290003] RIP: 0010:[] []
fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.290003] RSP: :880138e93c98 EFLAGS: 00010246
[ 45.290003] RAX: 7672645f6e6f6564 RBX: ea0004bd6180 RCX: 0036
[ 45.290003] RDX: 88013369b460 RSI: 880138e93cf8 RDI: 880130e0a800
[ 45.290003] RBP: 880138e93cb8 R08: 0c00 R09: a80012f58600
[ 45.290003] R10: 57ffd70a7ebd6180 R11: 003ccd37a850 R12: 880130e0a800
[ 45.290003] R13: 88013369b448 R14: 88013369b440 R15:
[ 45.290003] FS: 7f981237a8c0() GS:8168a000()
knlGS:
[ 45.290003] CS: 0010 DS: ES: CR0: 80050033
[ 45.290003] CR2: 7f9810821010 CR3: 00012f191000 CR4: 000407f0
[ 45.290003] DR0: DR1: DR2:
[ 45.290003] DR3: DR6: 0ff0 DR7: 0400
[ 45.290003] Process X (pid: 629, threadinfo 880138e92000, task
880130c16b50)
[ 45.290003] Stack:
[ 45.290003] 880130f37dc8 0001 88013b2049c0
ea0004bd6180
[ 45.290003] 880138e93d48 810b658c 880138e93d48
810b740a
[ 45.290003] 88012f183210 7f9810821010 880127c23420
30c16b50
[ 45.290003] Call Trace:
[ 45.290003] [] __do_fault+0xbc/0x420
[ 45.290003] [] ? do_wp_page.isra.77+0x2aa/0x640
[ 45.290003] [] handle_pte_fault+0x8c/0x7f0
[ 45.290003] [] ? __send_signal.part.24+0x130/0x300
[ 45.290003] [] ? pte_alloc_one+0x1a/0x40
[ 45.290003] [] handle_mm_fault+0x208/0x2c0
[ 45.290003] [] do_page_fault+0x143/0x490
[ 45.290003] [] ? check_preempt_curr+0x85/0xa0
[ 45.290003] [] ? __dequeue_entity+0x2a/0x50
[ 45.290003] [] ? pick_next_task_fair+0x6e/0x180
[ 45.290003] [] ? __schedule+0x22d/0x500
[ 45.290003] [] page_fault+0x1f/0x30
[ 45.290003] Code: 89 0a 4c 89 ef e8 35 fd 27 00 49 8b 36 49 8d bc 24 90 02
00 00 e8 95 66 e0 ff 5b b8 00 02 00 00 41 5c 41 5d 41 5e 5d c3 4c 89 e7 d0
e9 5e ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55
[ 45.290003] RIP [] fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.290003] RSP
[ 45.316388] ---[ end trace d4732d5a0bf375fa ]---
[ 45.347642] released /dev/fb1 user=1 count=0
[ 45.454869] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 45.454903] released /dev/fb1 user=1 count=0
[ 45.455020] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 45.456389] [drm] write mode info 144
[ 45.631358] [drm] write mode info 144
[ 45.632075] general protection fault: [#2]
[ 45.632121] CPU 0
[ 45.632139] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl
syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4
btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211
snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore
wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan]
[ 45.66]
[ 45.66] Pid: 836, comm: X Tainted: G D 3.5.1 #3 Acer Aspire
1810T/JM11-MS
[ 45.66] RIP: 0010:[] []
fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.66] RSP: :880126559c98 EFLAGS: 00010246
[ 45.66] RAX: 006f732e61786562 RBX: ea0004bd6180 RCX: 000
3.6-rc1 breaks my laptop graphics (intel)
Hi Daniel.
The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the
i915 driver initializes itself. I bisected this down to commit
24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the
blc controller on the right pipe), and when I revert that, and also
a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH
backlight registers) which depended on the first patch, my laptop works
just fine.
Below is the combined revert.
Any thoughts? Any patch I can try out?
thanks,
greg k-h
--
Subject: drm/i915: revert 24ded204429fa0f5501d37c63ee35c555c0b75ee and
a4f32fc3a37e982fffce8ec583643990ff288419
24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the
blc controller on the right pipe) breaks the boot for my laptop, so
revert it, and a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't
forget the PCH backlight registers) which depended on it.
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8435355..4e786f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -383,8 +383,7 @@ extern u32 intel_panel_get_max_backlight(struct drm_device
*dev);
extern u32 intel_panel_get_backlight(struct drm_device *dev);
extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
extern int intel_panel_setup_backlight(struct drm_device *dev);
-extern void intel_panel_enable_backlight(struct drm_device *dev,
-enum pipe pipe);
+extern void intel_panel_enable_backlight(struct drm_device *dev);
extern void intel_panel_disable_backlight(struct drm_device *dev);
extern void intel_panel_destroy_backlight(struct drm_device *dev);
extern enum drm_connector_status intel_panel_detect(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index e05c0d3..6547904 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -71,7 +71,6 @@ static struct intel_lvds *intel_attached_lvds(struct
drm_connector *connector)
static void intel_lvds_enable(struct intel_lvds *intel_lvds)
{
struct drm_device *dev = intel_lvds->base.base.dev;
- struct intel_crtc *intel_crtc =
to_intel_crtc(intel_lvds->base.base.crtc);
struct drm_i915_private *dev_priv = dev->dev_private;
u32 ctl_reg, lvds_reg, stat_reg;
@@ -108,7 +107,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000))
DRM_ERROR("timed out waiting for panel to power on\n");
- intel_panel_enable_backlight(dev, intel_crtc->pipe);
+ intel_panel_enable_backlight(dev);
}
static void intel_lvds_disable(struct intel_lvds *intel_lvds)
@@ -1079,14 +1078,35 @@ bool intel_lvds_init(struct drm_device *dev)
goto failed;
out:
- /*
-* Unlock registers and just
-* leave them unlocked
-*/
if (HAS_PCH_SPLIT(dev)) {
+ u32 pwm;
+
+ pipe = (I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT) ? 1 : 0;
+
+ /* make sure PWM is enabled and locked to the LVDS pipe */
+ pwm = I915_READ(BLC_PWM_CPU_CTL2);
+ if (pipe == 0 && (pwm & BLM_PIPE_B))
+ I915_WRITE(BLC_PWM_CPU_CTL2, pwm & ~BLM_PWM_ENABLE);
+ if (pipe)
+ pwm |= BLM_PIPE_B;
+ else
+ pwm &= ~BLM_PIPE_B;
+ I915_WRITE(BLC_PWM_CPU_CTL2, pwm | BLM_PWM_ENABLE);
+
+ pwm = I915_READ(BLC_PWM_PCH_CTL1);
+ pwm |= BLM_PCH_PWM_ENABLE;
+ I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+ /*
+* Unlock registers and just
+* leave them unlocked
+*/
I915_WRITE(PCH_PP_CONTROL,
I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
} else {
+ /*
+* Unlock registers and just
+* leave them unlocked
+*/
I915_WRITE(PP_CONTROL,
I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 10c7d39..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -287,24 +287,9 @@ void intel_panel_disable_backlight(struct drm_device *dev)
dev_priv->backlight_enabled = false;
intel_panel_actually_set_backlight(dev, 0);
-
- if (INTEL_INFO(dev)->gen >= 4) {
- uint32_t reg, tmp;
-
- reg = HAS_PCH_SPLIT(dev) ? BLC_PWM_CPU_CTL2 : BLC_PWM_CTL2;
-
- I915_WRITE(reg, I915_READ(reg) & ~BLM_PWM_ENABLE);
-
- if (HAS_PCH_SPLIT(dev)) {
- tmp = I915_READ(BLC_PWM_PCH_CTL1);
-
Re: 3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > Hi Daniel. > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > i915 driver initializes itself. I bisected this down to commit > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > blc controller on the right pipe), and when I revert that, and also > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > backlight registers) which depended on the first patch, my laptop works > > just fine. > > > > Below is the combined revert. > > > > Any thoughts? Any patch I can try out? > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > which is already merged to drm-intel-fixes. Ah, thanks, I'll go try that out, the Subject: line didn't draw my attention to it being the same problem as mine :) greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:33:05AM -0700, Greg KH wrote: > On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > > Hi Daniel. > > > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > > i915 driver initializes itself. I bisected this down to commit > > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > > blc controller on the right pipe), and when I revert that, and also > > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > > backlight registers) which depended on the first patch, my laptop works > > > just fine. > > > > > > Below is the combined revert. > > > > > > Any thoughts? Any patch I can try out? > > > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > > > which is already merged to drm-intel-fixes. > > Ah, thanks, I'll go try that out, the Subject: line didn't draw my > attention to it being the same problem as mine :) Yes, that works, many thanks. I'm guessing this is going to be going to Linus soon, right? greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
(Bringing this back to the mailing lists after a bit of uninteresting private conversation.) > Honestly, I think we need a way to force disable gmbus with a module > parameter or something anyway. It's not the first time gmbus has been > implicated with an issue. Maybe it even exists already, but I couldn't > find this. So if you confirm that fixes the problem for you on the ml, > at least maybe such a patch will be the result. > > If you feel it's a software bug (which I agree it seems likely), a > bisect is always much appreciated. Personally, I'll usually step back > major releases until something works, or I hit 3.2ish. Even knowing it > never worked through 3.2 is helpful. It's a friend's machine, which I normally only have remote access to, so it's a bit pf a pain, but I can manage. I just thought a basic i3 motherboard was so common I couldn't possibly be the only one with this problem. Here's the 3.2 dmesg showing the fallback working, but this is an Ubuntu-patched kernel (linux-image-3.2.0-29-generic) that may be a fair distance from stock: [ 44.401124] [drm] Initialized drm 1.1.0 20060810 [ 44.471549] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 44.471553] i915 :00:02.0: setting latency timer to 64 [ 44.555865] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.611882] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.667876] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.723831] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.779841] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.835854] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.895843] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.951836] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 45.007798] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.063716] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.119776] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.175716] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.231689] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.287696] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.343704] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.399667] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.455651] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.511629] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.567581] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.623645] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.679546] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.735614] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.791596] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.847533] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.903517] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 45.959547] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.015492] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.071473] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.127430] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.183447] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.239425] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.295407] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.351401] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.407382] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.463363] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.519347] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.575302] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.631320] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.687360] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.743300] [drm] GMBUS timed out, falling back
[RFC] make VM handling async
Yeah, I know I'm on vacation, but without coding I die of boringness in less than a week. This patchset is currently based on Jeromes VA fencing patch, but in the end makes it superfluous. It just moves the whole VM handling into the CP ring, removing the need to wait for anything directly in the VM code, the any waiting that happens is now in the allocation of page tables and that happens only on allocation of new VM space and not on freeing it, which in turn makes handling allot more simpler. It's not 100% complete cause page table updates should be made with the DMA ring, but we haven't released documentation for that yet, so I currently use CP memory writes instead. Please take a look and tell me what you think about it. Cheers, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/10] drm/radeon: fence virtual address and free it once idle v4
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
v4: Fix compilation warnings.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c |6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..b4a0db24 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+
+ if (parser->chunk_ib_idx == -1) {
+ return;
+ }
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
+ return;
+ }
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(&rdev->vm_manager.lock);
- /* remove all bo */
+ /* remove all bo at this point non are bus
[PATCH 02/10] drm/radeon: cleanup VM id handling a bit
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c |5 +++--
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
drivers/gpu/drm/radeon/radeon.h |5 +++--
drivers/gpu/drm/radeon/radeon_cs.c | 18 +++---
drivers/gpu/drm/radeon/radeon_ring.c | 14 +++---
drivers/gpu/drm/radeon/si.c |5 +++--
7 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9945d86..efa3ab9 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -871,12 +871,13 @@ void cayman_ring_ib_execute(struct radeon_device *rdev,
struct radeon_ib *ib)
#endif
(ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0xFF);
- radeon_ring_write(ring, ib->length_dw | (ib->vm_id << 24));
+ radeon_ring_write(ring, ib->length_dw |
+ (ib->vm ? (ib->vm->id << 24) : 0));
/* flush read cache over gart for this vmid */
radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
radeon_ring_write(ring, (CP_COHER_CNTL2 - PACKET3_SET_CONFIG_REG_START)
>> 2);
- radeon_ring_write(ring, ib->vm_id);
+ radeon_ring_write(ring, ib->vm ? ib->vm->id : 0);
radeon_ring_write(ring, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(ring, PACKET3_TC_ACTION_ENA | PACKET3_SH_ACTION_ENA);
radeon_ring_write(ring, 0x);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8acb34f..5f5f524 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3816,7 +3816,7 @@ int r100_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, 256);
+ r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, NULL, 256);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 637280f..75d448d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2635,7 +2635,7 @@ int r600_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ib_get(rdev, ring->idx, &ib, 256);
+ r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
if (r) {
DRM_ERROR("radeon: failed to get ib (%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8d75c65..ef1fdf2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -611,7 +611,7 @@ struct radeon_ib {
uint32_t*ptr;
int ring;
struct radeon_fence *fence;
- unsignedvm_id;
+ struct radeon_vm*vm;
boolis_const_ib;
struct radeon_fence *sync_to[RADEON_NUM_RINGS];
struct radeon_semaphore *semaphore;
@@ -753,7 +753,8 @@ struct si_rlc {
};
int radeon_ib_get(struct radeon_device *rdev, int ring,
- struct radeon_ib *ib, unsigned size);
+ struct radeon_ib *ib, struct radeon_vm *vm,
+ unsigned size);
void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib);
int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib,
struct radeon_ib *const_ib);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index b4a0db24..0a9d1eb 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -363,7 +363,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
* uncached).
*/
r = radeon_ib_get(rdev, parser->ring, &parser->ib,
- ib_chunk->length_dw * 4);
+ NULL, ib_chunk->length_dw * 4);
if (r) {
DRM_ERROR("Failed to get ib !\n");
return r;
@@ -380,7 +380,6 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
return r;
}
radeon_cs_sync_rings(parser);
- parser->ib.vm_id = 0;
r = radeon_ib_schedule(rdev, &parser->ib, NULL);
if (r) {
DRM_ERROR("Failed to schedule IB !\n");
@@ -426,7 +425,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
return -EINVAL;
}
r = radeon_ib_get(rdev, parser->ring, &parser->const_ib,
- ib_ch
[PATCH 03/10] drm/radeon: move VM funcs into asic structure
So it looks more like the rest of the driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 35 +---
drivers/gpu/drm/radeon/radeon_asic.c | 50 ++
drivers/gpu/drm/radeon/radeon_gart.c | 16 +--
3 files changed, 54 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ef1fdf2..5163346 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -660,28 +660,12 @@ struct radeon_vm {
struct radeon_fence *fence;
};
-struct radeon_vm_funcs {
- int (*init)(struct radeon_device *rdev);
- void (*fini)(struct radeon_device *rdev);
- /* cs mutex must be lock for schedule_ib */
- int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, int id);
- void (*unbind)(struct radeon_device *rdev, struct radeon_vm *vm);
- void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm *vm);
- uint32_t (*page_flags)(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags);
- void (*set_page)(struct radeon_device *rdev, struct radeon_vm *vm,
- unsigned pfn, uint64_t addr, uint32_t flags);
-};
-
struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
uint32_tuse_bitmap;
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
- /* fields constant after init */
- const struct radeon_vm_funcs*funcs;
/* number of VMIDs */
unsignednvm;
/* vram base address for page table entry */
@@ -1147,6 +1131,18 @@ struct radeon_asic {
void (*tlb_flush)(struct radeon_device *rdev);
int (*set_page)(struct radeon_device *rdev, int i, uint64_t
addr);
} gart;
+ struct {
+ int (*init)(struct radeon_device *rdev);
+ void (*fini)(struct radeon_device *rdev);
+ int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
+ void (*unbind)(struct radeon_device *rdev, struct radeon_vm
*vm);
+ void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
+ uint32_t (*page_flags)(struct radeon_device *rdev,
+ struct radeon_vm *vm,
+ uint32_t flags);
+ void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
+unsigned pfn, uint64_t addr, uint32_t flags);
+ } vm;
/* ring specific callbacks */
struct {
void (*ib_execute)(struct radeon_device *rdev, struct radeon_ib
*ib);
@@ -1698,6 +1694,13 @@ void radeon_ring_write(struct radeon_ring *ring,
uint32_t v);
#define radeon_asic_reset(rdev) (rdev)->asic->asic_reset((rdev))
#define radeon_gart_tlb_flush(rdev) (rdev)->asic->gart.tlb_flush((rdev))
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
+#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
+#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
+#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
+#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
+#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
+#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
#define radeon_ring_test(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev),
(cp))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 973417c..7d29d53 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1342,16 +1342,6 @@ static struct radeon_asic btc_asic = {
},
};
-static const struct radeon_vm_funcs cayman_vm_funcs = {
- .init = &cayman_vm_init,
- .fini = &cayman_vm_fini,
- .bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
- .tlb_flush = &cayman_vm_tlb_flush,
- .page_flags = &cayman_vm_page_flags,
- .set_page = &cayman_vm_set_page,
-};
-
static struct radeon_asic cayman_asic = {
.init = &cayman_init,
.fini = &cayman_fini,
@@ -1366,6 +1356,15 @@ static struct radeon_asic cayman_asic = {
.tlb_flush = &cayman_pcie_gart_tlb_flush,
.set_page = &rs600_gart_set_page,
[PATCH 04/10] drm/radeon: remove vm_unbind
It actually isn't very useful.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |2 --
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_gart.c |1 -
drivers/gpu/drm/radeon/si.c | 12
5 files changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index efa3ab9..3b1aab3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1501,17 +1501,6 @@ int cayman_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
return 0;
}
-void cayman_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (vm->id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm->id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
{
if (vm->id == -1)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5163346..aeb2d1f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1135,7 +1135,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
- void (*unbind)(struct radeon_device *rdev, struct radeon_vm
*vm);
void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
@@ -1697,7 +1696,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
-#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 7d29d53..9d5f4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1360,7 +1360,6 @@ static struct radeon_asic cayman_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1463,7 +1462,6 @@ static struct radeon_asic trinity_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1566,7 +1564,6 @@ static struct radeon_asic si_asic = {
.init = &si_vm_init,
.fini = &si_vm_fini,
.bind = &si_vm_bind,
- .unbind = &si_vm_unbind,
.tlb_flush = &si_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2902e5f..18a03ab 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -522,7 +522,6 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
radeon_fence_unref(&vm->fence);
/* hw unbind */
- radeon_asic_vm_unbind(rdev, vm);
rdev->vm_manager.use_bitmap &= ~(1 << vm->id);
list_del_init(&vm->list);
vm->id = -1;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4ebcb33..40a9a85 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2795,18 +2795,6 @@ int si_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
return 0;
}
-void si_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- if (vm->id < 8)
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
- else
- WREG32(VM_CONTEXT8_PA
[PATCH 05/10] drm/radeon: add sync helper function
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -115,19 +115,27 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p,
u32 ring, s32 priority
return 0;
}
+static void radeon_cs_sync_to(struct radeon_cs_parser *p,
+ struct radeon_fence *fence)
+{
+ struct radeon_fence *other;
+
+ if (!fence)
+ return;
+
+ other = p->ib.sync_to[fence->ring];
+ p->ib.sync_to[fence->ring] = radeon_fence_later(fence, other);
+}
+
static void radeon_cs_sync_rings(struct radeon_cs_parser *p)
{
int i;
for (i = 0; i < p->nrelocs; i++) {
- struct radeon_fence *a, *b;
-
- if (!p->relocs[i].robj || !p->relocs[i].robj->tbo.sync_obj)
+ if (!p->relocs[i].robj)
continue;
- a = p->relocs[i].robj->tbo.sync_obj;
- b = p->ib.sync_to[a->ring];
- p->ib.sync_to[a->ring] = radeon_fence_later(a, b);
+ radeon_cs_sync_to(p, p->relocs[i].robj->tbo.sync_obj);
}
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/radeon: make VM flushs a ring operation
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 31 ---
drivers/gpu/drm/radeon/radeon.h |6 --
drivers/gpu/drm/radeon/radeon_asic.c | 12 +---
drivers/gpu/drm/radeon/radeon_asic.h |3 +--
drivers/gpu/drm/radeon/radeon_cs.c |1 +
drivers/gpu/drm/radeon/radeon_gart.c |4 +++-
drivers/gpu/drm/radeon/radeon_ring.c |8
drivers/gpu/drm/radeon/si.c | 15 ---
8 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3b1aab3..ad337e8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1494,24 +1494,9 @@ int cayman_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >>
12);
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << id);
return 0;
}
-void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- if (vm->id == -1)
- return;
-
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
#define R600_PTE_VALID (1 << 0)
#define R600_PTE_SYSTEM(1 << 1)
#define R600_PTE_SNOOPED (1 << 2)
@@ -1543,3 +1528,19 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
addr |= flags;
writeq(addr, ptr + (pfn * 8));
}
+
+void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
+{
+ struct radeon_ring *ring = &rdev->ring[ib->ring];
+
+ if (!ib->vm || ib->vm->id == -1)
+ return;
+
+ /* flush hdp cache */
+ radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
+ radeon_ring_write(ring, 0x1);
+
+ /* bits 0-7 are the VM contexts0-7 */
+ radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
+ radeon_ring_write(ring, 1 << ib->vm->id);
+}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index aeb2d1f..1228778 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -658,6 +658,8 @@ struct radeon_vm {
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
+ /* last flush or NULL if we still need to flush */
+ struct radeon_fence *last_flush;
};
struct radeon_vm_manager {
@@ -1135,7 +1137,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
- void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
uint32_t flags);
@@ -1154,6 +1155,7 @@ struct radeon_asic {
int (*ring_test)(struct radeon_device *rdev, struct radeon_ring
*cp);
int (*ib_test)(struct radeon_device *rdev, struct radeon_ring
*cp);
bool (*is_lockup)(struct radeon_device *rdev, struct
radeon_ring *cp);
+ void (*vm_flush)(struct radeon_device *rdev, struct radeon_ib
*ib);
} ring[RADEON_NUM_RINGS];
/* irqs */
struct {
@@ -1696,7 +1698,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
-#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1705,6 +1706,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_ring_ib_execute(rdev, r, ib)
(rdev)->asic->ring[(r)].ib_execute((rdev), (ib))
#define radeon_ring_ib_parse(rdev, r, ib)
(rdev)->asic->ring[(r)].ib_parse((rdev), (ib))
#define radeon_ring_is_lockup(rdev, r, cp)
(rdev)->asic->ring[(r)].is_lockup((rdev), (cp))
+#define radeon_ring_vm
[PATCH 07/10] drm/radeon: rework VMID handling
Move binding onto the ring, simplifying handling a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c| 20 ++---
drivers/gpu/drm/radeon/radeon.h| 30 +++-
drivers/gpu/drm/radeon/radeon_asic.c |9 +--
drivers/gpu/drm/radeon/radeon_asic.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c |9 +--
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_gart.c | 126 +---
drivers/gpu/drm/radeon/si.c| 30 ++--
8 files changed, 153 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index ad337e8..88d5713 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1489,14 +1489,6 @@ void cayman_vm_fini(struct radeon_device *rdev)
{
}
-int cayman_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm, int id)
-{
- WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >>
12);
- return 0;
-}
-
#define R600_PTE_VALID (1 << 0)
#define R600_PTE_SYSTEM(1 << 1)
#define R600_PTE_SNOOPED (1 << 2)
@@ -1532,10 +1524,20 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
{
struct radeon_ring *ring = &rdev->ring[ib->ring];
+ struct radeon_vm *vm = ib->vm;
- if (!ib->vm || ib->vm->id == -1)
+ if (vm == NULL)
return;
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, 0);
+
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, vm->last_pfn);
+
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, vm->pt_gpu_addr >> 12);
+
/* flush hdp cache */
radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
radeon_ring_write(ring, 0x1);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1228778..e0c6673 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -268,6 +268,22 @@ static inline struct radeon_fence
*radeon_fence_later(struct radeon_fence *a,
}
}
+static inline bool radeon_fence_is_earlier(struct radeon_fence *a,
+ struct radeon_fence *b)
+{
+ if (!a) {
+ return false;
+ }
+
+ if (!b) {
+ return true;
+ }
+
+ BUG_ON(a->ring != b->ring);
+
+ return a->seq < b->seq;
+}
+
/*
* Tiling registers
*/
@@ -647,10 +663,13 @@ struct radeon_ring {
/*
* VM
*/
+
+#define RADEON_NUM_VM 16
+
struct radeon_vm {
struct list_headlist;
struct list_headva;
- int id;
+ unsignedid;
unsignedlast_pfn;
u64 pt_gpu_addr;
u64 *pt;
@@ -665,7 +684,7 @@ struct radeon_vm {
struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
- uint32_tuse_bitmap;
+ struct radeon_fence *active[RADEON_NUM_VM];
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
/* number of VMIDs */
@@ -1136,7 +1155,6 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
- int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
uint32_t flags);
@@ -1697,7 +1715,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1779,6 +1796,11 @@ int radeon_vm_init(struct radeon_device *rdev, struct
radeon_vm *vm);
void radeon_vm_fini(stru
[PATCH 08/10] drm/radeon: rework VM page table handling
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 28 +
drivers/gpu/drm/radeon/radeon_gart.c | 107 +++---
drivers/gpu/drm/radeon/radeon_sa.c | 20 +++
4 files changed, 43 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e0c6673..ed0ef17 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -316,7 +316,6 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
- struct radeon_fence *fence;
boolvalid;
};
@@ -1794,8 +1793,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev);
void radeon_vm_manager_fini(struct radeon_device *rdev);
int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
-int radeon_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm);
-void radeon_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm);
+int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
struct radeon_vm *vm, int ring);
void radeon_vm_fence(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index dc4554e..300fc25 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -286,30 +286,6 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
-static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
- struct radeon_fence *fence)
-{
- struct radeon_fpriv *fpriv = parser->filp->driver_priv;
- struct radeon_vm *vm = &fpriv->vm;
- struct radeon_bo_list *lobj;
-
- if (parser->chunk_ib_idx == -1) {
- return;
- }
- if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
- return;
- }
-
- list_for_each_entry(lobj, &parser->validated, tv.head) {
- struct radeon_bo_va *bo_va;
- struct radeon_bo *rbo = lobj->bo;
-
- bo_va = radeon_bo_va(rbo, vm);
- radeon_fence_unref(&bo_va->fence);
- bo_va->fence = radeon_fence_ref(fence);
- }
-}
-
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -323,8 +299,6 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
unsigned i;
if (!error) {
- /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
- radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
} else {
@@ -475,7 +449,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
- r = radeon_vm_bind(rdev, vm);
+ r = radeon_vm_alloc_pt(rdev, vm);
if (r) {
goto out;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index d668733..4bce026 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -478,43 +478,26 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
return 0;
}
-/* global mutex must be lock */
/**
- * radeon_vm_unbind_locked - unbind a specific vm
+ * radeon_vm_free_pt - free the page table for 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.
+ * Free the page table of a specific vm (cayman+).
+ *
+ * Global and local mutex must be lock!
*/
-static void radeon_vm_unbind_locked(struct radeon_device *rdev,
+static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
{
struct radeon_bo_va *bo_va;
- /* wait for vm use to end */
- 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)
-
[PATCH 09/10] drm/radeon: Move looping over the PTEs into chip code
Makes it easier to move it into the rings.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 22 +++---
drivers/gpu/drm/radeon/radeon.h | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_asic.h |7 +++
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
5 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 88d5713..1fd2e41 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1495,9 +1495,7 @@ void cayman_vm_fini(struct radeon_device *rdev)
#define R600_PTE_READABLE (1 << 5)
#define R600_PTE_WRITEABLE (1 << 6)
-uint32_t cayman_vm_page_flags(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags)
+uint32_t cayman_vm_page_flags(struct radeon_device *rdev, uint32_t flags)
{
uint32_t r600_flags = 0;
@@ -1512,13 +1510,23 @@ uint32_t cayman_vm_page_flags(struct radeon_device
*rdev,
}
void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
- unsigned pfn, uint64_t addr, uint32_t flags)
+ unsigned pfn, struct ttm_mem_reg *mem,
+ unsigned npages, uint32_t flags)
{
void __iomem *ptr = (void *)vm->pt;
+ uint64_t addr;
+ int i;
+
+ addr = flags = cayman_vm_page_flags(rdev, flags);
- addr = addr & 0xF000ULL;
- addr |= flags;
- writeq(addr, ptr + (pfn * 8));
+for (i = 0; i < npages; ++i, ++pfn) {
+if (mem) {
+addr = radeon_vm_get_addr(rdev, mem, i);
+ addr = addr & 0xF000ULL;
+ addr |= flags;
+}
+ writeq(addr, ptr + (pfn * 8));
+}
}
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ed0ef17..7d37cb2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,11 +1154,9 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
- uint32_t (*page_flags)(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags);
void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
-unsigned pfn, uint64_t addr, uint32_t flags);
+unsigned pfn, struct ttm_mem_reg *mem,
+unsigned npages, uint32_t flags);
} vm;
/* ring specific callbacks */
struct {
@@ -1714,8 +1712,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
-#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, mem, npages, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (mem), (npages), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
#define radeon_ring_test(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev),
(cp))
@@ -1799,6 +1796,9 @@ struct radeon_fence *radeon_vm_grab_id(struct
radeon_device *rdev,
void radeon_vm_fence(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_fence *fence);
+u64 radeon_vm_get_addr(struct radeon_device *rdev,
+ struct ttm_mem_reg *mem,
+ unsigned pfn);
int radeon_vm_bo_update_pte(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_bo *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 5486674..4b99a24 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,7 +1359,6 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
- .page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1462,7 +1461,6 @@ static struct radeon_asic trinity_asic = {
.vm = {
.init =
[PATCH 10/10] drm/radeon: make page table updates async
Currently doing the update with the CP.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 20 ++
drivers/gpu/drm/radeon/nid.h |1 +
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |3 ++
drivers/gpu/drm/radeon/radeon_gart.c | 70 +-
5 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 1fd2e41..78d9cfb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1513,20 +1513,24 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
unsigned pfn, struct ttm_mem_reg *mem,
unsigned npages, uint32_t flags)
{
- void __iomem *ptr = (void *)vm->pt;
- uint64_t addr;
+ struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
+ uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
int i;
addr = flags = cayman_vm_page_flags(rdev, flags);
-for (i = 0; i < npages; ++i, ++pfn) {
-if (mem) {
-addr = radeon_vm_get_addr(rdev, mem, i);
+ radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
+ radeon_ring_write(ring, pt & 0x);
+ radeon_ring_write(ring, (pt >> 32) & 0xff);
+ for (i = 0; i < npages; ++i) {
+ if (mem) {
+ addr = radeon_vm_get_addr(rdev, mem, i);
addr = addr & 0xF000ULL;
addr |= flags;
-}
- writeq(addr, ptr + (pfn * 8));
-}
+ }
+ radeon_ring_write(ring, addr & 0x);
+ radeon_ring_write(ring, (addr >> 32) & 0x);
+ }
}
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 870db34..2423d1b 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -585,6 +585,7 @@
#definePACKET3_SET_CONTEXT_REG_INDIRECT0x73
#definePACKET3_SET_RESOURCE_INDIRECT 0x74
#definePACKET3_SET_APPEND_CNT 0x75
+#definePACKET3_ME_WRITE0x7A
#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7d37cb2..3de0f08 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,6 +1154,8 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
+
+ u32 pt_ring_index;
void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
unsigned pfn, struct ttm_mem_reg *mem,
unsigned npages, uint32_t flags);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 4b99a24..d0b4e50 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,6 +1359,7 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1461,6 +1462,7 @@ static struct radeon_asic trinity_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1563,6 +1565,7 @@ static struct radeon_asic si_asic = {
.vm = {
.init = &si_vm_init,
.fini = &si_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index bf5378b..9cfd213 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -464,15 +464,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
continue;
list_for_each_entry(bo_va, &vm->va, vm_list) {
- struct ttm_mem_reg *mem = NULL;
- if (bo_va->valid)
- mem = &bo_va->bo->tbo.mem;
-
bo_va->valid = false;
- r = radeon_vm_bo_update_pte(rdev, vm, bo_va->bo, mem);
- if (r) {
- DRM_ERROR("Failed to update pte for vm %d!\n",
vm->id);
- }
}
}
return 0;
@@ -8
Re: [RFCv3 PATCH 1/8] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
On Mon August 13 2012 13:48:28 Soby Mathew wrote:
> Hi Hans,
>The patch seems to cover most of the requirement. I find 2 gaps:
>
> > +/* DV-class control IDs defined by V4L2 */
> > +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> > +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> > +
> > +#defineV4L2_CID_DV_TX_HOTPLUG
> > (V4L2_CID_DV_CLASS_BASE + 1)
> > +#defineV4L2_CID_DV_TX_RXSENSE
> > (V4L2_CID_DV_CLASS_BASE + 2)
> > +#defineV4L2_CID_DV_TX_EDID_PRESENT
> > (V4L2_CID_DV_CLASS_BASE + 3)
> > +#defineV4L2_CID_DV_TX_MODE
> > (V4L2_CID_DV_CLASS_BASE + 4)
> > +enum v4l2_dv_tx_mode {
> > + V4L2_DV_TX_MODE_DVI_D = 0,
> > + V4L2_DV_TX_MODE_HDMI= 1,
> > +};
>
>
> Even at the receiver side the DVI/HDMI mode need to be detected. So
> probably a control for the RX mode is needed.
We left that part out for the moment: we (Cisco) do not need that at the
moment, and for this first version I wanted to concentrate only on those
parts that were absolutely necessary.
Once it's merged it is much easier to add additional functionality like
that.
>
>
> > +#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
> > +enum v4l2_dv_rgb_range {
> > + V4L2_DV_RGB_RANGE_AUTO= 0,
> > + V4L2_DV_RGB_RANGE_LIMITED = 1,
> > + V4L2_DV_RGB_RANGE_FULL= 2,
> > +};
> > +
> > +#defineV4L2_CID_DV_RX_POWER_PRESENT
> > (V4L2_CID_DV_CLASS_BASE + 100)
> > +#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE +
> > 101)
> > +
>
> Similarly, some sources can support YC mode of transmission instaed of
> RGB. To control the YC Quantization Range, we can define control
> V4L2_CID_DV_TX_YC_RANGE
>
> Similar control would be needed at the Rx side also like
> V4L2_CID_DV_RX_YC_RANGE.
The question is if you actually need this control for the YC range. For RGB
it is necessary because you cannot rely on the autodetect: too many devices
do not handle that correctly, so you have to be able to override.
For YC the situation seems to be much better and we (Cisco) haven't seen the
need yet to be able to override the automatic YC range setup.
If there is a clear situation where this is necessary, then it can be added.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails with such error messages: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of function 'swiotlb_nr_tbl' drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 'ttm_dma_populate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but argument is of type 'struct device *' drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 'ttm_dma_unpopulate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but argument is of type 'struct device *' V2: 1, Add compilation error messages; 2, Make the From: address the same as Signed-off-by address. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
> +
> + if (!ret) {
> + cb->base.flags = 0;
> + cb->base.func = __dma_fence_wake_func;
> + cb->base.private = priv;
> + cb->fence = fence;
> + cb->func = func;
> + __add_wait_queue(&fence->event_queue, &cb->base);
> + }
> + spin_unlock_irqrestore(&fence->event_queue.lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_fence_add_callback);
I think for api completenes we should also have a
dma_fence_remove_callback function.
>>> We did originally but Maarten found it was difficult to deal with
>>> properly when the gpu's hang. I think his alternative was just to
>>> require the hung driver to signal the fence. I had kicked around the
>>> idea of a dma_fence_cancel() alternative to signal that could pass an
>>> error thru to the waiting driver.. although not sure if the other
>>> driver could really do anything differently at that point.
>> No, there is a very real reason I removed dma_fence_remove_callback. It is
>> absolutely non-trivial to cancel it once added, since you have to deal with
>> all kinds of race conditions.. See i915_gem_reset_requests in my git tree:
>> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=673c4b2550bc63ec134bca47a95dabd617a689ce
> I don't see the point in that code ... Why can't we drop the kref
> _outside_ of the critical section protected by event_queue_lock? Then you
> pretty much have an open-coded version of dma_fence_callback_cancel in
> there.
The event_queue_lock protects 2 things:
1. Refcount to dma_fence won't drop to 0 if val->fences[i] != NULL
Creator is supposed to keep a refcount until after dma_fence_signal
returns. Adding a refcount you release in the callback won't help
you here much.
2. Integrity of request->prime_list
The list_del's are otherwise not serialized, leaving a corrupted
list if 2 fences signal at the same time. kref_put in the non-free'ing
case is simply an atomic decrement, so there's no measurable penalty
for keeping it in the lock.
So no, you could remove it from the kref_put, but val->fences[i] = NULL
assignment would still need it, so there's no real penalty left for
putting kref_put in the spinlock to also protect the second case
without dropping/retaking lock.
I'll add dma_fence_remove_callback that returns a bool of whether
the callback was removed or not. In the latter case the fence already
fired. However, if you call dma_fence_remove_callback twice, on the
wrong fence, or without ever calling dma_fence_add_callback you'd
undefined behavior, and there's no guarantee I could detech such
situation, but with those constraints I think it could be useful to
have.
It sucks but prime_rm_lock is the inner lock so the only way not to
deadlock is doing what I'm doing there, or not getting the hardware
locked in the first place.
>
>> This is the only way to do it completely deadlock/memory corruption free
>> since you essentially have a locking inversion to avoid. I had it wrong
>> the first 2 times too, even when I knew about a lot of the locking
>> complications. If you want to do it, in most cases it will likely be easier
>> to just eat the signal and ignore it instead of canceling.
>>
> +
> +/**
> + * dma_fence_wait - wait for a fence to be signaled
> + *
> + * @fence: [in]The fence to wait on
> + * @intr:[in]if true, do an interruptible wait
> + * @timeout: [in]absolute time for timeout, in jiffies.
I don't quite like this, I think we should keep the styl of all other
wait_*_timeout functions and pass the arg as timeout in jiffies (and also
the same return semantics). Otherwise well have funny code that needs to
handle return values differently depending upon whether it waits upon a
dma_fence or a native object (where it would us the wait_*_timeout
functions directly).
>>> We did start out this way, but there was an ugly jiffies roll-over
>>> problem that was difficult to deal with properly. Using an absolute
>>> time avoided the problem.
>> Yeah, this makes it easier to wait on multiple fences, instead of
>> resetting the timeout over and over and over again, or manually
>> recalculating.
> I don't see how updating the jiffies_left timeout is that onerous, and in
> any case we can easily wrap that up into a little helper function, passing
> in an array of dma_fence pointers.
>
> Creating interfaces that differ from established kernel api patterns otoh
> isn't good imo. I.e. I want dma_fence_wait_bla to be a drop-in replacement
> for the corresponding wait_event_bla function/macro, which the same
> semantics for the timeout and return values.
>
> Differing in such things only leads to confusion when reading patches imo.
>
Ok, I'll see if I can make a set of functions that follow the normal rules
for these types of functions.
~Maarten
_
Re: [RFC] make VM handling async
> It's not 100% complete cause page table updates should be made with the DMA > ring, but we haven't released documentation for that yet, so I currently > use CP memory writes instead. Sad. Any release time hint? (the DMA ring will cleanup a lot of code). BTW, maybe at the same time the HDP_NONSURFACE regs should be 64bitified? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] GMBUS EDID read bit-banging fallback
Alex, Maciej, please test the following to see if it fixes the issue [1], thanks. BR, Jani. [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881 Jani Nikula (2): drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads drivers/gpu/drm/i915/intel_crt.c | 36 +--- drivers/gpu/drm/i915/intel_drv.h |2 ++ drivers/gpu/drm/i915/intel_modes.c | 31 ++- 3 files changed, 57 insertions(+), 12 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: extract connector update from intel_ddc_get_modes() for reuse
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_modes.c | 31 ++-
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 13f0467..8a224ca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -357,6 +357,8 @@ struct intel_fbc_work {
int interval;
};
+int intel_connector_update_modes(struct drm_connector *connector,
+ struct edid *edid);
int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
extern void intel_attach_force_audio_property(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index 45848b9..29b7259 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -33,6 +33,25 @@
#include "i915_drv.h"
/**
+ * intel_connector_update_modes - update connector from edid
+ * @connector: DRM connector device to use
+ * @edid: previously read EDID information
+ */
+int intel_connector_update_modes(struct drm_connector *connector,
+ struct edid *edid)
+{
+ int ret;
+
+ drm_mode_connector_update_edid_property(connector, edid);
+ ret = drm_add_edid_modes(connector, edid);
+ drm_edid_to_eld(connector, edid);
+ connector->display_info.raw_edid = NULL;
+ kfree(edid);
+
+ return ret;
+}
+
+/**
* intel_ddc_get_modes - get modelist from monitor
* @connector: DRM connector device to use
* @adapter: i2c adapter
@@ -43,18 +62,12 @@ int intel_ddc_get_modes(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid;
- int ret = 0;
edid = drm_get_edid(connector, adapter);
- if (edid) {
- drm_mode_connector_update_edid_property(connector, edid);
- ret = drm_add_edid_modes(connector, edid);
- drm_edid_to_eld(connector, edid);
- connector->display_info.raw_edid = NULL;
- kfree(edid);
- }
+ if (!edid)
+ return 0;
- return ret;
+ return intel_connector_update_modes(connector, edid);
}
static const struct drm_prop_enum_list force_audio_names[] = {
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6d235bd465309e12f4c56ea16e7
Author: Daniel Vetter
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
Author: Daniel Vetter
Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
fallback to CRT EDID reads.
LKML-Reference: <201207251020.47637.maciej.rute...@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_crt.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index bc5e2c9..80bf311 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -328,6 +328,36 @@ static bool intel_crt_detect_hotplug(struct drm_connector
*connector)
return ret;
}
+static struct edid *intel_crt_get_edid(struct drm_connector *connector,
+ struct i2c_adapter *i2c)
+{
+ struct edid *edid;
+
+ edid = drm_get_edid(connector, i2c);
+
+ if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
+ DRM_DEBUG_KMS("CRT GMBUS EDID read failed, retry using GPIO
bit-banging\n");
+ intel_gmbus_force_bit(i2c, true);
+ edid = drm_get_edid(connector, i2c);
+ intel_gmbus_force_bit(i2c, false);
+ }
+
+ return edid;
+}
+
+/* local version of intel_ddc_get_modes() to use intel_crt_get_edid() */
+static int intel_crt_ddc_get_modes(struct drm_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ struct edid *edid;
+
+ edid = intel_crt_get_edid(connector, adapter);
+ if (!edid)
+ return 0;
+
+ return intel_connector_update_modes(connector, edid);
+}
+
static bool intel_crt_detect_ddc(struct drm_connector *connector)
{
struct intel_crt *crt = intel_attached_crt(connector);
@@ -338,7 +368,7 @@ static bool intel_crt_detect_ddc(struct drm_connector
*connector)
BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
- edid = drm_get_edid(connector, i2c);
+ edid = intel_crt_get_edid(connector, i2c);
if (edid) {
bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
@@ -546,13 +576,13 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
- ret = intel_ddc_get_modes(connector, i2c);
+ ret = intel_crt_ddc_get_modes(connector, i2c);
if (ret || !IS_G4X(dev))
return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */
i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
- return intel_ddc_get_modes(connector, i2c);
+ return intel_crt_ddc_get_modes(connector, i2c);
}
static int intel_crt_set_property(struct drm_connector *connector,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv3 PATCH 1/8] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
Hi Hans,
The patch seems to cover most of the requirement. I find 2 gaps:
> +/* DV-class control IDs defined by V4L2 */
> +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> +
> +#defineV4L2_CID_DV_TX_HOTPLUG
> (V4L2_CID_DV_CLASS_BASE + 1)
> +#defineV4L2_CID_DV_TX_RXSENSE
> (V4L2_CID_DV_CLASS_BASE + 2)
> +#defineV4L2_CID_DV_TX_EDID_PRESENT
> (V4L2_CID_DV_CLASS_BASE + 3)
> +#defineV4L2_CID_DV_TX_MODE
> (V4L2_CID_DV_CLASS_BASE + 4)
> +enum v4l2_dv_tx_mode {
> + V4L2_DV_TX_MODE_DVI_D = 0,
> + V4L2_DV_TX_MODE_HDMI= 1,
> +};
Even at the receiver side the DVI/HDMI mode need to be detected. So
probably a control for the RX mode is needed.
> +#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
> +enum v4l2_dv_rgb_range {
> + V4L2_DV_RGB_RANGE_AUTO= 0,
> + V4L2_DV_RGB_RANGE_LIMITED = 1,
> + V4L2_DV_RGB_RANGE_FULL= 2,
> +};
> +
> +#defineV4L2_CID_DV_RX_POWER_PRESENT
> (V4L2_CID_DV_CLASS_BASE + 100)
> +#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 101)
> +
Similarly, some sources can support YC mode of transmission instaed of
RGB. To control the YC Quantization Range, we can define control
V4L2_CID_DV_TX_YC_RANGE
Similar control would be needed at the Rx side also like
V4L2_CID_DV_RX_YC_RANGE.
Best Regards
Soby Mathew
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote: > When SWIOTLB is configured, if without this patch kernel compilation > fails with such error messages: > > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': > drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of > function 'swiotlb_nr_tbl' > drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of > 'ttm_dma_populate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but > argument is of type 'struct device *' > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': > drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of > 'ttm_dma_unpopulate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but > argument is of type 'struct device *' > > V2: > 1, Add compilation error messages; > 2, Make the From: address the same as Signed-off-by address. > > Signed-off-by: Huacai Chen 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: v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote: > (Bringing this back to the mailing lists after a bit of uninteresting private > conversation.) > > > Honestly, I think we need a way to force disable gmbus with a module > > parameter or something anyway. It's not the first time gmbus has been > > implicated with an issue. Maybe it even exists already, but I couldn't > > find this. So if you confirm that fixes the problem for you on the ml, > > at least maybe such a patch will be the result. > > > > If you feel it's a software bug (which I agree it seems likely), a > > bisect is always much appreciated. Personally, I'll usually step back > > major releases until something works, or I hit 3.2ish. Even knowing it > > never worked through 3.2 is helpful. > > It's a friend's machine, which I normally only have remote access to, > so it's a bit pf a pain, but I can manage. I just thought a basic > i3 motherboard was so common I couldn't possibly be the only one with > this problem. > > Here's the 3.2 dmesg showing the fallback working, but this is an > Ubuntu-patched kernel (linux-image-3.2.0-29-generic) that may be a fair > distance from stock: One thing of interest would be the exact .config you use to build the kernel and the output of lsmod (after the kernel crashed). I guess the issue is with the combination of drivers you have (i2c_detect in the calltrace calls back into other registered i2c drivers ...). Yours, Daniel > > [ 44.401124] [drm] Initialized drm 1.1.0 20060810 > [ 44.471549] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [ 44.471553] i915 :00:02.0: setting latency timer to 64 > [ 44.555865] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.611882] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.667876] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.723831] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.779841] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.835854] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.895843] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 44.951836] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus disabled] > [ 45.007798] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.063716] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.119776] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.175716] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.231689] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.287696] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.343704] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.399667] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus ssc] > [ 45.455651] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.511629] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.567581] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.623645] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.679546] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.735614] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.791596] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.847533] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus vga] > [ 45.903517] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 45.959547] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.015492] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.071473] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.127430] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.183447] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.239425] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.295407] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus panel] > [ 46.351401] [drm] GMBUS timed out, falling back to bit banging on pin 0 > [i915 gmbus dpc] > [ 46.407382] [drm] GMBUS timed out, falling back to bit banging on p
Re: [BUG] EDID leaks kernel memory
On Sat, Aug 11, 2012 at 6:51 PM, Russell King - ARM Linux wrote: > Hi, > > While looking at the kernel DRM code, I've noticed that in many places > we kmalloc() memory to store the raw EDID information, whether it be > from a DDC adapter, or loaded from firmware. > > Nowhere can I find where this memory is freed. It seems in several > places that we assign it into connector->display_info.raw_edid, and > next time we obtain EDID information, we re-kmalloc and overwrite this > pointer. > > Note that some drivers do kfree() this memory themselves after blindly > setting connector->display_info.raw_edid to NULL... > > Can someone please point me to where this memory is freed? If not, I'll > cook up a patch to add some kfree's. Afaik the right thing is to simply kill the raw_edid pointer and handle the edid kmalloc simple as some temp storage fully controlled by the drivers. I've volunteered Jani from our team to cook up a few patches to handle this. Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
On Mon, 13 Aug 2012, Daniel Vetter wrote: > On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote: >> (Bringing this back to the mailing lists after a bit of uninteresting private >> conversation.) >> >> > Honestly, I think we need a way to force disable gmbus with a module >> > parameter or something anyway. It's not the first time gmbus has been >> > implicated with an issue. Maybe it even exists already, but I couldn't >> > find this. So if you confirm that fixes the problem for you on the ml, >> > at least maybe such a patch will be the result. >> > >> > If you feel it's a software bug (which I agree it seems likely), a >> > bisect is always much appreciated. Personally, I'll usually step back >> > major releases until something works, or I hit 3.2ish. Even knowing it >> > never worked through 3.2 is helpful. >> >> It's a friend's machine, which I normally only have remote access to, >> so it's a bit pf a pain, but I can manage. I just thought a basic >> i3 motherboard was so common I couldn't possibly be the only one with >> this problem. >> >> Here's the 3.2 dmesg showing the fallback working, but this is an >> Ubuntu-patched kernel (linux-image-3.2.0-29-generic) that may be a fair >> distance from stock: > > One thing of interest would be the exact .config you use to build the > kernel and the output of lsmod (after the kernel crashed). I guess the > issue is with the combination of drivers you have (i2c_detect in the > calltrace calls back into other registered i2c drivers ...). Hi all, this smells a bit like [1], don't you think? George, can you check the patch I just sent to (hopefully) fix that issue? Thanks. BR, Jani. [1] http://thread.gmane.org/gmane.linux.kernel/1339794 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Enhanced EDID quirk functionality
On 08/12/2012 04:31 PM, Paul Menzel wrote: > So I vote for getting this into stable and hopefully the maintainers > agree. Paul - We obviously disagree on whether this makes sense for -stable. If you feel strongly that it should go in, I suggest that you go ahead and submit it for inclusion. Thanks for all your help! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Consistently name interlaced modes
On Fri, Aug 10, 2012 at 6:52 PM, Russell King - ARM Linux wrote: > At the moment, there is an inconsistency in the way modes are named. > Modes with timings parsed from the EDID information will call > drm_mode_set_name(), which will name the mode using this form: > > x > > eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive > mode. > > However, timings parsed using the tables in drm_edid_modes.h do not > have the 'i' suffix. You are left to deduce that they're interlaced > from xrandr's output by the lower vertical refresh frequencies. > > This patch changes the interlaced mode names in drm_edid_modes.h to > follow the style set by drm_mode_set_name(), which makes it clear > in xrandr which modes are interlaced and which are not (as xrandr > groups the refresh rates on a line according to the name field.) > > Signed-off-by: Russell King Reviewed-by: Alex Deucher ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] gma500: Fix comment mispelling in cdv_intel_limits definition.
From: Forest Bond
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index bfb0565..247ad7b 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -76,7 +76,7 @@ static bool cdv_intel_find_dp_pll(const struct
cdv_intel_limit_t *limit, struct
#define CDV_LIMIT_DP_100 5
static const struct cdv_intel_limit_t cdv_intel_limits[] = {
- { /* CDV_SIGNLE_LVDS_96MHz */
+ { /* CDV_SINGLE_LVDS_96MHz */
.dot = {.min = 2, .max = 115500},
.vco = {.min = 180, .max = 360},
.n = {.min = 2, .max = 6},
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] gma500: psb_intel_crtc: Drop crtc_enable flag.
From: Forest Bond
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 247ad7b..4df1e72 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -930,7 +930,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Give the overlay scaler a chance to enable
* if it's on this pipe */
/* psb_intel_crtc_dpms_video(crtc, true); TODO */
- psb_intel_crtc->crtc_enable = true;
break;
case DRM_MODE_DPMS_OFF:
if (!psb_intel_crtc->active)
@@ -981,7 +980,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Wait for the clocks to turn off. */
udelay(150);
- psb_intel_crtc->crtc_enable = false;
break;
}
cdv_intel_update_watermark(dev, crtc);
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index c53e592..c9710ff 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -193,7 +193,6 @@ struct psb_intel_crtc {
u32 mode_flags;
bool active;
- bool crtc_enable;
/* Saved Crtc HW states */
struct psb_intel_crtc_state *crtc_state;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] gma500: Consider CRTC initially active.
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug] From: Forest Bond This causes the pipe to be forced off prior to initial mode set, which roughly mirrors the behavior of the i915 driver. It fixes initial mode setting on my Intel DN2800MT (Cedarview) board. Without it, mode setting triggers an out-of-range error from the monitor for most modes, but only on initial configuration (i.e. they can be configured successfully from userspace after that). Signed-off-by: Forest Bond Signed-off-by: Alan Cox Cc: Stables --- drivers/gpu/drm/gma500/psb_intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c b/drivers/gpu/drm/gma500/psb_intel_display.c index 30dc22a..8033526 100644 --- a/drivers/gpu/drm/gma500/psb_intel_display.c +++ b/drivers/gpu/drm/gma500/psb_intel_display.c @@ -1362,6 +1362,9 @@ void psb_intel_crtc_init(struct drm_device *dev, int pipe, (struct drm_connector **) (psb_intel_crtc + 1); psb_intel_crtc->mode_set.num_connectors = 0; psb_intel_cursor_init(dev, psb_intel_crtc); + + /* Set to true so that the pipe is forced off on initial config. */ + psb_intel_crtc->active = true; } int psb_intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data, ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16560] nvidia video card not working
https://bugzilla.kernel.org/show_bug.cgi?id=16560 Alan changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16581] 2.6.35 regression bisected : System hang when starting X with VGA/DVI monitor connected.
https://bugzilla.kernel.org/show_bug.cgi?id=16581 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17241] Enabling KMS on Radeon X300 gives NULL pointer dereference
https://bugzilla.kernel.org/show_bug.cgi?id=17241 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17511] Display no longer works with KMS enabled
https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) AssignedTo|other_ot...@kernel-bugs.osd |drivers_video-dri@kernel-bu |l.org |gs.osdl.org Product|Other |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17511] Display no longer works with KMS enabled
https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher 2012-08-13 16:16:01 --- What hardware is this? Is this still an issue with a newer kernel? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/radeon: make page table updates async
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
> Currently doing the update with the CP.
>
> Signed-off-by: Christian König
NAK until point below are addressed
> ---
> drivers/gpu/drm/radeon/ni.c | 20 ++
> drivers/gpu/drm/radeon/nid.h |1 +
> drivers/gpu/drm/radeon/radeon.h |2 +
> drivers/gpu/drm/radeon/radeon_asic.c |3 ++
> drivers/gpu/drm/radeon/radeon_gart.c | 70
> +-
> 5 files changed, 71 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 1fd2e41..78d9cfb 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1513,20 +1513,24 @@ void cayman_vm_set_page(struct radeon_device *rdev,
> struct radeon_vm *vm,
> unsigned pfn, struct ttm_mem_reg *mem,
> unsigned npages, uint32_t flags)
> {
> - void __iomem *ptr = (void *)vm->pt;
> - uint64_t addr;
> + struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
> + uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
> int i;
>
> addr = flags = cayman_vm_page_flags(rdev, flags);
>
> -for (i = 0; i < npages; ++i, ++pfn) {
> -if (mem) {
> -addr = radeon_vm_get_addr(rdev, mem, i);
> + radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
> + radeon_ring_write(ring, pt & 0x);
> + radeon_ring_write(ring, (pt >> 32) & 0xff);
> + for (i = 0; i < npages; ++i) {
> + if (mem) {
> + addr = radeon_vm_get_addr(rdev, mem, i);
> addr = addr & 0xF000ULL;
> addr |= flags;
> -}
> - writeq(addr, ptr + (pfn * 8));
> -}
> + }
> + radeon_ring_write(ring, addr & 0x);
> + radeon_ring_write(ring, (addr >> 32) & 0x);
> + }
> }
>
> void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
> diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
> index 870db34..2423d1b 100644
> --- a/drivers/gpu/drm/radeon/nid.h
> +++ b/drivers/gpu/drm/radeon/nid.h
> @@ -585,6 +585,7 @@
> #definePACKET3_SET_CONTEXT_REG_INDIRECT0x73
> #definePACKET3_SET_RESOURCE_INDIRECT 0x74
> #definePACKET3_SET_APPEND_CNT 0x75
> +#definePACKET3_ME_WRITE0x7A
>
> #endif
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 7d37cb2..3de0f08 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1154,6 +1154,8 @@ struct radeon_asic {
> struct {
> int (*init)(struct radeon_device *rdev);
> void (*fini)(struct radeon_device *rdev);
> +
> + u32 pt_ring_index;
> void (*set_page)(struct radeon_device *rdev, struct radeon_vm
> *vm,
> unsigned pfn, struct ttm_mem_reg *mem,
> unsigned npages, uint32_t flags);
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 4b99a24..d0b4e50 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1359,6 +1359,7 @@ static struct radeon_asic cayman_asic = {
> .vm = {
> .init = &cayman_vm_init,
> .fini = &cayman_vm_fini,
> + .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
> .set_page = &cayman_vm_set_page,
> },
> .ring = {
> @@ -1461,6 +1462,7 @@ static struct radeon_asic trinity_asic = {
> .vm = {
> .init = &cayman_vm_init,
> .fini = &cayman_vm_fini,
> + .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
> .set_page = &cayman_vm_set_page,
> },
> .ring = {
> @@ -1563,6 +1565,7 @@ static struct radeon_asic si_asic = {
> .vm = {
> .init = &si_vm_init,
> .fini = &si_vm_fini,
> + .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
> .set_page = &cayman_vm_set_page,
> },
> .ring = {
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index bf5378b..9cfd213 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -464,15 +464,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
> continue;
>
> list_for_each_entry(bo_va, &vm->va, vm_list) {
> - struct ttm_mem_reg *mem = NULL;
> - if (bo_va->valid)
> - mem = &bo_va->bo->tbo.mem;
> -
>
Re: [RFC] make VM handling async
On Mon, Aug 13, 2012 at 6:25 AM, Christian König wrote: > Yeah, I know I'm on vacation, but without coding I die of boringness in less > than a week. > > This patchset is currently based on Jeromes VA fencing patch, but in the end > makes it superfluous. It just moves the whole VM handling into the CP ring, > removing the need to wait for anything directly in the VM code, the any > waiting > that happens is now in the allocation of page tables and that happens only on > allocation of new VM space and not on freeing it, which in turn makes handling > allot more simpler. > > It's not 100% complete cause page table updates should be made with the DMA > ring, but we haven't released documentation for that yet, so I currently > use CP memory writes instead. > > Please take a look and tell me what you think about it. > > Cheers, > Christian. Except for patch 10 Reviewed-by: Jerome Glisse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected] nouveau: "Failed to idle channel x" after resume
On 2012-08-08 08:18 +0200, Sven Joachim wrote:
> On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>
>> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>>> once, subsequent attempts fail:
>>>
>>> ,
>>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>>> | suspend, -16
>>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [
>>> DRM][:01:00.0] resuming display...
>>> `
>> Interesting. Were there any messages prior to that?
>
> Nothing interesting:
>
> ,
> | Aug 8 07:49:16 turtle kernel: [ 89.655362] nouveau [
> DRM][:01:00.0] suspending fbcon...
> | Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [
> DRM][:01:00.0] suspending display...
> | Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [
> DRM][:01:00.0] unpinning framebuffer(s)...
> | Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [
> DRM][:01:00.0] evicting buffers...
> | Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [
> DRM][:01:00.0] suspending client object trees...
> `
>
>> I guess the the fifo
>> code detected a timeout when trying to save the graphics context, I have
>> I have other patches in my tree (I'll push them soon, tied up with other
>> work atm) that might help here.
>
> Thanks, I'll try them when they are available.
With current nouveau master ("drm/nouveau: fix find/replace bug in
license header") suspending works again, thanks! However, it is a bit
slow, taking between two and five seconds:
,
| Aug 13 18:17:56 turtle kernel: [ 678.524814] PM: Syncing filesystems ...
done.
| Aug 13 18:18:09 turtle kernel: [ 678.639202] Freezing user space processes
... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [ 678.649954] Freezing remaining freezable
tasks ... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [ 678.663298] Suspending console(s) (use
no_console_suspend to debug)
| Aug 13 18:18:09 turtle kernel: [ 678.680884] sd 0:0:0:0: [sda] Synchronizing
SCSI cache
| Aug 13 18:18:09 turtle kernel: [ 678.681000] sd 0:0:0:0: [sda] Stopping disk
| Aug 13 18:18:09 turtle kernel: [ 678.695141] parport_pc 00:07: disabled
| Aug 13 18:18:09 turtle kernel: [ 678.695204] serial 00:06: disabled
| Aug 13 18:18:09 turtle kernel: [ 678.695209] serial 00:06: wake-up
capability disabled by ACPI
| Aug 13 18:18:09 turtle kernel: [ 678.695235] nouveau [
DRM][:01:00.0] suspending fbcon...
| Aug 13 18:18:09 turtle kernel: [ 678.695239] nouveau [
DRM][:01:00.0] suspending display...
| Aug 13 18:18:09 turtle kernel: [ 678.742111] nouveau [
DRM][:01:00.0] unpinning framebuffer(s)...
| Aug 13 18:18:09 turtle kernel: [ 678.742189] nouveau [
DRM][:01:00.0] evicting buffers...
| Aug 13 18:18:09 turtle kernel: [ 682.357319] nouveau [
DRM][:01:00.0] suspending client object trees...
| Aug 13 18:18:09 turtle kernel: [ 683.526646] PM: suspend of devices complete
after 4863.181 msecs
`
With the 3.4.8 kernel, suspending takes little more than one second.
Cheers,
Sven
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17692] Intermittent failure to resume from suspend-to-ram in radeon_bo_get_surface_reg with RV515 and ColorTiling
https://bugzilla.kernel.org/show_bug.cgi?id=17692 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #8 from Alan 2012-08-13 16:24:49 --- If this is still seen with a modern kernel please update/re-open thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17782] Kernel panic when booting with radeon.audio=0
https://bugzilla.kernel.org/show_bug.cgi?id=17782 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #1 from Alan 2012-08-13 16:25:27 --- If you are still seeing this with a modern kernel please update/re-open the bug - thamks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/radeon: make page table updates async
On 13.08.2012 18:19, Jerome Glisse wrote:
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
Currently doing the update with the CP.
Signed-off-by: Christian König
NAK until point below are addressed
[SNIP]
For this to work properly you will need patch :
http://people.freedesktop.org/~glisse/0001-drm-radeon-make-sure-ib-bo-is-properly-bound-and-up-.patch
Otherwise there is a chance that ib bo pagetable is out of sync.
Oh yes indeed. Going to sort in your patch directly before of this one.
Also I haven't tested suspend/resume with this set yet, need to change
that before sending it upstream.
[SNIP]
@@ -832,7 +829,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid && mem)
+ if (bo_va->valid == !!mem)
return 0;
Logic is wrong, we want to return either if valid is true and mem not
null, which means bo is already bound and its pagetable entry are up
to date as it did not move since page table was last updated. Or
return if valid is false and mem is null, meaning the pagetable
already contain invalid page entry and we are unbinding the bo. So the
proper test should be :
if ((bo_va->valid && mem) || (!bo_va->valid && mem == NULL)) {
return 0;
}
Isn't that identical? Ok your version is definitely easier to read, so
I'm going to use that one anyway.
Thanks,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] make VM handling async
On 13.08.2012 14:53, Sylvain BERTRAND wrote: It's not 100% complete cause page table updates should be made with the DMA ring, but we haven't released documentation for that yet, so I currently use CP memory writes instead. Sad. Any release time hint? (the DMA ring will cleanup a lot of code). Yes and on top of that a quite nice performance improvement. Alex is currently trying to get that released, but no idea how far that got. BTW, maybe at the same time the HDP_NONSURFACE regs should be 64bitified? Hui? What do you mean with that? Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/radeon: make page table updates async
On Mon, Aug 13, 2012 at 12:53 PM, Christian König
wrote:
> On 13.08.2012 18:19, Jerome Glisse wrote:
>>
>> On Mon, Aug 13, 2012 at 6:26 AM, Christian König
>> wrote:
>>>
>>> Currently doing the update with the CP.
>>>
>>> Signed-off-by: Christian König
>>
>> NAK until point below are addressed
>
> [SNIP]
>
>> For this to work properly you will need patch :
>>
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-make-sure-ib-bo-is-properly-bound-and-up-.patch
>>
>> Otherwise there is a chance that ib bo pagetable is out of sync.
>
> Oh yes indeed. Going to sort in your patch directly before of this one.
>
> Also I haven't tested suspend/resume with this set yet, need to change that
> before sending it upstream.
I haven't tested my patch, but it should work.
>> [SNIP]
>>
>>> @@ -832,7 +829,7 @@ int radeon_vm_bo_update_pte(struct radeon_device
>>> *rdev,
>>> return -EINVAL;
>>> }
>>>
>>> - if (bo_va->valid && mem)
>>> + if (bo_va->valid == !!mem)
>>> return 0;
>>
>> Logic is wrong, we want to return either if valid is true and mem not
>> null, which means bo is already bound and its pagetable entry are up
>> to date as it did not move since page table was last updated. Or
>> return if valid is false and mem is null, meaning the pagetable
>> already contain invalid page entry and we are unbinding the bo. So the
>> proper test should be :
>>
>> if ((bo_va->valid && mem) || (!bo_va->valid && mem == NULL)) {
>> return 0;
>> }
>
> Isn't that identical? Ok your version is definitely easier to read, so I'm
> going to use that one anyway.
Yes it's, i was bit confuse by your test, would rather make the logic
easier to read for human.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, Aug 13, 2012 at 05:26:03PM +0800, Huacai Chen wrote: > When SWIOTLB is configured, if without this patch kernel compilation > fails with such error messages: > > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': > drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of > function 'swiotlb_nr_tbl' > drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of > 'ttm_dma_populate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but > argument is of type 'struct device *' > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': > drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of > 'ttm_dma_unpopulate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but > argument is of type 'struct device *' > > Signed-off-by: Huacai Chen > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-devel@lists.freedesktop.org Reviewed-by: Konrad Rzeszutek Wilk > --- > drivers/gpu/drm/radeon/radeon_ttm.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index 5b71c71..fc3ac22 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -41,6 +41,10 @@ > #include "radeon_reg.h" > #include "radeon.h" > > +#ifdef CONFIG_SWIOTLB > +#include > +#endif > + > #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) > > static int radeon_ttm_debugfs_init(struct radeon_device *rdev); > -- > 1.7.7.3 > > ___ > 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: 转发: Siliconmotion new kernel driver initial patch
On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen 陈俊杰 wrote: > > Since there is no response for the last mail. Maybe it didn't sent > successfully. So I send it again. Here is the initial patch for siliconmotion > kernel driver. What's with the #ifdef 0 or #ifdef 1? Why is there a bunch of ddkxxx something? Can those header files be squashed together? > > Aaron > > ___ > 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: [BUG] Intel xorg driver 2.20.2 overlay off-by-one bug
On Sun, 12 Aug 2012 10:01:44 +0100, Russell King - ARM Linux
wrote:
> While reading through the Intel driver code, I spotted this in
> I830SetPortAttributeOverlay:
>
> } else if (attribute == xvPipe) {
> xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
> if ((value < -1) || (value > xf86_config->num_crtc))
> return BadValue;
> if (value < 0)
> adaptor_priv->desired_crtc = NULL;
> else
> adaptor_priv->desired_crtc = xf86_config->crtc[value];
>
> This allows value == xf86_config->num_crtc to be valid, which would be
> the CRTC number _after_ the last one in the array. Presumably this is
> not desired, and the test should be ">=".
Thanks for bringing this to our attention and poking Dave, who promptly
pushed a patch to fix the bug.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected] nouveau: "Failed to idle channel x" after resume
On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>
> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
> >
> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
> >>> once, subsequent attempts fail:
> >>>
> >>> ,
> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
> >>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
> >>> | suspend, -16
> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [
> >>> DRM][:01:00.0] resuming display...
> >>> `
> >> Interesting. Were there any messages prior to that?
> >
> > Nothing interesting:
> >
> > ,
> > | Aug 8 07:49:16 turtle kernel: [ 89.655362] nouveau [
> > DRM][:01:00.0] suspending fbcon...
> > | Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [
> > DRM][:01:00.0] suspending display...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [
> > DRM][:01:00.0] unpinning framebuffer(s)...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [
> > DRM][:01:00.0] evicting buffers...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [
> > DRM][:01:00.0] suspending client object trees...
> > `
> >
> >> I guess the the fifo
> >> code detected a timeout when trying to save the graphics context, I have
> >> I have other patches in my tree (I'll push them soon, tied up with other
> >> work atm) that might help here.
> >
> > Thanks, I'll try them when they are available.
>
> With current nouveau master ("drm/nouveau: fix find/replace bug in
> license header") suspending works again, thanks! However, it is a bit
> slow, taking between two and five seconds:
>
> ,
> | Aug 13 18:17:56 turtle kernel: [ 678.524814] PM: Syncing filesystems ...
> done.
> | Aug 13 18:18:09 turtle kernel: [ 678.639202] Freezing user space processes
> ... (elapsed 0.01 seconds) done.
> | Aug 13 18:18:09 turtle kernel: [ 678.649954] Freezing remaining freezable
> tasks ... (elapsed 0.01 seconds) done.
> | Aug 13 18:18:09 turtle kernel: [ 678.663298] Suspending console(s) (use
> no_console_suspend to debug)
> | Aug 13 18:18:09 turtle kernel: [ 678.680884] sd 0:0:0:0: [sda]
> Synchronizing SCSI cache
> | Aug 13 18:18:09 turtle kernel: [ 678.681000] sd 0:0:0:0: [sda] Stopping
> disk
> | Aug 13 18:18:09 turtle kernel: [ 678.695141] parport_pc 00:07: disabled
> | Aug 13 18:18:09 turtle kernel: [ 678.695204] serial 00:06: disabled
> | Aug 13 18:18:09 turtle kernel: [ 678.695209] serial 00:06: wake-up
> capability disabled by ACPI
> | Aug 13 18:18:09 turtle kernel: [ 678.695235] nouveau [
> DRM][:01:00.0] suspending fbcon...
> | Aug 13 18:18:09 turtle kernel: [ 678.695239] nouveau [
> DRM][:01:00.0] suspending display...
> | Aug 13 18:18:09 turtle kernel: [ 678.742111] nouveau [
> DRM][:01:00.0] unpinning framebuffer(s)...
> | Aug 13 18:18:09 turtle kernel: [ 678.742189] nouveau [
> DRM][:01:00.0] evicting buffers...
> | Aug 13 18:18:09 turtle kernel: [ 682.357319] nouveau [
> DRM][:01:00.0] suspending client object trees...
> | Aug 13 18:18:09 turtle kernel: [ 683.526646] PM: suspend of devices
> complete after 4863.181 msecs
> `
>
> With the 3.4.8 kernel, suspending takes little more than one second.
>
> Cheers,
>Sven
I confirm exactly the same thing.
Here suspend takes more that 10 seconds:
[ 2165.363878] nouveau [ DRM][:01:00.0] suspending fbcon...
[ 2165.363885] nouveau [ DRM][:01:00.0] suspending display...
[ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
[ 2166.396877] nouveau [ DRM][:01:00.0] unpinning
framebuffer(s)...
[ 2166.396926] nouveau [ DRM][:01:00.0] evicting buffers...
[ 2174.809084] nouveau [ DRM][:01:00.0] suspending client
object trees...
[ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3
Best regards,
Maxim Levitsky
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, radeon and intel fixes mostly, one fix to the mgag200 driver to not hang on certain server variants. Dave. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to 7bac6b46607f2f44075cb45dd5b0b4d2e7c80695: Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2012-08-14 09:25:01 +1000) Alan Cox (3): vlv: it might be wise if we initialised the flag value... i915: fix error path leak in intel_sdvo_write_cmd i915: Remove silly test Alex Deucher (9): drm/radeon: fix handling for ddc type 5 on combios drm/radeon/dce4+: set a more reasonable cursor watermark drm/radeon: properly handle SS overrides on TN (v2) drm/radeon: properly handle crtc powergating drm/radeon: fix bank tiling parameters on evergreen drm/radeon: fix bank tiling parameters on cayman drm/radeon: fix ordering in pll picking on dce4+ drm/radeon: add some new SI pci ids drm/radeon: fix some missing parens in asic macros Alexey Khoroshilov (1): drm/edid: Fix potential memory leak in edid_load() Chris Wilson (1): drm/i915: Workaround hang with BSD and forcewake on SandyBridge Christian König (1): drm/radeon: fix bank tiling parameters on SI Daniel Vetter (2): drm/i915: fix forcewake related hangs on snb drm/i915: correctly order the ring init sequence Dave Airlie (4): i915: don't map imported dma-bufs for dmar. Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next drm/mgag200: fix G200ER pll picking algorithm Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Devendra Naga (1): drm/i915: remove unused variable Dmitrii Cherkasov (1): drm/radeon: fix typo in function header comment Eric Anholt (1): drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround. Hunt Xu (1): drm/i915: make rc6 in sysfs functions conditional Jerome Glisse (2): drm/radeon: do not reenable crtc after moving vram start address drm/radeon: fence virtual address and free it once idle v4 Marek Olšák (4): drm/radeon/kms: allow "invalid" DB formats as a means to disable DB drm/radeon/kms: reorder code in r600_check_texture_resource drm/radeon/kms: add MSAA texture support for r600-evergreen drm/radeon/kms: implement timestamp userspace query (v2) Paulo Zanoni (1): drm/i915: add more Haswell PCI IDs Stéphane Marchesin (1): drm/i915: Make intel_panel_get_backlight static. Thomas Meyer (1): drm/udl: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] drivers/char/agp/intel-agp.h| 39 +-- drivers/char/agp/intel-gtt.c| 60 +- drivers/gpu/drm/drm_edid_load.c |8 +-- drivers/gpu/drm/i915/i915_drv.c | 31 +++- drivers/gpu/drm/i915/i915_gem_context.c |1 - drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 drivers/gpu/drm/i915/i915_gem_gtt.c |3 +- drivers/gpu/drm/i915/i915_sysfs.c | 12 + drivers/gpu/drm/i915/intel_display.c|1 + drivers/gpu/drm/i915/intel_drv.h| 20 drivers/gpu/drm/i915/intel_i2c.c|3 -- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_pm.c |6 ++- drivers/gpu/drm/i915/intel_ringbuffer.c |7 ++- drivers/gpu/drm/i915/intel_sdvo.c |5 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 12 +++-- drivers/gpu/drm/radeon/atombios_crtc.c | 22 ++--- drivers/gpu/drm/radeon/evergreen.c | 71 +-- drivers/gpu/drm/radeon/evergreen_cs.c | 13 - drivers/gpu/drm/radeon/evergreend.h |2 + drivers/gpu/drm/radeon/ni.c | 14 -- drivers/gpu/drm/radeon/r600.c | 20 drivers/gpu/drm/radeon/r600_cs.c| 65 +--- drivers/gpu/drm/radeon/r600d.h |3 ++ drivers/gpu/drm/radeon/radeon.h | 12 +++-- drivers/gpu/drm/radeon/radeon_asic.h| 10 ++-- drivers/gpu/drm/radeon/radeon_atombios.c| 49 +- drivers/gpu/drm/radeon/radeon_combios.c | 57 + drivers/gpu/drm/radeon/radeon_cs.c | 32 ++-- drivers/gpu/drm/radeon/radeon_cursor.c |6 ++- drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_drv.c |5 +- drivers/gpu/drm/radeon/radeon_gart.c| 26 -- drivers/gpu/drm/radeon/radeon_gem.c
[PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 39 --
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 95248bd..b099a17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3804,15 +3804,6 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
display_bpc = 6;
}
- if (display_bpc * 3 > max_fdi_bpp) {
- if (max_fdi_bpp < 24)
- display_bpc = 6;
- else if (max_fdi_bpp < 30)
- display_bpc = 8;
- else if (max_fdi_bpp < 36)
- display_bpc = 10;
- DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
- }
/*
* We could just drive the pipe at the highest bpc all the time and
* enable dithering as needed, but that costs bandwidth. So choose
@@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
display_bpc = min(display_bpc, bpc);
- DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)\n",
- bpc, display_bpc);
+ display_bpc = 6;
+
+ if (display_bpc * 3 > max_fdi_bpp) {
+ if (max_fdi_bpp < 24)
+ display_bpc = 6;
+ else if (max_fdi_bpp < 30)
+ display_bpc = 8;
+ else if (max_fdi_bpp < 36)
+ display_bpc = 10;
+ DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
+ }
+
+ DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d) (max_fdi_bpp
%d)\n",
+ bpc, display_bpc, max_fdi_bpp);
*pipe_bpp = display_bpc * 3;
@@ -4737,8 +4740,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
max_fdi_bpp = 0;
max_lane = lane;
} else {
- u32 fdi_bw;
-
+ u32 fdi_bw, pps;
/* [e]DP over FDI requires target mode clock
instead of link clock */
if (is_dp)
@@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
* Compute the available FDI bandwidth, use that
* to compute the maximum supported BPP
*/
- fdi_bw = link_bw * max_lane * 19 / 20;
- max_fdi_bpp = fdi_bw / target_clock;
- DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n", max_lane,
max_fdi_bpp);
+ fdi_bw = (link_bw * 8) * max_lane;
+ pps = target_clock * 21 / 20;
+
+ max_fdi_bpp = fdi_bw / pps;
+ DRM_DEBUG_KMS("link_bw %d max_lane %d fdi_bw %u pps %u
max_fdi_bpp %d\n",
+ link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
}
/* [e]DP over FDI requires target mode clock instead of link clock. */
@@ -4809,6 +4814,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
*/
u32 bps = target_clock * pipe_bpp * 21 / 20;
lane = bps / (link_bw * 8) + 1;
+ DRM_DEBUG_KMS("target_clock %u pipe_bpp %u bps %u link_bw %u
lane %u\n",
+ target_clock, pipe_bpp, bps, link_bw, lane);
if (lane > max_lane) {
DRM_ERROR("Not enough lanes available for mode! (want
%d have %d)\n",
lane, max_lane);
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm/i915: IVB FDI B/C fixes and misc cleanups
This is the complete set of patches that yield a working 3-pipe mode setting configuration on my test machines. It does not make DPMS work, so I still need to figure that out. As the DPMS paths are almost entirely different from mode setting (whose crazy idea was that, anyway?), that may take a bit more time. I've managed to reproduce this bug with only two monitors just by forcing them onto FDI B/C, but only with 1920x1080 and larger modes: $ xrandr --output VGA1 --off --output DP1 --off $ xrandr --output VGA1 --auto --crtc 1 $ xrandr --output DP1 --auto --crtc 2 That works about 50% of the time on the original kernel. If it works, you can just try a couple of different modes to see if you can get it to fail. Just use reasonably large modes -- 640x480 has never failed for me. I'd love to know why $ xrandr --output DP1 --mode 1600x1200 --crtc 2 Finally, the X server has a terrible bug in the RandR code. It computes a desired initial configuration, and if that fails in any way, it refuses to start at all. So, if you connect three monitors that all require separate PLLs, then you get two monitors lit up, the third one fails and the X server aborts. Need to fix that so that if *any* monitors light up, the X server will keep going. *** The patches: *** [PATCH 1/7] drm/i915: Allow VGA on CRTC 2 Silly hold-over from the bad-old PLL sharing code. [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge Here's the patch which rejects modes that the FDI B/C lane sharing hardware can't support. This only affects modes larger than 1920x1200 though as that mode and smaller all fit in two FDI lanes. I ran across this while testing with a 2560x1200 monitor. [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear This seems like a sensible change in the FDI link training code -- gives the FDI hardware time to adapt to changes in the signalling. But, as I've never seen FDI fail to train, I'm not sure it's useful. [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after This mostly just cleans up some debug messages by moving various BPP computations around. "should" have no effect on the hardware. [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR Just happened across this obvious bug while reading through the driver. [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX The specs don't say which order to do this in, but it doesn't make sense to do these in the current order. With this in place, I saw mode setting errors reduced quite a bit, but not gone. [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training This may be the only patch necessary to get mode setting working on FDI-B/C, it ensures that error correction is always turned on during link training. The old code left error correction disabled as there was no posting read after setting that. I'm hoping this explains why the problem wasn't reliably reproducible -- the problem depended on how long the write waited to get to the hardware. I haven't done enough testing of this patch in isolation to know if this is true or not. -keith ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 94aabca..1a84425 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1815,7 +1815,7 @@ static void sandybridge_update_wm(struct drm_device *dev)
DRM_DEBUG_KMS("FIFO watermarks For pipe C -"
" plane %d, cursor: %d\n",
plane_wm, cursor_wm);
- enabled |= 3;
+ enabled |= 4;
}
/*
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..7106807 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3575,7 +3575,7 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
}
static bool intel_crtc_mode_fixup(struct drm_crtc *crtc,
- struct drm_display_mode *mode,
+ const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = crtc->dev;
@@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
*/
static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
unsigned int *pipe_bpp,
-struct drm_display_mode *mode)
+struct drm_display_mode *mode,
+int max_fdi_bpp)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3800,6 +3801,15 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
display_bpc = 6;
}
+ if (display_bpc * 3 > max_fdi_bpp) {
+ if (max_fdi_bpp < 24)
+ display_bpc = 6;
+ else if (max_fdi_bpp < 30)
+ display_bpc = 8;
+ else if (max_fdi_bpp < 36)
+ display_bpc = 10;
+ DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
+ }
/*
* We could just drive the pipe at the highest bpc all the time and
* enable dithering as needed, but that costs bandwidth. So choose
@@ -4570,6 +4580,53 @@ static int ironlake_get_refclk(struct drm_crtc *crtc)
return 12;
}
+/*
+ * FDI C can only have 2 lanes, borrowed from FDI B
+ */
+
+static int ivb_fdi_max_lanes(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe other_pipe;
+ struct drm_crtc *other_crtc;
+ struct intel_crtc *other_intel_crtc;
+ int max_lanes;
+
+ /* FDI links B and C share 4 lanes */
+ switch (intel_crtc->pipe) {
+ case PIPE_B:
+ other_pipe = PIPE_C;
+ max_lanes = 4;
+ break;
+ case PIPE_C:
+ other_pipe = PIPE_B;
+ max_lanes = 2;
+ break;
+ default:
+ return 4;
+ }
+ other_crtc = dev_priv->pipe_to_crtc_mapping[other_pipe];
+ other_intel_crtc = to_intel_crtc(other_crtc);
+
+ /* If the other FDI link isn't running, we can use all of the
+* available lanes
+*/
+ if (!other_intel_crtc->active)
+ return max_lanes;
+
+ /* If the other FDI link is using too many lanes, we can't have
+* any
+*/
+ if (other_intel_crtc->fdi_lanes > 2)
+ return 0;
+
+ /* When both are running, we only get 2 lanes at most
+*/
+ return 2;
+}
+
static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -4595,6 +4652,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
unsigned int pipe_bpp;
bool dither;
bool is_cpu_edp = false, is_pch_edp = false;
+ int max_fdi_bpp;
+ int max_lane;
for_each_encoder_on_crtc(dev, crtc, encoder) {
switch (encoder->type) {
@@ -4672,7 +4731,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
according to current link config */
if (is_cpu_edp) {
intel_edp_link_config(edp_encoder, &lane, &link_bw);
+ max_fdi_bpp = 0;
+ max_lane = lane;
} else {
+ u32 fdi_bw;
+
+ /* [e]DP over FDI requires target mode clock
+ instead of link clock */
+ if (is_dp)
+ target_clock = mode->clock;
+ else
+ target_clock = adjusted_mode->clock;
+
/* FDI is a binary signal running at ~2.7GHz, encoding
* each output octet as 10 bits. The actual frequency
* is stored as a divider into a 100MHz clock, and the
@@ -4681,6 +4751,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
[PATCH 1/7] drm/i915: Allow VGA on CRTC 2
This is left over from the old PLL sharing code and isn't useful now that PLLs are shared when possible. Signed-off-by: Keith Packard --- drivers/gpu/drm/i915/intel_crt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index bc5e2c9..7997b24 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -664,7 +664,7 @@ void intel_crt_init(struct drm_device *dev) if (IS_HASWELL(dev)) crt->base.crtc_mask = (1 << 0); else - crt->base.crtc_mask = (1 << 0) | (1 << 1); + crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); if (IS_GEN2(dev)) connector->interlace_allowed = 0; -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807..95248bd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2391,6 +2391,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
+ I915_WRITE(FDI_RX_IIR(pipe), FDI_RX_BIT_LOCK);
reg = FDI_RX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_LINK_TRAIN_NONE;
@@ -2398,10 +2399,10 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(reg, temp | FDI_RX_ENABLE);
POSTING_READ(reg);
- udelay(150);
/* Ironlake workaround, enable clock pointer after FDI enable*/
if (HAS_PCH_IBX(dev)) {
+ udelay(150);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR |
FDI_RX_PHASE_SYNC_POINTER_EN);
@@ -2409,6 +2410,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
reg = FDI_RX_IIR(pipe);
for (tries = 0; tries < 5; tries++) {
+ udelay(150);
temp = I915_READ(reg);
DRM_DEBUG_KMS("FDI_RX_IIR 0x%x\n", temp);
@@ -2422,6 +2424,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI train 1 fail!\n");
/* Train 2 */
+ I915_WRITE(FDI_RX_IIR(pipe), FDI_RX_SYMBOL_LOCK);
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_LINK_TRAIN_NONE;
@@ -2435,10 +2438,10 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(reg, temp);
POSTING_READ(reg);
- udelay(150);
reg = FDI_RX_IIR(pipe);
for (tries = 0; tries < 5; tries++) {
+ udelay(150);
temp = I915_READ(reg);
DRM_DEBUG_KMS("FDI_RX_IIR 0x%x\n", temp);
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
Doesn't make sense to disable in the other order. Signed-off-by: Keith Packard --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b099a17..754f10f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2776,17 +2776,17 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc) u32 reg, temp; /* disable CPU FDI tx and PCH FDI rx */ - reg = FDI_TX_CTL(pipe); - temp = I915_READ(reg); - I915_WRITE(reg, temp & ~FDI_TX_ENABLE); - POSTING_READ(reg); - reg = FDI_RX_CTL(pipe); temp = I915_READ(reg); temp &= ~(0x7 << 16); temp |= (I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK) << 11; I915_WRITE(reg, temp & ~FDI_RX_ENABLE); + POSTING_READ(reg); + udelay(100); + reg = FDI_TX_CTL(pipe); + temp = I915_READ(reg); + I915_WRITE(reg, temp & ~FDI_TX_ENABLE); POSTING_READ(reg); udelay(100); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/i915: Merge FDI RX reg writes during training
Need to turn on the error correction when enabling training or it might not get enabled in time. This seems to fix the FDI-B/FDI-C link training problem. Signed-off-by: Keith Packard --- drivers/gpu/drm/i915/intel_display.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 754f10f..1d24d55 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2324,6 +2324,8 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc) temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE; } I915_WRITE(reg, temp); + POSTING_READ(reg); + udelay(100); reg = FDI_RX_CTL(pipe); temp = I915_READ(reg); @@ -2334,16 +2336,15 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc) temp &= ~FDI_LINK_TRAIN_NONE; temp |= FDI_LINK_TRAIN_NONE; } + /* IVB wants error correction enabled */ + if (IS_IVYBRIDGE(dev)) + temp |= FDI_FS_ERRC_ENABLE | FDI_FE_ERRC_ENABLE; + I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE); /* wait one idle pattern time */ POSTING_READ(reg); udelay(1000); - - /* IVB wants error correction enabled */ - if (IS_IVYBRIDGE(dev)) - I915_WRITE(reg, I915_READ(reg) | FDI_FS_ERRC_ENABLE | - FDI_FE_ERRC_ENABLE); } static void cpt_phase_pointer_enable(struct drm_device *dev, int pipe) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43477] rendering errors in unigine tropics and sanctuary (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=43477 --- Comment #5 from maximlevit...@gmail.com 2012-08-14 04:51:48 UTC --- This still happens on nouveau, despite OpenGL 3.0 advertised. -- 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 43477] rendering errors in unigine tropics and sanctuary (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=43477 Andreas Boll changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Dear Chen, thanks for your patch. Firstly, is Chen your first or last name? If it is your first name, your
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > Dear Chen, > > > thanks for your patch. > > Firstly, is Chen your first or last name? If it is your first name, your > From address should be switched. Chen is may last name. > > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: >> When SWIOTLB is configured, if without this patch kernel compilation >> fails. > > Secondly, could you please always paste part of the error message into > the commit message so that people hitting this problem and searching for > it on the WWW have a higher chance finding your patch. > OK, I'll paste error message. > Thirdly, do you know why this was not caught beforehand and compilation > worked before? Maybe radeon is mostly used on X86 and swiotlb.h is included indirectly on X86 platform. This patch is split from my MIPS patchset, on MIPS machines compilation always failed. > >> Signed-off-by: Huacai Chen > > Lastly, the addresses in your From line and Signed-off-by line disagree. > You can easily fix that, by adding My patch is generated by git format-patch and there is surely a From line in the beginning (from chenhc at lemote.com), but the mail is sent out by gmail, so I don't know how to make From line and Signed-off-by agree. > > From: Huacai Chen > > to the beginning of your message. > >> Signed-off-by: Hongliang Tao >> Signed-off-by: Hua Yan >> Cc: dri-devel at lists.freedesktop.org >> --- >> drivers/gpu/drm/radeon/radeon_ttm.c |4 >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >> b/drivers/gpu/drm/radeon/radeon_ttm.c >> index 5b71c71..fc3ac22 100644 >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c >> @@ -41,6 +41,10 @@ >> #include "radeon_reg.h" >> #include "radeon.h" >> >> +#ifdef CONFIG_SWIOTLB >> +#include >> +#endif >> + >> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) >> >> static int radeon_ttm_debugfs_init(struct radeon_device *rdev); > > With the clarification above > > Acked-by: Paul Menzel > > can be added to your patch. > > > Thanks, > > Paul
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Dear Huacai, Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: > On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > > thanks for your patch. > > > > Firstly, is Chen your first or last name? If it is your first name, your > > From address should be switched. > Chen is may last name. I am sorry then. > > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: > >> When SWIOTLB is configured, if without this patch kernel compilation > >> fails. > > > > Secondly, could you please always paste part of the error message into > > the commit message so that people hitting this problem and searching for > > it on the WWW have a higher chance finding your patch. > > > OK, I'll paste error message. > > > Thirdly, do you know why this was not caught beforehand and compilation > > worked before? > Maybe radeon is mostly used on X86 and swiotlb.h is included > indirectly on X86 platform. This patch is split from my MIPS patchset, > on MIPS machines compilation always failed. Ah, I thought your patches had already been submitted. > >> Signed-off-by: Huacai Chen > > > > Lastly, the addresses in your From line and Signed-off-by line disagree. > > You can easily fix that, by adding > My patch is generated by git format-patch and there is surely a From > line in the beginning (from chenhc at lemote.com), It should be `From: Huacai Chen `. > but the mail is sent out by gmail, so I don't know how to make From > line and Signed-off-by agree. Do you copy the content of the file created by `git format-patch` into the Gmail Web compositor? If yes, just do not delete the `From` *and* `Date` lines from the beginning as for example Alex Deucher is doing [1]. [?] Thanks, Paul [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/112079d5/attachment.pgp>
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel wrote: > Dear Huacai, > > > Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: >> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: > >> > thanks for your patch. >> > >> > Firstly, is Chen your first or last name? If it is your first name, your >> > From address should be switched. >> Chen is may last name. > > I am sorry then. > >> > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: >> >> When SWIOTLB is configured, if without this patch kernel compilation >> >> fails. >> > >> > Secondly, could you please always paste part of the error message into >> > the commit message so that people hitting this problem and searching for >> > it on the WWW have a higher chance finding your patch. >> > >> OK, I'll paste error message. >> >> > Thirdly, do you know why this was not caught beforehand and compilation >> > worked before? >> Maybe radeon is mostly used on X86 and swiotlb.h is included >> indirectly on X86 platform. This patch is split from my MIPS patchset, >> on MIPS machines compilation always failed. > > Ah, I thought your patches had already been submitted. My MIPS patchset is under review (not accepted now), I think this drm patch is important and should be accept first, so sent it independently. > >> >> Signed-off-by: Huacai Chen >> > >> > Lastly, the addresses in your From line and Signed-off-by line disagree. >> > You can easily fix that, by adding >> My patch is generated by git format-patch and there is surely a From >> line in the beginning (from chenhc at lemote.com), > > It should be `From: Huacai Chen `. Yes, git format-patch generate `From: Huacai Chen ` > >> but the mail is sent out by gmail, so I don't know how to make From >> line and Signed-off-by agree. > > Do you copy the content of the file created by `git format-patch` into > the Gmail Web compositor? > > If yes, just do not delete the `From` *and* `Date` lines from the > beginning as for example Alex Deucher is doing [1]. No, I use git send-email to send the patch but use gmail's server (mail server of lemote.com is too weak). The original patch is begin with: - >From 70e1e058da3d39c52b7dba3e8fa754e7ed41828c Mon Sep 17 00:00:00 2001 From: Huacai Chen Date: Thu, 2 Aug 2012 17:02:59 +0800 Subject: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured. When SWIOTLB is configured, if without this patch kernel compilation fails with error messages: Do you means I need to copy the From line and paste it after the Subject line? > > [?] > > > Thanks, > > Paul > > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
Am Montag, den 13.08.2012, 16:04 +0800 schrieb Huacai Chen: > On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel wrote: > > Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen: > >> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote: [?] > >> > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen: [?] > >> >> Signed-off-by: Huacai Chen > >> > > >> > Lastly, the addresses in your From line and Signed-off-by line disagree. > >> > You can easily fix that, by adding > >> My patch is generated by git format-patch and there is surely a From > >> line in the beginning (from chenhc at lemote.com), > > > > It should be `From: Huacai Chen `. > Yes, git format-patch generate `From: Huacai Chen ` > > > > >> but the mail is sent out by gmail, so I don't know how to make From > >> line and Signed-off-by agree. > > > > Do you copy the content of the file created by `git format-patch` into > > the Gmail Web compositor? > > > > If yes, just do not delete the `From` *and* `Date` lines from the > > beginning as for example Alex Deucher is doing [1]. > No, I use git send-email to send the patch but use gmail's server > (mail server of lemote.com is too weak). The original patch is begin > with: > - > From 70e1e058da3d39c52b7dba3e8fa754e7ed41828c Mon Sep 17 00:00:00 2001 > From: Huacai Chen > Date: Thu, 2 Aug 2012 17:02:59 +0800 > Subject: [PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured. > > When SWIOTLB is configured, if without this patch kernel compilation > fails with error messages: > > Do you means I need to copy the From line and paste it after the Subject line? wereHamster on #git suggested to use git send-email --from 'Huacai Chen ' and it should do the right thing. Thanks, Paul > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/b1d9a4b2/attachment.pgp>
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails with such error messages: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of function 'swiotlb_nr_tbl' drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 'ttm_dma_populate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but argument is of type 'struct device *' drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 'ttm_dma_unpopulate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but argument is of type 'struct device *' Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3
转发: Siliconmotion new kernel driver initial patch
Since there is no response for the last mail. Maybe it didn't sent successfully. So I send it again. Here is the initial patch for siliconmotion kernel driver. Aaron -- next part -- A non-text attachment was scrubbed... Name: 0001-Siliconmotion-new-kernel-driver-initial-patch.patch Type: application/octet-stream Size: 369305 bytes Desc: 0001-Siliconmotion-new-kernel-driver-initial-patch.patch URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/9fc4abf7/attachment-0001.obj>
[PATCH 01/10] drm/radeon: fence virtual address and free it once idle v4
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
v4: Fix compilation warnings.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c |6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..b4a0db24 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+
+ if (parser->chunk_ib_idx == -1) {
+ return;
+ }
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
+ return;
+ }
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(&rdev->vm_manager.lock);
- /* remove all bo */
+ /* remove all bo at this point non are busy any more
[RFC] make VM handling async
Yeah, I know I'm on vacation, but without coding I die of boringness in less than a week. This patchset is currently based on Jeromes VA fencing patch, but in the end makes it superfluous. It just moves the whole VM handling into the CP ring, removing the need to wait for anything directly in the VM code, the any waiting that happens is now in the allocation of page tables and that happens only on allocation of new VM space and not on freeing it, which in turn makes handling allot more simpler. It's not 100% complete cause page table updates should be made with the DMA ring, but we haven't released documentation for that yet, so I currently use CP memory writes instead. Please take a look and tell me what you think about it. Cheers, Christian.
[PATCH 02/10] drm/radeon: cleanup VM id handling a bit
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c |5 +++--
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
drivers/gpu/drm/radeon/radeon.h |5 +++--
drivers/gpu/drm/radeon/radeon_cs.c | 18 +++---
drivers/gpu/drm/radeon/radeon_ring.c | 14 +++---
drivers/gpu/drm/radeon/si.c |5 +++--
7 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9945d86..efa3ab9 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -871,12 +871,13 @@ void cayman_ring_ib_execute(struct radeon_device *rdev,
struct radeon_ib *ib)
#endif
(ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0xFF);
- radeon_ring_write(ring, ib->length_dw | (ib->vm_id << 24));
+ radeon_ring_write(ring, ib->length_dw |
+ (ib->vm ? (ib->vm->id << 24) : 0));
/* flush read cache over gart for this vmid */
radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
radeon_ring_write(ring, (CP_COHER_CNTL2 - PACKET3_SET_CONFIG_REG_START)
>> 2);
- radeon_ring_write(ring, ib->vm_id);
+ radeon_ring_write(ring, ib->vm ? ib->vm->id : 0);
radeon_ring_write(ring, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(ring, PACKET3_TC_ACTION_ENA | PACKET3_SH_ACTION_ENA);
radeon_ring_write(ring, 0x);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8acb34f..5f5f524 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3816,7 +3816,7 @@ int r100_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, 256);
+ r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, NULL, 256);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 637280f..75d448d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2635,7 +2635,7 @@ int r600_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
- r = radeon_ib_get(rdev, ring->idx, &ib, 256);
+ r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
if (r) {
DRM_ERROR("radeon: failed to get ib (%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8d75c65..ef1fdf2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -611,7 +611,7 @@ struct radeon_ib {
uint32_t*ptr;
int ring;
struct radeon_fence *fence;
- unsignedvm_id;
+ struct radeon_vm*vm;
boolis_const_ib;
struct radeon_fence *sync_to[RADEON_NUM_RINGS];
struct radeon_semaphore *semaphore;
@@ -753,7 +753,8 @@ struct si_rlc {
};
int radeon_ib_get(struct radeon_device *rdev, int ring,
- struct radeon_ib *ib, unsigned size);
+ struct radeon_ib *ib, struct radeon_vm *vm,
+ unsigned size);
void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib);
int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib,
struct radeon_ib *const_ib);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index b4a0db24..0a9d1eb 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -363,7 +363,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
* uncached).
*/
r = radeon_ib_get(rdev, parser->ring, &parser->ib,
- ib_chunk->length_dw * 4);
+ NULL, ib_chunk->length_dw * 4);
if (r) {
DRM_ERROR("Failed to get ib !\n");
return r;
@@ -380,7 +380,6 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
return r;
}
radeon_cs_sync_rings(parser);
- parser->ib.vm_id = 0;
r = radeon_ib_schedule(rdev, &parser->ib, NULL);
if (r) {
DRM_ERROR("Failed to schedule IB !\n");
@@ -426,7 +425,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
return -EINVAL;
}
r = radeon_ib_get(rdev, parser->ring, &parser->const_ib,
- ib_chun
[PATCH 03/10] drm/radeon: move VM funcs into asic structure
So it looks more like the rest of the driver.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 35 +---
drivers/gpu/drm/radeon/radeon_asic.c | 50 ++
drivers/gpu/drm/radeon/radeon_gart.c | 16 +--
3 files changed, 54 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ef1fdf2..5163346 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -660,28 +660,12 @@ struct radeon_vm {
struct radeon_fence *fence;
};
-struct radeon_vm_funcs {
- int (*init)(struct radeon_device *rdev);
- void (*fini)(struct radeon_device *rdev);
- /* cs mutex must be lock for schedule_ib */
- int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, int id);
- void (*unbind)(struct radeon_device *rdev, struct radeon_vm *vm);
- void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm *vm);
- uint32_t (*page_flags)(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags);
- void (*set_page)(struct radeon_device *rdev, struct radeon_vm *vm,
- unsigned pfn, uint64_t addr, uint32_t flags);
-};
-
struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
uint32_tuse_bitmap;
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
- /* fields constant after init */
- const struct radeon_vm_funcs*funcs;
/* number of VMIDs */
unsignednvm;
/* vram base address for page table entry */
@@ -1147,6 +1131,18 @@ struct radeon_asic {
void (*tlb_flush)(struct radeon_device *rdev);
int (*set_page)(struct radeon_device *rdev, int i, uint64_t
addr);
} gart;
+ struct {
+ int (*init)(struct radeon_device *rdev);
+ void (*fini)(struct radeon_device *rdev);
+ int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
+ void (*unbind)(struct radeon_device *rdev, struct radeon_vm
*vm);
+ void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
+ uint32_t (*page_flags)(struct radeon_device *rdev,
+ struct radeon_vm *vm,
+ uint32_t flags);
+ void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
+unsigned pfn, uint64_t addr, uint32_t flags);
+ } vm;
/* ring specific callbacks */
struct {
void (*ib_execute)(struct radeon_device *rdev, struct radeon_ib
*ib);
@@ -1698,6 +1694,13 @@ void radeon_ring_write(struct radeon_ring *ring,
uint32_t v);
#define radeon_asic_reset(rdev) (rdev)->asic->asic_reset((rdev))
#define radeon_gart_tlb_flush(rdev) (rdev)->asic->gart.tlb_flush((rdev))
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
+#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
+#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
+#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
+#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
+#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
+#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
#define radeon_ring_test(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev),
(cp))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 973417c..7d29d53 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1342,16 +1342,6 @@ static struct radeon_asic btc_asic = {
},
};
-static const struct radeon_vm_funcs cayman_vm_funcs = {
- .init = &cayman_vm_init,
- .fini = &cayman_vm_fini,
- .bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
- .tlb_flush = &cayman_vm_tlb_flush,
- .page_flags = &cayman_vm_page_flags,
- .set_page = &cayman_vm_set_page,
-};
-
static struct radeon_asic cayman_asic = {
.init = &cayman_init,
.fini = &cayman_fini,
@@ -1366,6 +1356,15 @@ static struct radeon_asic cayman_asic = {
.tlb_flush = &cayman_pcie_gart_tlb_flush,
.set_page = &rs600_gart_set_page,
[PATCH 04/10] drm/radeon: remove vm_unbind
It actually isn't very useful.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |2 --
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_gart.c |1 -
drivers/gpu/drm/radeon/si.c | 12
5 files changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index efa3ab9..3b1aab3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1501,17 +1501,6 @@ int cayman_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
return 0;
}
-void cayman_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (vm->id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm->id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
{
if (vm->id == -1)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5163346..aeb2d1f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1135,7 +1135,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
- void (*unbind)(struct radeon_device *rdev, struct radeon_vm
*vm);
void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
@@ -1697,7 +1696,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
-#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 7d29d53..9d5f4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1360,7 +1360,6 @@ static struct radeon_asic cayman_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1463,7 +1462,6 @@ static struct radeon_asic trinity_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
- .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1566,7 +1564,6 @@ static struct radeon_asic si_asic = {
.init = &si_vm_init,
.fini = &si_vm_fini,
.bind = &si_vm_bind,
- .unbind = &si_vm_unbind,
.tlb_flush = &si_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2902e5f..18a03ab 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -522,7 +522,6 @@ static void radeon_vm_unbind_locked(struct radeon_device
*rdev,
radeon_fence_unref(&vm->fence);
/* hw unbind */
- radeon_asic_vm_unbind(rdev, vm);
rdev->vm_manager.use_bitmap &= ~(1 << vm->id);
list_del_init(&vm->list);
vm->id = -1;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4ebcb33..40a9a85 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2795,18 +2795,6 @@ int si_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
return 0;
}
-void si_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- if (vm->id < 8)
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
- else
- WREG32(VM_CONTEXT8_PAGE_
[PATCH 05/10] drm/radeon: add sync helper function
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -115,19 +115,27 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p,
u32 ring, s32 priority
return 0;
}
+static void radeon_cs_sync_to(struct radeon_cs_parser *p,
+ struct radeon_fence *fence)
+{
+ struct radeon_fence *other;
+
+ if (!fence)
+ return;
+
+ other = p->ib.sync_to[fence->ring];
+ p->ib.sync_to[fence->ring] = radeon_fence_later(fence, other);
+}
+
static void radeon_cs_sync_rings(struct radeon_cs_parser *p)
{
int i;
for (i = 0; i < p->nrelocs; i++) {
- struct radeon_fence *a, *b;
-
- if (!p->relocs[i].robj || !p->relocs[i].robj->tbo.sync_obj)
+ if (!p->relocs[i].robj)
continue;
- a = p->relocs[i].robj->tbo.sync_obj;
- b = p->ib.sync_to[a->ring];
- p->ib.sync_to[a->ring] = radeon_fence_later(a, b);
+ radeon_cs_sync_to(p, p->relocs[i].robj->tbo.sync_obj);
}
}
--
1.7.9.5
[PATCH 06/10] drm/radeon: make VM flushs a ring operation
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 31 ---
drivers/gpu/drm/radeon/radeon.h |6 --
drivers/gpu/drm/radeon/radeon_asic.c | 12 +---
drivers/gpu/drm/radeon/radeon_asic.h |3 +--
drivers/gpu/drm/radeon/radeon_cs.c |1 +
drivers/gpu/drm/radeon/radeon_gart.c |4 +++-
drivers/gpu/drm/radeon/radeon_ring.c |8
drivers/gpu/drm/radeon/si.c | 15 ---
8 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3b1aab3..ad337e8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1494,24 +1494,9 @@ int cayman_vm_bind(struct radeon_device *rdev, struct
radeon_vm *vm, int id)
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >>
12);
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << id);
return 0;
}
-void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
-{
- if (vm->id == -1)
- return;
-
- /* flush hdp cache */
- WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
- /* bits 0-7 are the VM contexts0-7 */
- WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
#define R600_PTE_VALID (1 << 0)
#define R600_PTE_SYSTEM(1 << 1)
#define R600_PTE_SNOOPED (1 << 2)
@@ -1543,3 +1528,19 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
addr |= flags;
writeq(addr, ptr + (pfn * 8));
}
+
+void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
+{
+ struct radeon_ring *ring = &rdev->ring[ib->ring];
+
+ if (!ib->vm || ib->vm->id == -1)
+ return;
+
+ /* flush hdp cache */
+ radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
+ radeon_ring_write(ring, 0x1);
+
+ /* bits 0-7 are the VM contexts0-7 */
+ radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
+ radeon_ring_write(ring, 1 << ib->vm->id);
+}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index aeb2d1f..1228778 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -658,6 +658,8 @@ struct radeon_vm {
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
+ /* last flush or NULL if we still need to flush */
+ struct radeon_fence *last_flush;
};
struct radeon_vm_manager {
@@ -1135,7 +1137,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
- void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
uint32_t flags);
@@ -1154,6 +1155,7 @@ struct radeon_asic {
int (*ring_test)(struct radeon_device *rdev, struct radeon_ring
*cp);
int (*ib_test)(struct radeon_device *rdev, struct radeon_ring
*cp);
bool (*is_lockup)(struct radeon_device *rdev, struct
radeon_ring *cp);
+ void (*vm_flush)(struct radeon_device *rdev, struct radeon_ib
*ib);
} ring[RADEON_NUM_RINGS];
/* irqs */
struct {
@@ -1696,7 +1698,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
-#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev),
(v))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1705,6 +1706,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_ring_ib_execute(rdev, r, ib)
(rdev)->asic->ring[(r)].ib_execute((rdev), (ib))
#define radeon_ring_ib_parse(rdev, r, ib)
(rdev)->asic->ring[(r)].ib_parse((rdev), (ib))
#define radeon_ring_is_lockup(rdev, r, cp)
(rdev)->asic->ring[(r)].is_lockup((rdev), (cp))
+#define radeon_ring_vm_f
[PATCH 07/10] drm/radeon: rework VMID handling
Move binding onto the ring, simplifying handling a bit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c| 20 ++---
drivers/gpu/drm/radeon/radeon.h| 30 +++-
drivers/gpu/drm/radeon/radeon_asic.c |9 +--
drivers/gpu/drm/radeon/radeon_asic.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c |9 +--
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_gart.c | 126 +---
drivers/gpu/drm/radeon/si.c| 30 ++--
8 files changed, 153 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index ad337e8..88d5713 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1489,14 +1489,6 @@ void cayman_vm_fini(struct radeon_device *rdev)
{
}
-int cayman_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm, int id)
-{
- WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
- WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
- WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >>
12);
- return 0;
-}
-
#define R600_PTE_VALID (1 << 0)
#define R600_PTE_SYSTEM(1 << 1)
#define R600_PTE_SNOOPED (1 << 2)
@@ -1532,10 +1524,20 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
{
struct radeon_ring *ring = &rdev->ring[ib->ring];
+ struct radeon_vm *vm = ib->vm;
- if (!ib->vm || ib->vm->id == -1)
+ if (vm == NULL)
return;
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, 0);
+
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, vm->last_pfn);
+
+ radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR +
(vm->id << 2), 0));
+ radeon_ring_write(ring, vm->pt_gpu_addr >> 12);
+
/* flush hdp cache */
radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
radeon_ring_write(ring, 0x1);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1228778..e0c6673 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -268,6 +268,22 @@ static inline struct radeon_fence
*radeon_fence_later(struct radeon_fence *a,
}
}
+static inline bool radeon_fence_is_earlier(struct radeon_fence *a,
+ struct radeon_fence *b)
+{
+ if (!a) {
+ return false;
+ }
+
+ if (!b) {
+ return true;
+ }
+
+ BUG_ON(a->ring != b->ring);
+
+ return a->seq < b->seq;
+}
+
/*
* Tiling registers
*/
@@ -647,10 +663,13 @@ struct radeon_ring {
/*
* VM
*/
+
+#define RADEON_NUM_VM 16
+
struct radeon_vm {
struct list_headlist;
struct list_headva;
- int id;
+ unsignedid;
unsignedlast_pfn;
u64 pt_gpu_addr;
u64 *pt;
@@ -665,7 +684,7 @@ struct radeon_vm {
struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
- uint32_tuse_bitmap;
+ struct radeon_fence *active[RADEON_NUM_VM];
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
/* number of VMIDs */
@@ -1136,7 +1155,6 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
- int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm,
int id);
uint32_t (*page_flags)(struct radeon_device *rdev,
struct radeon_vm *vm,
uint32_t flags);
@@ -1697,7 +1715,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v),
(id))
#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1779,6 +1796,11 @@ int radeon_vm_init(struct radeon_device *rdev, struct
radeon_vm *vm);
void radeon_vm_fini(struct r
[PATCH 08/10] drm/radeon: rework VM page table handling
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 28 +
drivers/gpu/drm/radeon/radeon_gart.c | 107 +++---
drivers/gpu/drm/radeon/radeon_sa.c | 20 +++
4 files changed, 43 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e0c6673..ed0ef17 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -316,7 +316,6 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
- struct radeon_fence *fence;
boolvalid;
};
@@ -1794,8 +1793,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev);
void radeon_vm_manager_fini(struct radeon_device *rdev);
int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
-int radeon_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm);
-void radeon_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm);
+int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
struct radeon_vm *vm, int ring);
void radeon_vm_fence(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index dc4554e..300fc25 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -286,30 +286,6 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
-static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
- struct radeon_fence *fence)
-{
- struct radeon_fpriv *fpriv = parser->filp->driver_priv;
- struct radeon_vm *vm = &fpriv->vm;
- struct radeon_bo_list *lobj;
-
- if (parser->chunk_ib_idx == -1) {
- return;
- }
- if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
- return;
- }
-
- list_for_each_entry(lobj, &parser->validated, tv.head) {
- struct radeon_bo_va *bo_va;
- struct radeon_bo *rbo = lobj->bo;
-
- bo_va = radeon_bo_va(rbo, vm);
- radeon_fence_unref(&bo_va->fence);
- bo_va->fence = radeon_fence_ref(fence);
- }
-}
-
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -323,8 +299,6 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
unsigned i;
if (!error) {
- /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
- radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
} else {
@@ -475,7 +449,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
- r = radeon_vm_bind(rdev, vm);
+ r = radeon_vm_alloc_pt(rdev, vm);
if (r) {
goto out;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index d668733..4bce026 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -478,43 +478,26 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
return 0;
}
-/* global mutex must be lock */
/**
- * radeon_vm_unbind_locked - unbind a specific vm
+ * radeon_vm_free_pt - free the page table for 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.
+ * Free the page table of a specific vm (cayman+).
+ *
+ * Global and local mutex must be lock!
*/
-static void radeon_vm_unbind_locked(struct radeon_device *rdev,
+static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
{
struct radeon_bo_va *bo_va;
- /* wait for vm use to end */
- 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)
-
[PATCH 09/10] drm/radeon: Move looping over the PTEs into chip code
Makes it easier to move it into the rings.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 22 +++---
drivers/gpu/drm/radeon/radeon.h | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_asic.h |7 +++
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
5 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 88d5713..1fd2e41 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1495,9 +1495,7 @@ void cayman_vm_fini(struct radeon_device *rdev)
#define R600_PTE_READABLE (1 << 5)
#define R600_PTE_WRITEABLE (1 << 6)
-uint32_t cayman_vm_page_flags(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags)
+uint32_t cayman_vm_page_flags(struct radeon_device *rdev, uint32_t flags)
{
uint32_t r600_flags = 0;
@@ -1512,13 +1510,23 @@ uint32_t cayman_vm_page_flags(struct radeon_device
*rdev,
}
void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
- unsigned pfn, uint64_t addr, uint32_t flags)
+ unsigned pfn, struct ttm_mem_reg *mem,
+ unsigned npages, uint32_t flags)
{
void __iomem *ptr = (void *)vm->pt;
+ uint64_t addr;
+ int i;
+
+ addr = flags = cayman_vm_page_flags(rdev, flags);
- addr = addr & 0xF000ULL;
- addr |= flags;
- writeq(addr, ptr + (pfn * 8));
+for (i = 0; i < npages; ++i, ++pfn) {
+if (mem) {
+addr = radeon_vm_get_addr(rdev, mem, i);
+ addr = addr & 0xF000ULL;
+ addr |= flags;
+}
+ writeq(addr, ptr + (pfn * 8));
+}
}
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ed0ef17..7d37cb2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,11 +1154,9 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
- uint32_t (*page_flags)(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags);
void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
-unsigned pfn, uint64_t addr, uint32_t flags);
+unsigned pfn, struct ttm_mem_reg *mem,
+unsigned npages, uint32_t flags);
} vm;
/* ring specific callbacks */
struct {
@@ -1714,8 +1712,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_page_flags(rdev, v, flags)
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
-#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, mem, npages, flags)
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (mem), (npages), (flags))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
#define radeon_ring_test(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev),
(cp))
@@ -1799,6 +1796,9 @@ struct radeon_fence *radeon_vm_grab_id(struct
radeon_device *rdev,
void radeon_vm_fence(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_fence *fence);
+u64 radeon_vm_get_addr(struct radeon_device *rdev,
+ struct ttm_mem_reg *mem,
+ unsigned pfn);
int radeon_vm_bo_update_pte(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_bo *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 5486674..4b99a24 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,7 +1359,6 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
- .page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1462,7 +1461,6 @@ static struct radeon_asic trinity_asic = {
.vm = {
.init = &caym
[PATCH 10/10] drm/radeon: make page table updates async
Currently doing the update with the CP.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 20 ++
drivers/gpu/drm/radeon/nid.h |1 +
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |3 ++
drivers/gpu/drm/radeon/radeon_gart.c | 70 +-
5 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 1fd2e41..78d9cfb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1513,20 +1513,24 @@ void cayman_vm_set_page(struct radeon_device *rdev,
struct radeon_vm *vm,
unsigned pfn, struct ttm_mem_reg *mem,
unsigned npages, uint32_t flags)
{
- void __iomem *ptr = (void *)vm->pt;
- uint64_t addr;
+ struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
+ uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
int i;
addr = flags = cayman_vm_page_flags(rdev, flags);
-for (i = 0; i < npages; ++i, ++pfn) {
-if (mem) {
-addr = radeon_vm_get_addr(rdev, mem, i);
+ radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
+ radeon_ring_write(ring, pt & 0x);
+ radeon_ring_write(ring, (pt >> 32) & 0xff);
+ for (i = 0; i < npages; ++i) {
+ if (mem) {
+ addr = radeon_vm_get_addr(rdev, mem, i);
addr = addr & 0xF000ULL;
addr |= flags;
-}
- writeq(addr, ptr + (pfn * 8));
-}
+ }
+ radeon_ring_write(ring, addr & 0x);
+ radeon_ring_write(ring, (addr >> 32) & 0x);
+ }
}
void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 870db34..2423d1b 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -585,6 +585,7 @@
#definePACKET3_SET_CONTEXT_REG_INDIRECT0x73
#definePACKET3_SET_RESOURCE_INDIRECT 0x74
#definePACKET3_SET_APPEND_CNT 0x75
+#definePACKET3_ME_WRITE0x7A
#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7d37cb2..3de0f08 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,6 +1154,8 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
+
+ u32 pt_ring_index;
void (*set_page)(struct radeon_device *rdev, struct radeon_vm
*vm,
unsigned pfn, struct ttm_mem_reg *mem,
unsigned npages, uint32_t flags);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 4b99a24..d0b4e50 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,6 +1359,7 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1461,6 +1462,7 @@ static struct radeon_asic trinity_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1563,6 +1565,7 @@ static struct radeon_asic si_asic = {
.vm = {
.init = &si_vm_init,
.fini = &si_vm_fini,
+ .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index bf5378b..9cfd213 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -464,15 +464,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
continue;
list_for_each_entry(bo_va, &vm->va, vm_list) {
- struct ttm_mem_reg *mem = NULL;
- if (bo_va->valid)
- mem = &bo_va->bo->tbo.mem;
-
bo_va->valid = false;
- r = radeon_vm_bo_update_pte(rdev, vm, bo_va->bo, mem);
- if (r) {
- DRM_ERROR("Failed to update pte for vm %d!\n",
vm->id);
- }
}
}
return 0;
@@ -801,7 +
[RFCv3 PATCH 1/8] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
On Mon August 13 2012 13:48:28 Soby Mathew wrote:
> Hi Hans,
>The patch seems to cover most of the requirement. I find 2 gaps:
>
> > +/* DV-class control IDs defined by V4L2 */
> > +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> > +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> > +
> > +#defineV4L2_CID_DV_TX_HOTPLUG
> > (V4L2_CID_DV_CLASS_BASE + 1)
> > +#defineV4L2_CID_DV_TX_RXSENSE
> > (V4L2_CID_DV_CLASS_BASE + 2)
> > +#defineV4L2_CID_DV_TX_EDID_PRESENT
> > (V4L2_CID_DV_CLASS_BASE + 3)
> > +#defineV4L2_CID_DV_TX_MODE
> > (V4L2_CID_DV_CLASS_BASE + 4)
> > +enum v4l2_dv_tx_mode {
> > + V4L2_DV_TX_MODE_DVI_D = 0,
> > + V4L2_DV_TX_MODE_HDMI= 1,
> > +};
>
>
> Even at the receiver side the DVI/HDMI mode need to be detected. So
> probably a control for the RX mode is needed.
We left that part out for the moment: we (Cisco) do not need that at the
moment, and for this first version I wanted to concentrate only on those
parts that were absolutely necessary.
Once it's merged it is much easier to add additional functionality like
that.
>
>
> > +#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
> > +enum v4l2_dv_rgb_range {
> > + V4L2_DV_RGB_RANGE_AUTO= 0,
> > + V4L2_DV_RGB_RANGE_LIMITED = 1,
> > + V4L2_DV_RGB_RANGE_FULL= 2,
> > +};
> > +
> > +#defineV4L2_CID_DV_RX_POWER_PRESENT
> > (V4L2_CID_DV_CLASS_BASE + 100)
> > +#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE +
> > 101)
> > +
>
> Similarly, some sources can support YC mode of transmission instaed of
> RGB. To control the YC Quantization Range, we can define control
> V4L2_CID_DV_TX_YC_RANGE
>
> Similar control would be needed at the Rx side also like
> V4L2_CID_DV_RX_YC_RANGE.
The question is if you actually need this control for the YC range. For RGB
it is necessary because you cannot rely on the autodetect: too many devices
do not handle that correctly, so you have to be able to override.
For YC the situation seems to be much better and we (Cisco) haven't seen the
need yet to be able to override the automatic YC range setup.
If there is a clear situation where this is necessary, then it can be added.
Regards,
Hans
[PATCH V2] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails with such error messages: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of function 'swiotlb_nr_tbl' drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 'ttm_dma_populate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but argument is of type 'struct device *' drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 'ttm_dma_unpopulate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but argument is of type 'struct device *' V2: 1, Add compilation error messages; 2, Make the From: address the same as Signed-off-by address. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3
[Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
> +
> + if (!ret) {
> + cb->base.flags = 0;
> + cb->base.func = __dma_fence_wake_func;
> + cb->base.private = priv;
> + cb->fence = fence;
> + cb->func = func;
> + __add_wait_queue(&fence->event_queue, &cb->base);
> + }
> + spin_unlock_irqrestore(&fence->event_queue.lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_fence_add_callback);
I think for api completenes we should also have a
dma_fence_remove_callback function.
>>> We did originally but Maarten found it was difficult to deal with
>>> properly when the gpu's hang. I think his alternative was just to
>>> require the hung driver to signal the fence. I had kicked around the
>>> idea of a dma_fence_cancel() alternative to signal that could pass an
>>> error thru to the waiting driver.. although not sure if the other
>>> driver could really do anything differently at that point.
>> No, there is a very real reason I removed dma_fence_remove_callback. It is
>> absolutely non-trivial to cancel it once added, since you have to deal with
>> all kinds of race conditions.. See i915_gem_reset_requests in my git tree:
>> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=673c4b2550bc63ec134bca47a95dabd617a689ce
> I don't see the point in that code ... Why can't we drop the kref
> _outside_ of the critical section protected by event_queue_lock? Then you
> pretty much have an open-coded version of dma_fence_callback_cancel in
> there.
The event_queue_lock protects 2 things:
1. Refcount to dma_fence won't drop to 0 if val->fences[i] != NULL
Creator is supposed to keep a refcount until after dma_fence_signal
returns. Adding a refcount you release in the callback won't help
you here much.
2. Integrity of request->prime_list
The list_del's are otherwise not serialized, leaving a corrupted
list if 2 fences signal at the same time. kref_put in the non-free'ing
case is simply an atomic decrement, so there's no measurable penalty
for keeping it in the lock.
So no, you could remove it from the kref_put, but val->fences[i] = NULL
assignment would still need it, so there's no real penalty left for
putting kref_put in the spinlock to also protect the second case
without dropping/retaking lock.
I'll add dma_fence_remove_callback that returns a bool of whether
the callback was removed or not. In the latter case the fence already
fired. However, if you call dma_fence_remove_callback twice, on the
wrong fence, or without ever calling dma_fence_add_callback you'd
undefined behavior, and there's no guarantee I could detech such
situation, but with those constraints I think it could be useful to
have.
It sucks but prime_rm_lock is the inner lock so the only way not to
deadlock is doing what I'm doing there, or not getting the hardware
locked in the first place.
>
>> This is the only way to do it completely deadlock/memory corruption free
>> since you essentially have a locking inversion to avoid. I had it wrong
>> the first 2 times too, even when I knew about a lot of the locking
>> complications. If you want to do it, in most cases it will likely be easier
>> to just eat the signal and ignore it instead of canceling.
>>
> +
> +/**
> + * dma_fence_wait - wait for a fence to be signaled
> + *
> + * @fence: [in]The fence to wait on
> + * @intr:[in]if true, do an interruptible wait
> + * @timeout: [in]absolute time for timeout, in jiffies.
I don't quite like this, I think we should keep the styl of all other
wait_*_timeout functions and pass the arg as timeout in jiffies (and also
the same return semantics). Otherwise well have funny code that needs to
handle return values differently depending upon whether it waits upon a
dma_fence or a native object (where it would us the wait_*_timeout
functions directly).
>>> We did start out this way, but there was an ugly jiffies roll-over
>>> problem that was difficult to deal with properly. Using an absolute
>>> time avoided the problem.
>> Yeah, this makes it easier to wait on multiple fences, instead of
>> resetting the timeout over and over and over again, or manually
>> recalculating.
> I don't see how updating the jiffies_left timeout is that onerous, and in
> any case we can easily wrap that up into a little helper function, passing
> in an array of dma_fence pointers.
>
> Creating interfaces that differ from established kernel api patterns otoh
> isn't good imo. I.e. I want dma_fence_wait_bla to be a drop-in replacement
> for the corresponding wait_event_bla function/macro, which the same
> semantics for the timeout and return values.
>
> Differing in such things only leads to confusion when reading patches imo.
>
Ok, I'll see if I can make a set of functions that follow the normal rules
for these types of functions.
~Maarten
[RFC] make VM handling async
> It's not 100% complete cause page table updates should be made with the DMA > ring, but we haven't released documentation for that yet, so I currently > use CP memory writes instead. Sad. Any release time hint? (the DMA ring will cleanup a lot of code). BTW, maybe at the same time the HDP_NONSURFACE regs should be 64bitified? -- Sylvain
[PATCH V2] drm/radeon: Include swiotlb.h if SWIOTLB configured.
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote: > When SWIOTLB is configured, if without this patch kernel compilation > fails with such error messages: > > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': > drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of > function 'swiotlb_nr_tbl' > drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of > 'ttm_dma_populate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but > argument is of type 'struct device *' > drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': > drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of > 'ttm_dma_unpopulate' from incompatible pointer type > include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but > argument is of type 'struct device *' > > V2: > 1, Add compilation error messages; > 2, Make the From: address the same as Signed-off-by address. > > Signed-off-by: Huacai Chen Reviewed-by: Michel D?nzer -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
