On Mon, Jul 01, 2013 at 08:33:03PM +0200, David Herrmann wrote:
> Instead of unmapping the nodes in TTM and GEM users manually, we provide
> a generic wrapper which does the correct thing for all vma-nodes.
>
> Signed-off-by: David Herrmann
Nice. One nitpick below, otherwise:
Reviewed-by: Danie
On Mon, Jul 01, 2013 at 08:33:00PM +0200, David Herrmann wrote:
> If we want to map GPU memory into user-space, we need to linearize the
> addresses to not confuse mm-core. Currently, GEM and TTM both implement
> their own offset-managers to assign a pgoff to each object for user-space
> CPU access
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/5d0e1668/attachment.html>
On Mon, Jul 01, 2013 at 08:32:59PM +0200, David Herrmann wrote:
> This helper tests whether a given node is currently linked into a drm_mm
> manager. We use the node->mm pointer for that as it is set for all linked
> objects.
>
> We also reset node->mm whenever a node is removed. All such access i
On Mon, Jul 01, 2013 at 08:32:58PM +0200, David Herrmann wrote:
> There is no reason to return "int" as this function never fails.
> Furthermore, several drivers (ast, sis) already depend on this.
>
> Signed-off-by: David Herrmann
Back when I've reworked drm_mm I was still a rookie and didn't wa
This is a bit messed up because chan->cli->mutex is a different class,
depending on whether it is the global drm client or not. This is
because the global cli->mutex lock can be taken for eviction,
so locking it before pinning the buffer objects may result in a deadlock.
The locking order from out
On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote:
> +
> +out_close:
> + if (dev->driver->postclose)
> + dev->driver->postclose(dev, priv);
> +out_free:
> kfree(priv);
> filp->private_data = NULL;
> return ret;
Looks like we are also missing:
if (drm_
org/archives/dri-devel/attachments/20130701/a9ba1f26/attachment.html>
On Mon, Jul 01, 2013 at 07:44:14PM +0900, Seung-Woo Kim wrote:
> seq of a trace point is unsigned int but print format was %d. So
> it fixes the format as %u.
>
> Signed-off-by: Seung-Woo Kim
> Signed-off-by: Kyungmin Park
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Te
On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
> On 07/01/13 02:01, Dave Airlie wrote:
> >how about instead of writing:
> >"However, at least I've taken the time to_think_ about what I'm doing
> >and realise that there_is_ scope here for the DRM core to improve,
> >rather
On Mon, Jul 1, 2013 at 2:32 PM, David Herrmann wrote:
> Hi
>
> I picked up the initial work from Dave [1], fixed several bugs, rewrote the
> drm_mm node handling and adjusted the different drivers.
> The series tries to replace the VMA-offset managers from GEM and TTM with a
> single unified imple
Instead of unmapping the nodes in TTM and GEM users manually, we provide
a generic wrapper which does the correct thing for all vma-nodes.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c| 8 +---
include/drm/drm_vma_manager.h
Use the new vma manager instead of the old hashtable. Also convert all
drivers to use the new convenience helpers. This drops all the
(map_list.hash.key << PAGE_SHIFT) non-sense.
Locking and access-management is exactly the same as before with an
additional lock inside of the vma-manager, which st
Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.
Even though the vma-manager uses its own locks, we still need bo->vm_lock
to prevent bos from being destroyed before we can get a reference during
look
If we want to map GPU memory into user-space, we need to linearize the
addresses to not confuse mm-core. Currently, GEM and TTM both implement
their own offset-managers to assign a pgoff to each object for user-space
CPU access. GEM uses a hash-table, TTM uses an rbtree.
This patch provides a unif
This helper tests whether a given node is currently linked into a drm_mm
manager. We use the node->mm pointer for that as it is set for all linked
objects.
We also reset node->mm whenever a node is removed. All such access is
currently safe as everyone calls kfree() on the object directly after
re
There is no reason to return "int" as this function never fails.
Furthermore, several drivers (ast, sis) already depend on this.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c| 8 ++--
drivers/gpu/drm/drm_mm.c | 4 +---
drivers/gpu/drm/ttm/ttm_bo.c
On Mon, Jul 01, 2013 at 07:28:49PM +0900, Seung-Woo Kim wrote:
> Hello Chris,
>
> Thank you for reviewing.
>
> On 2013? 07? 01? 19:23, Chris Wilson wrote:
> > On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote:
> >> seq of a trace point is unsigned int but print format was %d. So
> >>
Hi
I picked up the initial work from Dave [1], fixed several bugs, rewrote the
drm_mm node handling and adjusted the different drivers.
The series tries to replace the VMA-offset managers from GEM and TTM with a
single unified implementation. It uses the TTM RBTree idea to allow sub-mappings
(whic
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/20130701/ae5ef02c/attachment.html>
On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote:
> seq of a trace point is unsigned int but print format was %d. So
> it fixes the format as %u even the format can be not used.
I don't understand what you mean here. The patch itself looks fine.
> Signed-off-by: Seung-Woo Kim
> Sign
On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote:
> If raw_edid is null, it will crash, so checking in bad label is
> meaningless.
It would be an error on part of the caller, but the defense looks sane.
As the function is a bool, I would have preferred it returned
true/false, but your
On Mon, Jul 01, 2013 at 07:06:33PM +0900, Seung-Woo Kim wrote:
> From: YoungJun Cho
>
> There are wrong cases to handle error in drm_open_helper().
> The priv->minor, assigned by idr_find() which can return NULL,
> should be checked whether it is NULL or not before referencing it.
> And if an err
From: YoungJun Cho
The exynos_drm_gem_create() only calls drm_gem_object_release()
when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains
as a leak, which is allocated in exynos_drm_gem_init().
So this patch fixes it not to remain as a leak.
Signed-off-by: YoungJun Cho
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=65310
Emil Velikov changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter
wrote:
> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote:
>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130628:
>>>
>>> The regulator tree gained a build failure so I used the version from
>>>
On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote:
> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> Changes since 20130628:
>>
>> The regulator tree gained a build failure so I used the version from
>> next-20130628.
>>
>> The trivial tree gained a conflict against t
On 07/01/13 02:01, Dave Airlie wrote:
> how about instead of writing:
> "However, at least I've taken the time to_think_ about what I'm doing
> and realise that there_is_ scope here for the DRM core to improve,
> rather than burying this stuff deep inside my driver like everyone else
> has. That
On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Changes since 20130628:
>
> The regulator tree gained a build failure so I used the version from
> next-20130628.
>
> The trivial tree gained a conflict against the fbdev tree.
>
> The arm-soc tree gained a conflict against the
On Mon, Jul 1, 2013 at 10:17 AM, Russell King - ARM Linux
wrote:
> On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
>> OMG I'm working in a subsystem where stuff is being developed, with only
>> a few resources! I know my full time job isn't maintaining a 500,000
>> line subsystem,
>>
On Sun, Jun 30, 2013 at 10:52 PM, Russell King - ARM Linux
wrote:
> On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
>> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
>> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
>> > +{
>> > + struct
On 06/28/2013 04:11 AM, David Herrmann wrote:
> Hi
>
> On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren
> wrote:
>> On 06/24/2013 04:27 PM, David Herrmann wrote:
>>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>>> x86 causes troubles when loading multiple fbdev driv
The error path does this:
for (--i; i >= 0; --i) {
which is a forever loop because "i" is unsigned.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_test.c
b/drivers/gpu/drm/radeon/radeon_test.c
index f4d6bce..12e8099 100644
--- a/drivers/gpu/drm/radeon/radeon_t
It should be ">=" instead of ">" here. The table->mc_reg_address[]
array has SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE (16) elements.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index bab0185..55491e7 100644
--- a/drivers/gpu/drm/rade
On 06/28/2013 04:11 AM, David Herrmann wrote:
> Hi
>
> On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren
> wrote:
>> On 06/24/2013 04:27 PM, David Herrmann wrote:
>>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>>> x86 causes troubles when loading multiple fbdev driv
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #29 from Stefan Dösinger ---
Hmm, this seems like an idea worth thinking about. The D3D behavior the
proposed extension addresses is part of the D3DDECLUSAGE_POSITIONT /
D3DFVF_XYZRHW vertex input semantics.
For now I'm opposed to ma
On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson wrote:
> On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote:
>> If raw_edid is null, it will crash, so checking in bad label is
>> meaningless.
>
> It would be an error on part of the caller, but the defense looks sane.
> As the function is
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #24 from madbiologist ---
The fix is now also in Mesa 9.1.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.
Hi Sergei,
On Thursday 27 June 2013 17:04:45 Sergei Shtylyov wrote:
> On 27-06-2013 13:49, Laurent Pinchart wrote:
> > Replace the devm_request_mem_region() and devm_ioremap_nocache() calls
> > with devm_ioremap_resource().
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #1 from Alex Deucher ---
This is a mac?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=63520
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hello Chris,
On Jul 1, 2013 8:53 PM, "Chris Wilson" wrote:
>
> On Mon, Jul 01, 2013 at 08:14:42PM +0900, Seung-Woo Kim wrote:
> > Hello Chris,
> >
> > On 2013년 07월 01일 19:57, Chris Wilson wrote:
> > > On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote:
> > >> +
> > >> +out_close:
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=66452
Priority: medium
Bug ID: 66452
Assignee: dri-devel@lists.freedesktop.org
Summary: JUNIPER UVD accelerated playback of WMV3 streams does
not work
Severity: normal
Classifi
On Mon, Jul 01, 2013 at 08:14:42PM +0900, Seung-Woo Kim wrote:
> Hello Chris,
>
> On 2013년 07월 01일 19:57, Chris Wilson wrote:
> > On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote:
> >> +
> >> +out_close:
> >> + if (dev->driver->postclose)
> >> + dev->driver->postclose(dev, p
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Priority: medium
Bug ID: 66450
Assignee: dri-devel@lists.freedesktop.org
Summary: JUNIPER UVD accelerated playback of MPEG 1/2 streams
does not work
Severity: normal
Cla
Hello Chris,
On 2013년 07월 01일 19:57, Chris Wilson wrote:
> On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote:
>> +
>> +out_close:
>> +if (dev->driver->postclose)
>> +dev->driver->postclose(dev, priv);
>> +out_free:
>> kfree(priv);
>> filp->private_data = NULL;
On 07/01/13 11:42, Daniel Vetter wrote:
On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
at least on this point I do share Russell's impression. I've sent
bunch of patches improving TDA998x and DRM+DT:
- TDA998x irq handling - ignored
- TDA998x sync fix - ignored
- Fix drm
On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter wrote:
> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote:
>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130628:
>>>
>>> The regulator tree gained a build failure so I used the version from
>>>
On 07/01/13 02:01, Dave Airlie wrote:
how about instead of writing:
"However, at least I've taken the time to_think_ about what I'm doing
and realise that there_is_ scope here for the DRM core to improve,
rather than burying this stuff deep inside my driver like everyone else
has. That's no re
On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
> OMG I'm working in a subsystem where stuff is being developed, with only
> a few resources! I know my full time job isn't maintaining a 500,000
> line subsystem,
> and the sub maintainers and developers do a great job refactoring
> wher
when opencl is
disabled.
--
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/20130701/75020fd5/attachment.html>
On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote:
> +
> +out_close:
> + if (dev->driver->postclose)
> + dev->driver->postclose(dev, priv);
> +out_free:
> kfree(priv);
> filp->private_data = NULL;
> return ret;
Looks like we are also missing:
if (drm_
On Mon, Jul 01, 2013 at 07:44:14PM +0900, Seung-Woo Kim wrote:
> seq of a trace point is unsigned int but print format was %d. So
> it fixes the format as %u.
>
> Signed-off-by: Seung-Woo Kim
> Signed-off-by: Kyungmin Park
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Te
From: YoungJun Cho
There are wrong cases to handle error in drm_open_helper().
The priv->minor, assigned by idr_find() which can return NULL,
should be checked whether it is NULL or not before referencing it.
And if an error occurs after executing dev->driver->open() which
allocates driver specif
seq of a trace point is unsigned int but print format was %d. So
it fixes the format as %u.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
change from v1
- remove wrong commit messageas Chris commented
drivers/gpu/drm/drm_trace.h |6 +++---
1 files changed, 3 insertions(+),
On Mon, Jul 01, 2013 at 07:28:49PM +0900, Seung-Woo Kim wrote:
> Hello Chris,
>
> Thank you for reviewing.
>
> On 2013년 07월 01일 19:23, Chris Wilson wrote:
> > On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote:
> >> seq of a trace point is unsigned int but print format was %d. So
> >>
Hello Chris,
Thank you for reviewing.
On 2013년 07월 01일 19:23, Chris Wilson wrote:
> On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote:
>> seq of a trace point is unsigned int but print format was %d. So
>> it fixes the format as %u even the format can be not used.
>
> I don't underst
On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote:
> seq of a trace point is unsigned int but print format was %d. So
> it fixes the format as %u even the format can be not used.
I don't understand what you mean here. The patch itself looks fine.
> Signed-off-by: Seung-Woo Kim
> Sig
On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote:
> If raw_edid is null, it will crash, so checking in bad label is
> meaningless.
It would be an error on part of the caller, but the defense looks sane.
As the function is a bool, I would have preferred it returned
true/false, but your
On Mon, Jul 01, 2013 at 07:06:33PM +0900, Seung-Woo Kim wrote:
> From: YoungJun Cho
>
> There are wrong cases to handle error in drm_open_helper().
> The priv->minor, assigned by idr_find() which can return NULL,
> should be checked whether it is NULL or not before referencing it.
> And if an err
From: YoungJun Cho
There are wrong cases to handle error in drm_open_helper().
The priv->minor, assigned by idr_find() which can return NULL,
should be checked whether it is NULL or not before referencing it.
And if an error occurs after executing dev->driver->open() which
allocates driver specif
If raw_edid is null, it will crash, so checking in bad label is
meaningless.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_edid.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edi
seq of a trace point is unsigned int but print format was %d. So
it fixes the format as %u even the format can be not used.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_trace.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dri
This patch series fixes minor code issues including wrong trace point foramts,
meaningless null checking, and possible resource leak in error cases.
This is based drm-next branch.
Seung-Woo Kim (2):
drm: fix print format of sequence in trace point
drm: move edid null check to the first part
This is a bit messed up because chan->cli->mutex is a different class,
depending on whether it is the global drm client or not. This is
because the global cli->mutex lock can be taken for eviction,
so locking it before pinning the buffer objects may result in a deadlock.
The locking order from out
or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/003fb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
> On 07/01/13 02:01, Dave Airlie wrote:
> >how about instead of writing:
> >"However, at least I've taken the time to_think_ about what I'm doing
> >and realise that there_is_ scope here for the DRM core to improve,
> >rather
On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote:
> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> Changes since 20130628:
>>
>> The regulator tree gained a build failure so I used the version from
>> next-20130628.
>>
>> The trivial tree gained a conflict against t
vanced Error Reporting
Kernel driver in use: radeon
Kernel modules: radeon
--
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
On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
> OMG I'm working in a subsystem where stuff is being developed, with only
> a few resources! I know my full time job isn't maintaining a 500,000
> line subsystem,
> and the sub maintainers and developers do a great job refactoring
> wher
From: YoungJun Cho
When the exynos_drm_subdrv_open() returns error, the file_priv
should be released and file->driver_priv set to NULL.
Signed-off-by: YoungJun Cho
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |9 -
1 file changed, 8 insertions(+), 1 del
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130701/cabf4c07/attachment.html>
101 - 174 of 174 matches
Mail list logo
