e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/e66ca7d0/attachment.html>
ttm_agp_tt_create is itself defined under CONFIG_AGP, so there's no
point calling it otherwise.
Signed-off-by: Max Filippov
---
This fixes allmodconfig build failure for xtensa:
http://kisskb.ellerman.id.au/kisskb/buildresult/7346547/
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
1 files cha
On Thu, Oct 11, 2012 at 12:39 PM, Tapani P?lli
wrote:
> On 10/10/2012 08:05 PM, Chad Versace wrote:
>> On 10/07/2012 10:50 PM, Tapani P?lli wrote:
>>> Upstreaming old set of patches here to enable Android support in libdrm.
>>> Some little rebasing was required for the first one.
>>>
>>> Chad Ver
This patch moved the exynos-drm-hdmi platform device registration to the drm
driver. When DT is enabled, platform devices needs to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos
This patch moved the exynos-drm platform device registration to the drm driver.
When DT is enabled, platform devices needs to be registered within the driver
code. This patch fits the requirement of both DT and Non DT based drm drivers.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exyn
This patch adds drm-exynos and drm-exynos-hdmi device registration to the
drm driver. It was happening in machine init code earlier which is not
acceptable for dt enabled platforms.
Patch which cleans the respective code from arch/arm is "arm: exynos:
removing exynos-drm device registration from
layer works OK for me.
--
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/20121012/657a346e/attachment.html>
All items on the lru list are always reservable, so this is a stupid
thing to keep. Not only that, it is used in a way which would
guarantee deadlocks if it were ever to be set to block on reserve.
This is a lot of churn, but mostly because of the removal of the
argument which can be nested arbitr
On Fri, Oct 12, 2012 at 7:49 PM, Rob Clark wrote:
> From: Rob Clark
>
> This is following a bit the approach that Ville is taking for atomic-
> modeset, in that it is switching over to using properties for everything.
> The advantage of this approach is that it makes it easier to add new
> attrib
From: Rob Clark
---
drivers/staging/omapdrm/Makefile |1 +
drivers/staging/omapdrm/omap_atomic.c | 347 +
drivers/staging/omapdrm/omap_atomic.h | 52 +
drivers/staging/omapdrm/omap_crtc.c | 231 +++---
drivers/staging/omapdrm/oma
From: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 75
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |2 ++
include/drm/drm_crtc.h |2 ++
include/drm/drm_mode.h | 38 ++
5 files changed, 118 inse
From: Rob Clark
Start breaking out the mutable state of the CRTC into it's own
structure. Plus add _check_state() and _set_property() helpers.
This only moves the state that is related to scanout fb, which
is needed for nuclear-pageflip. The rest of the mutable state
should be moved from drm_cr
From: Rob Clark
Use atomic properties mechanism for CRTC page_flip. This by itself
doesn't accomplish anything, but it avoids having multiple code
paths to do the same thing when nuclear-pageflip and atomic-modeset
are introduced.
---
drivers/gpu/drm/drm_crtc.c | 167 ++
From: Rob Clark
Break the mutable state of a plane out into a separate structure.
This makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific
From: Rob Clark
Use atomic properties mechanism to set plane attributes. This by
itself doesn't accomplish anything, but it avoids having multiple
code paths to do the same thing when nuclear-pageflip and atomic-
modeset are introduced.
---
drivers/gpu/drm/drm_crtc.c | 278
From: Rob Clark
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
---
drivers/gpu/drm/drm_crtc.c | 29
From: Rob Clark
Flag for range property types indicating that the value is a signed
integer rather than unsigned. For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
drivers/gpu/drm/drm_crtc.c | 10 --
include/
From: Rob Clark
This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable. This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to compo
From: Rob Clark
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
drivers/gpu/drm/drm_crtc.c | 33 +
include/drm/drm_crtc.h | 10 ++
include/drm/drm_mode.h |
From: Rob Clark
The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically. This will be the basis of atomic-
modeset and nuclear-pageflip.
The basic flow is:
state = dev->atomic_begin();
for (... one or more ...)
obj->set_property(obj, st
From: Rob Clark
This is following a bit the approach that Ville is taking for atomic-
modeset, in that it is switching over to using properties for everything.
The advantage of this approach is that it makes it easier to add new
attributes to set as part of a page-flip (and even opens the option
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> the
From: Rob Clark
When the fb is detached from one CRTC/plane, paddr was set back to
zero. But really we don't want to do this because the fb could still
be attached to other CRTC/plane(s). This originally worked like this
to catch cases of freeing a pinned fb (but with the refcnt'ing this
should
From: Rob Clark
A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior (since
there are a lot of drivers that don't use drm_vblank_count_and_time())
Al
On Fri, Oct 12, 2012 at 7:49 PM, Rob Clark wrote:
> From: Rob Clark
>
> This is following a bit the approach that Ville is taking for atomic-
> modeset, in that it is switching over to using properties for everything.
> The advantage of this approach is that it makes it easier to add new
> attrib
From: Rob Clark
---
drivers/staging/omapdrm/Makefile |1 +
drivers/staging/omapdrm/omap_atomic.c | 347 +
drivers/staging/omapdrm/omap_atomic.h | 52 +
drivers/staging/omapdrm/omap_crtc.c | 231 +++---
drivers/staging/omapdrm/oma
From: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 75
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |2 ++
include/drm/drm_crtc.h |2 ++
include/drm/drm_mode.h | 38 ++
5 files changed, 118 inse
From: Rob Clark
Start breaking out the mutable state of the CRTC into it's own
structure. Plus add _check_state() and _set_property() helpers.
This only moves the state that is related to scanout fb, which
is needed for nuclear-pageflip. The rest of the mutable state
should be moved from drm_cr
From: Rob Clark
Use atomic properties mechanism for CRTC page_flip. This by itself
doesn't accomplish anything, but it avoids having multiple code
paths to do the same thing when nuclear-pageflip and atomic-modeset
are introduced.
---
drivers/gpu/drm/drm_crtc.c | 167 ++
From: Rob Clark
Break the mutable state of a plane out into a separate structure.
This makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific
From: Rob Clark
Use atomic properties mechanism to set plane attributes. This by
itself doesn't accomplish anything, but it avoids having multiple
code paths to do the same thing when nuclear-pageflip and atomic-
modeset are introduced.
---
drivers/gpu/drm/drm_crtc.c | 278
From: Rob Clark
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
---
drivers/gpu/drm/drm_crtc.c | 29
From: Rob Clark
Flag for range property types indicating that the value is a signed
integer rather than unsigned. For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
drivers/gpu/drm/drm_crtc.c | 10 --
include/
From: Rob Clark
This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable. This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to compo
From: Rob Clark
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
drivers/gpu/drm/drm_crtc.c | 33 +
include/drm/drm_crtc.h | 10 ++
include/drm/drm_mode.h |
From: Rob Clark
The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically. This will be the basis of atomic-
modeset and nuclear-pageflip.
The basic flow is:
state = dev->atomic_begin();
for (... one or more ...)
obj->set_property(obj, st
From: Rob Clark
This is following a bit the approach that Ville is taking for atomic-
modeset, in that it is switching over to using properties for everything.
The advantage of this approach is that it makes it easier to add new
attributes to set as part of a page-flip (and even opens the option
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
[l/
On 11.10.12 16:19, Laurent Pinchart wrote:
Hi Rob,
Thanks for the patch.
On Monday 08 October 2012 14:50:39 Rob Clark wrote:
From: Rob Clark
...
Do you know why some drivers don't call drm_vblank_count_and_time() ? For
instance nouveau sets the sequence to 0 and uses do_gettimeofday(), b
nts/20121012/6d88f97f/attachment.html>
With the nouveau calls fixed there were only 2 places left that used
fence_lock without a reservation, those are fixed in this patch:
ttm_bo_cleanup_refs_or_queue is fixed by simply doing things the other
way around.
ttm_bo_cleanup_refs is fixed by taking a reservation first, then a pointer
to th
Just use the return error from ttm_mem_evict_first instead.
Since ttm_mem_evict_first does the same check, the error message
from that function can be used.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 ---
1 file changed, 8 insertions(+), 19
This will otherwise cause a lockdep splat, so warn when nouveau
forgets to unpin a buffer, and fix up the ones I've hit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 +
drivers/gpu/drm/nouveau/nouveau_gem.c
This will otherwise cause a lockdep splat, so warn when nouveau
forgets to unpin a buffer, and fix up the ones I've hit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 +
drivers/gpu/drm/nouveau/nouveau_gem.c
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 16
drivers/gpu/drm/nouveau/nouveau_bo.h |1 +
drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 22 ++
1 fi
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
drivers/gpu/drm/radeon/radeon_ttm.c|7 +++
drivers/gpu/drm/ttm/ttm_bo.c |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |7 +++
include/drm/ttm/ttm_bo_driver.h|
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c|1 -
include/drm/ttm/ttm_bo_driver.h |3 ---
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drive
vmwgfx was its only user and always sets it to the same..
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 -
drivers/gpu/drm/ttm/ttm_bo_util.c |1 -
drivers/gpu/drm/ttm/ttm_execbuf_util.c |1 -
include/drm/ttm/ttm_bo_api.h |
It's always hardcoded to the same value.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 15 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4
3 files changed, 4 insertions(+), 22 delet
From: Rob Clark
When the fb is detached from one CRTC/plane, paddr was set back to
zero. But really we don't want to do this because the fb could still
be attached to other CRTC/plane(s). This originally worked like this
to catch cases of freeing a pinned fb (but with the refcnt'ing this
should
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index 3ce68a2..bd78257 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dma
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/radeon_object.c |6 +++---
drivers/gpu/drm/radeon/radeon_object.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/dri
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
include/drm/ttm/ttm_bo_api.h | 14 ++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index be1148e..d9d8541 100644
---
From: Rob Clark
A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior (since
there are a lot of drivers that don't use drm_vblank_count_and_time())
Al
Nobody uses it, so might as well simplify the code some.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 41
drivers/gpu/drm/ttm/ttm_bo_util.c |1 -
drivers/gpu/drm/ttm/ttm_execbuf_util.c |9
https://bugs.freedesktop.org/show_bug.cgi?id=55913
--- Comment #2 from francesco ---
Yes, really, is a issue of mplayer2, with mplayer I don't have any problem, you
can close this bug. Xv is more efficient on my pc.
--
You are receiving this mail because:
You are the assignee for the bug.
_
From: "Luis R. Rodriguez"
No functional changes.
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: devel at driverdev.osuosl.org
Cc: backports at vger.kernel.org
Cc: Rob Clark
Cc: Arnd Bergmann
Cc: Dave Jones
Cc: David Airlie
Cc: Ben Skeggs
Cc: Alan Cox
Cc: Da
From: "Luis R. Rodriguez"
The UAPI changes split kernel API and userspace API
content onto two separate header files. The userspace
API drm content was moved to include/uapi/drm/ with the
same file name while kernel specific API content was
kept under include/drm/ with the same file name. When
on
From: "Luis R. Rodriguez"
Here are a few minor updates to the UAPI changes [0]. The first
one is to help with the backport effort [1], the second one is
simply space cosmetic change to address my eyes bleeding
while reviewing the changes on next-20121012 with git.
If the changes on
On 10.10.12 13:03, Rob Clark wrote:
On Tue, Oct 9, 2012 at 10:33 PM, Mario Kleiner
wrote:
On 08.10.12 21:50, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c | 31
++-
1 file changed, 6 insertions(+), 25 de
radeon_cs_gem.c:333:13: warning: 'cs_gem_dump_bof' defined but
not used [-Wunused-function]
---
radeon/radeon_cs_gem.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 9834bcf..b963140 100644
--- a/radeon/radeon_cs_gem.
When firmware loading fails eg due to running a newer kernel and hardware
on an older distro, prevent the user confusing this subsequent warning
backtrace with the real issue further up, ie "failed to load firmware",
which doesn't produce a backtrace.
Signed-off-by: Daniel J Blueman
---
drivers/
Negreanu Marius writes:
> On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote:
>> On 10/10/2012 08:05 PM, Chad Versace wrote:
>>> On 10/07/2012 10:50 PM, Tapani Pälli wrote:
Upstreaming old set of patches here to enable Android support in libdrm.
Some little rebasing was required for
flects the upstream
build system better in android, and maybe over time that tool can be
improved so that android building of upstream projects is less of a
burden (seriously, why should you have to manually name the sources and
flags variables?).
That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable
result in complaints from automake?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/ff64ec2c/attachment.pgp>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121012/5d0fe90b/attachment.html>
/libOSMesa.so.7.11.0
./lib/libOSMesa.so.7
./lib/libOSMesa.so
with make linux -k
--
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/20121
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/15cd9fdf/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=55913
--- Comment #1 from Andy Furniss ---
(In reply to comment #0)
> Created attachment 68485 [details]
> vdpau output
>
> You said was now ready vdpau but when I try to watch a movie with this
> output on my radeon 4650 , the video run with some lag
sktop.org/archives/dri-devel/attachments/20121012/5e4ada15/attachment-0001.html>
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/20121012/1935fe82/attachment.html>
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/7b3cbc83/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/77051570/attachment.html>
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote:
> On 10/10/2012 08:05 PM, Chad Versace wrote:
>> On 10/07/2012 10:50 PM, Tapani Pälli wrote:
>>> Upstreaming old set of patches here to enable Android support in libdrm.
>>> Some little rebasing was required for the first one.
>>>
>>> Chad Vers
Hi Tomasz,
On Friday 12 October 2012 09:44:05 Tomasz Stanislawski wrote:
> On 10/11/2012 11:36 PM, Laurent Pinchart wrote:
> > On Wednesday 10 October 2012 16:46:41 Tomasz Stanislawski wrote:
> >> From: Marek Szyprowski
> >>
> >> The DMA transfer must be aligned to a specific value. If userptr i
Hi Tomasz,
On Friday 12 October 2012 08:28:23 Tomasz Stanislawski wrote:
> On 10/11/2012 11:49 PM, Laurent Pinchart wrote:
> > On Wednesday 10 October 2012 16:46:40 Tomasz Stanislawski wrote:
> >> This patch adds taking reference to the device for MMAP buffers.
> >>
> >> Such buffers, may be expo
On Fri, Oct 12, 2012 at 11:18 AM, Andy Gross wrote:
> During asynchronous refills, we don't wait for the refill to
> finish. However, we cannot release the engine back to the idle
> list until it has actually completed the refill operation. The
> engine release will now be done in the IRQ handle
During asynchronous refills, we don't wait for the refill to
finish. However, we cannot release the engine back to the idle
list until it has actually completed the refill operation. The
engine release will now be done in the IRQ handler, but only
for asynchronous refill operations.
Synchronous
All items on the lru list are always reservable, so this is a stupid
thing to keep. Not only that, it is used in a way which would
guarantee deadlocks if it were ever to be set to block on reserve.
This is a lot of churn, but mostly because of the removal of the
argument which can be nested arbitr
On Thu, Oct 11, 2012 at 2:26 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Wednesday 12 September 2012 22:49:47 Rob Clark wrote:
>> From: Rob Clark
>>
>> The 'atomic' mechanism allows for multiple properties to be updated,
>> checked, and commited atomically. This will be the basis of atomic-
>>
Hi Dave,
A bit of paranoid-WARNs fallout from modeset, otherwise just small
fixlets:
- some register magic to fix hsw crw (Paulo&Ben)
- fix backlight destruction for cpu edp (Jani)
- fix gen ch7xxx dvo ->get_hw_state
- fixup the plane->pipe fixup code, the broken version massively angers
the mod
Please disregard this mail. Wrong patch sent
On 10/12/2012 10:56 AM, Andy Gross wrote:
> During asynchronous refills, we don't wait for the refill to
> finish. However, we cannot release the engine back to the idle
> list until it has actually completed the refill operation. The
> engine releas
During asynchronous refills, we don't wait for the refill to
finish. However, we cannot release the engine back to the idle
list until it has actually completed the refill operation. The
engine release will now be done in the IRQ handler, but only
for asynchronous refill operations.
Synchronous
https://bugs.freedesktop.org/show_bug.cgi?id=26345
Chris Wilson changed:
What|Removed |Added
CC||tang...@gmx.com
--- Comment #150 from Chr
Hi Laurent,
On 10/11/2012 11:31 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote:
>> Most operations on DMA and DMABUF framework need page
>> aligned buffers.
>
> The comment is a bit misleading, the buffer is already page-aligned (unle
On Oct 8, 2012, at 5:52 AM, Tapani Pälli wrote:
> From: Haitao Huang
>
> Export necessary header files used by other components for Android,
> such as libva intel-driver, gralloc, hwcomposer, etc.
>
> Signed-off-by: Haitao Huang
> Signed-off-by: Chad Versace
Glad to see this getting submit
On Oct 8, 2012, at 5:52 AM, Tapani P?lli wrote:
> From: Haitao Huang
>
> Export necessary header files used by other components for Android,
> such as libva intel-driver, gralloc, hwcomposer, etc.
>
> Signed-off-by: Haitao Huang
> Signed-off-by: Chad Versace
Glad to see this getting submit
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> the
On Fri 12 October 2012 09:44:05 Tomasz Stanislawski wrote:
> Hi Laurent,
> Thank you for the review.
> Please refer to the comments below.
>
> On 10/11/2012 11:36 PM, Laurent Pinchart wrote:
> > Hi Tomasz,
> >
> > Thanks for the patch.
> >
> > On Wednesday 10 October 2012 16:46:41 Tomasz Stanisl
platform_driver_unregister(&mixer_driver);
> platform_driver_unregister(&hdmi_driver);
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/9bac1e46/attachment.html>
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
On 10/12/2012 08:44 AM, Rob Clark wrote:
>
> US);
>
> for (i = 0; i < dmm->num_engines; i++) {
> - if (status & DMM_IRQSTAT_LST)
> + if (status & DMM_IRQSTAT_LST) {
>
> wake_up_interruptible(&dmm->engines[i].wait_for_refill);
>
> +
Hi Laurent,
Thank you for the review.
Please refer to the comments below.
On 10/11/2012 11:36 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> On Wednesday 10 October 2012 16:46:41 Tomasz Stanislawski wrote:
>> From: Marek Szyprowski
>>
>> The DMA transfer must be aligned
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
[l/
On Fri, Oct 12, 2012 at 11:18 AM, Andy Gross wrote:
> During asynchronous refills, we don't wait for the refill to
> finish. However, we cannot release the engine back to the idle
> list until it has actually completed the refill operation. The
> engine release will now be done in the IRQ handle
On Thu, Oct 11, 2012 at 09:31:18PM +0200, Thierry Reding wrote:
> On Mon, Oct 08, 2012 at 09:49:21AM +0200, Steffen Trumtrar wrote:
> > On Mon, Oct 08, 2012 at 10:07:45AM +0300, Tomi Valkeinen wrote:
> > > On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
> [...]
> > > > +
> > > > +
During asynchronous refills, we don't wait for the refill to
finish. However, we cannot release the engine back to the idle
list until it has actually completed the refill operation. The
engine release will now be done in the IRQ handler, but only
for asynchronous refill operations.
Synchronous
On Thu, Oct 11, 2012 at 2:26 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Wednesday 12 September 2012 22:49:47 Rob Clark wrote:
>> From: Rob Clark
>>
>> The 'atomic' mechanism allows for multiple properties to be updated,
>> checked, and commited atomically. This will be the basis of atomic-
>>
Please disregard this mail. Wrong patch sent
On 10/12/2012 10:56 AM, Andy Gross wrote:
During asynchronous refills, we don't wait for the refill to
finish. However, we cannot release the engine back to the idle
list until it has actually completed the refill operation. The
engine release will
1 - 100 of 150 matches
Mail list logo
