Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: I've completely missed eaction->fpriv_head and all the related
code. We need to nuke that too to avoid accidentally deferencing the
freed-up vmwgfx-private fpriv.
v3: Also remove vmw_fpriv->fence_
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: I've completely missed eaction->fpriv_head and all the related
code. We need to nuke that too to avoid accidentally deferencing the
freed-up vmwgfx-private fpriv.
v3: Also remove vmw_fpriv->fence_
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunk.
Cc: Eric Anholt
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20
drivers/
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunks.
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 20
dri
The core takes care of that now.
v2: Fixup misplaced hunk.
Cc: Thierry Reding
Cc: Terje Bergström
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/dc.c | 17 -
drivers/gpu/drm/tegra/drm.c | 3 ---
drivers/gpu/drm/tegr
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunk.
Cc: Laurent Pinchart
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Laurent Pinchart
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20 --
Again since the core takes care of this we can remove them. While at
it also remove the postclose hook, it's empty.
v2: Laurent pointed me at even more code to delete.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
d
They only complete the page flip events to avoid oops when the drm
file closes. The core takes care of that now and we can remove this
code.
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 7 ---
d
So this one is special, since it tries to prevent races when userspace
crashes simply by disabling the vblank machinery. Well except that imx
always has vblanks enabled, and the disable_vblank hook actually just
tries to cancel a pending pageflip. Without any locking whatsoever. Of
course this is w
The core takes care of this now. And since kfree(NULL) is ok we can
simplify the function even further now.
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
1 file changed, 14 deletions(
The only thing this did was cancle pending flip events, and the core
takes care of that now.
Cc: Boris Brezillon
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 --
drivers/gpu/drm/atmel-hlcd
Now that the drm core unlinks/disarms events there's no need to do so
ourselves anymore. Nuke the code.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 21
The core code now takes care of unlinking drm_events from the file in
a generic way, so this code isn't needed any more.
For those wondering where the drm_vblank_put went to: With the new
logic events only get unlinked, but still exist. Hence any resources
(like vblank counters) don't need to be r
There's really no reason to not do so, instead of replicating this
for every use-case and every driver. Now we can't just nuke the events,
since that would still mean that all drm_event users would need to know
when that has happened, since calling e.g. drm_send_event isn't allowed
any more. Instea
I'm auditing them all, empty ones just confuse ...
Cc: Patrik Jakobsson
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu
The compiler will do this, but the void hits when grepping all the
hooks for a subsystem wide audit are slightly annoying. So remove them
for next time around.
Cc: Russell King
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_drv.
Doesn't do anything, but annoys when auditing them all.
Cc: Jianwei Wang
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.
Use them in the core vblank code and exynos/vmwgfx drivers.
Note that the difference between wake_up_all and _interruptible in
vmwgfx doesn't matter since the only waiter is the core code in
drm_fops.c. And that is interruptible.
v2: Adjust existing kerneldoc too.
Reviewed-by: Alex Deucher (v1)
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/v
Also fixes a bug in IPP with not correctly checking/allocating for
space in the event space. Not a too serious bug since it's not a
real ringbuffer, just a limit to avoid too much kernel allocations.
Cc: Rob Clark
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Dan
An attempt at not spreading out the file_priv->event_space stuff out
quite so far and wide. And I think fixes something in ipp_get_event()
that is broken (or if they are doing something more weird/subtle, then
breaks it in a fun way).
Based upon a patch from Rob Clark, rebased and polished.
v2:
Just prep work before I throw more drm_event refactorings on top.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 48 +--
drivers/gpu/drm/drm_fops.c | 129 ++---
include/drm/
Hi all,
Mostly just small changes from review feedback (plus a few misplaced hunks,
silly me). Plus an attempt at better kerneldoc to explain how this works. Since
that caused questions both from Thomas and Laurent let me explain things also
here:
Currently anyone using drm_events (vblank code, a
;> [ 15.063459] WARNING: CPU: 3 PID: 1122 at
>> drivers/base/power/common.c:150 dev_pm_domain_set+0x4c/0x58()
>> [ 15.072838] PM domains can only be changed for unbound devices
>> [ 15.078735] Modules linked in:
>> [ 15.081849] CPU: 3 PID: 1122 Comm: init Not tainted
>&g
On Mon, Jan 11, 2016 at 09:36:04AM +0100, Thierry Reding wrote:
> On Mon, Dec 14, 2015 at 06:30:28PM +0200, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 04:23:41PM +0100, Thierry Reding wrote:
> > > On Mon, Dec 14, 2015 at 04:48:09PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Dec 14, 2015
On Mon, Jan 11, 2016 at 12:11:05PM -0800, Linus Torvalds wrote:
> On Mon, Jan 11, 2016 at 3:28 AM, Chris Wilson
> wrote:
> >
> > Bizarrely,
> >
> > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > index 6000ad7..cf074400 100644
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/m
On Mon, Jan 11, 2016 at 07:51:03PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 08, 2016 at 11:27:05PM +, Chris Wilson wrote:
> > When userspace closes a handle, we remove it from the file->object_idr
> > and then tell the driver to drop its references to that file/handle.
> > However, as the fi
On Mon, Jan 11, 2016 at 04:54:19PM +0100, Christian König wrote:
> >Out of curiosity, where do you generate so many foreign dma-buf backes
> >objects?
> That was just an experiment of sharing buffers between two AMD devices. A
> stupid reference count bug and I've leaked 60 full HD frame a second.
https://bugzilla.kernel.org/show_bug.cgi?id=108261
Cesko Voeten changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Darren,
On Mon, Jan 11, 2016 at 09:45:25AM -0800, Darren Hart wrote:
> On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote:
> > > On Fri, Jan 08, 2016 at 09:49:22AM -0700, Jonathan Corbet wrote:
> > > > Well, it's built
Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
The main obstacle on these machines is that the panel mode in VBIOS
is bogus. Fortunately gmux can switch DDC independently from the
display, thereby allowing the inactive GPU to probe the panel's EDID.
In short, vga_switcheroo
Allow handlers to declare their capabilities and allow clients to
obtain that information. So far we have these use cases:
* If the handler is able to switch DDC separately, clients need to
probe EDID with drm_get_edid_switcheroo(). We should allow them
to detect a capable handler to ensure th
Originally by Seth Forshee , 2012-10-04:
During graphics driver initialization it's useful to be able to mux
only the DDC to the inactive client in order to read the EDID. Add
a switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switc
gmux has 3 switch registers:
* GMUX_PORT_SWITCH_DISPLAY switches the panel
* GMUX_PORT_SWITCH_DDC switches the panel's DDC lines
(only on pre-retinas; on retinas this is a no-op)
* GMUX_PORT_SWITCH_EXTERNAL switches the external DP port(s)
(only on models without Thunderbolt, i.e. introduced b
Originally by Seth Forshee , 2012-10-04:
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a
VBT or have invalid mode data in the VBT
Originally by Seth Forshee , 2012-10-04:
Some dual graphics machines support muxing the DDC separately from
the display, so make use of this functionality when reading the EDID
on the inactive GPU. Also serialize drm_get_edid() with a mutex to
avoid races on the DDC mux state.
Modi
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo h
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo handler is capable of temporarily swit
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo handler is capable of temporarily swit
Centralize gmux' ACPI HID in a header file and add apple_gmux_present().
This can be used by other drivers to activate quirks specific to dual
GPU MacBook Pros & Mac Pros. The alternative would be to hardcode DMI
or PCI IDs and amend them whenever Apple introduces a new machine.
Tested-by: Lukas W
gmux is a microcontroller built into dual GPU MacBook Pros.
On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux
to temporarily switch DDC so that we can probe the panel's EDID.
The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary
because if either of them is disabled
gmux is a microcontroller built into dual GPU MacBook Pros.
On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux
to temporarily switch DDC so that we can probe the panel's EDID.
The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary
because if either of them is disabled
gmux is a microcontroller built into dual GPU MacBook Pros.
On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux
to temporarily switch DDC so that we can probe the panel's EDID.
The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary
because if either of them is disabled
On Tue, 5 Jan 2016 20:38:17 +
Russell King - ARM Linux wrote:
> Some comments from an ARM architecture point of view. I haven't
> reviewed it from a DRM point of view yet.
Anyway, thanks for your explanations and remarks.
> > +static void de2_crtc_enable(struct drm_crtc *crtc)
> > +{
On Fri, Jan 08, 2016 at 11:27:05PM +, Chris Wilson wrote:
> When userspace closes a handle, we remove it from the file->object_idr
> and then tell the driver to drop its references to that file/handle.
> However, as the file/handle is already available again for reuse, it may
> be reallocated b
On Fri, Jan 8, 2016 at 9:46 AM, Inki Dae wrote:
> This patch fixes a kernel panic issue which happened
> when drm driver is closed while modetest.
>
> This issue could be reproduced easily by launching modetest
> with page flip repeatedly.
>
> The reason is that invalid drm_file object could be ac
This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Signed-off-by: Emmanuel Gil Peyrot
---
include/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..59fc54d 100644
--- a/inclu
Hi Inki,
On 8 January 2016 at 08:46, Inki Dae wrote:
> Changelog v3:
> - initialize only device specific things. Each page flip event object
> is created by DRM core so DRM core should release the object including
> incrementing event space.
I'm a bit confused here; we no longer call event->
On Sat, 12 Dec 2015 12:13:45 +0100
Daniel Vetter wrote:
> I just figured there's no way this could get it, and I'd
> much rather improve the docs themselves than trying to convince core
> kernel folks that this might be useful.
So I'm not quite sure why you figured that; I never said it, certain
ves/dri-devel/attachments/20160111/7d5c2b54/attachment.html>
On Mon, Jan 11, 2016 at 04:07:50PM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
> > Dear All,
> >
> > I would like to add support for configuring alpha modes: straight and
> > pre-multiplied for blending to Exynos DRM driver. For those who see tho
> Out of curiosity, where do you generate so many foreign dma-buf backes
> objects?
That was just an experiment of sharing buffers between two AMD devices.
A stupid reference count bug and I've leaked 60 full HD frame a second.
Took a bit over two minutes to eat up 1GB of GTT space and the box dy
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/72accd3b/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/5fbe1c9f/attachment-0001.html>
LGTM,
Although perhaps check that the LRU lock is held as well.
Reviewed-by: Thomas Hellstrom
On 01/11/2016 03:35 PM, Christian König wrote:
> From: Christian König
>
> This allows the drivers to move a BO to the end of the LRU
> without removing and adding it again.
>
> v2: Make it more rob
On Mon, Jan 11, 2016 at 12:03:03PM +0100, Marek Szyprowski wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to drm core and plane state structures
> - added helpers for normalizing zpos properties of given set of pl
Reviewed-by: Thomas Hellstrom
BTW, does Radeon touch the caching mode of imported buffers through TTM
(like write-combining)?
Do we need something similar for that?
/Thomas
On 01/11/2016 03:35 PM, Christian König wrote:
> From: Christian König
>
> It doesn't make any sense to try to swap ou
On Mon, Jan 11, 2016 at 12:03:04PM +0100, Marek Szyprowski wrote:
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
> drivers/gpu/drm/exynos
On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
> Dear All,
>
> I would like to add support for configuring alpha modes: straight and
> pre-multiplied for blending to Exynos DRM driver. For those who see those
> terms for the first time:
> 1. straight alpha mode means means that
LGTM, minor nitpick below.
Reviewed-by: Thomas Hellstrom
On 01/11/2016 03:35 PM, Christian König wrote:
> From: Christian König
>
> If we import a BO with an external reservation object we don't
> reserve/unreserve it. So we never add it to the LRU causing a possible
> deny of service.
s/deny
On Mon, Jan 11, 2016 at 02:07:15PM +0100, Lukas Wunner wrote:
> Hi Daniel,
>
> On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote:
> > > Here's a v2, the only change is Bruno Pr?mont's addition to the commit
> > > message
On Mon, Jan 11, 2016 at 03:38:23PM +0100, Christian König wrote:
> >While this would be one way to work around the GTT space DOS, it
> >wouldn't work around the DOS problem of the exporter pinning system
> >pages that probably never get accounted. That's a limitation of the
> >export-import mechan
ing a 'reboot' command:
>
> Requesting system reboot
> [ 15.058782] [ cut here ]
> [ 15.063459] WARNING: CPU: 3 PID: 1122 at
> drivers/base/power/common.c:150 dev_pm_domain_set+0x4c/0x58()
> [ 15.072838] PM domains can only be chan
> While this would be one way to work around the GTT space DOS, it
> wouldn't work around the DOS problem of the exporter pinning system
> pages that probably never get accounted. That's a limitation of the
> export-import mechanism (dma-buf).
Yeah, completely agree. That's a problem we sooner or
From: Christian König
Most VM BOs end up in the duplicates list, validate it
first make -ENOMEM less likely.
Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/g
From: Christian König
This makes it less likely to run into an ENOMEM because
VM page tables are evicted last.
v2: move the BOs in the LRU tail after validation
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++
From: Christian König
This allows the drivers to move a BO to the end of the LRU
without removing and adding it again.
v2: Make it more robust, handle pinned and swapable BOs as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 21 +
include/drm/ttm
From: Christian König
It doesn't make any sense to try to swap out imported BOs.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a98a5d5..3ea9
From: Christian König
If we import a BO with an external reservation object we don't
reserve/unreserve it. So we never add it to the LRU causing a possible
deny of service.
v2: fix typo in commit message
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
1 file ch
Dear All,
I would like to add support for configuring alpha modes: straight and
pre-multiplied for blending to Exynos DRM driver. For those who see
those terms for the first time:
1. straight alpha mode means means that all A and RGB values are from
full 0.255 range,
2. pre-multiplied alpha mod
Hi,
On 10 January 2016 at 23:48, Laurent Pinchart
wrote:
> On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote:
>> @@ -353,18 +354,16 @@ static void drm_events_release(struct drm_file
>> *file_priv) {
>> struct drm_device *dev = file_priv->minor->dev;
>> struct drm_pending_event
On Monday 11 January 2016 12:26:44 Liviu Dudau wrote:
> > If so, just fold my fixes into your patches when you rebase.
>
> OK, will do. Repeating the question on another thread: are you OK with me
> carrying
> the Juno .dts changes through drm-next for HDLCD and you picking up Robin
> Murphy's
>
On Mon, Jan 11, 2016 at 02:49:10PM +0100, Arnd Bergmann wrote:
> On Monday 11 January 2016 12:26:44 Liviu Dudau wrote:
> > > If so, just fold my fixes into your patches when you rebase.
> >
> > OK, will do. Repeating the question on another thread: are you OK with me
> > carrying
> > the Juno .dt
Hi Daniel,
On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote:
> > Here's a v2, the only change is Bruno Pr?mont's addition to the commit
> > message.
> >
> > @Daniel Vetter: Could you pick this up for topic/drm-misc pleas
On 01/11/2016 01:39 PM, Christian König wrote:
> Am 10.01.2016 um 16:10 schrieb Thomas Hellstrom:
>> On 01/09/2016 11:46 AM, Christian König wrote:
>>> It's correct that exported buffers can't be moved to another domain or
>>> swapped to disk while another device is using it.
>>>
>>> But for impo
Am 10.01.2016 um 16:10 schrieb Thomas Hellstrom:
> On 01/09/2016 11:46 AM, Christian König wrote:
>> It's correct that exported buffers can't be moved to another domain or
>> swapped to disk while another device is using it.
>>
>> But for imports that's a different story:
>>> an imported object sh
On Monday 11 January 2016 11:12:56 Liviu Dudau wrote:
> On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> > On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> > >
> > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> > > a completely superfluous opt
On Mon, Jan 11, 2016 at 12:45 PM, Rafael J. Wysocki
wrote:
> OK, so does the appended patch help?
Yes, thanks. I do not see the warnings after 'reboot' with your patch applied:
Tested-by: Fabio Estevam
58()
[ 15.072838] PM domains can only be changed for unbound devices
[ 15.078735] Modules linked in:
[ 15.081849] CPU: 3 PID: 1122 Comm: init Not tainted
4.4.0-rc8-next-20160111-dirty #207
[ 15.089826] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 15.096375] Backtrace:
On Mon, Jan 11, 2016 at 01:18:55PM +0100, Arnd Bergmann wrote:
> On Monday 11 January 2016 11:12:56 Liviu Dudau wrote:
> > On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> > > On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> > > >
> > > > Ugh... wouldn't it be much simple
On Mon, Jan 11, 2016 at 3:28 AM, Chris Wilson
wrote:
>
> Bizarrely,
>
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 6000ad7..cf074400 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -141,6 +141,7 @@ void clflush_cache_range(void *vaddr, unsigned
This patch simplifies initialization of generic rotation property and
aligns the code to match recently introduced function for intializing
generic zpos property. It also adds missing documentation.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10
This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 66 +++
drivers/gpu/drm/exynos
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to drm core and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then p
Hello all,
This patch series is a continuation of rework of blending support in
Exynos DRM driver. Some background can be found here:
http://www.spinics.net/lists/dri-devel/msg96969.html
Daniel Vetter suggested that zpos property should be made generic, with
well-defined semantics. This patchset
Hi Rob,
On 01/11/2016 10:06 AM, Rob Herring wrote:
> On Thu, Jan 07, 2016 at 05:05:11PM +0800, Yakir Yang wrote:
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v2: None
>>
>> .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4
>> +++-
>> 1 file changed, 3 insertions(
On 2016å¹´01æ10æ¥ 23:10, Thomas Hellstrom wrote:
> On 01/09/2016 11:46 AM, Christian König wrote:
>> It's correct that exported buffers can't be moved to another domain or
>> swapped to disk while another device is using it.
>>
>> But for imports that's a different story:
>>> an imported obje
On Sat, Jan 09, 2016 at 02:36:03PM -0800, Andy Lutomirski wrote:
> On Sat, Jan 9, 2016 at 12:01 AM, Chris Wilson
> wrote:
> > On Thu, Jan 07, 2016 at 02:32:23PM -0800, H. Peter Anvin wrote:
> >> On 01/07/16 14:29, H. Peter Anvin wrote:
> >> >
> >> > I would be very interested in knowing if replac
On Mon, Jan 11, 2016 at 08:19:54PM +0100, Lukas Wunner wrote:
> Hi Darren,
>
> On Mon, Jan 11, 2016 at 09:45:25AM -0800, Darren Hart wrote:
> > On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote:
> > > > On Fri, Jan 08,
LGTM.
Reviewed-by: Thomas Hellstrom
On 01/10/2016 11:26 PM, Daniel Vetter wrote:
> Again since the drm core takes care of event unlinking/disarming this
> is now just needless code.
>
> v2: I've completely missed eaction->fpriv_head and all the related
> code. We need to nuke that too to avoid
On 01/11/2016 07:38 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thanks a lot for the patch.
>
> On Saturday 09 January 2016 22:20:25 Archit Taneja wrote:
>> We don't want to use the old i2c slave encoder interface anymore.
>
> I happily agree with that :-)
>
>> Remove that and make the i2c drive
On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> >
> > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> > a completely superfluous option to me. I don't think we've ever had the
> > equivalent of "v
Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_vma_manager.c | 43 ---
include/drm/drm_vma_mana
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the numbe
On Fri, Jan 01, 2016 at 03:09:10PM +0100, Arnd Bergmann wrote:
> The newly added DRM_HDLCD driver tries to select DMA_CMA, but that is
> not necessarily possible, as not all configurations contain
> HAVE_DMA_CONTIGUOUS:
>
> warning: (DRM_HDLCD) selects DMA_CMA which has unmet direct dependencies
On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote:
> > On Fri, Jan 08, 2016 at 09:49:22AM -0700, Jonathan Corbet wrote:
> > > Well, it's built around the asciidoc patch, which isn't in the mainline
> > > at this point. Sho
ms for udelay()/mdelay()
and ~5 ms for the usleep_range() case. I'll see if I can get one more
test setup running for better comparison.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/98a0ea54/attachment-0001.sig>
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.free
When userspace closes a handle, we remove it from the file->object_idr
and then tell the driver to drop its references to that file/handle.
However, as the file/handle is already available again for reuse, it may
be reallocated back to userspace and active on a new object before the
driver has had
1 - 100 of 112 matches
Mail list logo