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. Should things go a different direction, that could force
> some changes here;
If/when that happens, I'll be happy to fixup the documentation
Document what I've learned so far about the gmux so that we can
collaboratively reverse-engineer its remaining unknown bits
without everyone having to start from scratch.
The DOC sections are bound together in the gpu.tmpl DocBook
under a new vga_switcheroo "Handlers" chapter. Eventually
this shou
Hi Daniel,
Thank you for the patch.
On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote:
> 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
Hi Daniel,
Thank you for the patch.
On Sunday 10 January 2016 23:26:06 Daniel Vetter wrote:
> Again since the drm core takes care of event unlinking/disarming this
> is now just needless code.
>
> v2: Fixup misplaced hunk.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
This looks go
Hi Daniel,
Thank you for the patch.
On Friday 08 January 2016 21:36:48 Daniel Vetter wrote:
> Again since the drm core takes care of event unlinking/disarming this
> is now just needless code.
This looks good to me assuming that the mechanism works in the core, which
looks like magic to me at t
Hi Daniel,
Thank you for the patch.
On Friday 08 January 2016 21:36:47 Daniel Vetter wrote:
> Again since the core takes care of this we can remove them. While at
> it also remove the postclose hook, it's empty.
>
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Signed-off-by: Daniel Vetter
> ---
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/c0a00ff7/attachment.html>
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 driver create a drm_bridge entity instead.
> Converting to bridges he
org/archives/dri-devel/attachments/20160111/abcf15f3/attachment.html>
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
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(
Hi Dan,
I see, I will fix this warning.
Best Regards
Rex
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Friday, January 08, 2016 4:39 AM
To: Zhu, Rex
Cc: dri-devel at lists.freedesktop.org
Subject: re: drm/amd/powerplay: show gpu load when print gpu perfo
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 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. Should things go a different direction, that could force
> > some changes
On Mon, Jan 11, 2016 at 02:03:34AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Friday 08 January 2016 21:36:47 Daniel Vetter wrote:
> > Again since the core takes care of this we can remove them. While at
> > it also remove the postclose hook, it's empty.
> >
>
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>
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
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
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 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
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
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
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
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
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
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 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 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
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 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
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 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
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
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:
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
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
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
> 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
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
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 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
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
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
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 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
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 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 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
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
> 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
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/5fbe1c9f/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160111/72accd3b/attachment.html>
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
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
ves/dri-devel/attachments/20160111/7d5c2b54/attachment.html>
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
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)
> > +{
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->
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 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
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
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,
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.
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
https://bugzilla.kernel.org/show_bug.cgi?id=108261
Cesko Voeten changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 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
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
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/
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)
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
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
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
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
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/
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:
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
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.
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.
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
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
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
1 - 100 of 112 matches
Mail list logo
