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
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 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
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox wrote:
>> The whole purpose of this API is to let DRM and V4L drivers share buffers for
>> zero-copy pipelines. Unfortunately it is a fact that several popular DRM
>> drivers
>> are closed source. So we have a choice between keeping the export symbols GPL
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>
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
make sure that a waiting reserve is never done in
1 (fail).
--
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/ad508e3c/attachment.html>
Hi Laurent,
Thank your your review.
On 10/11/2012 11:49 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> 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 exported
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:
> [...]
> > > > +
> > > > +
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
ither, and attach the terminal output from ET?
--
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/8d18f2cf/attachment-0001.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 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
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 Fri, Oct 12, 2012 at 6:22 AM, Inki Dae wrote:
>
>
> 2012? 10? 12? Rahul Sharma?? ??:
>
>> 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
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
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 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
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/
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
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
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
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
>>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/77051570/attachment.html>
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>
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>
sktop.org/archives/dri-devel/attachments/20121012/5e4ada15/attachment-0001.html>
On Thu, Oct 11, 2012 at 11:08 PM, 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
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.
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/15cd9fdf/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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121012/5d0fe90b/attachment.html>
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);
>
> +
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
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
---
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/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
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
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 |
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
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|
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 | 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
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
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
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
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
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
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-
>>
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 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
> > 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 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 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
nts/20121012/6d88f97f/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 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
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>
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>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/e66ca7d0/attachment.html>
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
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
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
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
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
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
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
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
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
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 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
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
---
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
---
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
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
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
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
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"
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
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:
> [...]
> > > > +
> > > > +
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
https://bugs.freedesktop.org/show_bug.cgi?id=40211
--- Comment #14 from Michel Dänzer ---
Okay, but I still wonder why Wine ends up with indirect rendering, and if
that's the case for ET as well.
Can you see if running with the environment variable LIBGL_DEBUG=verbose gives
any hints for either,
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 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
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 Fri, Oct 12, 2012 at 6:22 AM, Inki Dae wrote:
>
>
> 2012? 10? 12? Rahul Sharma?? ??:
>
>> 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
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
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 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
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/
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
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
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
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
>>
https://bugs.freedesktop.org/show_bug.cgi?id=55913
Priority: medium
Bug ID: 55913
Assignee: dri-devel@lists.freedesktop.org
Summary: Vdpau driver lag
Severity: major
Classification: Unclassified
OS: Linux (All)
Repo
https://bugs.freedesktop.org/show_bug.cgi?id=55913
francesco changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this mail because
https://bugs.freedesktop.org/show_bug.cgi?id=55913
Michel Dänzer changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=55919
Priority: medium
Bug ID: 55919
Assignee: dri-devel@lists.freedesktop.org
Summary: fatal error: nouveau/nouveau_device.h: No such file or
directory
Severity: major
Classif
On Thu, Oct 11, 2012 at 11:08 PM, 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
1 - 100 of 150 matches
Mail list logo
