for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/1d48e837/attachment.html>
ves/dri-devel/attachments/20140911/1b7493c8/attachment.html>
//lists.freedesktop.org/archives/dri-devel/attachments/20140911/bb539874/attachment.html>
On 2014? 09? 10? 19:24, Andrzej Hajda wrote:
> Hi Inki,
>
> To test it properly I have to fix init/remove bugs [1].
> Of course these bugs were not introduced by this patch,
> but they prevented some basic tests.
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
>
> I have
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/f1718bab/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/5b6271bf/attachment.html>
ceiving 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/20140911/d92cc6b1/attachment.html>
On 2014? 09? 10? 18:01, Daniel Vetter wrote:
> Ok I've stumbled over the exynos mmap stuff again while cleaning up
> drm legacy cruft and I just don't get what you're doing and why
> exactly exynos needs to be special.
>
> _All_ other drm drivers happily get along with the vma offset manger
> stuf
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #9 from Javier Fernandez ---
well, actually i havent tested upstream versions of 3.16 kernels, only Ubuntu
kernels (which are patched)
thats why i ask about installing upstream ones...
what do u think?
Also, i can remember earlier r
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #10 from Javier Fernandez ---
the kernel i am using now and on which open source driver is working is
3.16.0-14-lowlatency
--
You are receiving this mail because:
You are watching the assignee of the bug.
|.org|
--
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/20140911/13dc6ba2/attachment.html>
On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote:
> On 2014? 09? 10? 18:01, Daniel Vetter wrote:
> > Ok I've stumbled over the exynos mmap stuff again while cleaning up
> > drm legacy cruft and I just don't get what you're doing and why
> > exactly exynos needs to be special.
> >
> > _All_
On Wed, Sep 10, 2014 at 04:42:04PM +0200, David Herrmann wrote:
> Hi
>
> On Wed, Sep 10, 2014 at 12:43 PM, Daniel Vetter
> wrote:
> > Also drop the unneeded EXPORT_SYMBOL and sprinkle drm_legacy_ prefixes
> > where missing.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_b
On Wed, Sep 10, 2014 at 04:43:31PM +0200, David Herrmann wrote:
> Hi
>
> On Wed, Sep 10, 2014 at 12:43 PM, Daniel Vetter
> wrote:
> > Also sprinkle the drm_legacy_ prefix where missing.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 4 ++--
> > drivers/gpu/drm
On 2014? 09? 10? 19:24, Andrzej Hajda wrote:
> Hi Inki,
>
> To test it properly I have to fix init/remove bugs [1].
> Of course these bugs were not introduced by this patch,
> but they prevented some basic tests.
I had tested my patch with trats2 board, and works well without below
patch set. hm.
7;ve tried both wine and wine-csmt, both have the same issue.
Thanks!
--
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/20140911/992b2a12/attachment.html>
On Wed, Sep 10, 2014 at 05:54:23PM +0200, David Herrmann wrote:
> Backlight devices have always been managed independently of display
> controllers. They're often controlled via different hardware interfaces
> and their relationship to display-controllers varies vastly between
> different boards. H
Hi,
On 09/11/2014 03:22 PM, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote:
>> On 2014? 09? 10? 18:01, Daniel Vetter wrote:
>>> Ok I've stumbled over the exynos mmap stuff again while cleaning up
>>> drm legacy cruft and I just don't get what you're doing and why
>
On 09/11/2014 08:37 AM, Inki Dae wrote:
> On 2014? 09? 10? 19:24, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> To test it properly I have to fix init/remove bugs [1].
>> Of course these bugs were not introduced by this patch,
>> but they prevented some basic tests.
> I had tested my patch with trats2 boa
Also drop the unneeded EXPORT_SYMBOL and sprinkle drm_legacy_ prefixes
where missing.
v2: Drop the confusing _core_ and drop extern, both suggested by
David.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 2 +-
drivers/gpu/drm/drm_dma.c| 10 --
Also sprinkle the drm_legacy_ prefix where missing.
v2: Drop extern from function declarations and include "drm_legacy.h"
in drm_scatter.c, spotted by David.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
drivers/gpu/drm/drm_legacy.h | 7 +++
d
A few odd cases:
- mgag200 someho had a totally unused drm_dma_handle_t. Remove it.
- i915 still uses the legacy pci dma alloc api, so grows an include.
Everything else fairly standard.
v2: Include "drm_legacy.h" in drm.ko source files for consistency.
Signed-off-by: Daniel Vetter
---
drivers/
On 2014? 09? 11? 15:22, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote:
>> On 2014? 09? 10? 18:01, Daniel Vetter wrote:
>>> Ok I've stumbled over the exynos mmap stuff again while cleaning up
>>> drm legacy cruft and I just don't get what you're doing and why
>>> ex
On 2014? 09? 11? 16:01, Joonyoung Shim wrote:
> Hi,
>
> On 09/11/2014 03:22 PM, Daniel Vetter wrote:
>> On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote:
>>> On 2014? 09? 10? 18:01, Daniel Vetter wrote:
Ok I've stumbled over the exynos mmap stuff again while cleaning up
drm legac
hat
still doesn't work, please provide the stderr debugging output about
raster_config.
--
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-d
On Wed, 10 Sep 2014, David Herrmann wrote:
> Use static initializers instead of setting up global variables during
> runtime. This reduces code size and execution time.
>
> Signed-off-by: David Herrmann
Reviewed-by: Jani Nikula
> ---
> drivers/video/backlight/backlight.c | 9 +++--
> 1 fi
On Wed, 10 Sep 2014, David Herrmann wrote:
> There is really no reason to use a mutex to protect a simple list. Convert
> the list-lock to a simple spinlock instead.
>
> The spin-locks prepare for a backlight_find() helper, which should
> preferably be usable from atomic context. A mutex would pre
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/77991362/attachment.html>
On Thu, Sep 11, 2014 at 04:22:00PM +0900, Inki Dae wrote:
> On 2014? 09? 11? 15:22, Daniel Vetter wrote:
> > On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote:
> >> On 2014? 09? 10? 18:01, Daniel Vetter wrote:
> >>> Ok I've stumbled over the exynos mmap stuff again while cleaning up
> >>> dr
no idea how to do that, nor I have time to learn - I'm
just a Ubuntu user with no technical skills.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.or
t.cgi?id=105745
--
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/20140911/38720f94/attachment-0001.html>
t --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/dcb34da8/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/a00cb2fe/attachment.html>
Hi Mario,
Can you please take a look at the patches I've submitted and review
them (at least the first 2)? Dave will close the 3.18 drm-next merge
window at the end of this week and I'd like to really get this in.
Thanks, Daniel
On Wed, Sep 10, 2014 at 5:45 PM, Mario Kleiner
wrote:
> On Wed, S
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/722b7bb5/attachment.sig>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/66ba7771/attachment.html>
e so:
priv->backlight = backlight_device_ref(bd);
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/661a9ada/attachment-0001.sig>
Hi
On Thu, Sep 11, 2014 at 1:10 PM, Thierry Reding
wrote:
> On Wed, Sep 10, 2014 at 05:54:22PM +0200, David Herrmann wrote:
> [...]
>> +void backlight_set_brightness(struct backlight_device *bd, unsigned int
>> value,
>> + enum backlight_update_reason reason)
>> +{
>> +
= backlight_device_unref(priv->backlight);
> to release a reference and reset the pointer at the same time.
That looks somewhat odd to me. Wouldn't priv->backlight typically go
away after the unref anyway (presumably because priv is going to get
freed soon after)?
But I have no strong objections to returning NULL from _unref(), if code
doesn't need it it can always choose not to use the return value.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/b882b62b/attachment.sig>
On 09/10/2014 05:36 PM, Daniel Vetter wrote:
> Imo u32 hints at a register value, but in reality all callers only
> care whether the sampled timestamp is precise or not. So give them
> just a bool.
>
> Also move the declaration out of drmP.h, it's only used in drm_irq.c.
All good. Maybe then also
On Thu, Sep 11, 2014 at 1:28 PM, Mario Kleiner
wrote:
> On 09/10/2014 05:36 PM, Daniel Vetter wrote:
>>
>> Imo u32 hints at a register value, but in reality all callers only
>> care whether the sampled timestamp is precise or not. So give them
>> just a bool.
>>
>> Also move the declaration out of
Hi there,
Here is a small modification I had to make to get buffers shared
between Mesa and LibVA on Chrome OS. This is required to have
refcounting properly between the 2 API otherwise, Mesa might end up
calling exit() when the kernel tells it that one of the buffer object
used in a batch buffer
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_p
On Thu, Sep 11, 2014 at 12:33:41PM +0100, Lionel Landwerlin wrote:
> When using Mesa and LibVA in the same process, one would like to be
> able bind buffers from the output of the decoder to a GL texture
> through an EGLImage.
>
> LibVA can reuse buffers allocated by Gbm through a file descriptor.
rfectly.
The cover letter's description is right though, in that you get a cryptic
message thanks to relocation having been totally skipped when you submit
objects from a foreign bufmgr.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://l
On 11/09/14 12:52, Chris Wilson wrote:
> On Thu, Sep 11, 2014 at 12:33:41PM +0100, Lionel Landwerlin wrote:
>> When using Mesa and LibVA in the same process, one would like to be
>> able bind buffers from the output of the decoder to a GL texture
>> through an EGLImage.
>>
>> LibVA can reuse buffer
Hi
On Thu, Sep 11, 2014 at 8:48 AM, Daniel Vetter wrote:
> Nice you skid around all the pitfalls and trapdoors, I guess we've all
> been rather blind ;-)
>
> Two high-level comments:
> - We also want to forward "bl_power". cros was totally not happy when we
> stopped treating brightness == 0 as
On Thu, Sep 11, 2014 at 01:21:13PM +0100, Lionel Landwerlin wrote:
> On 11/09/14 12:52, Chris Wilson wrote:
> >Just use an embedded list rather than array, that would greatly simplify
> >the search, cration and deletion.
>
> I tried to use the embedded list, but from my understanding I need
> the
On Thu, 11 Sep 2014, Daniel Vetter wrote:
> On Wed, Sep 10, 2014 at 05:54:23PM +0200, David Herrmann wrote:
>> Backlight devices have always been managed independently of display
>> controllers. They're often controlled via different hardware interfaces
>> and their relationship to display-control
Hi
On Wed, Sep 10, 2014 at 10:40 PM, Matthew Garrett
wrote:
> On Wed, 2014-09-10 at 17:54 +0200, David Herrmann wrote:
>
>> * User-space currently has a hard-time figuring out which backlight device
>> to
>>use, and which backlight device belongs to which display. So far, most
>>systems
On 2014? 08? 28? 18:07, Andrzej Hajda wrote:
> This set of patches contains various improvement and fixes
> for exynos_drm ipp framework.
> The patchset is based on exynos-drm-next branch.
>
> IPP framework was tested for regressions on exynos4210-trats target.
>
> In the 2nd version of the serie
Update Exynos's DRM driver to use component match support rater than
add_components.
Changelog v2:
- release devices and drivers if failed.
- change compare_of to compare_dev.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 44 +++
1 file chan
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #11 from Alex Deucher ---
You'll have to ask ubuntu if they have added any special changes. I'm not able
to reproduce any display problems.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Sep 11, 2014 at 02:22:55PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Sep 11, 2014 at 8:48 AM, Daniel Vetter wrote:
> > Nice you skid around all the pitfalls and trapdoors, I guess we've all
> > been rather blind ;-)
> >
> > Two high-level comments:
> > - We also want to forward "bl_po
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/2e968b49/attachment-0001.html>
org/archives/dri-devel/attachments/20140911/474790e6/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/e8dc0dc3/attachment.html>
g 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/20140911/43c9dfe4/attachment.html>
On Wed, Sep 10, 2014 at 05:36:09PM +0200, Daniel Vetter wrote:
> Drivers without a hardware vblank counter simply can't account for the
> vblanks that happened while the vblank interrupt was off. To check
> this grab a vblank timestamp and if the result is dubious follow the
> normal save-and-disab
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Vi
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/a6b54d49/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/20140911/fa366c32/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/6ad1f9a9/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140911/8232ff02/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/bc5e0d45/attachment.html>
On 09/11/2014 02:57 PM, Inki Dae wrote:
> Update Exynos's DRM driver to use component match support rater than
> add_components.
>
> Changelog v2:
> - release devices and drivers if failed.
> - change compare_of to compare_dev.
>
> Signed-off-by: Inki Dae
Modulo fixes I have posted earlier.
Te
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/bf4dec15/attachment.html>
ter is useless for this asic.
--
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/20140911/0c8bcef3/attachment.html>
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_p
Following Chris' review, here is an updated patch using drmMMListHead.
I did a quick read of the benchmarks/tests files in igt, as far as I
can see, drm_intel_bufmgr_destroy() is always called before the drm
file descriptor is closed. So it seems this change shouldn't break
anything.
Cheers,
-
L
On Thu, Sep 11, 2014 at 04:36:20PM +0100, Lionel Landwerlin wrote:
> When using Mesa and LibVA in the same process, one would like to be
> able bind buffers from the output of the decoder to a GL texture
> through an EGLImage.
>
> LibVA can reuse buffers allocated by Gbm through a file descriptor.
Hi
On Thu, Sep 11, 2014 at 3:06 PM, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 02:22:55PM +0200, David Herrmann wrote:
>> actual-brightness is a bit more tricky. Currently, DRM caches property
>> values, so there is no read_property() hook. We'd have to add this.
>> But it'll be quite nasty a
On Fri, 05 Sep 2014, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
>
> This commit splits intel_update_plane() and
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_p
sed mega as the files are too big to attach to the bug report.
Thanks!
--
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
From: Gustavo Padovan
7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression.
We fix it by doing the right assignment of crtc_y
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83747
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140911/e2b58ef4/attachment.html>
On Thu, Sep 11, 2014 at 6:12 PM, Dieter N?tzel wrote:
> Hello Alex and Christian,
>
> RV730 (AGP) need badly
>
> From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
> From: Alex Deucher
> Date: Mon, 8 Sep 2014 13:16:39 -0400
> Subject: [PATCH] drm/radeon: only use me/pfp sync o
On Thu, Sep 11, 2014 at 6:14 PM, Alex Deucher wrote:
> On Thu, Sep 11, 2014 at 6:12 PM, Dieter N?tzel
> wrote:
>> Hello Alex and Christian,
>>
>> RV730 (AGP) need badly
>>
>> From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
>> From: Alex Deucher
>> Date: Mon, 8 Sep 2014 13
Hi Dave,
This pull adds concurrent buffer read support to radeon to
avoid serialization when read buffers are shared between engines.
The following changes since commit c4d922b14544d115232b7448a2ea7640ba901eb6:
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into
drm-n
While zone->name is currently hard coded, the call to kobject_init_and_add()
should follow the more defensive argument list usage (as already done in
other places in ttm_memory.c) where "%s" is used instead of directly passing
in a variable as a format string.
Signed-off-by: Kees Cook
---
driver
81 matches
Mail list logo
