[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..557ef2f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2167,27 +2167,27 @@ static int __devinit hdmi_resources_init(struct
hdmi_context *hdata)
/* get clocks, power */
res->hdmi = clk_get(dev, "hdmi");
- if (IS_ERR_OR_NULL(res->hdmi)) {
+ if (IS_ERR(res->hdmi)) {
DRM_ERROR("failed to get clock 'hdmi'\n");
goto fail;
}
res->sclk_hdmi = clk_get(dev, "sclk_hdmi");
- if (IS_ERR_OR_NULL(res->sclk_hdmi)) {
+ if (IS_ERR(res->sclk_hdmi)) {
DRM_ERROR("failed to get clock 'sclk_hdmi'\n");
goto fail;
}
res->sclk_pixel = clk_get(dev, "sclk_pixel");
- if (IS_ERR_OR_NULL(res->sclk_pixel)) {
+ if (IS_ERR(res->sclk_pixel)) {
DRM_ERROR("failed to get clock 'sclk_pixel'\n");
goto fail;
}
res->sclk_hdmiphy = clk_get(dev, "sclk_hdmiphy");
- if (IS_ERR_OR_NULL(res->sclk_hdmiphy)) {
+ if (IS_ERR(res->sclk_hdmiphy)) {
DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
goto fail;
}
res->hdmiphy = clk_get(dev, "hdmiphy");
- if (IS_ERR_OR_NULL(res->hdmiphy)) {
+ if (IS_ERR(res->hdmiphy)) {
DRM_ERROR("failed to get clock 'hdmiphy'\n");
goto fail;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 2/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
In the fail: path of mixer_resources_init() and vp_resources_init()
the first clk tested cannot be NULL either, so IS_ERR_OR_NULL is
removed from these as well. Other clocks may still be NULL as they
haven't been clk_get'd yet.
Signed-off-by: Tony Prisk
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_mixer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e7fbb82..dbd97c0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -972,14 +972,14 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
spin_lock_init(&mixer_res->reg_slock);
mixer_res->mixer = clk_get(dev, "mixer");
- if (IS_ERR_OR_NULL(mixer_res->mixer)) {
+ if (IS_ERR(mixer_res->mixer)) {
dev_err(dev, "failed to get clock 'mixer'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_hdmi = clk_get(dev, "sclk_hdmi");
- if (IS_ERR_OR_NULL(mixer_res->sclk_hdmi)) {
+ if (IS_ERR(mixer_res->sclk_hdmi)) {
dev_err(dev, "failed to get clock 'sclk_hdmi'\n");
ret = -ENODEV;
goto fail;
@@ -1019,7 +1019,7 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
fail:
if (!IS_ERR_OR_NULL(mixer_res->sclk_hdmi))
clk_put(mixer_res->sclk_hdmi);
- if (!IS_ERR_OR_NULL(mixer_res->mixer))
+ if (!IS_ERR(mixer_res->mixer))
clk_put(mixer_res->mixer);
return ret;
}
@@ -1034,19 +1034,19 @@ static int __devinit vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
int ret;
mixer_res->vp = clk_get(dev, "vp");
- if (IS_ERR_OR_NULL(mixer_res->vp)) {
+ if (IS_ERR(mixer_res->vp)) {
dev_err(dev, "failed to get clock 'vp'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_mixer = clk_get(dev, "sclk_mixer");
- if (IS_ERR_OR_NULL(mixer_res->sclk_mixer)) {
+ if (IS_ERR(mixer_res->sclk_mixer)) {
dev_err(dev, "failed to get clock 'sclk_mixer'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_dac = clk_get(dev, "sclk_dac");
- if (IS_ERR_OR_NULL(mixer_res->sclk_dac)) {
+ if (IS_ERR(mixer_res->sclk_dac)) {
dev_err(dev, "failed to get clock 'sclk_dac'\n");
ret = -ENODEV;
goto fail;
@@ -1077,7 +1077,7 @@ fail:
clk_put(mixer_res->sclk_dac);
if (!IS_ERR_OR_NULL(mixer_res->sclk_mixer))
clk_put(mixer_res->sclk_mixer);
- if (!IS_ERR_OR_NULL(mixer_res->vp))
+ if (!IS_ERR(mixer_res->vp))
clk_put(mixer_res->vp);
return ret;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Tue, 2012-12-18 at 21:39 +0300, Dan Carpenter wrote: > On Wed, Dec 19, 2012 at 06:34:05AM +1300, Tony Prisk wrote: > > Resend to include mailing lists. > > > > Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. > > > > The original code is correct. clk_get() can return NULL depending > on the .config. > > regards, > dan carpenter Thanks for than Dan, Arguably that seems like an incorrect behaviour on the part of the clock subsystem given that the 'proper' function has kernel doc: * Returns a struct clk corresponding to the clock producer, or * valid IS_ERR() condition containing errno. Therefore the 'empty' version should adhere to the same rules, and not return NULL. I've cc'd Mike Turquette as well for his thoughts. Regards Tony P ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > I don't care either way, but being different from the documentation > is less bad than crashing which is what your patch does. Please > be more careful in the future. > > regards, > dan carpenter Critism accepted. Given that the driver depends on (PLAT_SAMSUNG || ARCH_MULTIPLATFORM), and multiplatform select COMMON_CLK and PLAT_SAMSUNG is selected only by ARCH_S3C64XX which has HAVE_CLK I didn't see a problem here. Your point is still valid and I will sort it out with Mike first. Regards Tony P ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Wed, 2012-12-19 at 08:11 +1300, Tony Prisk wrote: > On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > > I don't care either way, but being different from the documentation > > is less bad than crashing which is what your patch does. Please > > be more careful in the future. > > > > regards, > > dan carpenter > > Critism accepted. > > Given that the driver depends on (PLAT_SAMSUNG || ARCH_MULTIPLATFORM), > and multiplatform select COMMON_CLK and PLAT_SAMSUNG is selected only by > ARCH_S3C64XX which has HAVE_CLK I didn't see a problem here. > > Your point is still valid and I will sort it out with Mike first. > > Regards > Tony P Actually, I was wrong here - PLAT_SAMSUNG is selectable via PLAT_S3C24XX || ARCH_S3C64XX || PLAT_S5P but all these options (or the options that select them) seem to select a clock system as well, hence still no reason for a crash. Regards Tony P ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: create unified vma offset manager
On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> So we have to offset manager implementations for dealing with VMA offsets.
> GEM had one using the hash table, TTM had one using an rbtree,
>
> I'd rather we just had one to rule them all, since ttm is using the rbtree
> variant to allow sub mappings, to keep ABI we need to use that one.
>
> This also adds a bunch of inline helpers to avoid gem/ttm poking around
> inside the vma_offset objects. TTM needs a reset helper to remove a vma_offset
> when it copies an object to another one for buffer moves. The helpers
> also let drivers avoid the map_list.hash_key << PAGE_SHIFT nonsense.
Any clue as to the performance difference between the two
implementations? What does it add to the cost of a pagefault?
Hmm, don't have an i-g-t handy for scalability testing of the fault
handlers.
> +int drm_vma_offset_setup(struct drm_vma_offset_manager *man,
> + struct drm_vma_offset_node *node,
> + unsigned long num_pages)
> +{
> + int ret;
> +
> +retry_pre_get:
> + ret = drm_mm_pre_get(&man->addr_space_mm);
> + if (unlikely(ret != 0))
> + return ret;
> +
> + write_lock(&man->vm_lock);
> + node->vm_node = drm_mm_search_free(&man->addr_space_mm,
> +num_pages, 0, 0);
> +
> + if (unlikely(node->vm_node == NULL)) {
> + ret = -ENOMEM;
ret = -ENOSPC;
Depended upon by the higher layers for determining when to purge their
caches; i-g-t/gem_mmap_offset_exhaustion
> + goto out_unlock;
> + }
> +
> + node->vm_node = drm_mm_get_block_atomic(node->vm_node,
> + num_pages, 0);
> +
I'd feel happier if this tried to only take from the preallocated pool
rather than actually try a GFP_ATOMIC allocation.
> + if (unlikely(node->vm_node == NULL)) {
> + write_unlock(&man->vm_lock);
> + goto retry_pre_get;
> + }
> +
> + node->num_pages = num_pages;
> + drm_vma_offset_insert_rb(man, node);
> + write_unlock(&man->vm_lock);
> +
> + return 0;
> +out_unlock:
> + write_unlock(&man->vm_lock);
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(drm_vma_offset_setup);
--
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: [PATCH 3/3] drm/gem: start adding support for per-file object mmaps
From: Chris Wilson Subject: Re: [proof-of-concept/rfc] per object file mmaps To: Dave Airlie , dri-devel@lists.freedesktop.org In-Reply-To: <1355892119-13926-1-git-send-email-airl...@gmail.com> References: <1355892119-13926-1-git-send-email-airl...@gmail.com> On Wed, 19 Dec 2012 14:41:56 +1000, Dave Airlie wrote: > The 2+3 patches are actually the code, the first was just a cleanup. > > Anyways the second patch describes it best, but I've taken the approach > that we just need to keep track of what filp this object has had a handle > created on, and block mmaps on it. We could also probably block a bit > more explicitly in the driver respective mmap offset retrieval ioctls, > however we need to block in mmap itself to stop people just picking misc > address and trying them. > > It doesn't really add much now, but with render nodes where we have flink_to > or fd passing it would be more useful. > > I've no idea if I'll get to do much more with this, so consider it an > indication of how I'd like it done for someone else to run with :-) Locking looks entirely non-existent for per-file mmap add/remove in the generic gem code. Also we have a pair of hooks there that look like they would be a convenient point to place that code. -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: [PATCH 1/3] drm: create unified vma offset manager
On Wed, Dec 19, 2012 at 09:22:26AM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > So we have to offset manager implementations for dealing with VMA offsets.
> > GEM had one using the hash table, TTM had one using an rbtree,
> >
> > I'd rather we just had one to rule them all, since ttm is using the rbtree
> > variant to allow sub mappings, to keep ABI we need to use that one.
> >
> > This also adds a bunch of inline helpers to avoid gem/ttm poking around
> > inside the vma_offset objects. TTM needs a reset helper to remove a
> > vma_offset
> > when it copies an object to another one for buffer moves. The helpers
> > also let drivers avoid the map_list.hash_key << PAGE_SHIFT nonsense.
>
> Any clue as to the performance difference between the two
> implementations? What does it add to the cost of a pagefault?
>
> Hmm, don't have an i-g-t handy for scalability testing of the fault
> handlers.
>
> > +int drm_vma_offset_setup(struct drm_vma_offset_manager *man,
> > +struct drm_vma_offset_node *node,
> > +unsigned long num_pages)
> > +{
> > + int ret;
> > +
> > +retry_pre_get:
> > + ret = drm_mm_pre_get(&man->addr_space_mm);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + write_lock(&man->vm_lock);
> > + node->vm_node = drm_mm_search_free(&man->addr_space_mm,
> > + num_pages, 0, 0);
> > +
> > + if (unlikely(node->vm_node == NULL)) {
> > + ret = -ENOMEM;
> ret = -ENOSPC;
>
> Depended upon by the higher layers for determining when to purge their
> caches; i-g-t/gem_mmap_offset_exhaustion
The larger topic is that drm_mm is only 32bit on 32bit and we routinely
exhaust that after a few weeks of uptime. Or better: We _did_ exhaust
that, until we've added tons of checks in both kernel&libdrm to reap
cached objects if it doesn't work. Hence it's paramount for our code to
get a -ENOSPC to engage in mmap offset reaping.
> > + goto out_unlock;
> > + }
> > +
> > + node->vm_node = drm_mm_get_block_atomic(node->vm_node,
> > + num_pages, 0);
> > +
>
> I'd feel happier if this tried to only take from the preallocated pool
> rather than actually try a GFP_ATOMIC allocation.
Seconded. Imo drm_mm_pre_get should just die - it artificially limits
prealloc to 4 nodes, which means you'll fall over if 5 threads enter this.
And with the drm_mm rework of about a year ago it's no longer required,
you can simply embedded the struct drm_mm_node whereever you want, and mm
won't allocate anything any more on top of that. Or preallocate the
drm_mm_node in the code, outside of the locks. Inserting the node happens
then with drm_mm_insert* functions, which combine the search_free +
get_blcok (since really, there's nothing interesting you can do with the
hole space you get from search_free). See e.g.
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d
for the conversion. My efforts of yonder to convert everyon have stalled a
bit in the ttm code, but now that i915 is converted and (hopefully) the
mmap offset stuff, I'll pick this up again. Would allow us to kill quite a
bit of cruft from the drm_mm interfaces.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58491] regression : r600g: work around ddx over alignment
https://bugs.freedesktop.org/show_bug.cgi?id=58491 --- Comment #9 from Andy Furniss --- (In reply to comment #8) > (In reply to comment #7) > > Indeed, the resolution is the problem, > > > > running any application in my system resolution (1680x1050) breaks > > rendering, something like 640x480 has no problems. It also corrupts things > > like glxgears while I resize them (from any resolution). > > What I mean is, glxgears gets corrupted if I resize its window while it is > running, it displays corrupted blocks I am also seeing this resize corruption on HD4890 (native res = 1920x1080). Some demos seem to start corrupted - gearbox starts with band at top. Projtex - less reliable, may need other demos run first, but may start totally corrupted then correct when a key is pressed. -- 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 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown
https://bugs.freedesktop.org/show_bug.cgi?id=56634 --- Comment #6 from Andy Furniss --- (In reply to comment #5) > Using kernel from linus's repo fixes this issue. > Not sure if it is a "proper" fix, so I'll let you close the repoer if it > should be closed. > > (now I'm getting 40 fps in heaven , nice boost if we forget about the 3 fps > thing) etqw is also running normally again with drm-next kernel and current mesa/llvm. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Common Display Framework-T
Hi Tomi, On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > Hi, > > I have been testing Common Display Framework on OMAP, and making changes > that I've discussed in the posts I've sent in reply to the CDF series from > Laurent. While my CDF code is rather hacky and not at all ready, I wanted > to post the code for comments and also as a reference code to my posts. > > So here is CDF-T (Tomi-edition =). We've discussed your approach extensively face-to-face today so I won't review the patches in detail, but I will instead summarize our discussion to make sure we understood each other (and let other developers jump in). For the purpose of this discussion the term "display controller driver" (or just "display controller") refer to both the low-level driver layer that communicates directly with the display controller hardware, and to the higher- level driver layer that implements and exposes the userspace API (FBDEV, KMS and/or V4L). Those layers can be implemented in multiple kernel modules (such as in the OMAP DSS case, with omapdss for the low-level layer and omapdrm, omapfb and omapvout for the API-level layer) or a single kernel module. Control model - The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- model.png shows the CDF control model. The panel object depicted on the figure doesn't need to be a panel in the stricter sense but could be any chain of off-SoC (both on-board or off-board) display entities. It however helps thinking about it as a panel and doesn't hurt the model. The panel is controlled through abstract control requests. Those requests are used to retrieve panel information (such as the physical size, the supported video modes, EDID information, ...), set the panel configuration (such as the active video timings) or control the panel operation state (enabling/disabling the panel, controlling panel blanking and power management, ...). They are exposed by the panel using function pointers, and called by other kernel components in response to userspace requests (through the FBDEV, KMS or V4L2 APIs) or in-kernel events (for instance hotplug notifications). In response to the control requests the panel driver will communicate with the panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., not shown on the figure) and will control the video stream it receives on its input. The panel is connected at the hardware level to a video source (shown as a green hashed rectangle) that provides it with a video stream. The video stream flows from the video source to the panel and is directly controlled by its source, as shown by the green arrow from the display controller to the video stream. The video source exposes stream control operations as function pointers that are used by the panel to control the video stream, as shown by the green arrow from the panel to the video source. The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- model-2.png shows the call flow across entities when the panel is a pipeline made of more than a single entity. In this case the SoC (on the left of the dashed line) outputs a video stream on a DSI bus connected to a DSI to LVDS transmitter. The output of the DSI to LVDS transmitter is connected to an LVDS panel (or, more accurately, an LVDS panel module made of an LVDS panel controller and a panel). The transmitter and panel module are seen by the display controller and userspace API implementations as a single entity that exposes control request operations and controls its input video stream. When a control request is performed (outermost green arrow) the DSI to LVDS transmitter will propagate it to the panel, possibly mangling the input parameters or the response. For panel operation state control requests the last entity in the pipeline will likely want to control the video stream it receives on its input. The video stream control calls will be propagated from right to left as shown by the red arrows. Every entity in the call stack can communicate with its hardware device through the corresponding control bus, and/or control the video stream it receives on its input. This model allows filtering out modes and timings supported by the panel but unsupported by the transmitter and mangling the modes and timings according to the transmitter limitations. It has no complexity drawback for simple devices, as the corresponding drivers can just forward the calls directly. Similar use cases could exist for other control operations than mode and information retrieval. Discovery - Before being able to issue control requests, panel devices need to be discovered and associated with the connected display controller(s). Panels and display controllers are cross-dependent. There is no way around that, as the display controller needs a reference to the panel to call control requests in response to userspace API, and the panel needs a reference to th
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
Op 18-12-12 17:12, Markus Trippelsdorf schreef: > On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 14:38, Markus Trippelsdorf schreef: >>> On 2012.12.18 at 12:20 +0100, Michel Dänzer wrote: On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote: > On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote: >> On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: >>> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf >>> wrote: On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > wrote: >> As soon as I open the following website: >> http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html >> >> my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: > Is this a regression? Most likely a 3D driver bug unless you are only > seeing it with specific kernels. What browser are you using and do > you have hw accelerated webgl, etc. enabled? If so, what version of > mesa are you using? This is a regression, because it is caused by yesterdays merge of drm-next by Linus. IOW I only see this bug when running a v3.7-9432-g9360b53 kernel. >>> Can you bisect? I'm guessing it may be related to the new DMA rings. >>> Possibly: >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> Yes, the commit above causes the issue. >> >> 2d6cc72 GPU lockups > With 2d6cc72 reverted I get: > > Dec 17 23:09:35 x4 kernel: [ cut here ] Probably a separate issue, can you bisect this one as well? >>> Yes. Git-bisect points to: >>> >>> 85b144f860176ec18db927d6d9ecdfb24d9c6483 is the first bad commit >>> commit 85b144f860176ec18db927d6d9ecdfb24d9c6483 >>> Author: Maarten Lankhorst >>> Date: Thu Nov 29 11:36:54 2012 + >>> >>> drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock >>> held, v3 >>> >>> (Please note that this bug is a little bit harder to reproduce. But >>> when you scroll up and down for ~10 seconds on the webpage mentioned >>> above it will trigger the oops. >>> So while I'm not 100% sure that the issue is caused by exactly this >>> commit, the vicinity should be right) >>> >> Those dmesg warnings sound suspicious, looks like something is going >> very wrong there. >> >> Can you revert the one before it? "drm/radeon: allow move_notify to be >> called without reservation" Reservation should be held at this point, >> that commit got in accidentally. >> >> I doubt not holding a reservation is causing it though, I don't really >> see how that commit could cause it however, so can you please double >> check it never happened before that point, and only started at that >> commit? >> >> also slap in a BUG_ON(!ttm_bo_is_reserved(bo)) in >> ttm_bo_cleanup_refs_and_unlock for good measure, and a >> BUG_ON(spin_trylock(&bdev->fence_lock)); to ttm_bo_wait. >> >> I really don't see how that specific commit can be wrong though, so >> awaiting your results first before I try to dig more into it. > I just reran git-bisect just on your commits (from 1a1494def to 97a875cbd) > and I landed on the same commit as above: > > commit 85b144f86 (drm/ttm: call ttm_bo_cleanup_refs with reservation and lru > lock held, v3) > > So now I'm pretty sure it's specifically this commit that started the > issue. > > With your supposed debugging BUG_ONs added I still get: > > Dec 18 17:01:15 x4 kernel: [ cut here ] > Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 > radeon_fence_ref+0x2c/0x40() > Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name > Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted > 3.7.0-rc7-00520-g85b144f-dirty #174 > Dec 18 17:01:15 x4 kernel: Call Trace: > Dec 18 17:01:15 x4 kernel: [] ? > warn_slowpath_common+0x74/0xb0 > Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_mem_evict_first+0x1dc/0x2a0 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_man_get_node+0x62/0xb0 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_mem_space+0x28e/0x340 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_move_buffer+0xfc/0x170 > Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 > Dec 18 17:01:15 x4 kernel: [] ? radeon_bo_create+0x18a/0x200 > Dec 18 17:01:15 x4 kernel: [] ? radeon_bo_clear_va+0x40/0x40 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_object_create+0x92/0x160 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_create_ioctl+0x6c/0x150 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_object_free+0x2f/0x40 > Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 Jochen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Jochen --- This bug is still unsolved for me. I'm having Nvidia graphics card (Macbook 5,1) and using Ubuntu 12.04 with proprietary Nvidia driver. -- 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/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Fix regression introduced by 85b144f860176 Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0bf66f9..9f85418 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo, * at this point the buffer should be dead, so * no new sync objects can be attached. */ - sync_obj = driver->sync_obj_ref(&bo->sync_obj); + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); atomic_set(&bo->reserved, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: > Op 18-12-12 17:12, Markus Trippelsdorf schreef: > > With your supposed debugging BUG_ONs added I still get: > > > > Dec 18 17:01:15 x4 kernel: [ cut here ] > > Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 > > radeon_fence_ref+0x2c/0x40() > > Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name > > Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted > > 3.7.0-rc7-00520-g85b144f-dirty #174 > > Dec 18 17:01:15 x4 kernel: Call Trace: > > Dec 18 17:01:15 x4 kernel: [] ? > > warn_slowpath_common+0x74/0xb0 > > Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_mem_evict_first+0x1dc/0x2a0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_man_get_node+0x62/0xb0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_mem_space+0x28e/0x340 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_move_buffer+0xfc/0x170 > > Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 > > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 > > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_bo_create+0x18a/0x200 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_bo_clear_va+0x40/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_object_create+0x92/0x160 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_create_ioctl+0x6c/0x150 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_object_free+0x2f/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x4f0 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_pwrite_ioctl+0x20/0x20 > > Dec 18 17:01:15 x4 kernel: [] ? do_vfs_ioctl+0x2e4/0x4e0 > > Dec 18 17:01:15 x4 kernel: [] ? vfs_read+0x118/0x160 > > Dec 18 17:01:15 x4 kernel: [] ? sys_ioctl+0x4c/0xa0 > > Dec 18 17:01:15 x4 kernel: [] ? sys_read+0x51/0xa0 > > Dec 18 17:01:15 x4 kernel: [] ? > > system_call_fastpath+0x16/0x1b > so the kref to fence is null here. This should be impossible and > indicates a bug in refcounting somewhere, or possibly memory > corruption. > > Lets first look where things could go wrong.. > > sync_obj member requires fence_lock to be taken, but radeon code in > general doesn't do that, hm.. > > I think radeon_cs_sync_rings needs to take fence_lock during the > iteration, then taking on a refcount to the fence, and > radeon_crtc_page_flip and radeon_move_blit are lacking refcount on > fence_lock as well. > > But that would probably still not explain why it crashes in > radeon_vm_bo_invalidate shortly after, so it seems just as likely that > it's operating on freed memory there or something. > > But none of the code touches refcounting for that bo, and I really > don't see how I messed up anything there. > > I seem to be able to reproduce it if I add a hack though, can you test > if you get the exact same issues if you apply this patch? Your patch doesn't apply unfortunately: markus@x4 linux % patch -p1 --dry-run < ~/maarten.patch checking file drivers/gpu/drm/ttm/ttm_bo.c Hunk #1 succeeded at 512 with fuzz 1. Hunk #6 FAILED at 814. 1 out of 6 hunks FAILED markus@x4 linux % git describe v3.7-10833-g752451f markus@x4 linux % -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
Op 19-12-12 15:20, Markus Trippelsdorf schreef: > On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 17:12, Markus Trippelsdorf schreef: >>> With your supposed debugging BUG_ONs added I still get: >>> >>> Dec 18 17:01:15 x4 kernel: [ cut here ] >>> Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 >>> radeon_fence_ref+0x2c/0x40() >>> Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name >>> Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted >>> 3.7.0-rc7-00520-g85b144f-dirty #174 >>> Dec 18 17:01:15 x4 kernel: Call Trace: >>> Dec 18 17:01:15 x4 kernel: [] ? >>> warn_slowpath_common+0x74/0xb0 >>> Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_mem_evict_first+0x1dc/0x2a0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_man_get_node+0x62/0xb0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_mem_space+0x28e/0x340 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_move_buffer+0xfc/0x170 >>> Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 >>> Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 >>> Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_bo_create+0x18a/0x200 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_bo_clear_va+0x40/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_object_create+0x92/0x160 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_create_ioctl+0x6c/0x150 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_object_free+0x2f/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x4f0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_pwrite_ioctl+0x20/0x20 >>> Dec 18 17:01:15 x4 kernel: [] ? do_vfs_ioctl+0x2e4/0x4e0 >>> Dec 18 17:01:15 x4 kernel: [] ? vfs_read+0x118/0x160 >>> Dec 18 17:01:15 x4 kernel: [] ? sys_ioctl+0x4c/0xa0 >>> Dec 18 17:01:15 x4 kernel: [] ? sys_read+0x51/0xa0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> system_call_fastpath+0x16/0x1b >> so the kref to fence is null here. This should be impossible and >> indicates a bug in refcounting somewhere, or possibly memory >> corruption. >> >> Lets first look where things could go wrong.. >> >> sync_obj member requires fence_lock to be taken, but radeon code in >> general doesn't do that, hm.. >> >> I think radeon_cs_sync_rings needs to take fence_lock during the >> iteration, then taking on a refcount to the fence, and >> radeon_crtc_page_flip and radeon_move_blit are lacking refcount on >> fence_lock as well. >> >> But that would probably still not explain why it crashes in >> radeon_vm_bo_invalidate shortly after, so it seems just as likely that >> it's operating on freed memory there or something. >> >> But none of the code touches refcounting for that bo, and I really >> don't see how I messed up anything there. >> >> I seem to be able to reproduce it if I add a hack though, can you test >> if you get the exact same issues if you apply this patch? > Your patch doesn't apply unfortunately: > > markus@x4 linux % patch -p1 --dry-run < ~/maarten.patch > checking file drivers/gpu/drm/ttm/ttm_bo.c > Hunk #1 succeeded at 512 with fuzz 1. > Hunk #6 FAILED at 814. > 1 out of 6 hunks FAILED > markus@x4 linux % git describe > v3.7-10833-g752451f > markus@x4 linux % It applies on top of the regressed commit. It should probably not be too hard to make it apply manually on whatever you're using. But the real fix will be "drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling", which I cc'd you on. The patch I posted earlier in this thread will just aggressively stress test the codepath. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: > Fix regression introduced by 85b144f860176 Thanks for the catch and patch. Also please add the commit summary to make the commit message self contained? The problem description would also be nice. > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf Message-ID: <20121217182752.GA351@x4> > --- > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index 0bf66f9..9f85418 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > ttm_buffer_object *bo, >* at this point the buffer should be dead, so >* no new sync objects can be attached. >*/ > - sync_obj = driver->sync_obj_ref(&bo->sync_obj); > + sync_obj = driver->sync_obj_ref(bo->sync_obj); Any idea, why this only had an impact for one person so far? > spin_unlock(&bdev->fence_lock); > > atomic_set(&bo->reserved, 0); 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/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel wrote: > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: >> Fix regression introduced by 85b144f860176 > > Thanks for the catch and patch. > > Also please add the commit summary to make the commit message self > contained? > > The problem description would also be nice. > >> Signed-off-by: Maarten Lankhorst >> Reported-by: Markus Trippelsdorf > Message-ID: <20121217182752.GA351@x4> > >> --- >> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c >> index 0bf66f9..9f85418 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c >> @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct >> ttm_buffer_object *bo, >>* at this point the buffer should be dead, so >>* no new sync objects can be attached. >>*/ >> - sync_obj = driver->sync_obj_ref(&bo->sync_obj); >> + sync_obj = driver->sync_obj_ref(bo->sync_obj); > > Any idea, why this only had an impact for one person so far? There are several radeon bugs from drm-next 3.8 that may be ultimately related to this. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel > wrote: > > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: > >> Fix regression introduced by 85b144f860176 > > > > Thanks for the catch and patch. > > > > Also please add the commit summary to make the commit message self > > contained? > > > > The problem description would also be nice. > > > >> Signed-off-by: Maarten Lankhorst > >> Reported-by: Markus Trippelsdorf > > Message-ID: <20121217182752.GA351@x4> > > > >> --- > >> > >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > >> index 0bf66f9..9f85418 100644 > >> --- a/drivers/gpu/drm/ttm/ttm_bo.c > >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c > >> @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > >> ttm_buffer_object *bo, > >>* at this point the buffer should be dead, so > >>* no new sync objects can be attached. > >>*/ > >> - sync_obj = driver->sync_obj_ref(&bo->sync_obj); > >> + sync_obj = driver->sync_obj_ref(bo->sync_obj); > > > > Any idea, why this only had an impact for one person so far? > > There are several radeon bugs from drm-next 3.8 that may be ultimately > related to this. This patch fixes the kernel BUG, but now I get these errors in my Xorg.log: [23.092] [mi] Increasing EQ size to 512 to prevent dropped events. (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] (EE) 1: /usr/bin/X (mieqEnqueue+0x21b) [0x56615b] (EE) 2: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] (EE) 3: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] (EE) 6: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x428c) [0x7ff8f250528c] (EE) 7: /usr/bin/X (0x40+0x71cd8) [0x471cd8] (EE) 8: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] (EE) 9: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] (EE) 10: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] (EE) 11: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] (EE) 12: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) [0x7ff8f246cbdf] (EE) 13: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) [0x7ff8f25107bf] (EE) 14: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] (EE) 15: /usr/bin/X (_CallCallbacks+0x34) [0x438894] (EE) 16: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] (EE) 17: /usr/bin/X (0x40+0x33aa1) [0x433aa1] (EE) 18: /usr/bin/X (0x40+0x230cd) [0x4230cd] (EE) 19: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] (EE) 20: /usr/bin/X (0x40+0x22c09) [0x422c09] (EE) (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. (EE) [mi] EQ overflow continuing. 100 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] (EE) 2: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] (EE) 3: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x428c) [0x7ff8f250528c] (EE) 6: /usr/bin/X (0x40+0x71cd8) [0x471cd8] (EE) 7: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] (EE) 8: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] (EE) 9: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] (EE) 10: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] (EE) 11: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) [0x7ff8f246cbdf] (EE) 12: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) [0x7ff8f25107bf] (EE) 13: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] (EE) 14: /usr/bin/X (_CallCallbacks+0x34) [0x438894] (EE) 15: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] (EE) 16: /usr/bin/X (0x40+0x33aa1) [0x433aa1] (EE) 17: /usr/bin/X (0x40+0x230cd) [0x4230cd] (EE) 18: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] (EE) 19: /usr/bin/X (0x40+0x22c09) [0x422c09] (EE) (EE) [mi] EQ overflow continuing. 200 events have been dropped. And the pictures get distorted on the test-webpage when I scroll up and down, see: http://trippelsdorf.de/bad.png -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart wrote: > Hi Jani, > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >> I can see the need for a framework for DSI panels and such (in fact Tomi >> and I have talked about it like 2-3 years ago already!) but what is the >> story for HDMI and DP? In particular, what's the relationship between >> DRM and CDF here? Is there a world domination plan to switch the DRM >> drivers to use this framework too? ;) Do you have some rough plans how >> DRM and CDF should work together in general? > > There's always a world domination plan, isn't there ? :-) > > I certainly want CDF to be used by DRM (or more accurately KMS). That's what > the C stands for, common refers to sharing panel and other display entity > drivers between FBDEV, KMS and V4L2. > > I currently have no plan to expose CDF internals to userspace through the KMS > API. We might have to do so later if the hardware complexity grows in such a > way that finer control than what KMS provides needs to be exposed to > userspace, but I don't think we're there yet. The CDF API will thus only be > used internally in the kernel by display controller drivers. The KMS core > might get functions to handle common display entity operations, but the bulk > of the work will be in the display controller drivers to start with. We will > then see what can be abstracted in KMS helper functions. > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF > API. That's just a thought for now, I haven't tried to implement them, but it > would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. > > Do you have thoughts to share on this topic ? It just seems to me that, at least from a DRM/KMS perspective, adding another layer (=CDF) for HDMI or DP (or legacy outputs) would be overengineering it. They are pretty well standardized, and I don't see there would be a need to write multiple display drivers for them. Each display controller has one, and can easily handle any chip specific requirements right there. It's my gut feeling that an additional framework would just get in the way. Perhaps there could be more common HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, but that's another thing. So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM perspective? Or, put another way, is it more of an alternative to using DRM? Please enlighten me if there's some real benefit here that I fail to see! For DSI panels (or DSI-to-whatever bridges) it's of course another story. You typically need a panel specific driver. And here I see the main point of the whole CDF: decoupling display controllers and the panel drivers, and sharing panel (and converter chip) specific drivers across display controllers. Making it easy to write new drivers, as there would be a model to follow. I'm definitely in favour of coming up with some framework that would tackle that. BR, Jani. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > Hi Laurent - > > On Tue, 18 Dec 2012, Laurent Pinchart > wrote: >> Hi Jani, >> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>> I can see the need for a framework for DSI panels and such (in fact Tomi >>> and I have talked about it like 2-3 years ago already!) but what is the >>> story for HDMI and DP? In particular, what's the relationship between >>> DRM and CDF here? Is there a world domination plan to switch the DRM >>> drivers to use this framework too? ;) Do you have some rough plans how >>> DRM and CDF should work together in general? >> >> There's always a world domination plan, isn't there ? :-) >> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >> the C stands for, common refers to sharing panel and other display entity >> drivers between FBDEV, KMS and V4L2. >> >> I currently have no plan to expose CDF internals to userspace through the KMS >> API. We might have to do so later if the hardware complexity grows in such a >> way that finer control than what KMS provides needs to be exposed to >> userspace, but I don't think we're there yet. The CDF API will thus only be >> used internally in the kernel by display controller drivers. The KMS core >> might get functions to handle common display entity operations, but the bulk >> of the work will be in the display controller drivers to start with. We will >> then see what can be abstracted in KMS helper functions. >> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >> API. That's just a thought for now, I haven't tried to implement them, but it >> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >> >> Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! fwiw, I think there are at least a couple cases where multiple SoC's have the same HDMI IP block. And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF is appropriate for HDMI drivers. Although trying to keep this all independent of DRM (as opposed to just something similar to what drivers/gpu/i2c is today) seems a bit overkill for me. Being able to use the helpers in drm and avoiding an extra layer of translation seems like the better option to me. So my vote would be drivers/gpu/cdf. BR, -R > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. > > > BR, > Jani. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.19 at 15:54 +0100, Markus Trippelsdorf wrote: > On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > > And the pictures get distorted on the test-webpage when I scroll up and > down, see: > http://trippelsdorf.de/bad.png The picture distortion issue is caused by: commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb Author: Dave Airlie Date: Fri Dec 14 21:04:46 2012 +1000 radeon: fix regression with eviction since evict caching changes Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d drm/radeon: use cached memory when evicting for vram on non agp evicting from TTM would try and evict to TTM instead of system, not so good. This should fix: https://bugs.freedesktop.org/show_bug.cgi?id=58272 Signed-off-by: Dave Airlie Signed-off-by: Maarten Lankhorst Signed-off-by: Alex Deucher Reverting the commit above "fixes" the problem. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
v2: Check the original hole not the adjusted as the coloring may confuse
us when later searching for the overlapping nodes. Also make sure that
we do apply the range restriction and color adjustment in the same
order for both scanning, searching and insertion.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 45 +
include/drm/drm_mm.h |2 +-
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b751b8e..5847669 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -244,11 +244,13 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
BUG_ON(!hole_node->hole_follows || node->allocated);
- if (mm->color_adjust)
- mm->color_adjust(hole_node, color, &adj_start, &adj_end);
-
if (adj_start < start)
adj_start = start;
+ if (adj_end > end)
+ adj_end = end;
+
+ if (mm->color_adjust)
+ mm->color_adjust(hole_node, color, &adj_start, &adj_end);
if (alignment) {
unsigned tmp = adj_start % alignment;
@@ -519,7 +521,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -546,7 +548,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -565,8 +567,7 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
+ unsigned long adj_start, adj_end;
mm->scanned_blocks++;
@@ -583,14 +584,8 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
node->node_list.next = &mm->prev_scanned_node->node_list;
mm->prev_scanned_node = node;
- hole_start = drm_mm_hole_node_start(prev_node);
- hole_end = drm_mm_hole_node_end(prev_node);
-
- adj_start = hole_start;
- adj_end = hole_end;
-
- if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ adj_start = hole_start = drm_mm_hole_node_start(prev_node);
+ adji_end = hole_end = drm_mm_hole_node_end(prev_node);
if (mm->scan_check_range) {
if (adj_start < mm->scan_start)
@@ -599,11 +594,14 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
adj_end = mm->scan_end;
}
+ if (mm->color_adjust)
+ mm->color_adjust(prev_node, mm->scan_color,
+adj_start, adj_end);
+
if (check_free_hole(adj_start, adj_end,
mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -639,19 +637,10 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
node_list);
prev_node->hole_follows = node->scanned_preceeds_hole;
- INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+return (__drm_mm_hole_node_end(node) > mm->scan_hit_start &&
+node->start < mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index cd45365..58b8979 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned long scan_size;
unsigned long scan_hit_s
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
v2: Check the original hole not the adjusted as the coloring may confuse
us when later searching for the overlapping nodes. Also make sure that
we do apply the range restriction and color adjustment in the same
order for both scanning, searching and insertion.
v3: Send the version that was actually tested.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 45 +
include/drm/drm_mm.h |2 +-
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b751b8e..e6fce66 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -244,11 +244,13 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
BUG_ON(!hole_node->hole_follows || node->allocated);
- if (mm->color_adjust)
- mm->color_adjust(hole_node, color, &adj_start, &adj_end);
-
if (adj_start < start)
adj_start = start;
+ if (adj_end > end)
+ adj_end = end;
+
+ if (mm->color_adjust)
+ mm->color_adjust(hole_node, color, &adj_start, &adj_end);
if (alignment) {
unsigned tmp = adj_start % alignment;
@@ -519,7 +521,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -546,7 +548,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -565,8 +567,7 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
+ unsigned long adj_start, adj_end;
mm->scanned_blocks++;
@@ -583,14 +584,8 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
node->node_list.next = &mm->prev_scanned_node->node_list;
mm->prev_scanned_node = node;
- hole_start = drm_mm_hole_node_start(prev_node);
- hole_end = drm_mm_hole_node_end(prev_node);
-
- adj_start = hole_start;
- adj_end = hole_end;
-
- if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ adj_start = hole_start = drm_mm_hole_node_start(prev_node);
+ adj_end = hole_end = drm_mm_hole_node_end(prev_node);
if (mm->scan_check_range) {
if (adj_start < mm->scan_start)
@@ -599,11 +594,14 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
adj_end = mm->scan_end;
}
+ if (mm->color_adjust)
+ mm->color_adjust(prev_node, mm->scan_color,
+&adj_start, &adj_end);
+
if (check_free_hole(adj_start, adj_end,
mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -639,19 +637,10 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
node_list);
prev_node->hole_follows = node->scanned_preceeds_hole;
- INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+return (__drm_mm_hole_node_end(node) > mm->scan_hit_start &&
+node->start < mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index cd45365..58b8979 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned
[PATCH] drm/radeon: add support for MEM_WRITE packet
From: Jerome Glisse
To make it easier to debug some lockup from userspace add support
to MEM_WRITE packet.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
drivers/gpu/drm/radeon/r600_cs.c | 29 +
drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
3 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 74c6b42..5cea852 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2654,6 +2654,35 @@ static int evergreen_packet3_check(struct
radeon_cs_parser *p,
ib[idx+4] = upper_32_bits(offset) & 0xff;
}
break;
+ case PACKET3_MEM_WRITE:
+ {
+ u64 offset;
+
+ if (pkt->count != 3) {
+ DRM_ERROR("bad MEM_WRITE (invalid count)\n");
+ return -EINVAL;
+ }
+ r = evergreen_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
+ return -EINVAL;
+ }
+ offset = radeon_get_ib_value(p, idx+0);
+ offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) << 32UL;
+ if (offset & 0x7) {
+ DRM_ERROR("bad MEM_WRITE (address not qwords
aligned)\n");
+ return -EINVAL;
+ }
+ if ((offset + 8) > radeon_bo_size(reloc->robj)) {
+ DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx, 0x%lx\n",
+ offset + 8, radeon_bo_size(reloc->robj));
+ return -EINVAL;
+ }
+ offset += reloc->lobj.gpu_offset;
+ ib[idx+0] = offset;
+ ib[idx+1] = upper_32_bits(offset) & 0xff;
+ break;
+ }
case PACKET3_COPY_DW:
if (pkt->count != 4) {
DRM_ERROR("bad COPY_DW (invalid count)\n");
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 0be768b..9ea13d0 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2294,6 +2294,35 @@ static int r600_packet3_check(struct radeon_cs_parser *p,
ib[idx+4] = upper_32_bits(offset) & 0xff;
}
break;
+ case PACKET3_MEM_WRITE:
+ {
+ u64 offset;
+
+ if (pkt->count != 3) {
+ DRM_ERROR("bad MEM_WRITE (invalid count)\n");
+ return -EINVAL;
+ }
+ r = r600_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
+ return -EINVAL;
+ }
+ offset = radeon_get_ib_value(p, idx+0);
+ offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) << 32UL;
+ if (offset & 0x7) {
+ DRM_ERROR("bad MEM_WRITE (address not qwords
aligned)\n");
+ return -EINVAL;
+ }
+ if ((offset + 8) > radeon_bo_size(reloc->robj)) {
+ DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx, 0x%lx\n",
+ offset + 8, radeon_bo_size(reloc->robj));
+ return -EINVAL;
+ }
+ offset += reloc->lobj.gpu_offset;
+ ib[idx+0] = offset;
+ ib[idx+1] = upper_32_bits(offset) & 0xff;
+ break;
+ }
case PACKET3_COPY_DW:
if (pkt->count != 4) {
DRM_ERROR("bad COPY_DW (invalid count)\n");
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 9b1a727..ff75934 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -68,9 +68,10 @@
* 2.25.0 - eg+: new info request for num SE and num SH
* 2.26.0 - r600-eg: fix htile size computation
* 2.27.0 - r600-SI: Add CS ioctl support for async DMA
+ * 2.28.0 - r600-eg: Add MEM_WRITE packet support
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 27
+#define KMS_DRIVER_MINOR 28
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Op 19-12-12 15:18, Maarten Lankhorst schreef: > Fix regression introduced by 85b144f860176 > > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf > Hey Paul Menzel, I just wanted to have the fix out asap, and had to leave right after. Updated commit message below: Fix regression introduced by 85b144f860176 "drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3" Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase refcount on &bo->sync_obj instead of bo->sync_obj. The compiler didn't complain since sync_obj_ref takes a void pointer, so it was still valid c. This could result in lockups, memory corruptions, and warnings like these when graphics card VRAM usage is high: [ cut here ] WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40() Hardware name: System Product Name Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174 Call Trace: [] ? warn_slowpath_common+0x74/0xb0 [] ? radeon_fence_ref+0x2c/0x40 [] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 [] ? ttm_mem_evict_first+0x1dc/0x2a0 [] ? ttm_bo_man_get_node+0x62/0xb0 [] ? ttm_bo_mem_space+0x28e/0x340 [] ? ttm_bo_move_buffer+0xfc/0x170 [] ? kmem_cache_alloc+0xb2/0xc0 [] ? ttm_bo_validate+0x95/0x110 [] ? ttm_bo_init+0x2ec/0x3b0 [] ? radeon_bo_create+0x18a/0x200 [] ? radeon_bo_clear_va+0x40/0x40 [] ? radeon_gem_object_create+0x92/0x160 [] ? radeon_gem_create_ioctl+0x6c/0x150 [] ? radeon_gem_object_free+0x2f/0x40 [] ? drm_ioctl+0x420/0x4f0 [] ? radeon_gem_pwrite_ioctl+0x20/0x20 [] ? do_vfs_ioctl+0x2e4/0x4e0 [] ? vfs_read+0x118/0x160 [] ? sys_ioctl+0x4c/0xa0 [] ? sys_read+0x51/0xa0 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf Message-ID: <20121217182752.GA351@x4> --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0bf66f9..9f85418 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo, * at this point the buffer should be dead, so * no new sync objects can be attached. */ - sync_obj = driver->sync_obj_ref(&bo->sync_obj); + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); atomic_set(&bo->reserved, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: add support for MEM_WRITE packet
On Wed, Dec 19, 2012 at 12:26 PM, wrote:
> From: Jerome Glisse
>
> To make it easier to debug some lockup from userspace add support
> to MEM_WRITE packet.
>
> Signed-off-by: Jerome Glisse
Looks good to me. Added to my fixes queue.
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
> drivers/gpu/drm/radeon/r600_cs.c | 29 +
> drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
> 3 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 74c6b42..5cea852 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -2654,6 +2654,35 @@ static int evergreen_packet3_check(struct
> radeon_cs_parser *p,
> ib[idx+4] = upper_32_bits(offset) & 0xff;
> }
> break;
> + case PACKET3_MEM_WRITE:
> + {
> + u64 offset;
> +
> + if (pkt->count != 3) {
> + DRM_ERROR("bad MEM_WRITE (invalid count)\n");
> + return -EINVAL;
> + }
> + r = evergreen_cs_packet_next_reloc(p, &reloc);
> + if (r) {
> + DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
> + return -EINVAL;
> + }
> + offset = radeon_get_ib_value(p, idx+0);
> + offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) <<
> 32UL;
> + if (offset & 0x7) {
> + DRM_ERROR("bad MEM_WRITE (address not qwords
> aligned)\n");
> + return -EINVAL;
> + }
> + if ((offset + 8) > radeon_bo_size(reloc->robj)) {
> + DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx,
> 0x%lx\n",
> + offset + 8, radeon_bo_size(reloc->robj));
> + return -EINVAL;
> + }
> + offset += reloc->lobj.gpu_offset;
> + ib[idx+0] = offset;
> + ib[idx+1] = upper_32_bits(offset) & 0xff;
> + break;
> + }
> case PACKET3_COPY_DW:
> if (pkt->count != 4) {
> DRM_ERROR("bad COPY_DW (invalid count)\n");
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 0be768b..9ea13d0 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -2294,6 +2294,35 @@ static int r600_packet3_check(struct radeon_cs_parser
> *p,
> ib[idx+4] = upper_32_bits(offset) & 0xff;
> }
> break;
> + case PACKET3_MEM_WRITE:
> + {
> + u64 offset;
> +
> + if (pkt->count != 3) {
> + DRM_ERROR("bad MEM_WRITE (invalid count)\n");
> + return -EINVAL;
> + }
> + r = r600_cs_packet_next_reloc(p, &reloc);
> + if (r) {
> + DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
> + return -EINVAL;
> + }
> + offset = radeon_get_ib_value(p, idx+0);
> + offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) <<
> 32UL;
> + if (offset & 0x7) {
> + DRM_ERROR("bad MEM_WRITE (address not qwords
> aligned)\n");
> + return -EINVAL;
> + }
> + if ((offset + 8) > radeon_bo_size(reloc->robj)) {
> + DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx,
> 0x%lx\n",
> + offset + 8, radeon_bo_size(reloc->robj));
> + return -EINVAL;
> + }
> + offset += reloc->lobj.gpu_offset;
> + ib[idx+0] = offset;
> + ib[idx+1] = upper_32_bits(offset) & 0xff;
> + break;
> + }
> case PACKET3_COPY_DW:
> if (pkt->count != 4) {
> DRM_ERROR("bad COPY_DW (invalid count)\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 9b1a727..ff75934 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -68,9 +68,10 @@
> * 2.25.0 - eg+: new info request for num SE and num SH
> * 2.26.0 - r600-eg: fix htile size computation
> * 2.27.0 - r600-SI: Add CS ioctl support for async DMA
> + * 2.28.0 - r600-eg: Add MEM_WRITE packet support
> */
> #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 27
> +#define KMS_DRIVER_MINOR 28
> #define KMS_DRIVER_PATCHLEVEL 0
> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> int radeon_driver_unload_kms(struct drm_device *dev);
> --
> 1.7.11.7
>
> ___
Re: [PATCH 02/10] drm/doc: integrate drm_crtc.c kerneldoc
On Tue, Dec 18, 2012 at 10:25:05PM +0100, Daniel Vetter wrote:
> And do a quick pass to adjust them to the last few (years?) of changes
> ...
>
> This time actually compile-tested ;-)
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl |4 ++
> drivers/gpu/drm/drm_crtc.c | 92
> +++-
> 2 files changed, 48 insertions(+), 48 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4ee2304..caab791 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -321,6 +326,7 @@ EXPORT_SYMBOL(drm_framebuffer_unreference);
>
> /**
> * drm_framebuffer_reference - incr the fb refcnt
Maybe improve the comment here while you're at it. The function name is
more verbose/readable than the comment :)
> + * @fb: framebuffer
> */
> void drm_framebuffer_reference(struct drm_framebuffer *fb)
> {
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Dear Maarten, Am Mittwoch, den 19.12.2012, 18:21 +0100 schrieb Maarten Lankhorst: > Op 19-12-12 15:18, Maarten Lankhorst schreef: > > Fix regression introduced by 85b144f860176 > > > > Signed-off-by: Maarten Lankhorst > > Reported-by: Markus Trippelsdorf > I just wanted to have the fix out asap, and had to leave right after. I see. Sorry for my message then! > Updated commit message below: Awesome! By the way, you can add --- 8< --- below the message and the patch with commit message and `git am --scissors` will leave out the reply in the commit message. > Fix regression introduced by 85b144f860176 > "drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3" > > Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase > refcount on &bo->sync_obj instead of bo->sync_obj. > > The compiler didn't complain since sync_obj_ref takes a void pointer, > so it was still valid c. > > This could result in lockups, memory corruptions, and warnings like > these when graphics card VRAM usage is high: > > [ cut here ] > WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40() > Hardware name: System Product Name > Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174 > Call Trace: > [] ? warn_slowpath_common+0x74/0xb0 > [] ? radeon_fence_ref+0x2c/0x40 > [] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 > [] ? ttm_mem_evict_first+0x1dc/0x2a0 > [] ? ttm_bo_man_get_node+0x62/0xb0 > [] ? ttm_bo_mem_space+0x28e/0x340 > [] ? ttm_bo_move_buffer+0xfc/0x170 > [] ? kmem_cache_alloc+0xb2/0xc0 > [] ? ttm_bo_validate+0x95/0x110 > [] ? ttm_bo_init+0x2ec/0x3b0 > [] ? radeon_bo_create+0x18a/0x200 > [] ? radeon_bo_clear_va+0x40/0x40 > [] ? radeon_gem_object_create+0x92/0x160 > [] ? radeon_gem_create_ioctl+0x6c/0x150 > [] ? radeon_gem_object_free+0x2f/0x40 > [] ? drm_ioctl+0x420/0x4f0 > [] ? radeon_gem_pwrite_ioctl+0x20/0x20 > [] ? do_vfs_ioctl+0x2e4/0x4e0 > [] ? vfs_read+0x118/0x160 > [] ? sys_ioctl+0x4c/0xa0 > [] ? sys_read+0x51/0xa0 > [] ? system_call_fastpath+0x16/0x1b > > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf > Message-ID: <20121217182752.GA351@x4> > --- > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index 0bf66f9..9f85418 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > ttm_buffer_object *bo, >* at this point the buffer should be dead, so >* no new sync objects can be attached. >*/ > - sync_obj = driver->sync_obj_ref(&bo->sync_obj); > + sync_obj = driver->sync_obj_ref(bo->sync_obj); > spin_unlock(&bdev->fence_lock); > > atomic_set(&bo->reserved, 0); Acked-by: Paul Menzel 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
[Bug 35396] [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE
https://bugs.freedesktop.org/show_bug.cgi?id=35396 --- Comment #1 from Fabio Pedretti --- Is this still an issue? -- 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 41659] Weird unit rendering on SpringRTS
https://bugs.freedesktop.org/show_bug.cgi?id=41659 --- Comment #9 from Fabio Pedretti --- Is this still an issue? -- 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 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=44327 --- Comment #1 from Fabio Pedretti --- Is this still an issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fan control in nouveau driver with geforce 9600gt
> Here you go :) > > I managed to reproduce the issue. Please test this patch! Okay switching to automatic mode when pwm1 == 100 now gradually (in a few seconds, it is not cut down to 35 suddenly) lowers it down to 35. Switching to automatic mode while in manual mode doesn't make the pwm increase until 100. It seems okay I think. (Another point, Shouldn't we expect that the pwm is set to full power back again when I disable thermal management? Currently when I echo 0 to pwm1_enable, the fan power stays the same, e.g. 35 for example.) You can add a for me for a future reference. Thanks! Ozan Çağlayan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the >>> opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, >>> Marcus >>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >>> inviting me to Connect and providing a venue to discuss this topic. >>> >> >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane > but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. > > CDF or some sort of mechanism to share panel drivers between drivers > is useful. Keeping it within drm, is probably a good idea, if nothing > else to simplify re-use of helper fxns (like avi-infoframe stuff, for > example) and avoid dealing with merging changes across multiple trees. > Treating them more like shared libraries and less like sub-devices > which can be dynamically loaded/unloaded (ie. they should be not built > as separate modules or suspend/resumed or probed/removed independently > of the master driver) is a really good idea to avoid uncovering nasty > synchronization issues later (remove vs modeset or pageflip) or > surprising userspace in bad ways. > >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx > > BR, > -R > >> Dave. >> ___ >> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae wrote: > > > 2012/12/18 Daniel Vetter >> >> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote: >> >> The other thing I'd like you guys to do is kill the idea of fbdev and >> >> v4l drivers that are "shared" with the drm codebase, really just >> >> implement fbdev and v4l on top of the drm layer, some people might >> >> think this is some sort of maintainer thing, but really nothing else >> >> makes sense, and having these shared display frameworks just to avoid >> >> having using drm/kms drivers seems totally pointless. Fix the drm >> >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> >> framework because our previous 3 frameworks didn't work out doesn't >> >> seem like a situation I want to get behind too much. >> > >> > yeah, let's not have multiple frameworks to do the same thing.. For >> > fbdev, it is pretty clear that it is a dead end. For v4l2 >> > (subdev+mcf), it is perhaps bit more flexible when it comes to random >> > arbitrary hw pipelines than kms. But to take advantage of that, your >> > userspace isn't going to be portable anyways, so you might as well use >> > driver specific properties/ioctls. But I tend to think that is more >> > useful for cameras. And from userspace perspective, kms planes are >> > less painful to use for output than v4l2, so lets stick to drm/kms for >> > output (and not try to add camera/capture support to kms).. k, thx >> >> Yeah, I guess having a v4l device also exported by the same driver >> that exports the drm interface might make sense in some cases. But in >> many cases I think the video part is just an independent IP block and >> shuffling data around with dma-buf is all we really need. So yeah, I >> guess sharing display resources between v4l and drm kms driver should >> be a last resort option, since coordination (especially if it's >> supposed to be somewhat dynamic) will be extremely hairy. > > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. Actually, > in case of Exynos, some guys tried to duplicate eDP driver into exynos drm > framework in same issue. If you're talking about us, this is misleading, as we didn't try to duplicate the eDP driver. What we did is remove it from driver/video and put it in DRM. The reason for that is that it's not needed for fbdev, since KMS helpers let you implement fbdev. So we can just remove all the exynos graphics support from drivers/video since it becomes obsolete with the KMS fbdev helpers. And everything can be in DRM. And later, we can remove the multiple platform drivers from DRM as well, since they're not needed either. Stéphane > So I think the best way is to avoid duplicating > codes and resolve ordering issue such as s/r operations between all the > various components. > > And the below is my opinion, > > > - > Display > Controller-CDF---|MIPI-DSI/DBI---LCD > Panel| > > - > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms based > specific drivers like now. And each driver calls some interfaces of CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)--pm > runtime(fb)fb_blank--mipi and lcd > dpms(drm kms)pm runtime(drm > kms)--fb_blank--mipi and lcd > > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm kms > based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)---pm > runtime(fb)fb blank---mipi and lcd > s/r(drm kms)dpms(drm kms)---pm runtime(drm > kms)--fb_blank--mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. > > Thanks, > Inki Dae > > >> >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48
[Bug 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=44327 --- Comment #2 from Pavel Ondračka --- (In reply to comment #1) > Is this still an issue? This is still an issue with latest mesa git. -- 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 v2 0/2] drm/omap: Add PM and OMAP5 support
First patch adds PM capabilities for omapdrm. Second patch adds OMAP5 support to DMM driver component. Series was build tested and based on linux-next. v2: Updated commit msg for PM patch Andy Gross (2): drm/omap: Add PM capabilities drm/omap: Add OMAP5 support drivers/staging/omapdrm/omap_dmm_priv.h |5 + drivers/staging/omapdrm/omap_dmm_tiler.c | 159 ++ drivers/staging/omapdrm/omap_drv.c | 14 +++ drivers/staging/omapdrm/omap_drv.h |4 + drivers/staging/omapdrm/omap_gem.c | 28 + drivers/staging/omapdrm/tcm.h|2 + 6 files changed, 169 insertions(+), 43 deletions(-) -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omap: Add OMAP5 support
Add support for OMAP5 processor. The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
size.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_priv.h |5 +
drivers/staging/omapdrm/omap_dmm_tiler.c | 127 +++--
drivers/staging/omapdrm/tcm.h|2 +
3 files changed, 90 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h
b/drivers/staging/omapdrm/omap_dmm_priv.h
index 273ec12..58bcd6a 100644
--- a/drivers/staging/omapdrm/omap_dmm_priv.h
+++ b/drivers/staging/omapdrm/omap_dmm_priv.h
@@ -118,6 +118,11 @@ struct pat {
#define DESCR_SIZE 128
#define REFILL_BUFFER_SIZE ((4 * 128 * 256) + (3 * DESCR_SIZE))
+/* For OMAP5, a fixed offset is added to all Y coordinates for 1D buffers.
+ * This is used in programming to address the upper portion of the LUT
+*/
+#define OMAP5_LUT_OFFSET 128
+
struct dmm;
struct dmm_txn {
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index c42c5e5..3910215 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -213,6 +213,11 @@ static void dmm_txn_append(struct dmm_txn *txn, struct
pat_area *area,
txn->last_pat->next_pa = (uint32_t)pat_pa;
pat->area = *area;
+
+ /* adjust Y coordinates based off of container parameters */
+ pat->area.y0 += engine->tcm->y_offset;
+ pat->area.y1 += engine->tcm->y_offset;
+
pat->ctrl = (struct pat_ctrl){
.start = 1,
.lut_id = engine->tcm->lut_id,
@@ -622,6 +627,11 @@ static int omap_dmm_probe(struct platform_device *dev)
omap_dmm->lut_width = ((pat_geom >> 16) & 0xF) << 5;
omap_dmm->lut_height = ((pat_geom >> 24) & 0xF) << 5;
+ /* increment LUT by one if on OMAP5 */
+ /* LUT has twice the height, and is split into a separate container */
+ if (omap_dmm->lut_height != omap_dmm->container_height)
+ omap_dmm->num_lut++;
+
/* initialize DMM registers */
writel(0x, omap_dmm->base + DMM_PAT_VIEW__0);
writel(0x, omap_dmm->base + DMM_PAT_VIEW__1);
@@ -701,6 +711,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* init containers */
+ /* Each LUT is associated with a TCM (container manager). We use the
+ lut_id to denote the lut_id used to identify the correct LUT for
+ programming during reill operations */
for (i = 0; i < omap_dmm->num_lut; i++) {
omap_dmm->tcm[i] = sita_init(omap_dmm->container_width,
omap_dmm->container_height,
@@ -717,13 +730,23 @@ static int omap_dmm_probe(struct platform_device *dev)
/* assign access mode containers to applicable tcm container */
/* OMAP 4 has 1 container for all 4 views */
+ /* OMAP 5 has 2 containers, 1 for 2D and 1 for 1D */
containers[TILFMT_8BIT] = omap_dmm->tcm[0];
containers[TILFMT_16BIT] = omap_dmm->tcm[0];
containers[TILFMT_32BIT] = omap_dmm->tcm[0];
- containers[TILFMT_PAGE] = omap_dmm->tcm[0];
+
+ if (omap_dmm->container_height != omap_dmm->lut_height) {
+ /* second LUT is used for PAGE mode. Programming must use
+ y offset that is added to all y coordinates. LUT id is still
+ 0, because it is the same LUT, just the upper 128 lines */
+ containers[TILFMT_PAGE] = omap_dmm->tcm[1];
+ omap_dmm->tcm[1]->y_offset = OMAP5_LUT_OFFSET;
+ omap_dmm->tcm[1]->lut_id = 0;
+ } else {
+ containers[TILFMT_PAGE] = omap_dmm->tcm[0];
+ }
area = (struct tcm_area) {
- .is2d = true,
.tcm = NULL,
.p1.x = omap_dmm->container_width - 1,
.p1.y = omap_dmm->container_height - 1,
@@ -835,64 +858,81 @@ int tiler_map_show(struct seq_file *s, void *arg)
int h_adj;
int w_adj;
unsigned long flags;
+ int lut_idx;
+
if (!omap_dmm) {
/* early return if dmm/tiler device is not initialized */
return 0;
}
- h_adj = omap_dmm->lut_height / ydiv;
- w_adj = omap_dmm->lut_width / xdiv;
+ h_adj = omap_dmm->container_height / ydiv;
+ w_adj = omap_dmm->container_width / xdiv;
- map = kzalloc(h_adj * sizeof(*map), GFP_KERNEL);
- global_map = kzalloc((w_adj + 1) * h_adj, GFP_KERNEL);
+ map = kmalloc(h_adj * sizeof(*map), GFP_KERNEL);
+ global_map = kmalloc((w_adj + 1) * h_adj, GFP_KERNEL);
if (!map || !global_map)
goto error;
- memset(global_map, ' ', (w_adj + 1) * h_adj);
- for (i = 0; i < omap_dmm->lut_height; i++) {
- map[i] = globa
[PATCH 1/2] drm/omap: Add PM capabilities
Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT. We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.
On resume, the DMM resume handler will first reprogram the LUT to point
to the dummy page. The subsequent resume handler in the omapdrm will call
into the DMM and reprogram each of the buffer objects. This will ensure
that all of the necessary objects will be pinned into the DMM properly.
Order of suspend/resume handlers is done by device creation. We create
the DMM device before the omapdrm, so the correct order is maintained.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_tiler.c | 34 ++
drivers/staging/omapdrm/omap_drv.c | 14
drivers/staging/omapdrm/omap_drv.h |4 +++
drivers/staging/omapdrm/omap_gem.c | 28
4 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 59bf438..c42c5e5 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -903,12 +903,46 @@ error:
}
#endif
+#ifdef CONFIG_PM
+static int omap_dmm_resume(struct device *dev)
+{
+ struct tcm_area area;
+ int i;
+
+ if (!omap_dmm)
+ return -ENODEV;
+
+ area = (struct tcm_area) {
+ .is2d = true,
+ .tcm = NULL,
+ .p1.x = omap_dmm->container_width - 1,
+ .p1.y = omap_dmm->container_height - 1,
+ };
+
+ /* initialize all LUTs to dummy page entries */
+ for (i = 0; i < omap_dmm->num_lut; i++) {
+ area.tcm = omap_dmm->tcm[i];
+ if (fill(&area, NULL, 0, 0, true))
+ dev_err(dev, "refill failed");
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops omap_dmm_pm_ops = {
+ .resume = omap_dmm_resume,
+};
+#endif
+
struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+#ifdef CONFIG_PM
+ .pm = &omap_dmm_pm_ops,
+#endif
},
};
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index ae5ecc2..d246f85 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -368,6 +368,9 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
/* well, limp along without an fbdev.. maybe X11 will work? */
}
+ /* store off drm_device for use in pm ops */
+ dev_set_drvdata(dev->dev, dev);
+
drm_kms_helper_poll_init(dev);
return 0;
@@ -393,6 +396,8 @@ static int dev_unload(struct drm_device *dev)
kfree(dev->dev_private);
dev->dev_private = NULL;
+ dev_set_drvdata(dev->dev, NULL);
+
return 0;
}
@@ -558,10 +563,19 @@ static int pdev_remove(struct platform_device *device)
return 0;
}
+#ifdef CONFIG_PM
+static const struct dev_pm_ops omapdrm_pm_ops = {
+ .resume = omap_gem_resume,
+};
+#endif
+
struct platform_driver pdev = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &omapdrm_pm_ops,
+#endif
},
.probe = pdev_probe,
.remove = pdev_remove,
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index cd1f22b..f921027 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -135,6 +135,10 @@ void omap_gem_describe(struct drm_gem_object *obj, struct
seq_file *m);
void omap_gem_describe_objects(struct list_head *list, struct seq_file *m);
#endif
+#ifdef CONFIG_PM
+int omap_gem_resume(struct device *dev);
+#endif
+
int omap_irq_enable_vblank(struct drm_device *dev, int crtc);
void omap_irq_disable_vblank(struct drm_device *dev, int crtc);
irqreturn_t omap_irq_handler(DRM_IRQ_ARGS);
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index c38992b..08f1e292 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -964,6 +964,34 @@ void *omap_gem_vaddr(struct drm_gem_object *obj)
return omap_obj->vaddr;
}
+#ifdef CONFIG_PM
+/* re-pin objects in DMM in resume path: */
+int omap_gem_resume(struct device *dev)
+{
+ struct drm_device *drm_dev = dev_get_drvdata(dev);
+ struct omap_drm_private *priv = drm_dev->dev_private;
+ struct omap_gem_object *omap_obj;
+ int ret = 0;
+
+ list_for_each_entry(omap_obj, &priv->obj_list, mm_list) {
+ i
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
On 12/18/2012 04:33 PM, Paul Menzel wrote: > I am sorry for the trouble caused by this. As a work around, you could > also specify the QUIRKS on the Linux command line. Those patches never made it in. I gave up when I was asked to rewrite everything without using unions. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] tegradrm fixes and cleanups
Some small fixes and cleanups for the tegradrm driver. This is potentially 3.8-fixes material. Lucas Stach (6): drm: tegra: fix front_porch <-> back_porch mixup drm: tegra: don't leave clients host1x member uninitialized drm: tegra: protect DC register access with mutex drm: tegra: remove redundant tegra2_tmds_config entry drm: tegra: clean out old gem prototypes drm: tegra: program only one window during modeset drivers/gpu/drm/tegra/dc.c | 24 ++-- drivers/gpu/drm/tegra/drm.h| 19 +-- drivers/gpu/drm/tegra/hdmi.c | 25 ++--- drivers/gpu/drm/tegra/host1x.c | 2 ++ 4 Dateien geändert, 27 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm: tegra: fix front_porch <-> back_porch mixup
Fixes wrong picture offset observed when using HDMI output with a
Technisat HD TV.
Signed-off-by: Lucas Stach
Acked-by: Mark Zhang
Tested-by: Mark Zhang
---
Captions are a bit confusing here. As the porch is always relative to
the sync pulse, the left picture margin is actually the back_porch.
---
drivers/gpu/drm/tegra/dc.c | 8
drivers/gpu/drm/tegra/hdmi.c | 6 +++---
2 Dateien geändert, 7 Zeilen hinzugefügt(+), 7 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0744103..54683e4 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -102,12 +102,12 @@ static int tegra_dc_set_timings(struct tegra_dc *dc,
((mode->hsync_end - mode->hsync_start) << 0);
tegra_dc_writel(dc, value, DC_DISP_SYNC_WIDTH);
- value = ((mode->vsync_start - mode->vdisplay) << 16) |
- ((mode->hsync_start - mode->hdisplay) << 0);
- tegra_dc_writel(dc, value, DC_DISP_BACK_PORCH);
-
value = ((mode->vtotal - mode->vsync_end) << 16) |
((mode->htotal - mode->hsync_end) << 0);
+ tegra_dc_writel(dc, value, DC_DISP_BACK_PORCH);
+
+ value = ((mode->vsync_start - mode->vdisplay) << 16) |
+ ((mode->hsync_start - mode->hdisplay) << 0);
tegra_dc_writel(dc, value, DC_DISP_FRONT_PORCH);
value = (mode->vdisplay << 16) | mode->hdisplay;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index ab40164..81ea934 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -479,7 +479,7 @@ static void tegra_hdmi_setup_avi_infoframe(struct
tegra_hdmi *hdmi,
return;
}
- h_front_porch = mode->htotal - mode->hsync_end;
+ h_front_porch = mode->hsync_start - mode->hdisplay;
memset(&frame, 0, sizeof(frame));
frame.r = HDMI_AVI_R_SAME;
@@ -634,8 +634,8 @@ static int tegra_output_hdmi_enable(struct tegra_output
*output)
pclk = mode->clock * 1000;
h_sync_width = mode->hsync_end - mode->hsync_start;
- h_front_porch = mode->htotal - mode->hsync_end;
- h_back_porch = mode->hsync_start - mode->hdisplay;
+ h_back_porch = mode->htotal - mode->hsync_end;
+ h_front_porch = mode->hsync_start - mode->hdisplay;
err = regulator_enable(hdmi->vdd);
if (err < 0) {
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm: tegra: don't leave clients host1x member uninitialized
No real problem for now, as nothing is using this, but leaving it unitialized is asking for trouble later on. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/host1x.c | 2 ++ 1 Datei geändert, 2 Zeilen hinzugefügt(+) diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1x.c index bdb97a5..5d17b11 100644 --- a/drivers/gpu/drm/tegra/host1x.c +++ b/drivers/gpu/drm/tegra/host1x.c @@ -239,6 +239,8 @@ int host1x_register_client(struct host1x *host1x, struct host1x_client *client) } } + client->host1x = host1x; + return 0; } -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm: tegra: protect DC register access with mutex
Window properties are programmed through a shared aperture and have to
happen atomically. Also we do the read-update-write dance on some of the
shared regs.
To make sure that different functions don't stumble over each other
protect the register access with a mutex.
Signed-off-by: Lucas Stach
---
We could probably make this a bit more fine grained, but this would add
some complexity and I don't really see a win there for now.
---
drivers/gpu/drm/tegra/dc.c | 13 +
drivers/gpu/drm/tegra/drm.h | 1 +
2 Dateien geändert, 14 Zeilen hinzugefügt(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 54683e4..b256574 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -171,6 +171,8 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
return err;
}
+ mutex_lock(&dc->regs_mutex);
+
/* program display mode */
tegra_dc_set_timings(dc, mode);
@@ -269,6 +271,8 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
tegra_dc_writel(dc, 0xff00, DC_WIN_BLEND_NOKEY);
tegra_dc_writel(dc, 0xff00, DC_WIN_BLEND_1WIN);
+ mutex_unlock(&dc->regs_mutex);
+
return 0;
}
@@ -287,6 +291,8 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc)
else
syncpt = SYNCPT_VBLANK0;
+ mutex_lock(&dc->regs_mutex);
+
/* initialize display controller */
tegra_dc_writel(dc, 0x0100, DC_CMD_GENERAL_INCR_SYNCPT_CNTRL);
tegra_dc_writel(dc, 0x100 | syncpt, DC_CMD_CONT_SYNCPT_VSYNC);
@@ -320,6 +326,8 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc)
value = VBLANK_INT | WIN_A_UF_INT | WIN_B_UF_INT | WIN_C_UF_INT;
tegra_dc_writel(dc, value, DC_CMD_INT_ENABLE);
+
+ mutex_unlock(&dc->regs_mutex);
}
static void tegra_crtc_commit(struct drm_crtc *crtc)
@@ -330,6 +338,8 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
update_mask = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
+ mutex_lock(&dc->regs_mutex);
+
tegra_dc_writel(dc, update_mask << 8, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_INT_ENABLE);
@@ -341,6 +351,8 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
tegra_dc_writel(dc, value, DC_CMD_INT_MASK);
tegra_dc_writel(dc, update_mask, DC_CMD_STATE_CONTROL);
+
+ mutex_unlock(&dc->regs_mutex);
}
static void tegra_crtc_load_lut(struct drm_crtc *crtc)
@@ -747,6 +759,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
return -ENOMEM;
INIT_LIST_HEAD(&dc->list);
+ mutex_init(&dc->regs_mutex);
dc->dev = &pdev->dev;
dc->clk = devm_clk_get(&pdev->dev, NULL);
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 3a843a7..eae1f56 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -84,6 +84,7 @@ struct tegra_dc {
struct clk *clk;
+ struct mutex regs_mutex;
void __iomem *regs;
int irq;
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm: tegra: remove redundant tegra2_tmds_config entry
The 720p and 1080p entries are completely redundant, as we are matching
the table entries against <=pclk.
Also generalize the comment, as we are using those table entries even
when driving other modes than the standard TV ones.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 19 +++
1 Datei geändert, 3 Zeilen hinzugefügt(+), 16 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 81ea934..e060c7e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -149,7 +149,7 @@ struct tmds_config {
};
static const struct tmds_config tegra2_tmds_config[] = {
- { /* 480p modes */
+ { /* slow pixel clock modes */
.pclk = 2700,
.pll0 = SOR_PLL_BG_V17_S(3) | SOR_PLL_ICHPMP(1) |
SOR_PLL_RESISTORSEL | SOR_PLL_VCOCAP(0) |
@@ -163,21 +163,8 @@ static const struct tmds_config tegra2_tmds_config[] = {
DRIVE_CURRENT_LANE1(DRIVE_CURRENT_7_125_mA) |
DRIVE_CURRENT_LANE2(DRIVE_CURRENT_7_125_mA) |
DRIVE_CURRENT_LANE3(DRIVE_CURRENT_7_125_mA),
- }, { /* 720p modes */
- .pclk = 7425,
- .pll0 = SOR_PLL_BG_V17_S(3) | SOR_PLL_ICHPMP(1) |
- SOR_PLL_RESISTORSEL | SOR_PLL_VCOCAP(1) |
- SOR_PLL_TX_REG_LOAD(3),
- .pll1 = SOR_PLL_TMDS_TERM_ENABLE | SOR_PLL_PE_EN,
- .pe_current = PE_CURRENT0(PE_CURRENT_6_0_mA) |
- PE_CURRENT1(PE_CURRENT_6_0_mA) |
- PE_CURRENT2(PE_CURRENT_6_0_mA) |
- PE_CURRENT3(PE_CURRENT_6_0_mA),
- .drive_current = DRIVE_CURRENT_LANE0(DRIVE_CURRENT_7_125_mA) |
- DRIVE_CURRENT_LANE1(DRIVE_CURRENT_7_125_mA) |
- DRIVE_CURRENT_LANE2(DRIVE_CURRENT_7_125_mA) |
- DRIVE_CURRENT_LANE3(DRIVE_CURRENT_7_125_mA),
- }, { /* 1080p modes */
+ },
+ { /* high pixel clock modes */
.pclk = UINT_MAX,
.pll0 = SOR_PLL_BG_V17_S(3) | SOR_PLL_ICHPMP(1) |
SOR_PLL_RESISTORSEL | SOR_PLL_VCOCAP(1) |
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm: tegra: clean out old gem prototypes
There is no gem.c anymore, those functions are implemented by the drm_cma_helpers now. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/drm.h | 18 -- 1 Datei geändert, 18 Zeilen entfernt(-) diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h index eae1f56..71e61f2 100644 --- a/drivers/gpu/drm/tegra/drm.h +++ b/drivers/gpu/drm/tegra/drm.h @@ -205,24 +205,6 @@ extern int tegra_output_parse_dt(struct tegra_output *output); extern int tegra_output_init(struct drm_device *drm, struct tegra_output *output); extern int tegra_output_exit(struct tegra_output *output); -/* from gem.c */ -extern struct tegra_gem_object *tegra_gem_alloc(struct drm_device *drm, - size_t size); -extern int tegra_gem_handle_create(struct drm_device *drm, - struct drm_file *file, size_t size, - unsigned long flags, uint32_t *handle); -extern int tegra_gem_dumb_create(struct drm_file *file, struct drm_device *drm, -struct drm_mode_create_dumb *args); -extern int tegra_gem_dumb_map_offset(struct drm_file *file, -struct drm_device *drm, uint32_t handle, -uint64_t *offset); -extern int tegra_gem_dumb_destroy(struct drm_file *file, - struct drm_device *drm, uint32_t handle); -extern int tegra_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma); -extern int tegra_gem_init_object(struct drm_gem_object *obj); -extern void tegra_gem_free_object(struct drm_gem_object *obj); -extern struct vm_operations_struct tegra_gem_vm_ops; - /* from fb.c */ extern int tegra_drm_fb_init(struct drm_device *drm); extern void tegra_drm_fb_exit(struct drm_device *drm); -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm: tegra: program only one window during modeset
The intention is to program exactly WIN_A, not WIN_A and possibly others. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/dc.c | 3 +-- 1 Datei geändert, 1 Zeile hinzugefügt(+), 2 Zeilen entfernt(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index b256574..3475bd9 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -223,8 +223,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc, win.stride = crtc->fb->pitches[0]; /* program window registers */ - value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER); - value |= WINDOW_A_SELECT; + value = WINDOW_A_SELECT; tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER); tegra_dc_writel(dc, win.fmt, DC_WIN_COLOR_DEPTH); -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm urgent fix
Hi Linus, just a single urgent regression fix, seeing a few wierd behaviours I'd like not to persist. Dave. The following changes since commit 55bde6b1442fed8af67b92d21acce67db454c9f9: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-12-16 06:05:03 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to 0953e76e91f4b6206cef50bd680696dc6bf1ef99: drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling (2012-12-20 07:46:20 +1000) Maarten Lankhorst (1): drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Common Display Framework-T
Hi Tomi, On Wednesday 19 December 2012 16:53:10 Tomi Valkeinen wrote: > On 2012-12-19 15:21, Laurent Pinchart wrote: > > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > >> Hi, > >> > >> I have been testing Common Display Framework on OMAP, and making changes > >> that I've discussed in the posts I've sent in reply to the CDF series > >> from Laurent. While my CDF code is rather hacky and not at all ready, I > >> wanted to post the code for comments and also as a reference code to my > >> posts. > >> > >> So here is CDF-T (Tomi-edition =). > > > > We've discussed your approach extensively face-to-face today so I won't > > review the patches in detail, but I will instead summarize our discussion > > to make sure we understood each other (and let other developers jump in). > > I have some comments =). But mostly it looks good. Thanks :-) > > For the purpose of this discussion the term "display controller driver" > > (or just "display controller") refer to both the low-level driver layer > > that communicates directly with the display controller hardware, and to > > the higher- level driver layer that implements and exposes the userspace > > API (FBDEV, KMS and/or V4L). Those layers can be implemented in multiple > > kernel modules (such as in the OMAP DSS case, with omapdss for the > > low-level layer and omapdrm, omapfb and omapvout for the API-level layer) > > or a single kernel module. > > > > Control model > > - > > > > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > model.png shows the CDF control model. > > > > The panel object depicted on the figure doesn't need to be a panel in the > > stricter sense but could be any chain of off-SoC (both on-board or > > off-board) display entities. It however helps thinking about it as a > > panel and doesn't hurt the model. > > I don't think it needs to be off-soc. The dispc and the panel in the > image could be any two components, in- or off-soc. That's correct, whether the components are on-SoC or off-SoC doesn't matter here. > > The panel is controlled through abstract control requests. Those requests > > are used to retrieve panel information (such as the physical size, the > > supported video modes, EDID information, ...), set the panel > > configuration (such as the active video timings) or control the panel > > operation state (enabling/disabling the panel, controlling panel blanking > > and power management, ...). They are exposed by the panel using function > > pointers, and called by other kernel components in response to userspace > > requests (through the FBDEV, KMS or V4L2 APIs) or in-kernel events (for > > instance hotplug notifications). > > > > In response to the control requests the panel driver will communicate with > > the panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., > > not shown on the figure) and will control the video stream it receives on > > its input. > > > > The panel is connected at the hardware level to a video source (shown as a > > green hashed rectangle) that provides it with a video stream. The video > > stream flows from the video source to the panel and is directly > > controlled by its source, as shown by the green arrow from the display > > controller to the video stream. The video source exposes stream control > > operations as function pointers that are used by the panel to control the > > video stream, as shown by the green arrow from the panel to the video > > source. > > > > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > model-2.png shows the call flow across entities when the panel is a > > pipeline made of more than a single entity. In this case the SoC (on the > > left of the dashed line) outputs a video stream on a DSI bus connected to > > a DSI to LVDS transmitter. The output of the DSI to LVDS transmitter is > > connected to an LVDS panel (or, more accurately, an LVDS panel module > > made of an LVDS panel controller and a panel). > > Here also I don't see any reason to separate in- or off-soc components. > I think the call from DISPC, which now goes to the transmitter, should > first go to the DPI/DSI block. Whether the DPI/DSI block is in- or > off-soc should be irrelevant regarding CDF. Agreed. > > The transmitter and panel module are seen by the display controller and > > userspace API implementations as a single entity that exposes control > > request operations and controls its input video stream. When a control > > request is > > I don't like the sound of this. I think the CDF shouldn't care how the > userspace API is implemented. There's no reason in CDF level to separate > in- or out-soc entities, nor expose only one entity. If DRM requires > mapping DRM's crtc, encoder and connector to, respectively, dispc, > DPI/DSI, the-rest, it should be able to do that, but CDF shouldn't force > that model. > > Of course, the implementor of the particular SoC display driver could decide > to use one
Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 43 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if
it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf->lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file->private_data;
+ BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf->ops->vmap)
- return dmabuf->ops->vmap(dmabuf);
- return NULL;
+ if (!dmabuf->ops->vmap)
+ return NULL;
+
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->vmapping_counter) {
+ dmabuf->vmapping_counter++;
+ BUG_ON(!dmabuf->vmap_ptr);
+ ptr = dmabuf->vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf->vmap_ptr);
+
+ ptr = dmabuf->ops->vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf->vmap_ptr = ptr;
+ dmabuf->vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dmabuf->vmapping_counter > 0);
This should be BUG_ON(vmapping_counter == 0);
Otherwise, this seems to work fine.
--
Aaron
+ BUG_ON(dmabuf->vmap_ptr != vaddr);
+
+ mutex_lock(&dmabuf->lock);
+ if (--dmabuf->vmapping_counter == 0) {
+ if (dmabuf->ops->vunmap)
+ dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->vmap_ptr = NULL;
+ }
+ mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+ unsigned vmapping_counter;
+ void *vmap_ptr;
void *priv;
};
___
dri-devel mailing l
Re: Fan control in nouveau driver with geforce 9600gt
On 19/12/2012 20:39, Ozan Çağlayan wrote: Here you go :) I managed to reproduce the issue. Please test this patch! Okay switching to automatic mode when pwm1 == 100 now gradually (in a few seconds, it is not cut down to 35 suddenly) lowers it down to 35. Switching to automatic mode while in manual mode doesn't make the pwm increase until 100. Yep, exactly what I meant to :) It seems okay I think. (Another point, Shouldn't we expect that the pwm is set to full power back again when I disable thermal management? Currently when I echo 0 to pwm1_enable, the fan power stays the same, e.g. 35 for example.) So, we had some discussions within the nouveau community about this and we decided that 0 would mean, no updates on the current status. Anything against it? You can add a for me for a future reference. Sure, let me send a pull-request to the nouveau maintainer then :) Thanks! Ozan Çağlayan Thanks for your testing and feedback! Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/prime: keep a reference from the handle to exported dma-buf
From: Dave Airlie
This is likely the simplest solution to the problem, and seems
to work fine.
When we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.
I'd like to refrain from too much in this patch as I'd like it to
go to stable, so future cleanups should look at maybe reducing
the obj storing two pointers etc.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem.c | 2 +-
drivers/gpu/drm/drm_prime.c | 34 ++
include/drm/drmP.h | 1 +
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 24efae4..e221b7b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -209,7 +209,7 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj,
struct drm_file *filp)
obj->import_attach->dmabuf);
}
if (obj->export_dma_buf) {
- drm_prime_remove_imported_buf_handle(&filp->prime,
+ drm_prime_remove_exported_buf_handle(&filp->prime,
obj->export_dma_buf);
}
}
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..583d126 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,6 +62,8 @@ struct drm_prime_member {
uint32_t handle;
};
+static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
+
int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle, uint32_t flags,
int *prime_fd)
@@ -104,8 +106,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
/* if we've exported this buffer the cheat and add it to the import list
* so we get the correct handle back
*/
- ret = drm_prime_add_imported_buf_handle(&file_priv->prime,
- obj->export_dma_buf, handle);
+ ret = drm_prime_add_exported_buf_handle(&file_priv->prime,
+ obj->export_dma_buf, handle);
if (ret) {
drm_gem_object_unreference_unlocked(obj);
mutex_unlock(&file_priv->prime.lock);
@@ -307,7 +309,7 @@ void drm_prime_destroy_file_private(struct
drm_prime_file_private *prime_fpriv)
}
EXPORT_SYMBOL(drm_prime_destroy_file_private);
-int drm_prime_add_imported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
+static int drm_prime_add_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
{
struct drm_prime_member *member;
@@ -320,6 +322,18 @@ int drm_prime_add_imported_buf_handle(struct
drm_prime_file_private *prime_fpriv
list_add(&member->entry, &prime_fpriv->head);
return 0;
}
+
+int drm_prime_add_imported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
+{
+ return drm_prime_add_buf_handle(prime_fpriv, dma_buf, handle);
+}
+
+static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
+{
+ /* take a reference to the buf handle for this case */
+ get_dma_buf(dma_buf);
+ return drm_prime_add_buf_handle(prime_fpriv, dma_buf, handle);
+}
EXPORT_SYMBOL(drm_prime_add_imported_buf_handle);
int drm_prime_lookup_imported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t *handle)
@@ -336,7 +350,7 @@ int drm_prime_lookup_imported_buf_handle(struct
drm_prime_file_private *prime_fp
}
EXPORT_SYMBOL(drm_prime_lookup_imported_buf_handle);
-void drm_prime_remove_imported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf)
+static void drm_prime_remove_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf)
{
struct drm_prime_member *member, *safe;
@@ -349,4 +363,16 @@ void drm_prime_remove_imported_buf_handle(struct
drm_prime_file_private *prime_f
}
mutex_unlock(&prime_fpriv->lock);
}
+
+void drm_prime_remove_imported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf)
+{
+ drm_prime_remove_buf_handle(prime_fpriv, dma_buf);
+}
EXPORT_SYMBOL(drm_prime_remove_imported_buf_handle);
+
+void drm_prime_remove_exported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf)
+{
+ drm_prime_remove_buf_handle(prime_fpriv, dma_buf);
+ dma_buf_put(dma_buf);
+}
+EXPORT_SYMBOL(drm_prime_remove_exported_buf_handle);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fad21c9..6dcfa2e 100644
--- a/include/drm/drmP.h
+++ b/include/d
Re: [PATCH] drm/prime: drop reference on imported dma-buf come from gem
> In drm_prime_handle_to_fd_ioctl(), flags is cleared to only support > DRM_CLOEXEC but in gem_prime_export() callbacks of each driver, it uses > 0600 as flags for dma_buf_export() like following. > > return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, 0600); Oops, nice catch, radeon and nouveau did the correct thing here, I'll send a patch to fix that. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix flags in dma buf exporting
From: Dave Airlie
As pointed out by Seung-Woo Kim this should have been
passing flags like nouveau/radeon have.
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 773ef77..7be4241 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -226,7 +226,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_device
*dev,
{
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
- return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, 0600);
+ return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, flags);
}
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
--
1.8.0.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Add debugfs support
On Fri, Dec 14, 2012 at 7:36 PM, wrote: > From: Sumit Semwal > > Add debugfs support to make it easier to print debug information > about the dma-buf buffers. > I like thie idea, /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function ‘dma_buf_describe’: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:563:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long int’ [-Wformat] /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: At top level: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:528:123: warning: ‘dma_buf_init’ defined but not used [-Wunused-function] not sure my compiler does though. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm: tegra: protect DC register access with mutex
OK, you add a mutex in a tegra_dc structure. But I think there is no
parallel scenario while we operate on a dc. AFAIK, the functions which
you add mutex protection are called by drm sequentially(except for
function "tegra_crtc_load_lut" I'm not very clear about that).
So could you give us an example?
Mark
On 12/20/2012 05:38 AM, Lucas Stach wrote:
> Window properties are programmed through a shared aperture and have to
> happen atomically. Also we do the read-update-write dance on some of the
> shared regs.
> To make sure that different functions don't stumble over each other
> protect the register access with a mutex.
>
> Signed-off-by: Lucas Stach
> ---
> We could probably make this a bit more fine grained, but this would add
> some complexity and I don't really see a win there for now.
> ---
> drivers/gpu/drm/tegra/dc.c | 13 +
> drivers/gpu/drm/tegra/drm.h | 1 +
> 2 Dateien geändert, 14 Zeilen hinzugefügt(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 54683e4..b256574 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -171,6 +171,8 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> return err;
> }
>
> + mutex_lock(&dc->regs_mutex);
> +
> /* program display mode */
> tegra_dc_set_timings(dc, mode);
>
> @@ -269,6 +271,8 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> tegra_dc_writel(dc, 0xff00, DC_WIN_BLEND_NOKEY);
> tegra_dc_writel(dc, 0xff00, DC_WIN_BLEND_1WIN);
>
> + mutex_unlock(&dc->regs_mutex);
> +
> return 0;
> }
>
> @@ -287,6 +291,8 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc)
> else
> syncpt = SYNCPT_VBLANK0;
>
> + mutex_lock(&dc->regs_mutex);
> +
> /* initialize display controller */
> tegra_dc_writel(dc, 0x0100, DC_CMD_GENERAL_INCR_SYNCPT_CNTRL);
> tegra_dc_writel(dc, 0x100 | syncpt, DC_CMD_CONT_SYNCPT_VSYNC);
> @@ -320,6 +326,8 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc)
>
> value = VBLANK_INT | WIN_A_UF_INT | WIN_B_UF_INT | WIN_C_UF_INT;
> tegra_dc_writel(dc, value, DC_CMD_INT_ENABLE);
> +
> + mutex_unlock(&dc->regs_mutex);
> }
>
> static void tegra_crtc_commit(struct drm_crtc *crtc)
> @@ -330,6 +338,8 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
>
> update_mask = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>
> + mutex_lock(&dc->regs_mutex);
> +
> tegra_dc_writel(dc, update_mask << 8, DC_CMD_STATE_CONTROL);
>
> value = tegra_dc_readl(dc, DC_CMD_INT_ENABLE);
> @@ -341,6 +351,8 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
> tegra_dc_writel(dc, value, DC_CMD_INT_MASK);
>
> tegra_dc_writel(dc, update_mask, DC_CMD_STATE_CONTROL);
> +
> + mutex_unlock(&dc->regs_mutex);
> }
>
> static void tegra_crtc_load_lut(struct drm_crtc *crtc)
> @@ -747,6 +759,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> INIT_LIST_HEAD(&dc->list);
> + mutex_init(&dc->regs_mutex);
> dc->dev = &pdev->dev;
>
> dc->clk = devm_clk_get(&pdev->dev, NULL);
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 3a843a7..eae1f56 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -84,6 +84,7 @@ struct tegra_dc {
>
> struct clk *clk;
>
> + struct mutex regs_mutex;
> void __iomem *regs;
> int irq;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm: tegra: clean out old gem prototypes
We must forget about that. I believe no one read the header files while review. So thanks. :) Mark On 12/20/2012 05:38 AM, Lucas Stach wrote: > There is no gem.c anymore, those functions are implemented by the > drm_cma_helpers now. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/drm/tegra/drm.h | 18 -- > 1 Datei geändert, 18 Zeilen entfernt(-) > > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h > index eae1f56..71e61f2 100644 > --- a/drivers/gpu/drm/tegra/drm.h > +++ b/drivers/gpu/drm/tegra/drm.h > @@ -205,24 +205,6 @@ extern int tegra_output_parse_dt(struct tegra_output > *output); > extern int tegra_output_init(struct drm_device *drm, struct tegra_output > *output); > extern int tegra_output_exit(struct tegra_output *output); > > -/* from gem.c */ > -extern struct tegra_gem_object *tegra_gem_alloc(struct drm_device *drm, > - size_t size); > -extern int tegra_gem_handle_create(struct drm_device *drm, > -struct drm_file *file, size_t size, > -unsigned long flags, uint32_t *handle); > -extern int tegra_gem_dumb_create(struct drm_file *file, struct drm_device > *drm, > - struct drm_mode_create_dumb *args); > -extern int tegra_gem_dumb_map_offset(struct drm_file *file, > - struct drm_device *drm, uint32_t handle, > - uint64_t *offset); > -extern int tegra_gem_dumb_destroy(struct drm_file *file, > - struct drm_device *drm, uint32_t handle); > -extern int tegra_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma); > -extern int tegra_gem_init_object(struct drm_gem_object *obj); > -extern void tegra_gem_free_object(struct drm_gem_object *obj); > -extern struct vm_operations_struct tegra_gem_vm_ops; > - > /* from fb.c */ > extern int tegra_drm_fb_init(struct drm_device *drm); > extern void tegra_drm_fb_exit(struct drm_device *drm); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Add debugfs support
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie wrote: > On Fri, Dec 14, 2012 at 7:36 PM, wrote: >> From: Sumit Semwal >> >> Add debugfs support to make it easier to print debug information >> about the dma-buf buffers. >> I've attached two patches that make it work on my system, and fix the warnings, I've used it to debug some leaks I was seeing, feel free to squash these patches into the original patch. Dave. 0001-dma_buf-fix-debugfs-init.patch Description: Binary data 0002-dma-buf-fix-warning-in-seq_printf.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)
From: Dave Airlie
This is likely the simplest solution to the problem, and seems
to work fine.
When we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.
I'd like to refrain from too much in this patch as I'd like it to
go to stable, so future cleanups should look at maybe reducing
the obj storing two pointers etc.
v1.1: move export symbol line back up.
v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem.c | 2 +-
drivers/gpu/drm/drm_prime.c | 95 -
include/drm/drmP.h | 3 +-
3 files changed, 72 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 24efae4..e221b7b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -209,7 +209,7 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj,
struct drm_file *filp)
obj->import_attach->dmabuf);
}
if (obj->export_dma_buf) {
- drm_prime_remove_imported_buf_handle(&filp->prime,
+ drm_prime_remove_exported_buf_handle(&filp->prime,
obj->export_dma_buf);
}
}
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..a9ddea9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,6 +62,8 @@ struct drm_prime_member {
uint32_t handle;
};
+static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
+
int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle, uint32_t flags,
int *prime_fd)
@@ -69,6 +71,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_gem_object *obj;
void *buf;
int ret;
+ struct dma_buf *dmabuf;
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj)
@@ -77,41 +80,57 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
mutex_lock(&file_priv->prime.lock);
/* re-export the original imported object */
if (obj->import_attach) {
- get_dma_buf(obj->import_attach->dmabuf);
- *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
- drm_gem_object_unreference_unlocked(obj);
- mutex_unlock(&file_priv->prime.lock);
- return 0;
+ dmabuf = obj->import_attach->dmabuf;
+ goto out_have_obj;
}
if (obj->export_dma_buf) {
- get_dma_buf(obj->export_dma_buf);
- *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
+ dmabuf = obj->export_dma_buf;
+ goto out_have_obj;
+ }
+
+ buf = dev->driver->gem_prime_export(dev, obj, flags);
+ if (IS_ERR(buf)) {
+ /* normally the created dma-buf takes ownership of the ref,
+* but if that fails then drop the ref
+*/
drm_gem_object_unreference_unlocked(obj);
- } else {
- buf = dev->driver->gem_prime_export(dev, obj, flags);
- if (IS_ERR(buf)) {
- /* normally the created dma-buf takes ownership of the
ref,
-* but if that fails then drop the ref
-*/
- drm_gem_object_unreference_unlocked(obj);
- mutex_unlock(&file_priv->prime.lock);
- return PTR_ERR(buf);
- }
- obj->export_dma_buf = buf;
- *prime_fd = dma_buf_fd(buf, flags);
+ mutex_unlock(&file_priv->prime.lock);
+ return PTR_ERR(buf);
}
+ obj->export_dma_buf = buf;
+
/* if we've exported this buffer the cheat and add it to the import list
* so we get the correct handle back
*/
- ret = drm_prime_add_imported_buf_handle(&file_priv->prime,
- obj->export_dma_buf, handle);
+ ret = drm_prime_add_exported_buf_handle(&file_priv->prime,
+ obj->export_dma_buf, handle);
if (ret) {
drm_gem_object_unreference_unlocked(obj);
mutex_unlock(&file_priv->prime.lo
[Bug 43751] [TTM] Out of kernel memory
https://bugzilla.kernel.org/show_bug.cgi?id=43751 Alexey Neyman changed: What|Removed |Added CC||sti...@att.net --- Comment #5 from Alexey Neyman 2012-12-20 07:24:37 --- Same issue here: Also Nvidia 8600, on HP dv9700 laptop: 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8600M GS] (rev a1) The same problem easily reproduced by running easytag (GTK app) under KDE. Using Ubuntu 12.10, kernel 3.5.0. There were no such issue with Ubuntu 12.04 (kernel 3.2.0). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/exynos: fix flags in dma buf exporting
This patch fixes flags passed to dma buf exporting. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin.park --- I found exynos drm also sends wrong flag for dma buf exporting. So I send this based on drm-fixes branch. drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index fae1f2e..8cb8c56 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -185,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct drm_device *drm_dev, struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj); return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops, - exynos_gem_obj->base.size, 0600); + exynos_gem_obj->base.size, flags); } struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev, -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omap: fix flags in dma buf exporting
This patch fixes flags passed to dma buf exporting.
Signed-off-by: Seung-Woo Kim
Cc: Rob Clark
---
I found omap drm also sends wrong flag for dma buf exporting. So I send this
based on drm-fixes branch.
drivers/staging/omapdrm/omap_gem_dmabuf.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
b/drivers/staging/omapdrm/omap_gem_dmabuf.c
index c6f3ef6..e5ffe72 100644
--- a/drivers/staging/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c
@@ -194,7 +194,7 @@ struct dma_buf_ops omap_dmabuf_ops = {
struct dma_buf * omap_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags)
{
- return dma_buf_export(obj, &omap_dmabuf_ops, obj->size, 0600);
+ return dma_buf_export(obj, &omap_dmabuf_ops, obj->size, flags);
}
struct drm_gem_object * omap_gem_prime_import(struct drm_device *dev,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
unifying the vma offset managers
So a passing comment on irc from Daniel made me look at this, and cleaning up some surrounding things. This unifies the GEM/TTM vma offset managers around a single one based on the TTM one. There is also a patch to cleanup the GEM code after this, and one to clean up some bits of TTM also. I've tested it on an intel and a radeon machine and it appears to at least boot. Dave.
[PATCH 2/3] drm/gem: drop maplist from gem objects.
From: Dave Airlie
We currently don't need map_lists to store this information, with the new
encapsulation, just move the vma_offset object into the gem object.
In the future I'd guess we need per-filp vma offsets so this might make
it a bit cleaner to start from.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem.c | 44 -
drivers/gpu/drm/drm_gem_cma_helper.c| 4 +--
drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 ++---
drivers/gpu/drm/gma500/gem.c| 6 ++---
drivers/gpu/drm/i915/i915_gem.c | 8 +++---
drivers/gpu/drm/udl/udl_gem.c | 6 ++---
include/drm/drmP.h | 3 +--
7 files changed, 21 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 551352f..bb5ac23 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -304,11 +304,8 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
{
struct drm_device *dev = obj->dev;
struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->map_list;
- drm_vma_offset_destroy(&mm->vma_manager, &list->vma_offset);
- kfree(list->map);
- list->map = NULL;
+ drm_vma_offset_destroy(&mm->vma_manager, &obj->vma_offset);
}
EXPORT_SYMBOL(drm_gem_free_mmap_offset);
@@ -328,32 +325,10 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
{
struct drm_device *dev = obj->dev;
struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
int ret;
- /* Set the object up for mmap'ing */
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle = obj;
-
- ret = drm_vma_offset_setup(&mm->vma_manager, &list->vma_offset,
+ ret = drm_vma_offset_setup(&mm->vma_manager, &obj->vma_offset,
obj->size / PAGE_SIZE);
- if (ret)
- goto out_free_list;
-
- return 0;
-
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
return ret;
}
EXPORT_SYMBOL(drm_gem_create_mmap_offset);
@@ -642,10 +617,8 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
struct drm_file *priv = filp->private_data;
struct drm_device *dev = priv->minor->dev;
struct drm_gem_mm *mm = dev->mm_private;
- struct drm_local_map *map = NULL;
struct drm_gem_object *obj;
struct drm_vma_offset_node *offset_node;
- struct drm_map_list *list;
int ret = 0;
if (drm_device_is_unplugged(dev))
@@ -660,21 +633,14 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
return drm_mmap(filp, vma);
}
- list = container_of(offset_node, struct drm_map_list, vma_offset);
- map = list->map;
- if (!map ||
- ((map->flags & _DRM_RESTRICTED) && !capable(CAP_SYS_ADMIN))) {
- ret = -EPERM;
- goto out_unlock;
- }
+ obj = container_of(offset_node, struct drm_gem_object, vma_offset);
/* Check for valid size. */
- if (map->size < vma->vm_end - vma->vm_start) {
+ if (obj->size < vma->vm_end - vma->vm_start) {
ret = -EINVAL;
goto out_unlock;
}
- obj = map->handle;
if (!obj->dev->driver->gem_vm_ops) {
ret = -EINVAL;
goto out_unlock;
@@ -682,7 +648,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = obj->dev->driver->gem_vm_ops;
- vma->vm_private_data = map->handle;
+ vma->vm_private_data = (void *)obj;
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
/* Take a ref for this mapping of the object, so that the fault
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 43b485f..a567a6e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -29,7 +29,7 @@
static unsigned int get_gem_mmap_offset(struct drm_gem_object *obj)
{
- return (unsigned
int)drm_vma_node_offset_addr(&obj->map_list.vma_offset);
+ return (unsigned int)drm_vma_node_offset_addr(&obj->vma_offset);
}
static void drm_gem_cma_buf_destroy(struct drm_device *drm,
@@ -140,7 +140,7 @@ void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
{
struct drm_gem_cma_object *cma_obj;
- if (drm_vma_node_is_allocated(&obj->map_list.vma_offset))
+ if (drm_vma_node_is_allocated(&obj->vma_offset))
drm_gem_free_mmap_offset(gem_obj);
drm_gem_object_release(gem_obj);
diff --git a/driv
[PATCH 1/3] drm: create unified vma offset manager
From: Dave Airlie
So we have to offset manager implementations for dealing with VMA offsets.
GEM had one using the hash table, TTM had one using an rbtree,
I'd rather we just had one to rule them all, since ttm is using the rbtree
variant to allow sub mappings, to keep ABI we need to use that one.
This also adds a bunch of inline helpers to avoid gem/ttm poking around
inside the vma_offset objects. TTM needs a reset helper to remove a vma_offset
when it copies an object to another one for buffer moves. The helpers
also let drivers avoid the map_list.hash_key << PAGE_SHIFT nonsense.
TODO: check interactions with ttm vm_lock.
I've tested booted this on Intel Ironlake and AMD REDWOOD.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_gem.c | 54 +++-
drivers/gpu/drm/drm_gem_cma_helper.c| 4 +-
drivers/gpu/drm/drm_vma_offset_man.c| 149
drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 +-
drivers/gpu/drm/gma500/gem.c| 6 +-
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/ttm/ttm_bo.c| 74 +++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 86 --
drivers/gpu/drm/udl/udl_gem.c | 6 +-
include/drm/drmP.h | 8 +-
include/drm/drm_vma_offset_man.h| 58 +
include/drm/ttm/ttm_bo_api.h| 10 +--
include/drm/ttm/ttm_bo_driver.h | 3 +-
15 files changed, 291 insertions(+), 185 deletions(-)
create mode 100644 drivers/gpu/drm/drm_vma_offset_man.c
create mode 100644 include/drm/drm_vma_offset_man.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6f58c81..20a1eeb 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
- drm_trace_points.o drm_global.o drm_prime.o
+ drm_trace_points.o drm_global.o drm_prime.o drm_vma_offset_man.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 24efae4..551352f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -103,18 +103,11 @@ drm_gem_init(struct drm_device *dev)
dev->mm_private = mm;
- if (drm_ht_create(&mm->offset_hash, 12)) {
+ if (drm_vma_offset_man_init(&mm->vma_manager,
DRM_FILE_PAGE_OFFSET_START, DRM_FILE_PAGE_OFFSET_SIZE)) {
kfree(mm);
return -ENOMEM;
}
-
- if (drm_mm_init(&mm->offset_manager, DRM_FILE_PAGE_OFFSET_START,
- DRM_FILE_PAGE_OFFSET_SIZE)) {
- drm_ht_remove(&mm->offset_hash);
- kfree(mm);
- return -ENOMEM;
- }
-
+
return 0;
}
@@ -123,8 +116,7 @@ drm_gem_destroy(struct drm_device *dev)
{
struct drm_gem_mm *mm = dev->mm_private;
- drm_mm_takedown(&mm->offset_manager);
- drm_ht_remove(&mm->offset_hash);
+ drm_vma_offset_man_fini(&mm->vma_manager);
kfree(mm);
dev->mm_private = NULL;
}
@@ -314,8 +306,7 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
struct drm_gem_mm *mm = dev->mm_private;
struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
+ drm_vma_offset_destroy(&mm->vma_manager, &list->vma_offset);
kfree(list->map);
list->map = NULL;
}
@@ -352,34 +343,13 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
map->size = obj->size;
map->handle = obj;
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, false);
-
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
+ ret = drm_vma_offset_setup(&mm->vma_manager, &list->vma_offset,
+ obj->size / PAGE_SIZE);
+ if (ret)
goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
-
[PATCH 3/3] drm/ttm: drop addr_space_offset, use accessor
From: Dave Airlie
This uses the drm vm accessor to access the address space offset
rather than storing it separately.
When I boot tested this, it threw up a problem in the virtual unmapping code
where we unmap a mapping range from 0 unnecessairly, so this patch also
checks we have a mapping before calling the unmap_mapping_range.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ast/ast_main.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_main.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.h| 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 13 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
include/drm/ttm/ttm_bo_api.h | 1 -
9 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f668e6c..bb7e9d5 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -495,7 +495,7 @@ void ast_gem_free_object(struct drm_gem_object *obj)
static inline u64 ast_bo_mmap_offset(struct ast_bo *bo)
{
- return bo->bo.addr_space_offset;
+ return drm_vma_node_offset_addr(&bo->bo.vma_offset);
}
int
ast_dumb_mmap_offset(struct drm_file *file,
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 6a9b12e..1b21135 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -302,7 +302,7 @@ void cirrus_gem_free_object(struct drm_gem_object *obj)
static inline u64 cirrus_bo_mmap_offset(struct cirrus_bo *bo)
{
- return bo->bo.addr_space_offset;
+ return drm_vma_node_offset_addr(&bo->bo.vma_offset);
}
int
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 70dd3c5..f139008 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -357,7 +357,7 @@ void mgag200_gem_free_object(struct drm_gem_object *obj)
static inline u64 mgag200_bo_mmap_offset(struct mgag200_bo *bo)
{
- return bo->bo.addr_space_offset;
+ return drm_vma_node_offset_addr(&bo->bo.vma_offset);
}
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index e4188f2..e5c127a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -778,7 +778,7 @@ nouveau_display_dumb_map_offset(struct drm_file *file_priv,
gem = drm_gem_object_lookup(dev, file_priv, handle);
if (gem) {
struct nouveau_bo *bo = gem->driver_private;
- *poffset = bo->bo.addr_space_offset;
+ *poffset = drm_vma_node_offset_addr(&bo->bo.vma_offset);
drm_gem_object_unreference_unlocked(gem);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 8bf695c..6be9249 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -194,7 +194,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct
drm_gem_object *gem,
}
rep->size = nvbo->bo.mem.num_pages << PAGE_SHIFT;
- rep->map_handle = nvbo->bo.addr_space_offset;
+ rep->map_handle = drm_vma_node_offset_addr(&nvbo->bo.vma_offset);
rep->tile_mode = nvbo->tile_mode;
rep->tile_flags = nvbo->tile_flags;
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 5fc86b0..a661db5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -104,7 +104,7 @@ static inline unsigned radeon_bo_gpu_page_alignment(struct
radeon_bo *bo)
*/
static inline u64 radeon_bo_mmap_offset(struct radeon_bo *bo)
{
- return bo->tbo.addr_space_offset;
+ return drm_vma_node_offset_addr(&bo->tbo.vma_offset);
}
extern int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7f3596c..3f42621 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1596,12 +1596,13 @@ bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
- loff_t offset = (loff_t) bo->addr_space_offset;
- loff_t holelen = ((loff_t) bo->mem.num_pages) << PAGE_SHIFT;
- if (!bdev->dev_mapping)
- return;
- unmap_mapping_range(bdev->dev_mapping, offset, holelen, 1);
+ if (drm_vma_node_is_allocated(&bo->vma_offset) && bdev->dev_mapping) {
+ loff_t offset = (loff_t)
drm_vma_node_offset_addr(&bo->vma_offset);
+ loff_t holelen = ((loff_t) bo->mem.num_pages) << PAGE_SHIFT;
+
[proof-of-concept/rfc] per object file mmaps
The 2+3 patches are actually the code, the first was just a cleanup. Anyways the second patch describes it best, but I've taken the approach that we just need to keep track of what filp this object has had a handle created on, and block mmaps on it. We could also probably block a bit more explicitly in the driver respective mmap offset retrieval ioctls, however we need to block in mmap itself to stop people just picking misc address and trying them. It doesn't really add much now, but with render nodes where we have flink_to or fd passing it would be more useful. I've no idea if I'll get to do much more with this, so consider it an indication of how I'd like it done for someone else to run with :-) Dave.
[PATCH 1/3] drm/vma/gem/ttm: consolide unmapping range
From: Dave Airlie
This is just a cleanup, can probably do better, but at least it makes
the calls to the unmap_mapping_range consistent.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_vma_offset_man.c | 11 +++
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/ttm/ttm_bo.c | 8 ++--
include/drm/drm_vma_offset_man.h | 3 +++
4 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_vma_offset_man.c
b/drivers/gpu/drm/drm_vma_offset_man.c
index cf2e291..7456892 100644
--- a/drivers/gpu/drm/drm_vma_offset_man.c
+++ b/drivers/gpu/drm/drm_vma_offset_man.c
@@ -125,6 +125,17 @@ out_unlock:
}
EXPORT_SYMBOL(drm_vma_offset_setup);
+void drm_vma_unmap_mapping(struct address_space *dev_mapping,
+ struct drm_vma_offset_node *node)
+{
+ if (dev_mapping && drm_vma_node_is_allocated(node)) {
+ unmap_mapping_range(dev_mapping,
+ drm_vma_node_offset_addr(node),
+ node->num_pages << PAGE_SHIFT, 1);
+ }
+}
+EXPORT_SYMBOL(drm_vma_unmap_mapping);
+
int drm_vma_offset_man_init(struct drm_vma_offset_manager *man, uint64_t
file_page_offset, uint64_t size)
{
int ret;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 16f1b2c..8d28123 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1424,11 +1424,8 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
if (!obj->fault_mappable)
return;
- if (obj->base.dev->dev_mapping)
- unmap_mapping_range(obj->base.dev->dev_mapping,
-
(loff_t)drm_vma_node_offset_addr(&obj->base.vma_offset),
- obj->base.size, 1);
-
+ drm_vma_unmap_mapping(obj->base.dev->dev_mapping,
+ &obj->base.vma_offset);
obj->fault_mappable = false;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3f42621..2a7b6a6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1597,12 +1597,8 @@ void ttm_bo_unmap_virtual_locked(struct
ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
- if (drm_vma_node_is_allocated(&bo->vma_offset) && bdev->dev_mapping) {
- loff_t offset = (loff_t)
drm_vma_node_offset_addr(&bo->vma_offset);
- loff_t holelen = ((loff_t) bo->mem.num_pages) << PAGE_SHIFT;
-
- unmap_mapping_range(bdev->dev_mapping, offset, holelen, 1);
- }
+ drm_vma_unmap_mapping(bdev->dev_mapping,
+ &bo->vma_offset);
ttm_mem_io_free_vm(bo);
}
diff --git a/include/drm/drm_vma_offset_man.h b/include/drm/drm_vma_offset_man.h
index 4211c60..b8ef845 100644
--- a/include/drm/drm_vma_offset_man.h
+++ b/include/drm/drm_vma_offset_man.h
@@ -35,6 +35,9 @@ void drm_vma_offset_destroy(struct drm_vma_offset_manager
*man,
int drm_vma_offset_man_init(struct drm_vma_offset_manager *man, uint64_t
file_page_offset, uint64_t size);
void drm_vma_offset_man_fini(struct drm_vma_offset_manager *man);
+void drm_vma_unmap_mapping(struct address_space *dev_mapping,
+ struct drm_vma_offset_node *node);
+
static inline void drm_vma_node_reset(struct drm_vma_offset_node *node)
{
node->vm_node = NULL;
--
1.8.0.2
[PATCH 2/3] drm/ttm: add object per-file mmap validation
From: Dave Airlie
So instead of creating a whole set of per-file address spaces, and having
some sort of melt down in my understanding of the inode/address_space code,
I realised we could just keep a lot of filps that the object has been attached
to, or has had a handle created on.
At the moment this gives us nothing extra, since you can nearly always guess
the handles and gem open them, but in the future where we have fd passing
or flink to, then this should block other clients from mmaping objects they
haven't been explicitly given a handle for.
This just implements it in TTM for radeon/nouveau, vmwgfx and other drivers
would need updates as well. It might also be nice to try and consolidate
things a bit better.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_vma_offset_man.c | 43 +++
drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++
drivers/gpu/drm/radeon/radeon_gem.c | 7 ++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 15 +---
include/drm/drm_vma_offset_man.h | 18 ++-
5 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_vma_offset_man.c
b/drivers/gpu/drm/drm_vma_offset_man.c
index 7456892..ee2f425 100644
--- a/drivers/gpu/drm/drm_vma_offset_man.c
+++ b/drivers/gpu/drm/drm_vma_offset_man.c
@@ -91,6 +91,7 @@ int drm_vma_offset_setup(struct drm_vma_offset_manager *man,
{
int ret;
+ INIT_LIST_HEAD(&node->flist);
retry_pre_get:
ret = drm_mm_pre_get(&man->addr_space_mm);
if (unlikely(ret != 0))
@@ -158,3 +159,45 @@ void drm_vma_offset_man_fini(struct drm_vma_offset_manager
*man)
write_unlock(&man->vm_lock);
}
EXPORT_SYMBOL(drm_vma_offset_man_fini);
+
+int drm_vma_offset_node_add_file(struct drm_vma_offset_node *node,
+struct file *filp)
+{
+ struct drm_vma_offset_node_per_file *fnode;
+
+ fnode = kmalloc(sizeof(*fnode), GFP_KERNEL);
+ if (!fnode)
+ return -ENOMEM;
+
+ fnode->filp = filp;
+ list_add(&fnode->lhead, &node->flist);
+ return 0;
+}
+EXPORT_SYMBOL(drm_vma_offset_node_add_file);
+
+void drm_vma_offset_node_remove_file(struct drm_vma_offset_node *node,
+ struct file *filp)
+{
+ struct drm_vma_offset_node_per_file *fnode, *temp;
+
+ list_for_each_entry_safe(fnode, temp, &node->flist, lhead) {
+ if (fnode->filp == filp) {
+ list_del(&fnode->lhead);
+ kfree(fnode);
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(drm_vma_offset_node_remove_file);
+
+bool drm_vma_offset_node_valid_file(struct drm_vma_offset_node *node,
+ struct file *filp)
+{
+ struct drm_vma_offset_node_per_file *fnode;
+ list_for_each_entry(fnode, &node->flist, lhead) {
+ if (fnode->filp == filp)
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL(drm_vma_offset_node_valid_file);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 6be9249..8281f5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -74,6 +74,11 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_vma *vma;
int ret;
+ ret = drm_vma_offset_node_add_file(&nvbo->bo.vma_offset,
+ file_priv->filp);
+ if (ret)
+ return ret;
+
if (!cli->base.vm)
return 0;
@@ -111,6 +116,8 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_vma *vma;
int ret;
+ drm_vma_offset_node_remove_file(&nvbo->bo.vma_offset, file_priv->filp);
+
if (!cli->base.vm)
return;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index fe5c1f6..daba965 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -146,6 +146,12 @@ int radeon_gem_object_open(struct drm_gem_object *obj,
struct drm_file *file_pri
struct radeon_bo_va *bo_va;
int r;
+ /* allocate a file to bo */
+ r = drm_vma_offset_node_add_file(&rbo->tbo.vma_offset,
+file_priv->filp);
+ if (r)
+ return r;
+
if (rdev->family < CHIP_CAYMAN) {
return 0;
}
@@ -176,6 +182,7 @@ void radeon_gem_object_close(struct drm_gem_object *obj,
struct radeon_bo_va *bo_va;
int r;
+ drm_vma_offset_node_remove_file(&rbo->tbo.vma_offset, file_priv->filp);
if (rdev->family < CHIP_CAYMAN) {
return;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3e52e25..d111d3d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.
[PATCH 3/3] drm/gem: start adding support for per-file object mmaps
From: Dave Airlie
This adds the support for drivers that use the gem mmap call, they need
to specify DRIVER_GEM_MMAP in their feature set, so they get this behaviour.
This saves me adding 10 open/close handlers for now, if someone would like
to do that instead of midlayer, then I'd be happy to watch.
TODO: all other non-i915 drivers.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem.c | 17 +
drivers/gpu/drm/i915/i915_drv.c | 2 +-
include/drm/drmP.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bb5ac23..dbbd736 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -240,6 +240,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
drm_gem_remove_prime_handles(obj, filp);
+ if (drm_core_check_feature(dev, DRIVER_GEM_MMAP))
+ drm_vma_offset_node_remove_file(&obj->vma_offset, filp->filp);
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
@@ -280,9 +282,19 @@ again:
drm_gem_object_handle_reference(obj);
+ if (drm_core_check_feature(dev, DRIVER_GEM_MMAP)) {
+ ret = drm_vma_offset_node_add_file(&obj->vma_offset,
+ file_priv->filp);
+ if (ret) {
+ drm_gem_handle_delete(file_priv, *handlep);
+ return ret;
+ }
+ }
if (dev->driver->gem_open_object) {
ret = dev->driver->gem_open_object(obj, file_priv);
if (ret) {
+ if (drm_core_check_feature(dev, DRIVER_GEM_MMAP))
+
drm_vma_offset_node_remove_file(&obj->vma_offset, file_priv->filp);
drm_gem_handle_delete(file_priv, *handlep);
return ret;
}
@@ -633,6 +645,11 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
return drm_mmap(filp, vma);
}
+ if (drm_vma_offset_node_valid_file(offset_node, filp) == false) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
obj = container_of(offset_node, struct drm_gem_object, vma_offset);
/* Check for valid size. */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 530db83..a42cb8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,7 +1017,7 @@ static struct drm_driver driver = {
*/
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
- DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
+ DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
DRIVER_GEM_MMAP,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f7186e8..b6bce07 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -155,6 +155,7 @@ int drm_err(const char *func, const char *format, ...);
#define DRIVER_GEM 0x1000
#define DRIVER_MODESET 0x2000
#define DRIVER_PRIME 0x4000
+#define DRIVER_GEM_MMAP0x8000
#define DRIVER_BUS_PCI 0x1
#define DRIVER_BUS_PLATFORM 0x2
--
1.8.0.2
[PATCH 1/2] drm/exynos: hdmi: add support for extra permissable resolutions
On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote:
> On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma
> wrote:
>> Program the core and timing generator registers using the timing data
>> provided in drm_display_mode instead of using hardcoded configurations.
>> This allows us to support more standard resolutions like 640x480, 720x576
>> and 1680x1050. Additional PHY configs has been added to support extra
>> refresh rates.
>>
>> It also reduces the duplication of the timing data.
>>
>
> s/permissable/permissible/ in the subject
>
I noticed that later. I will change it.
>
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Sean Paul
>> Signed-off-by: Shirish S
>> Signed-off-by: Akshay Saraswat
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 1004
>> --
>> 1 files changed, 354 insertions(+), 650 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 68936e6..9afabe8 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -49,6 +49,8 @@
>> #define MAX_WIDTH 1920
>> #define MAX_HEIGHT 1080
>> #define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
>> +#define hdmi_v14_mode_found(c, w, h) (((hdmi_v14_find_phy_conf(c) >= 0) && \
>> + (hdmi_v14_find_mode(w, h) >= 0)) ? 0 : (-EINVAL))
>>
>> /* AVI header and aspect ratio */
>> #define HDMI_AVI_VERSION 0x02
>> @@ -88,6 +90,73 @@ struct hdmi_resources {
>> int regul_count;
>> };
>>
>> +struct hdmi_tg_regs {
>> + u8 cmd[1];
>> + u8 h_fsz[2];
>> + u8 hact_st[2];
>> + u8 hact_sz[2];
>> + u8 v_fsz[2];
>> + u8 vsync[2];
>> + u8 vsync2[2];
>> + u8 vact_st[2];
>> + u8 vact_sz[2];
>> + u8 field_chg[2];
>> + u8 vact_st2[2];
>> + u8 vact_st3[2];
>> + u8 vact_st4[2];
>> + u8 vsync_top_hdmi[2];
>> + u8 vsync_bot_hdmi[2];
>> + u8 field_top_hdmi[2];
>> + u8 field_bot_hdmi[2];
>> + u8 tg_3d[1];
>> +};
>> +
>> +struct hdmi_core_regs {
>> + u8 h_blank[2];
>> + u8 v2_blank[2];
>> + u8 v1_blank[2];
>> + u8 v_line[2];
>> + u8 h_line[2];
>> + u8 hsync_pol[1];
>> + u8 vsync_pol[1];
>> + u8 int_pro_mode[1];
>> + u8 v_blank_f0[2];
>> + u8 v_blank_f1[2];
>> + u8 h_sync_start[2];
>> + u8 h_sync_end[2];
>> + u8 v_sync_line_bef_2[2];
>> + u8 v_sync_line_bef_1[2];
>> + u8 v_sync_line_aft_2[2];
>> + u8 v_sync_line_aft_1[2];
>> + u8 v_sync_line_aft_pxl_2[2];
>> + u8 v_sync_line_aft_pxl_1[2];
>> + u8 v_blank_f2[2]; /* for 3D mode */
>> + u8 v_blank_f3[2]; /* for 3D mode */
>> + u8 v_blank_f4[2]; /* for 3D mode */
>> + u8 v_blank_f5[2]; /* for 3D mode */
>> + u8 v_sync_line_aft_3[2];
>> + u8 v_sync_line_aft_4[2];
>> + u8 v_sync_line_aft_5[2];
>> + u8 v_sync_line_aft_6[2];
>> + u8 v_sync_line_aft_pxl_3[2];
>> + u8 v_sync_line_aft_pxl_4[2];
>> + u8 v_sync_line_aft_pxl_5[2];
>> + u8 v_sync_line_aft_pxl_6[2];
>> + u8 vact_space_1[2];
>> + u8 vact_space_2[2];
>> + u8 vact_space_3[2];
>> + u8 vact_space_4[2];
>> + u8 vact_space_5[2];
>> + u8 vact_space_6[2];
>> +};
>> +
>> +struct hdmi_v14_conf {
>> + int pixel_clock;
>> + struct hdmi_core_regs core;
>> + struct hdmi_tg_regs tg;
>> + int cea_video_id;
>> +};
>> +
>> struct hdmi_context {
>> struct device *dev;
>> struct drm_device *drm_dev;
>> @@ -106,6 +175,7 @@ struct hdmi_context {
>>
>> /* current hdmiphy conf index */
>> int cur_conf;
>> + struct hdmi_v14_confmode_conf;
>>
>> struct hdmi_resources res;
>>
>> @@ -394,584 +464,91 @@ static const struct hdmi_v13_conf hdmi_v13_confs[] = {
>> };
>>
>> /* HDMI Version 1.4 */
>> -static const u8 hdmiphy_conf27_027[32] = {
>> - 0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
>> - 0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
>> - 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> - 0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
>> -};
>> -
>> -static const u8 hdmiphy_conf74_176[32] = {
>> - 0x01, 0xd1, 0x1f, 0x10, 0x40, 0x5b, 0xef, 0x08,
>> - 0x81, 0xa0, 0xb9, 0xd8, 0x45, 0xa0, 0xac, 0x80,
>> - 0x5a, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> - 0x54, 0xa6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
>> -};
>> -
>> -static const u8 hdmiphy_conf74_25[32] = {
>> - 0x01, 0xd1, 0x1f, 0x10, 0x40, 0x40, 0xf8, 0x08,
>> - 0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
>> - 0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> - 0x54, 0xa5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
>> -};
>> -
>> -static const u8 hdmiphy_conf148_5[32] = {
>> - 0x0
[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..557ef2f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2167,27 +2167,27 @@ static int __devinit hdmi_resources_init(struct
hdmi_context *hdata)
/* get clocks, power */
res->hdmi = clk_get(dev, "hdmi");
- if (IS_ERR_OR_NULL(res->hdmi)) {
+ if (IS_ERR(res->hdmi)) {
DRM_ERROR("failed to get clock 'hdmi'\n");
goto fail;
}
res->sclk_hdmi = clk_get(dev, "sclk_hdmi");
- if (IS_ERR_OR_NULL(res->sclk_hdmi)) {
+ if (IS_ERR(res->sclk_hdmi)) {
DRM_ERROR("failed to get clock 'sclk_hdmi'\n");
goto fail;
}
res->sclk_pixel = clk_get(dev, "sclk_pixel");
- if (IS_ERR_OR_NULL(res->sclk_pixel)) {
+ if (IS_ERR(res->sclk_pixel)) {
DRM_ERROR("failed to get clock 'sclk_pixel'\n");
goto fail;
}
res->sclk_hdmiphy = clk_get(dev, "sclk_hdmiphy");
- if (IS_ERR_OR_NULL(res->sclk_hdmiphy)) {
+ if (IS_ERR(res->sclk_hdmiphy)) {
DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
goto fail;
}
res->hdmiphy = clk_get(dev, "hdmiphy");
- if (IS_ERR_OR_NULL(res->hdmiphy)) {
+ if (IS_ERR(res->hdmiphy)) {
DRM_ERROR("failed to get clock 'hdmiphy'\n");
goto fail;
}
--
1.7.9.5
[PATCH RESEND 2/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
In the fail: path of mixer_resources_init() and vp_resources_init()
the first clk tested cannot be NULL either, so IS_ERR_OR_NULL is
removed from these as well. Other clocks may still be NULL as they
haven't been clk_get'd yet.
Signed-off-by: Tony Prisk
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_mixer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e7fbb82..dbd97c0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -972,14 +972,14 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
spin_lock_init(&mixer_res->reg_slock);
mixer_res->mixer = clk_get(dev, "mixer");
- if (IS_ERR_OR_NULL(mixer_res->mixer)) {
+ if (IS_ERR(mixer_res->mixer)) {
dev_err(dev, "failed to get clock 'mixer'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_hdmi = clk_get(dev, "sclk_hdmi");
- if (IS_ERR_OR_NULL(mixer_res->sclk_hdmi)) {
+ if (IS_ERR(mixer_res->sclk_hdmi)) {
dev_err(dev, "failed to get clock 'sclk_hdmi'\n");
ret = -ENODEV;
goto fail;
@@ -1019,7 +1019,7 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
fail:
if (!IS_ERR_OR_NULL(mixer_res->sclk_hdmi))
clk_put(mixer_res->sclk_hdmi);
- if (!IS_ERR_OR_NULL(mixer_res->mixer))
+ if (!IS_ERR(mixer_res->mixer))
clk_put(mixer_res->mixer);
return ret;
}
@@ -1034,19 +1034,19 @@ static int __devinit vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
int ret;
mixer_res->vp = clk_get(dev, "vp");
- if (IS_ERR_OR_NULL(mixer_res->vp)) {
+ if (IS_ERR(mixer_res->vp)) {
dev_err(dev, "failed to get clock 'vp'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_mixer = clk_get(dev, "sclk_mixer");
- if (IS_ERR_OR_NULL(mixer_res->sclk_mixer)) {
+ if (IS_ERR(mixer_res->sclk_mixer)) {
dev_err(dev, "failed to get clock 'sclk_mixer'\n");
ret = -ENODEV;
goto fail;
}
mixer_res->sclk_dac = clk_get(dev, "sclk_dac");
- if (IS_ERR_OR_NULL(mixer_res->sclk_dac)) {
+ if (IS_ERR(mixer_res->sclk_dac)) {
dev_err(dev, "failed to get clock 'sclk_dac'\n");
ret = -ENODEV;
goto fail;
@@ -1077,7 +1077,7 @@ fail:
clk_put(mixer_res->sclk_dac);
if (!IS_ERR_OR_NULL(mixer_res->sclk_mixer))
clk_put(mixer_res->sclk_mixer);
- if (!IS_ERR_OR_NULL(mixer_res->vp))
+ if (!IS_ERR(mixer_res->vp))
clk_put(mixer_res->vp);
return ret;
}
--
1.7.9.5
[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Tue, 2012-12-18 at 21:39 +0300, Dan Carpenter wrote: > On Wed, Dec 19, 2012 at 06:34:05AM +1300, Tony Prisk wrote: > > Resend to include mailing lists. > > > > Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. > > > > The original code is correct. clk_get() can return NULL depending > on the .config. > > regards, > dan carpenter Thanks for than Dan, Arguably that seems like an incorrect behaviour on the part of the clock subsystem given that the 'proper' function has kernel doc: * Returns a struct clk corresponding to the clock producer, or * valid IS_ERR() condition containing errno. Therefore the 'empty' version should adhere to the same rules, and not return NULL. I've cc'd Mike Turquette as well for his thoughts. Regards Tony P
[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > I don't care either way, but being different from the documentation > is less bad than crashing which is what your patch does. Please > be more careful in the future. > > regards, > dan carpenter Critism accepted. Given that the driver depends on (PLAT_SAMSUNG || ARCH_MULTIPLATFORM), and multiplatform select COMMON_CLK and PLAT_SAMSUNG is selected only by ARCH_S3C64XX which has HAVE_CLK I didn't see a problem here. Your point is still valid and I will sort it out with Mike first. Regards Tony P
[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL
On Wed, 2012-12-19 at 08:11 +1300, Tony Prisk wrote: > On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > > I don't care either way, but being different from the documentation > > is less bad than crashing which is what your patch does. Please > > be more careful in the future. > > > > regards, > > dan carpenter > > Critism accepted. > > Given that the driver depends on (PLAT_SAMSUNG || ARCH_MULTIPLATFORM), > and multiplatform select COMMON_CLK and PLAT_SAMSUNG is selected only by > ARCH_S3C64XX which has HAVE_CLK I didn't see a problem here. > > Your point is still valid and I will sort it out with Mike first. > > Regards > Tony P Actually, I was wrong here - PLAT_SAMSUNG is selectable via PLAT_S3C24XX || ARCH_S3C64XX || PLAT_S5P but all these options (or the options that select them) seem to select a clock system as well, hence still no reason for a crash. Regards Tony P
[PATCH 1/3] drm: create unified vma offset manager
On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> So we have to offset manager implementations for dealing with VMA offsets.
> GEM had one using the hash table, TTM had one using an rbtree,
>
> I'd rather we just had one to rule them all, since ttm is using the rbtree
> variant to allow sub mappings, to keep ABI we need to use that one.
>
> This also adds a bunch of inline helpers to avoid gem/ttm poking around
> inside the vma_offset objects. TTM needs a reset helper to remove a vma_offset
> when it copies an object to another one for buffer moves. The helpers
> also let drivers avoid the map_list.hash_key << PAGE_SHIFT nonsense.
Any clue as to the performance difference between the two
implementations? What does it add to the cost of a pagefault?
Hmm, don't have an i-g-t handy for scalability testing of the fault
handlers.
> +int drm_vma_offset_setup(struct drm_vma_offset_manager *man,
> + struct drm_vma_offset_node *node,
> + unsigned long num_pages)
> +{
> + int ret;
> +
> +retry_pre_get:
> + ret = drm_mm_pre_get(&man->addr_space_mm);
> + if (unlikely(ret != 0))
> + return ret;
> +
> + write_lock(&man->vm_lock);
> + node->vm_node = drm_mm_search_free(&man->addr_space_mm,
> +num_pages, 0, 0);
> +
> + if (unlikely(node->vm_node == NULL)) {
> + ret = -ENOMEM;
ret = -ENOSPC;
Depended upon by the higher layers for determining when to purge their
caches; i-g-t/gem_mmap_offset_exhaustion
> + goto out_unlock;
> + }
> +
> + node->vm_node = drm_mm_get_block_atomic(node->vm_node,
> + num_pages, 0);
> +
I'd feel happier if this tried to only take from the preallocated pool
rather than actually try a GFP_ATOMIC allocation.
> + if (unlikely(node->vm_node == NULL)) {
> + write_unlock(&man->vm_lock);
> + goto retry_pre_get;
> + }
> +
> + node->num_pages = num_pages;
> + drm_vma_offset_insert_rb(man, node);
> + write_unlock(&man->vm_lock);
> +
> + return 0;
> +out_unlock:
> + write_unlock(&man->vm_lock);
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(drm_vma_offset_setup);
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 3/3] drm/gem: start adding support for per-file object mmaps
From: Chris Wilson Subject: Re: [proof-of-concept/rfc] per object file mmaps To: Dave Airlie , dri-devel at lists.freedesktop.org In-Reply-To: <1355892119-13926-1-git-send-email-airlied at gmail.com> References: <1355892119-13926-1-git-send-email-airlied at gmail.com> On Wed, 19 Dec 2012 14:41:56 +1000, Dave Airlie wrote: > The 2+3 patches are actually the code, the first was just a cleanup. > > Anyways the second patch describes it best, but I've taken the approach > that we just need to keep track of what filp this object has had a handle > created on, and block mmaps on it. We could also probably block a bit > more explicitly in the driver respective mmap offset retrieval ioctls, > however we need to block in mmap itself to stop people just picking misc > address and trying them. > > It doesn't really add much now, but with render nodes where we have flink_to > or fd passing it would be more useful. > > I've no idea if I'll get to do much more with this, so consider it an > indication of how I'd like it done for someone else to run with :-) Locking looks entirely non-existent for per-file mmap add/remove in the generic gem code. Also we have a pair of hooks there that look like they would be a convenient point to place that code. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 1/3] drm: create unified vma offset manager
On Wed, Dec 19, 2012 at 09:22:26AM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > So we have to offset manager implementations for dealing with VMA offsets.
> > GEM had one using the hash table, TTM had one using an rbtree,
> >
> > I'd rather we just had one to rule them all, since ttm is using the rbtree
> > variant to allow sub mappings, to keep ABI we need to use that one.
> >
> > This also adds a bunch of inline helpers to avoid gem/ttm poking around
> > inside the vma_offset objects. TTM needs a reset helper to remove a
> > vma_offset
> > when it copies an object to another one for buffer moves. The helpers
> > also let drivers avoid the map_list.hash_key << PAGE_SHIFT nonsense.
>
> Any clue as to the performance difference between the two
> implementations? What does it add to the cost of a pagefault?
>
> Hmm, don't have an i-g-t handy for scalability testing of the fault
> handlers.
>
> > +int drm_vma_offset_setup(struct drm_vma_offset_manager *man,
> > +struct drm_vma_offset_node *node,
> > +unsigned long num_pages)
> > +{
> > + int ret;
> > +
> > +retry_pre_get:
> > + ret = drm_mm_pre_get(&man->addr_space_mm);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + write_lock(&man->vm_lock);
> > + node->vm_node = drm_mm_search_free(&man->addr_space_mm,
> > + num_pages, 0, 0);
> > +
> > + if (unlikely(node->vm_node == NULL)) {
> > + ret = -ENOMEM;
> ret = -ENOSPC;
>
> Depended upon by the higher layers for determining when to purge their
> caches; i-g-t/gem_mmap_offset_exhaustion
The larger topic is that drm_mm is only 32bit on 32bit and we routinely
exhaust that after a few weeks of uptime. Or better: We _did_ exhaust
that, until we've added tons of checks in both kernel&libdrm to reap
cached objects if it doesn't work. Hence it's paramount for our code to
get a -ENOSPC to engage in mmap offset reaping.
> > + goto out_unlock;
> > + }
> > +
> > + node->vm_node = drm_mm_get_block_atomic(node->vm_node,
> > + num_pages, 0);
> > +
>
> I'd feel happier if this tried to only take from the preallocated pool
> rather than actually try a GFP_ATOMIC allocation.
Seconded. Imo drm_mm_pre_get should just die - it artificially limits
prealloc to 4 nodes, which means you'll fall over if 5 threads enter this.
And with the drm_mm rework of about a year ago it's no longer required,
you can simply embedded the struct drm_mm_node whereever you want, and mm
won't allocate anything any more on top of that. Or preallocate the
drm_mm_node in the code, outside of the locks. Inserting the node happens
then with drm_mm_insert* functions, which combine the search_free +
get_blcok (since really, there's nothing interesting you can do with the
hole space you get from search_free). See e.g.
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d
for the conversion. My efforts of yonder to convert everyon have stalled a
bit in the ttm code, but now that i915 is converted and (hopefully) the
mmap offset stuff, I'll pick this up again. Would allow us to kill quite a
bit of cruft from the drm_mm interfaces.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 58491] regression : r600g: work around ddx over alignment
https://bugs.freedesktop.org/show_bug.cgi?id=58491 --- Comment #9 from Andy Furniss --- (In reply to comment #8) > (In reply to comment #7) > > Indeed, the resolution is the problem, > > > > running any application in my system resolution (1680x1050) breaks > > rendering, something like 640x480 has no problems. It also corrupts things > > like glxgears while I resize them (from any resolution). > > What I mean is, glxgears gets corrupted if I resize its window while it is > running, it displays corrupted blocks I am also seeing this resize corruption on HD4890 (native res = 1920x1080). Some demos seem to start corrupted - gearbox starts with band at top. Projtex - less reliable, may need other demos run first, but may start totally corrupted then correct when a key is pressed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/44f7a7e5/attachment.html>
[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown
https://bugs.freedesktop.org/show_bug.cgi?id=56634 --- Comment #6 from Andy Furniss --- (In reply to comment #5) > Using kernel from linus's repo fixes this issue. > Not sure if it is a "proper" fix, so I'll let you close the repoer if it > should be closed. > > (now I'm getting 40 fps in heaven , nice boost if we forget about the 3 fps > thing) etqw is also running normally again with drm-next kernel and current mesa/llvm. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/6e441ef0/attachment.html>
[RFC 0/6] Common Display Framework-T
Hi Tomi, On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > Hi, > > I have been testing Common Display Framework on OMAP, and making changes > that I've discussed in the posts I've sent in reply to the CDF series from > Laurent. While my CDF code is rather hacky and not at all ready, I wanted > to post the code for comments and also as a reference code to my posts. > > So here is CDF-T (Tomi-edition =). We've discussed your approach extensively face-to-face today so I won't review the patches in detail, but I will instead summarize our discussion to make sure we understood each other (and let other developers jump in). For the purpose of this discussion the term "display controller driver" (or just "display controller") refer to both the low-level driver layer that communicates directly with the display controller hardware, and to the higher- level driver layer that implements and exposes the userspace API (FBDEV, KMS and/or V4L). Those layers can be implemented in multiple kernel modules (such as in the OMAP DSS case, with omapdss for the low-level layer and omapdrm, omapfb and omapvout for the API-level layer) or a single kernel module. Control model - The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- model.png shows the CDF control model. The panel object depicted on the figure doesn't need to be a panel in the stricter sense but could be any chain of off-SoC (both on-board or off-board) display entities. It however helps thinking about it as a panel and doesn't hurt the model. The panel is controlled through abstract control requests. Those requests are used to retrieve panel information (such as the physical size, the supported video modes, EDID information, ...), set the panel configuration (such as the active video timings) or control the panel operation state (enabling/disabling the panel, controlling panel blanking and power management, ...). They are exposed by the panel using function pointers, and called by other kernel components in response to userspace requests (through the FBDEV, KMS or V4L2 APIs) or in-kernel events (for instance hotplug notifications). In response to the control requests the panel driver will communicate with the panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., not shown on the figure) and will control the video stream it receives on its input. The panel is connected at the hardware level to a video source (shown as a green hashed rectangle) that provides it with a video stream. The video stream flows from the video source to the panel and is directly controlled by its source, as shown by the green arrow from the display controller to the video stream. The video source exposes stream control operations as function pointers that are used by the panel to control the video stream, as shown by the green arrow from the panel to the video source. The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- model-2.png shows the call flow across entities when the panel is a pipeline made of more than a single entity. In this case the SoC (on the left of the dashed line) outputs a video stream on a DSI bus connected to a DSI to LVDS transmitter. The output of the DSI to LVDS transmitter is connected to an LVDS panel (or, more accurately, an LVDS panel module made of an LVDS panel controller and a panel). The transmitter and panel module are seen by the display controller and userspace API implementations as a single entity that exposes control request operations and controls its input video stream. When a control request is performed (outermost green arrow) the DSI to LVDS transmitter will propagate it to the panel, possibly mangling the input parameters or the response. For panel operation state control requests the last entity in the pipeline will likely want to control the video stream it receives on its input. The video stream control calls will be propagated from right to left as shown by the red arrows. Every entity in the call stack can communicate with its hardware device through the corresponding control bus, and/or control the video stream it receives on its input. This model allows filtering out modes and timings supported by the panel but unsupported by the transmitter and mangling the modes and timings according to the transmitter limitations. It has no complexity drawback for simple devices, as the corresponding drivers can just forward the calls directly. Similar use cases could exist for other control operations than mode and information retrieval. Discovery - Before being able to issue control requests, panel devices need to be discovered and associated with the connected display controller(s). Panels and display controllers are cross-dependent. There is no way around that, as the display controller needs a reference to the panel to call control requests in response to userspace API, and the panel needs a reference to th
GPU lockup CP stall for more than 10000msec on latest vanilla git
Op 18-12-12 17:12, Markus Trippelsdorf schreef: > On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 14:38, Markus Trippelsdorf schreef: >>> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote: On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote: > On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote: >> On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: >>> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf >>> wrote: On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > wrote: >> As soon as I open the following website: >> http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html >> >> my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: > Is this a regression? Most likely a 3D driver bug unless you are only > seeing it with specific kernels. What browser are you using and do > you have hw accelerated webgl, etc. enabled? If so, what version of > mesa are you using? This is a regression, because it is caused by yesterdays merge of drm-next by Linus. IOW I only see this bug when running a v3.7-9432-g9360b53 kernel. >>> Can you bisect? I'm guessing it may be related to the new DMA rings. >>> Possibly: >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> Yes, the commit above causes the issue. >> >> 2d6cc72 GPU lockups > With 2d6cc72 reverted I get: > > Dec 17 23:09:35 x4 kernel: [ cut here ] Probably a separate issue, can you bisect this one as well? >>> Yes. Git-bisect points to: >>> >>> 85b144f860176ec18db927d6d9ecdfb24d9c6483 is the first bad commit >>> commit 85b144f860176ec18db927d6d9ecdfb24d9c6483 >>> Author: Maarten Lankhorst >>> Date: Thu Nov 29 11:36:54 2012 + >>> >>> drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock >>> held, v3 >>> >>> (Please note that this bug is a little bit harder to reproduce. But >>> when you scroll up and down for ~10 seconds on the webpage mentioned >>> above it will trigger the oops. >>> So while I'm not 100% sure that the issue is caused by exactly this >>> commit, the vicinity should be right) >>> >> Those dmesg warnings sound suspicious, looks like something is going >> very wrong there. >> >> Can you revert the one before it? "drm/radeon: allow move_notify to be >> called without reservation" Reservation should be held at this point, >> that commit got in accidentally. >> >> I doubt not holding a reservation is causing it though, I don't really >> see how that commit could cause it however, so can you please double >> check it never happened before that point, and only started at that >> commit? >> >> also slap in a BUG_ON(!ttm_bo_is_reserved(bo)) in >> ttm_bo_cleanup_refs_and_unlock for good measure, and a >> BUG_ON(spin_trylock(&bdev->fence_lock)); to ttm_bo_wait. >> >> I really don't see how that specific commit can be wrong though, so >> awaiting your results first before I try to dig more into it. > I just reran git-bisect just on your commits (from 1a1494def to 97a875cbd) > and I landed on the same commit as above: > > commit 85b144f86 (drm/ttm: call ttm_bo_cleanup_refs with reservation and lru > lock held, v3) > > So now I'm pretty sure it's specifically this commit that started the > issue. > > With your supposed debugging BUG_ONs added I still get: > > Dec 18 17:01:15 x4 kernel: [ cut here ] > Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 > radeon_fence_ref+0x2c/0x40() > Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name > Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted > 3.7.0-rc7-00520-g85b144f-dirty #174 > Dec 18 17:01:15 x4 kernel: Call Trace: > Dec 18 17:01:15 x4 kernel: [] ? > warn_slowpath_common+0x74/0xb0 > Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_mem_evict_first+0x1dc/0x2a0 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_man_get_node+0x62/0xb0 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_mem_space+0x28e/0x340 > Dec 18 17:01:15 x4 kernel: [] ? > ttm_bo_move_buffer+0xfc/0x170 > Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 > Dec 18 17:01:15 x4 kernel: [] ? radeon_bo_create+0x18a/0x200 > Dec 18 17:01:15 x4 kernel: [] ? radeon_bo_clear_va+0x40/0x40 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_object_create+0x92/0x160 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_create_ioctl+0x6c/0x150 > Dec 18 17:01:15 x4 kernel: [] ? > radeon_gem_object_free+0x2f/0x40 > Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 Jochen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Jochen --- This bug is still unsolved for me. I'm having Nvidia graphics card (Macbook 5,1) and using Ubuntu 12.04 with proprietary Nvidia driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/07e1aaec/attachment.html>
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Fix regression introduced by 85b144f860176 Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0bf66f9..9f85418 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo, * at this point the buffer should be dead, so * no new sync objects can be attached. */ - sync_obj = driver->sync_obj_ref(&bo->sync_obj); + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); atomic_set(&bo->reserved, 0);
GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: > Op 18-12-12 17:12, Markus Trippelsdorf schreef: > > With your supposed debugging BUG_ONs added I still get: > > > > Dec 18 17:01:15 x4 kernel: [ cut here ] > > Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 > > radeon_fence_ref+0x2c/0x40() > > Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name > > Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted > > 3.7.0-rc7-00520-g85b144f-dirty #174 > > Dec 18 17:01:15 x4 kernel: Call Trace: > > Dec 18 17:01:15 x4 kernel: [] ? > > warn_slowpath_common+0x74/0xb0 > > Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_mem_evict_first+0x1dc/0x2a0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_man_get_node+0x62/0xb0 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_mem_space+0x28e/0x340 > > Dec 18 17:01:15 x4 kernel: [] ? > > ttm_bo_move_buffer+0xfc/0x170 > > Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 > > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 > > Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_bo_create+0x18a/0x200 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_bo_clear_va+0x40/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_object_create+0x92/0x160 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_create_ioctl+0x6c/0x150 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_object_free+0x2f/0x40 > > Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x4f0 > > Dec 18 17:01:15 x4 kernel: [] ? > > radeon_gem_pwrite_ioctl+0x20/0x20 > > Dec 18 17:01:15 x4 kernel: [] ? do_vfs_ioctl+0x2e4/0x4e0 > > Dec 18 17:01:15 x4 kernel: [] ? vfs_read+0x118/0x160 > > Dec 18 17:01:15 x4 kernel: [] ? sys_ioctl+0x4c/0xa0 > > Dec 18 17:01:15 x4 kernel: [] ? sys_read+0x51/0xa0 > > Dec 18 17:01:15 x4 kernel: [] ? > > system_call_fastpath+0x16/0x1b > so the kref to fence is null here. This should be impossible and > indicates a bug in refcounting somewhere, or possibly memory > corruption. > > Lets first look where things could go wrong.. > > sync_obj member requires fence_lock to be taken, but radeon code in > general doesn't do that, hm.. > > I think radeon_cs_sync_rings needs to take fence_lock during the > iteration, then taking on a refcount to the fence, and > radeon_crtc_page_flip and radeon_move_blit are lacking refcount on > fence_lock as well. > > But that would probably still not explain why it crashes in > radeon_vm_bo_invalidate shortly after, so it seems just as likely that > it's operating on freed memory there or something. > > But none of the code touches refcounting for that bo, and I really > don't see how I messed up anything there. > > I seem to be able to reproduce it if I add a hack though, can you test > if you get the exact same issues if you apply this patch? Your patch doesn't apply unfortunately: markus at x4 linux % patch -p1 --dry-run < ~/maarten.patch checking file drivers/gpu/drm/ttm/ttm_bo.c Hunk #1 succeeded at 512 with fuzz 1. Hunk #6 FAILED at 814. 1 out of 6 hunks FAILED markus at x4 linux % git describe v3.7-10833-g752451f markus at x4 linux % -- Markus
GPU lockup CP stall for more than 10000msec on latest vanilla git
Op 19-12-12 15:20, Markus Trippelsdorf schreef: > On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 17:12, Markus Trippelsdorf schreef: >>> With your supposed debugging BUG_ONs added I still get: >>> >>> Dec 18 17:01:15 x4 kernel: [ cut here ] >>> Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42 >>> radeon_fence_ref+0x2c/0x40() >>> Dec 18 17:01:15 x4 kernel: Hardware name: System Product Name >>> Dec 18 17:01:15 x4 kernel: Pid: 157, comm: X Not tainted >>> 3.7.0-rc7-00520-g85b144f-dirty #174 >>> Dec 18 17:01:15 x4 kernel: Call Trace: >>> Dec 18 17:01:15 x4 kernel: [] ? >>> warn_slowpath_common+0x74/0xb0 >>> Dec 18 17:01:15 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_mem_evict_first+0x1dc/0x2a0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_man_get_node+0x62/0xb0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_mem_space+0x28e/0x340 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> ttm_bo_move_buffer+0xfc/0x170 >>> Dec 18 17:01:15 x4 kernel: [] ? kmem_cache_alloc+0xb2/0xc0 >>> Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_validate+0x95/0x110 >>> Dec 18 17:01:15 x4 kernel: [] ? ttm_bo_init+0x2ec/0x3b0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_bo_create+0x18a/0x200 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_bo_clear_va+0x40/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_object_create+0x92/0x160 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_create_ioctl+0x6c/0x150 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_object_free+0x2f/0x40 >>> Dec 18 17:01:15 x4 kernel: [] ? drm_ioctl+0x420/0x4f0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> radeon_gem_pwrite_ioctl+0x20/0x20 >>> Dec 18 17:01:15 x4 kernel: [] ? do_vfs_ioctl+0x2e4/0x4e0 >>> Dec 18 17:01:15 x4 kernel: [] ? vfs_read+0x118/0x160 >>> Dec 18 17:01:15 x4 kernel: [] ? sys_ioctl+0x4c/0xa0 >>> Dec 18 17:01:15 x4 kernel: [] ? sys_read+0x51/0xa0 >>> Dec 18 17:01:15 x4 kernel: [] ? >>> system_call_fastpath+0x16/0x1b >> so the kref to fence is null here. This should be impossible and >> indicates a bug in refcounting somewhere, or possibly memory >> corruption. >> >> Lets first look where things could go wrong.. >> >> sync_obj member requires fence_lock to be taken, but radeon code in >> general doesn't do that, hm.. >> >> I think radeon_cs_sync_rings needs to take fence_lock during the >> iteration, then taking on a refcount to the fence, and >> radeon_crtc_page_flip and radeon_move_blit are lacking refcount on >> fence_lock as well. >> >> But that would probably still not explain why it crashes in >> radeon_vm_bo_invalidate shortly after, so it seems just as likely that >> it's operating on freed memory there or something. >> >> But none of the code touches refcounting for that bo, and I really >> don't see how I messed up anything there. >> >> I seem to be able to reproduce it if I add a hack though, can you test >> if you get the exact same issues if you apply this patch? > Your patch doesn't apply unfortunately: > > markus at x4 linux % patch -p1 --dry-run < ~/maarten.patch > checking file drivers/gpu/drm/ttm/ttm_bo.c > Hunk #1 succeeded at 512 with fuzz 1. > Hunk #6 FAILED at 814. > 1 out of 6 hunks FAILED > markus at x4 linux % git describe > v3.7-10833-g752451f > markus at x4 linux % It applies on top of the regressed commit. It should probably not be too hard to make it apply manually on whatever you're using. But the real fix will be "drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling", which I cc'd you on. The patch I posted earlier in this thread will just aggressively stress test the codepath. ~Maarten
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: > Fix regression introduced by 85b144f860176 Thanks for the catch and patch. Also please add the commit summary to make the commit message self contained? The problem description would also be nice. > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf Message-ID: <20121217182752.GA351 at x4> > --- > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index 0bf66f9..9f85418 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > ttm_buffer_object *bo, >* at this point the buffer should be dead, so >* no new sync objects can be attached. >*/ > - sync_obj = driver->sync_obj_ref(&bo->sync_obj); > + sync_obj = driver->sync_obj_ref(bo->sync_obj); Any idea, why this only had an impact for one person so far? > spin_unlock(&bdev->fence_lock); > > atomic_set(&bo->reserved, 0); Thanks, Paul -- 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/20121219/44239f1a/attachment.pgp>
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel wrote: > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: >> Fix regression introduced by 85b144f860176 > > Thanks for the catch and patch. > > Also please add the commit summary to make the commit message self > contained? > > The problem description would also be nice. > >> Signed-off-by: Maarten Lankhorst >> Reported-by: Markus Trippelsdorf > Message-ID: <20121217182752.GA351 at x4> > >> --- >> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c >> index 0bf66f9..9f85418 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c >> @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct >> ttm_buffer_object *bo, >>* at this point the buffer should be dead, so >>* no new sync objects can be attached. >>*/ >> - sync_obj = driver->sync_obj_ref(&bo->sync_obj); >> + sync_obj = driver->sync_obj_ref(bo->sync_obj); > > Any idea, why this only had an impact for one person so far? There are several radeon bugs from drm-next 3.8 that may be ultimately related to this. Alex
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel > wrote: > > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: > >> Fix regression introduced by 85b144f860176 > > > > Thanks for the catch and patch. > > > > Also please add the commit summary to make the commit message self > > contained? > > > > The problem description would also be nice. > > > >> Signed-off-by: Maarten Lankhorst > >> Reported-by: Markus Trippelsdorf > > Message-ID: <20121217182752.GA351 at x4> > > > >> --- > >> > >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > >> index 0bf66f9..9f85418 100644 > >> --- a/drivers/gpu/drm/ttm/ttm_bo.c > >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c > >> @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > >> ttm_buffer_object *bo, > >>* at this point the buffer should be dead, so > >>* no new sync objects can be attached. > >>*/ > >> - sync_obj = driver->sync_obj_ref(&bo->sync_obj); > >> + sync_obj = driver->sync_obj_ref(bo->sync_obj); > > > > Any idea, why this only had an impact for one person so far? > > There are several radeon bugs from drm-next 3.8 that may be ultimately > related to this. This patch fixes the kernel BUG, but now I get these errors in my Xorg.log: [23.092] [mi] Increasing EQ size to 512 to prevent dropped events. (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] (EE) 1: /usr/bin/X (mieqEnqueue+0x21b) [0x56615b] (EE) 2: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] (EE) 3: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] (EE) 6: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x428c) [0x7ff8f250528c] (EE) 7: /usr/bin/X (0x40+0x71cd8) [0x471cd8] (EE) 8: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] (EE) 9: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] (EE) 10: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] (EE) 11: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] (EE) 12: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) [0x7ff8f246cbdf] (EE) 13: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) [0x7ff8f25107bf] (EE) 14: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] (EE) 15: /usr/bin/X (_CallCallbacks+0x34) [0x438894] (EE) 16: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] (EE) 17: /usr/bin/X (0x40+0x33aa1) [0x433aa1] (EE) 18: /usr/bin/X (0x40+0x230cd) [0x4230cd] (EE) 19: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] (EE) 20: /usr/bin/X (0x40+0x22c09) [0x422c09] (EE) (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. (EE) [mi] EQ overflow continuing. 100 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] (EE) 2: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] (EE) 3: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so (0x7ff8f2501000+0x428c) [0x7ff8f250528c] (EE) 6: /usr/bin/X (0x40+0x71cd8) [0x471cd8] (EE) 7: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] (EE) 8: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] (EE) 9: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] (EE) 10: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] (EE) 11: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) [0x7ff8f246cbdf] (EE) 12: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) [0x7ff8f25107bf] (EE) 13: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] (EE) 14: /usr/bin/X (_CallCallbacks+0x34) [0x438894] (EE) 15: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] (EE) 16: /usr/bin/X (0x40+0x33aa1) [0x433aa1] (EE) 17: /usr/bin/X (0x40+0x230cd) [0x4230cd] (EE) 18: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] (EE) 19: /usr/bin/X (0x40+0x22c09) [0x422c09] (EE) (EE) [mi] EQ overflow continuing. 200 events have been dropped. And the pictures get distorted on the test-webpage when I scroll up and down, see: http://trippelsdorf.de/bad.png -- Markus
[RFC v2 0/5] Common Display Framework
Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart wrote: > Hi Jani, > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >> I can see the need for a framework for DSI panels and such (in fact Tomi >> and I have talked about it like 2-3 years ago already!) but what is the >> story for HDMI and DP? In particular, what's the relationship between >> DRM and CDF here? Is there a world domination plan to switch the DRM >> drivers to use this framework too? ;) Do you have some rough plans how >> DRM and CDF should work together in general? > > There's always a world domination plan, isn't there ? :-) > > I certainly want CDF to be used by DRM (or more accurately KMS). That's what > the C stands for, common refers to sharing panel and other display entity > drivers between FBDEV, KMS and V4L2. > > I currently have no plan to expose CDF internals to userspace through the KMS > API. We might have to do so later if the hardware complexity grows in such a > way that finer control than what KMS provides needs to be exposed to > userspace, but I don't think we're there yet. The CDF API will thus only be > used internally in the kernel by display controller drivers. The KMS core > might get functions to handle common display entity operations, but the bulk > of the work will be in the display controller drivers to start with. We will > then see what can be abstracted in KMS helper functions. > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF > API. That's just a thought for now, I haven't tried to implement them, but it > would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. > > Do you have thoughts to share on this topic ? It just seems to me that, at least from a DRM/KMS perspective, adding another layer (=CDF) for HDMI or DP (or legacy outputs) would be overengineering it. They are pretty well standardized, and I don't see there would be a need to write multiple display drivers for them. Each display controller has one, and can easily handle any chip specific requirements right there. It's my gut feeling that an additional framework would just get in the way. Perhaps there could be more common HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, but that's another thing. So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM perspective? Or, put another way, is it more of an alternative to using DRM? Please enlighten me if there's some real benefit here that I fail to see! For DSI panels (or DSI-to-whatever bridges) it's of course another story. You typically need a panel specific driver. And here I see the main point of the whole CDF: decoupling display controllers and the panel drivers, and sharing panel (and converter chip) specific drivers across display controllers. Making it easy to write new drivers, as there would be a model to follow. I'm definitely in favour of coming up with some framework that would tackle that. BR, Jani.
[RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > Hi Laurent - > > On Tue, 18 Dec 2012, Laurent Pinchart > wrote: >> Hi Jani, >> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>> I can see the need for a framework for DSI panels and such (in fact Tomi >>> and I have talked about it like 2-3 years ago already!) but what is the >>> story for HDMI and DP? In particular, what's the relationship between >>> DRM and CDF here? Is there a world domination plan to switch the DRM >>> drivers to use this framework too? ;) Do you have some rough plans how >>> DRM and CDF should work together in general? >> >> There's always a world domination plan, isn't there ? :-) >> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >> the C stands for, common refers to sharing panel and other display entity >> drivers between FBDEV, KMS and V4L2. >> >> I currently have no plan to expose CDF internals to userspace through the KMS >> API. We might have to do so later if the hardware complexity grows in such a >> way that finer control than what KMS provides needs to be exposed to >> userspace, but I don't think we're there yet. The CDF API will thus only be >> used internally in the kernel by display controller drivers. The KMS core >> might get functions to handle common display entity operations, but the bulk >> of the work will be in the display controller drivers to start with. We will >> then see what can be abstracted in KMS helper functions. >> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >> API. That's just a thought for now, I haven't tried to implement them, but it >> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way. >> >> Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see > there would be a need to write multiple display drivers for them. Each > display controller has one, and can easily handle any chip specific > requirements right there. It's my gut feeling that an additional > framework would just get in the way. Perhaps there could be more common > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a > non-DRM perspective? Or, put another way, is it more of an alternative > to using DRM? Please enlighten me if there's some real benefit here that > I fail to see! fwiw, I think there are at least a couple cases where multiple SoC's have the same HDMI IP block. And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF is appropriate for HDMI drivers. Although trying to keep this all independent of DRM (as opposed to just something similar to what drivers/gpu/i2c is today) seems a bit overkill for me. Being able to use the helpers in drm and avoiding an extra layer of translation seems like the better option to me. So my vote would be drivers/gpu/cdf. BR, -R > For DSI panels (or DSI-to-whatever bridges) it's of course another > story. You typically need a panel specific driver. And here I see the > main point of the whole CDF: decoupling display controllers and the > panel drivers, and sharing panel (and converter chip) specific drivers > across display controllers. Making it easy to write new drivers, as > there would be a model to follow. I'm definitely in favour of coming up > with some framework that would tackle that. > > > BR, > Jani. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.19 at 15:54 +0100, Markus Trippelsdorf wrote: > On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > > And the pictures get distorted on the test-webpage when I scroll up and > down, see: > http://trippelsdorf.de/bad.png The picture distortion issue is caused by: commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb Author: Dave Airlie Date: Fri Dec 14 21:04:46 2012 +1000 radeon: fix regression with eviction since evict caching changes Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d drm/radeon: use cached memory when evicting for vram on non agp evicting from TTM would try and evict to TTM instead of system, not so good. This should fix: https://bugs.freedesktop.org/show_bug.cgi?id=58272 Signed-off-by: Dave Airlie Signed-off-by: Maarten Lankhorst Signed-off-by: Alex Deucher Reverting the commit above "fixes" the problem. -- Markus
[RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > >
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
v2: Check the original hole not the adjusted as the coloring may confuse
us when later searching for the overlapping nodes. Also make sure that
we do apply the range restriction and color adjustment in the same
order for both scanning, searching and insertion.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 45 +
include/drm/drm_mm.h |2 +-
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b751b8e..5847669 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -244,11 +244,13 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
BUG_ON(!hole_node->hole_follows || node->allocated);
- if (mm->color_adjust)
- mm->color_adjust(hole_node, color, &adj_start, &adj_end);
-
if (adj_start < start)
adj_start = start;
+ if (adj_end > end)
+ adj_end = end;
+
+ if (mm->color_adjust)
+ mm->color_adjust(hole_node, color, &adj_start, &adj_end);
if (alignment) {
unsigned tmp = adj_start % alignment;
@@ -519,7 +521,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -546,7 +548,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -565,8 +567,7 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
+ unsigned long adj_start, adj_end;
mm->scanned_blocks++;
@@ -583,14 +584,8 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
node->node_list.next = &mm->prev_scanned_node->node_list;
mm->prev_scanned_node = node;
- hole_start = drm_mm_hole_node_start(prev_node);
- hole_end = drm_mm_hole_node_end(prev_node);
-
- adj_start = hole_start;
- adj_end = hole_end;
-
- if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ adj_start = hole_start = drm_mm_hole_node_start(prev_node);
+ adji_end = hole_end = drm_mm_hole_node_end(prev_node);
if (mm->scan_check_range) {
if (adj_start < mm->scan_start)
@@ -599,11 +594,14 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
adj_end = mm->scan_end;
}
+ if (mm->color_adjust)
+ mm->color_adjust(prev_node, mm->scan_color,
+adj_start, adj_end);
+
if (check_free_hole(adj_start, adj_end,
mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -639,19 +637,10 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
node_list);
prev_node->hole_follows = node->scanned_preceeds_hole;
- INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+return (__drm_mm_hole_node_end(node) > mm->scan_hit_start &&
+node->start < mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index cd45365..58b8979 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned long scan_size;
unsigned long scan_hit_start;
-
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
v2: Check the original hole not the adjusted as the coloring may confuse
us when later searching for the overlapping nodes. Also make sure that
we do apply the range restriction and color adjustment in the same
order for both scanning, searching and insertion.
v3: Send the version that was actually tested.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 45 +
include/drm/drm_mm.h |2 +-
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b751b8e..e6fce66 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -244,11 +244,13 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
BUG_ON(!hole_node->hole_follows || node->allocated);
- if (mm->color_adjust)
- mm->color_adjust(hole_node, color, &adj_start, &adj_end);
-
if (adj_start < start)
adj_start = start;
+ if (adj_end > end)
+ adj_end = end;
+
+ if (mm->color_adjust)
+ mm->color_adjust(hole_node, color, &adj_start, &adj_end);
if (alignment) {
unsigned tmp = adj_start % alignment;
@@ -519,7 +521,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -546,7 +548,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -565,8 +567,7 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
+ unsigned long adj_start, adj_end;
mm->scanned_blocks++;
@@ -583,14 +584,8 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
node->node_list.next = &mm->prev_scanned_node->node_list;
mm->prev_scanned_node = node;
- hole_start = drm_mm_hole_node_start(prev_node);
- hole_end = drm_mm_hole_node_end(prev_node);
-
- adj_start = hole_start;
- adj_end = hole_end;
-
- if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ adj_start = hole_start = drm_mm_hole_node_start(prev_node);
+ adj_end = hole_end = drm_mm_hole_node_end(prev_node);
if (mm->scan_check_range) {
if (adj_start < mm->scan_start)
@@ -599,11 +594,14 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
adj_end = mm->scan_end;
}
+ if (mm->color_adjust)
+ mm->color_adjust(prev_node, mm->scan_color,
+&adj_start, &adj_end);
+
if (check_free_hole(adj_start, adj_end,
mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -639,19 +637,10 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
node_list);
prev_node->hole_follows = node->scanned_preceeds_hole;
- INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+return (__drm_mm_hole_node_end(node) > mm->scan_hit_start &&
+node->start < mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index cd45365..58b8979 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned long scan_s
[PATCH] drm/radeon: add support for MEM_WRITE packet
From: Jerome Glisse
To make it easier to debug some lockup from userspace add support
to MEM_WRITE packet.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
drivers/gpu/drm/radeon/r600_cs.c | 29 +
drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
3 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 74c6b42..5cea852 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2654,6 +2654,35 @@ static int evergreen_packet3_check(struct
radeon_cs_parser *p,
ib[idx+4] = upper_32_bits(offset) & 0xff;
}
break;
+ case PACKET3_MEM_WRITE:
+ {
+ u64 offset;
+
+ if (pkt->count != 3) {
+ DRM_ERROR("bad MEM_WRITE (invalid count)\n");
+ return -EINVAL;
+ }
+ r = evergreen_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
+ return -EINVAL;
+ }
+ offset = radeon_get_ib_value(p, idx+0);
+ offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) << 32UL;
+ if (offset & 0x7) {
+ DRM_ERROR("bad MEM_WRITE (address not qwords
aligned)\n");
+ return -EINVAL;
+ }
+ if ((offset + 8) > radeon_bo_size(reloc->robj)) {
+ DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx, 0x%lx\n",
+ offset + 8, radeon_bo_size(reloc->robj));
+ return -EINVAL;
+ }
+ offset += reloc->lobj.gpu_offset;
+ ib[idx+0] = offset;
+ ib[idx+1] = upper_32_bits(offset) & 0xff;
+ break;
+ }
case PACKET3_COPY_DW:
if (pkt->count != 4) {
DRM_ERROR("bad COPY_DW (invalid count)\n");
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 0be768b..9ea13d0 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2294,6 +2294,35 @@ static int r600_packet3_check(struct radeon_cs_parser *p,
ib[idx+4] = upper_32_bits(offset) & 0xff;
}
break;
+ case PACKET3_MEM_WRITE:
+ {
+ u64 offset;
+
+ if (pkt->count != 3) {
+ DRM_ERROR("bad MEM_WRITE (invalid count)\n");
+ return -EINVAL;
+ }
+ r = r600_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
+ return -EINVAL;
+ }
+ offset = radeon_get_ib_value(p, idx+0);
+ offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) << 32UL;
+ if (offset & 0x7) {
+ DRM_ERROR("bad MEM_WRITE (address not qwords
aligned)\n");
+ return -EINVAL;
+ }
+ if ((offset + 8) > radeon_bo_size(reloc->robj)) {
+ DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx, 0x%lx\n",
+ offset + 8, radeon_bo_size(reloc->robj));
+ return -EINVAL;
+ }
+ offset += reloc->lobj.gpu_offset;
+ ib[idx+0] = offset;
+ ib[idx+1] = upper_32_bits(offset) & 0xff;
+ break;
+ }
case PACKET3_COPY_DW:
if (pkt->count != 4) {
DRM_ERROR("bad COPY_DW (invalid count)\n");
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 9b1a727..ff75934 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -68,9 +68,10 @@
* 2.25.0 - eg+: new info request for num SE and num SH
* 2.26.0 - r600-eg: fix htile size computation
* 2.27.0 - r600-SI: Add CS ioctl support for async DMA
+ * 2.28.0 - r600-eg: Add MEM_WRITE packet support
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 27
+#define KMS_DRIVER_MINOR 28
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
--
1.7.11.7
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Op 19-12-12 15:18, Maarten Lankhorst schreef: > Fix regression introduced by 85b144f860176 > > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf > Hey Paul Menzel, I just wanted to have the fix out asap, and had to leave right after. Updated commit message below: Fix regression introduced by 85b144f860176 "drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3" Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase refcount on &bo->sync_obj instead of bo->sync_obj. The compiler didn't complain since sync_obj_ref takes a void pointer, so it was still valid c. This could result in lockups, memory corruptions, and warnings like these when graphics card VRAM usage is high: [ cut here ] WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40() Hardware name: System Product Name Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174 Call Trace: [] ? warn_slowpath_common+0x74/0xb0 [] ? radeon_fence_ref+0x2c/0x40 [] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 [] ? ttm_mem_evict_first+0x1dc/0x2a0 [] ? ttm_bo_man_get_node+0x62/0xb0 [] ? ttm_bo_mem_space+0x28e/0x340 [] ? ttm_bo_move_buffer+0xfc/0x170 [] ? kmem_cache_alloc+0xb2/0xc0 [] ? ttm_bo_validate+0x95/0x110 [] ? ttm_bo_init+0x2ec/0x3b0 [] ? radeon_bo_create+0x18a/0x200 [] ? radeon_bo_clear_va+0x40/0x40 [] ? radeon_gem_object_create+0x92/0x160 [] ? radeon_gem_create_ioctl+0x6c/0x150 [] ? radeon_gem_object_free+0x2f/0x40 [] ? drm_ioctl+0x420/0x4f0 [] ? radeon_gem_pwrite_ioctl+0x20/0x20 [] ? do_vfs_ioctl+0x2e4/0x4e0 [] ? vfs_read+0x118/0x160 [] ? sys_ioctl+0x4c/0xa0 [] ? sys_read+0x51/0xa0 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf Message-ID: <20121217182752.GA351 at x4> --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0bf66f9..9f85418 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo, * at this point the buffer should be dead, so * no new sync objects can be attached. */ - sync_obj = driver->sync_obj_ref(&bo->sync_obj); + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); atomic_set(&bo->reserved, 0);
[PATCH] drm/radeon: add support for MEM_WRITE packet
On Wed, Dec 19, 2012 at 12:26 PM, wrote:
> From: Jerome Glisse
>
> To make it easier to debug some lockup from userspace add support
> to MEM_WRITE packet.
>
> Signed-off-by: Jerome Glisse
Looks good to me. Added to my fixes queue.
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
> drivers/gpu/drm/radeon/r600_cs.c | 29 +
> drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
> 3 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 74c6b42..5cea852 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -2654,6 +2654,35 @@ static int evergreen_packet3_check(struct
> radeon_cs_parser *p,
> ib[idx+4] = upper_32_bits(offset) & 0xff;
> }
> break;
> + case PACKET3_MEM_WRITE:
> + {
> + u64 offset;
> +
> + if (pkt->count != 3) {
> + DRM_ERROR("bad MEM_WRITE (invalid count)\n");
> + return -EINVAL;
> + }
> + r = evergreen_cs_packet_next_reloc(p, &reloc);
> + if (r) {
> + DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
> + return -EINVAL;
> + }
> + offset = radeon_get_ib_value(p, idx+0);
> + offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) <<
> 32UL;
> + if (offset & 0x7) {
> + DRM_ERROR("bad MEM_WRITE (address not qwords
> aligned)\n");
> + return -EINVAL;
> + }
> + if ((offset + 8) > radeon_bo_size(reloc->robj)) {
> + DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx,
> 0x%lx\n",
> + offset + 8, radeon_bo_size(reloc->robj));
> + return -EINVAL;
> + }
> + offset += reloc->lobj.gpu_offset;
> + ib[idx+0] = offset;
> + ib[idx+1] = upper_32_bits(offset) & 0xff;
> + break;
> + }
> case PACKET3_COPY_DW:
> if (pkt->count != 4) {
> DRM_ERROR("bad COPY_DW (invalid count)\n");
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 0be768b..9ea13d0 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -2294,6 +2294,35 @@ static int r600_packet3_check(struct radeon_cs_parser
> *p,
> ib[idx+4] = upper_32_bits(offset) & 0xff;
> }
> break;
> + case PACKET3_MEM_WRITE:
> + {
> + u64 offset;
> +
> + if (pkt->count != 3) {
> + DRM_ERROR("bad MEM_WRITE (invalid count)\n");
> + return -EINVAL;
> + }
> + r = r600_cs_packet_next_reloc(p, &reloc);
> + if (r) {
> + DRM_ERROR("bad MEM_WRITE (missing reloc)\n");
> + return -EINVAL;
> + }
> + offset = radeon_get_ib_value(p, idx+0);
> + offset += ((u64)(radeon_get_ib_value(p, idx+1) & 0xff)) <<
> 32UL;
> + if (offset & 0x7) {
> + DRM_ERROR("bad MEM_WRITE (address not qwords
> aligned)\n");
> + return -EINVAL;
> + }
> + if ((offset + 8) > radeon_bo_size(reloc->robj)) {
> + DRM_ERROR("bad MEM_WRITE bo too small: 0x%llx,
> 0x%lx\n",
> + offset + 8, radeon_bo_size(reloc->robj));
> + return -EINVAL;
> + }
> + offset += reloc->lobj.gpu_offset;
> + ib[idx+0] = offset;
> + ib[idx+1] = upper_32_bits(offset) & 0xff;
> + break;
> + }
> case PACKET3_COPY_DW:
> if (pkt->count != 4) {
> DRM_ERROR("bad COPY_DW (invalid count)\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 9b1a727..ff75934 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -68,9 +68,10 @@
> * 2.25.0 - eg+: new info request for num SE and num SH
> * 2.26.0 - r600-eg: fix htile size computation
> * 2.27.0 - r600-SI: Add CS ioctl support for async DMA
> + * 2.28.0 - r600-eg: Add MEM_WRITE packet support
> */
> #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 27
> +#define KMS_DRIVER_MINOR 28
> #define KMS_DRIVER_PATCHLEVEL 0
> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> int radeon_driver_unload_kms(struct drm_device *dev);
> --
> 1.7.11.7
>
> ___
