Just so everyone is aware we are running a hard and fast rule of
everything in linux-next by rc6 this time around, so if your tree is
directly included in linux-next that means everything needs to be in
drm-next by the end of this week.
If your tree is directly included in linux-next I'd still lik
On 4 April 2017 at 05:51, Dave Airlie wrote:
> Just so everyone is aware we are running a hard and fast rule of
> everything in linux-next by rc6 this time around, so if your tree is
> directly included in linux-next that means everything needs to be in
> drm-next by the end of this w
te SSPP_MAX value
Arnd Bergmann (1):
drm/msm: adreno: fix build error without debugfs
Dave Airlie (2):
Merge branch 'vmwgfx-fixes-4.11' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
Merge branch 'msm-fixes-4.11-rc6' of
git://people.freedeskt
From: Dave Airlie
This allows us to create sync files with different semantics,
and clearly define the interoperation between them it also
provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept
types from userspace so they can return
From: Dave Airlie
These are just alloc and fdget interfaces needed by the drm sync
objects code.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 21 +++--
include/linux/sync_file.h | 3 ++-
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
o
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 86 +++---
1 file changed, 48 insertions(+
From: Dave Airlie
This creates a new interface for amdgpu with ioctls to
create/destroy/import and export shared semaphores using
sem object backed by the sync_file code. The semaphores
are not installed as fd (except for export), but rather
like other driver internal objects in an idr. The idr
This series enhances my previous semaphore work on for amdgpu,
with a generic DRM sync object. (drm_syncobj).
It first enhances sync_file to have a type/flags so we can have
different semantics for different sync files, and a wait
to retrieve the type of sync_file for userspace.
Then it adds drm
From: Dave Airlie
This just adds two helper interfaces to bridge the gap from
drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_syncobj.c | 72 +++
include/drm
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c| 36
From: Dave Airlie
This patch allows the underlying fence in a sync_file to be changed
or set to NULL. This isn't currently required but for Vulkan
semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence,
along with a new mutex
On 4 April 2017 at 14:27, Dave Airlie wrote:
> This series enhances my previous semaphore work on for amdgpu,
> with a generic DRM sync object. (drm_syncobj).
>
> It first enhances sync_file to have a type/flags so we can have
> different semantics for different sync files,
On 5 April 2017 at 16:51, Laurent Pinchart
wrote:
> As the DRM LVDS panel driver uses a different approach to DT bindings
> compared to what Thierry Reding advocates, add a specific MAINTAINERS
> entry to avoid bothering Thierry with requests related to that driver.
Could you document a bit more
On 10 April 2017 at 19:03, Laurent Pinchart
wrote:
> Hi Thierry,
>
> On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote:
>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
>> > Hi Thierry,
>> >
>> > I don't mean to stir up anything, just voicing "my 2c" as they say.
>> >
>> > On 7 A
On 4 April 2017 at 18:07, Christian König wrote:
> Am 04.04.2017 um 06:27 schrieb Dave Airlie:
>>
>> From: Dave Airlie
>>
>> This patch allows the underlying fence in a sync_file to be changed
>> or set to NULL. This isn't currently required but for Vulk
On 4 April 2017 at 21:05, Christian König wrote:
> Am 04.04.2017 um 10:10 schrieb Daniel Vetter:
>>
>> On Tue, Apr 04, 2017 at 09:40:57AM +0200, Christian König wrote:
>>>
>>> Am 04.04.2017 um 06:27 schrieb Dave Airlie:
>>>>
>>>> From
This set of sync object patches should address most of the issues
raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixups
My plans are to write some igt tests this week, and try
to get some more review on what the API
From: Dave Airlie
This allows us to create sync files with different semantics,
and clearly define the interoperation between them it also
provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept
types from userspace so they can return
From: Dave Airlie
These are just alloc and fdget interfaces needed by the drm sync
objects code.
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 21 +++--
include/linux/sync_file.h | 3 ++-
2 files
From: Dave Airlie
This patch allows the underlying fence in a sync_file to be changed
or set to NULL. This isn't currently required but for Vulkan
semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence,
along with a new mutex
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c| 36
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1
From: Dave Airlie
This just adds two helper interfaces to bridge the gap from
drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_syncobj.c | 77 +++
include/drm
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
o
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for
From: Dave Airlie
sync_file uses the reference count of the file, the internal
kref was never getting moved past 1.
We can reintroduce this if we decide we need it later.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 13 ++---
include/linux/sync_file.h | 1 -
2
On 11 April 2017 at 22:42, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:20PM +1000, Dave Airlie wrote:
>> +static int amdgpu_sem_lookup_and_sync(struct amdgpu_cs_parser *p,
>> + uint32_t handle)
>> +{
>> + int r;
>>
On 11 April 2017 at 17:50, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This object can be used to implement the Vulkan semaphores.
>>
>> The object behaviour differs from fence, in that you can
>
On 12 April 2017 at 12:36, Mao, David wrote:
> Does it means we have to submit command to trigger the semaphore wait/signal?
Yes, but I think that should be fine, we need to submit a job to the
scheduler to
get the waits to happen or to have a fence to fill into the signals.
Dave.
__
On 12 April 2017 at 12:49, Mao, David wrote:
> But how to handle the semaphore wait in the vkQueuePresentkHR?
The problem here is that really we'd want the presenting process to
do the signal once it submits the work for actual presentations (be
that the X server DDX or whatever).
However that i
On 12 April 2017 at 13:34, Mao, David wrote:
> My point is it is reasonable to split the semaphore signal/wait with the
> command submission.
> For the signal ioctl, we could just pick the last fence in the same schedule
> context, and we don't need to ask for a explicit flush or a dummy submiss
From: Dave Airlie
These are just alloc and fdget interfaces needed by the drm sync
objects code.
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 21 +++--
include/linux/sync_file.h | 3 ++-
2 files
From: Dave Airlie
This allows us to create sync files with different semantics,
and clearly define the interoperation between them it also
provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept
types from userspace so they can return
From: Dave Airlie
This patch allows the underlying fence in a sync_file to be changed
or set to NULL. This isn't currently required but for Vulkan
semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence,
along with a new mutex
Okay another day, another sync object patchset.
In my drm-syncobj branch.
This round should:
a) address the amdgpu CS ERESTARTSYS failure case, I've reworked
the sync_file/syncobj/amdgpu bits to have a lookup and just replace
in separate phases and just do the wait lookup and sync, then later
rep
From: Dave Airlie
This just adds two helper interfaces to bridge the gap from
drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
v2: drop one of the APIs and replace with a fence
lookup to make the amdgpu api more robust.
Signed-off-by: Dave Airlie
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
v2: change replace fence API to have a return value,
don't allow polling on semaphore ob
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
o
>>
>> Not sure what the best semantics are there, any opinions on barring
>> wakeups/polling on semaphore sync_files, and just punting this
>> until we need it.
>
> I think getting it right now will make writing sw_sync-esque (i.e. cpu)
> tests easier and more complete.
I just don't have any use c
On 8 April 2017 at 02:42, CK Hu wrote:
> Hi, Dave:
>
> This series is MT2701 DRM support.
Just FYI, I failed to notice this, but Stephen pointed it out,
please make sure you add a Signed-off-by line if you are committing
other people's patch to a tree, As the maintainer you must add these,
not A
On 13 April 2017 at 06:39, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
>> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
>> > >>
>> > >> Not sure what the best semantics are there, any opinions on barri
>
> The problem, as I see it, is that you are taking functionality away from
> sync_file. If you are wrapping them up inside a sync_file, we have a
> fair expectation that our code to handle sync_files will continue to
> work.
What code? there is no code existing that should be sharing sync object
On 13 April 2017 at 08:34, Chris Wilson wrote:
> On Thu, Apr 13, 2017 at 07:41:28AM +1000, Dave Airlie wrote:
>> >
>> > The problem, as I see it, is that you are taking functionality away from
>> > sync_file. If you are wrapping them up inside a sync_file, we have a
From: Dave Airlie
sync_file uses the reference count of the file, the internal
kref was never getting moved past 1.
We can reintroduce this if we decide we need it later.
[airlied: fix buildbot warnings]
Reviewed-by: Chris Wilson
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c
From: Dave Airlie
The current code never updates this pointer after init,
and it should always be initialised with a valid value.
However in the future we want to share some code with
semaphore files, and those will want to use rcu to update
this pointer. However none of the places sync_file
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sem_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
o
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and we can reintroduce some of the API then if nee
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for
From: Dave Airlie
This adds support for a file that has semaphore semantics
(for Vulkan shared semaphores).
These objects are persistent objects that can have a
fence that changes. When the object is signaled, a fence
is attached to it, and when an object is waited on, the
fence is removed. All
From: Dave Airlie
This just splits out a common base object to be shared
between sync_file and sem_files.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 49 +++-
drivers/gpu/drm/drm_atomic.c | 4 ++--
include/linux/sync_file.h| 17
i915/execlists: Wrap tail pointer after reset tweaking
drm/i915: Avoid lock dropping between rescheduling
drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
drm/i915: Use a dummy timeline name for a signaled fence
Dave Airlie (4):
Merge branch 'etnaviv/fixes&
On 14 April 2017 at 19:45, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
>> This set of sync object patches should address most of the issues
>> raised in review.
>>
>> The major changes:
>> Race on destroy should be gone,
On 18 April 2017 at 12:05, Inki Dae wrote:
> Hi Dave,
>
>Some improvements, fixups and cleanups to Exynos DRM.
>
>Ps. this pull-reuqest includes a merge tag from Krzysztof Kozlowski
>who is a Exynos SoC maintainer, which includes dt patches because
>these should be merged together
On 19 April 2017 at 07:55, Jason Ekstrand wrote:
> A few thoughts (from the anv perspective) that I put on IRC but may be
> better in a mail. In no particular order:
>
> 1. Having the fd exported from a syncobj be a valid sync_file seems like a
> fairly pointless feature to me. If we can make t
On 19 April 2017 at 22:07, Christian König wrote:
> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>
>> Okay I've taken Chris's suggestions to heart and reworked things
>> around a sem_file to see how they might look.
>>
>> This means the drm_syncobj are c
On 20 April 2017 at 04:42, Dave Airlie wrote:
> On 19 April 2017 at 22:07, Christian König wrote:
>> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>>
>>> Okay I've taken Chris's suggestions to heart and reworked things
>>> around a sem_file to s
On 20 April 2017 at 19:13, Marek Szyprowski wrote:
> Dear all,
>
> This is an updated proposal for extending EXYNOS DRM API with generic support
> for hardware modules, which can be used for processing image data from the
> one memory buffer to another. Typical memory-to-memory operations are:
> r
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1
From: Dave Airlie
This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.
This should only be used to interact with sync files where necessary.
Signed-off-by: Dave
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can
Okay I've gone around the sun with these a few times, and
pretty much implemented what I said last week.
This is pretty much a complete revamp.
1. sync objects are self contained drm objects, they
have a file reference so can be passed between processes.
2. Added a sync object wait interface mod
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and
On 26 April 2017 at 18:45, Christian König wrote:
> Am 26.04.2017 um 05:28 schrieb Dave Airlie:
>>
>> Okay I've gone around the sun with these a few times, and
>> pretty much implemented what I said last week.
>>
>> This is pretty much a complete revamp.
&g
On 26 April 2017 at 17:20, Christian König wrote:
> NAK, I'm wondering how often I have to reject that change. We should
> probably add a comment here.
>
> Even with a zero timeout we still need to enable signaling, otherwise some
> fence will never signal if userspace just polls on them.
>
> If a
On 27 April 2017 at 03:01, Liviu Dudau wrote:
> Hi Dave,
>
> Updated pull request to fix the all-modconfig build on 32bit arm
> builds.
>
> This pull request includes the latest updates on Mali DP, adding
> support for colour management, plane scaling and power management.
> The patches have trick
her
> DRM structures like drm_crtc, drm_connector etc.
>
> Signed-off-by: Dhinakaran Pandiyan
Makes sense, can't think of any reason I initially didn't do this.
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> drivers/gpu/drm/i915/intel_d
> find_vcpi_slots() and reuse drm_dp_mst_allocate_vcpi()
>
Also seem sane, at least for the core bits,
Reviewed-by: Dave Airlie
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 20 +---
> drivers/gpu/drm/i915/intel_dp_mst.c| 4
4962:
Revert "drm/probe-helpers: Drop locking from poll_enable"
(2017-01-26 06:44:03 +1000)
revert one patch missing some prereqs
----
Dave Airlie (1):
M, Markus Trippelsdorf wrote:
> > > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
> > > >>
> > > >> Alex Deucher (8):
> > > >> drm/radeon/si: load special ucode for certa
int Taylor (1):
drm/i915: prevent crash with .disable_display parameter
Dan Carpenter (1):
drm/vc4: fix a bounds check
Daniele Ceraolo Spurio (1):
drm/i915: reinstate call to trace_i915_vma_bind
Dave Airlie (4):
Merge tag 'drm-misc-fixes-2017-01-23' of
git://anong
fencing from execbuf
intel: Clear execobject flags before preserving object in reuse cache
intel: Export a function to re-enable implicit synchronisation
Dave Airlie (2):
Revert "Bump version for 2.4.75 release"
intel: fix make distcheck
Dongwon Kim (1):
int
On 29 January 2017 at 15:41, Shawn Guo wrote:
> Hi Dave,
>
> Please consider to pull the following ZTE DRM driver updates for 4.11.
> Thanks.
Sorry for delay, I've pulled this and fixed up the plane format mismatch,
please confirm it works with drm-next.
Dave.
__
etter (2):
drm: prevent double-(un)registration for connectors
drm: Don't race connector registration
Dave Airlie (4):
Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-fixes
Merge tag 'drm-misc-fixes-2017-01-31' of
git://anongi
>
> I definitely don't want that we don't attempt this. But brought from years
> of experience, I recommend to merge first (with pre-refactoring already
> applied, but helpers only extracted, not yet at the right spot), and then
> follow up with. Because on average, there's way too many trees with
On 5 February 2017 at 18:40, Mark yao wrote:
> Hi Dave
>
> drm/rockchip cdn-dp driver is v17 now, I think it's ready to land it.
>
> Thanks.
>
> The following changes since commit 99743ae4c5f52f8f8ceb17783056fcc9b4f8b64c:
>
> Merge branch 'drm-etnaviv-next' of
> https://git.pengutronix.de/git/ls
drm: vc4: adapt to new behaviour of drm_crtc.c
Chris Wilson (2):
drm/i915: Flush untouched framebuffers before display on !llc
drm/i915: Remove overzealous fence warn on runtime suspend
Dave Airlie (3):
Merge branch 'drm-vmwgfx-fixes-4_10' of
git://people.freedesktop.o
On 11 January 2017 at 12:57, Y.C. Chen wrote:
> From: "Y.C. Chen"
Please run checkpatch over this patch, it's got a lot of bad whitespace issues
(4 space and 2 space indents, indent the timing tables , remove start
of line whitespace.).
Dave.
>
> Signed-off-by: Y.C. Chen
> ---
> drivers/gpu/
On 16 February 2017 at 19:49, Jani Nikula wrote:
>
> Hi Dave, this one superseeds [1]. Better to flush out the single uapi
> fix for v4.11 now so it's not forgotten.
Looks like I had already pulled, I just reverted Maarten's patch on
top of drm-next.
Dave.
___
On 16 February 2017 at 08:16, Marek Vasut wrote:
> Hi,
>
> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
At this stage I'd rather not give these to Linus, can you rebase them onto
drm-next, and resend, feel free to add stable cc's.
Fixes like this should really be getting to me
3:17 +1000)
one i915, one radeon regression fix.
----
Dave Airlie (2):
Merge tag 'drm-misc-fixes-2017-02-15' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
Merge branch 'drm-fixes-4.10' o
On 17 February 2017 at 18:00, Marek Vasut wrote:
> On 02/17/2017 03:41 AM, Dave Airlie wrote:
>> On 16 February 2017 at 08:16, Marek Vasut wrote:
>>> Hi,
>>>
>>> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
>>
>> At this stage I&
On 19 February 2017 at 08:25, Marek Vasut wrote:
> On 02/17/2017 09:34 PM, Dave Airlie wrote:
>> On 17 February 2017 at 18:00, Marek Vasut wrote:
>>> On 02/17/2017 03:41 AM, Dave Airlie wrote:
>>>> On 16 February 2017 at 08:16, Marek Vasut wrote:
>>>&
On 20 Feb. 2017 18:29, "Marek Vasut" wrote:
On 02/20/2017 03:56 AM, Dave Airlie wrote:
> On 19 February 2017 at 08:25, Marek Vasut wrote:
>> On 02/17/2017 09:34 PM, Dave Airlie wrote:
>>> On 17 February 2017 at 18:00, Marek Vasut wrote:
>>>> On 02/17/20
On 17 February 2017 at 22:58, Martin Peres wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the more likely to be interested in the discussion but
> please
On 19 February 2017 at 04:22, Noralf Trønnes wrote:
> Hi Dave,
>
> Please pull tinydrm.
Pulled, just FYI I've seen this on my 32-bit arm builds.
> CC [M] drivers/gpu/drm/tinydrm/mipi-dbi.o
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/tinydrm/mipi-dbi.c:
In function ‘mipi_dbi_debugfs_co
On 20 February 2017 at 21:55, Vincent Abriou wrote:
> Fix compilation warning introduced by:
> commit 0c7ff84f7f9d ("drm/sti: remove deprecated legacy vtg slave")
> commit 5e60f595d6ca ("drm/sti: use atomic_helper for commit")
>
I've pulled this in, please be more careful in future to avoid this
On 1 November 2016 at 08:48, Peter Wu wrote:
> Check whether the kernel really supports power resources for a device,
> otherwise the power might not be removed when the device is runtime
> suspended (DSM should still work in these cases where PR does not).
>
> This is a workaround for a problem w
ilson (1):
drm/i915: Use fence_write() from rpm resume
Dan Carpenter (2):
drm/imx: drm_dev_alloc() returns error pointers
drm/i915: fix a read size argument
Daniel Stone (1):
drm: i915: Wait for fences on new fb, not old
Dave Airlie (5):
Merge tag 'drm-misc
On 7 Nov. 2016 11:40, "Shawn Guo" wrote:
>
> Hi David, Daniel,
>
> On Mon, Oct 31, 2016 at 05:17:22PM +0800, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > The series adds the initial ZTE VOU display controller DRM/KMS driver.
> > There are still some features to be added, like overlay plane, scali
On 4 November 2016 at 20:41, Christophe Fergeau wrote:
> On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
>> > Or maybe other parts of the
>> > kernel/userspace rely on this rounding down.
>>
>> This is where I suspect we could run in trouble. Odd resolutions simply
>> don't happen
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
> udl 1-2:1.0: fb1: udldrmfb frame buffer device
> [drm] Initialized udl on minor 1
> usbcore: registered new interface driver udl
>
>
> Is this expected WARN?
I've just posted a patch in theory to fix it, please test if oyu have time.
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
and it looks like the answer is no, so here's
v2 which kmemdups.
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 16 +++---
On 8 November 2016 at 16:40, Dave Airlie wrote:
>> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
>> udl 1-2:1.0: fb1: udldrmfb frame buffer device
>> [drm] Initialized udl on minor 1
>> usbcore: registered new interface driver udl
>>
>>
>
ilson (2):
drm/i915: Round tile chunks up for constructing partial VMAs
drm/i915: Limit Valleyview and earlier to only using mappable scanout
Christian König (2):
drm/amd: fix scheduler fence teardown order v2
drm/amdgpu: add some error handling to amdgpu_init v2
Dave Air
601 - 700 of 4762 matches
Mail list logo
