tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem
head: faf022804be516663a33f620536b006a56d59ee4
commit: 8281fe367426f82485f68767c5c8c7106685e9a9 [3/8] sync_file: split out
fence_file base class from sync_file.
config: x86_64-randconfig-s3-04131130 (attached as .config)
com
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #11 from Michel Dänzer ---
(In reply to at46n from comment #10)
> I started steam in a terminal but there is only steam and normal game output
> like in crash.log but nothing from valgrind.
It might be captured in ~/.steam/error.log
tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem
head: 7194cd4513c3cb05f312dc66c36a2c9fbd4c1aa1
commit: 8281fe367426f82485f68767c5c8c7106685e9a9 [3/7] sync_file: split out
fence_file base class from sync_file.
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debi
drm-tip/drm-tip boot: 149 boots: 5 failed, 143 passed with 1 offline
(v4.11-rc6-1924-g22e5f388a82d)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1924-g22e5f388a82d/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
From: Tom Cooksey
This is a modesetting driver for the pl111 CLCD display controller
found on various ARM platforms such as the Versatile Express. The
driver has only been tested on the bcm911360_entphn platform so far,
with PRIME-based buffer sharing between vc4 and clcd.
It reuses the existing
We'd like to reuse these register definitions for the DRM CLCD driver,
but there's a bunch of fbdev-specific code in the current header.
v2: Add #ifndef guard.
Signed-off-by: Eric Anholt
---
include/linux/amba/clcd-regs.h | 81 ++
include/linux/amba/clcd.
Hi Linus,
I was away the end of last week, so some of these would have been in
rc6, and it's Easter from tomorrow, so I decided I better dequeue what
I have now.
The nouveau changes, just add a hw enable for GP107 display (like a
pci id addition really), and fix a couple of regressions.
i915 has
On Thu, Apr 13, 2017 at 11:41:41AM +1000, Dave Airlie wrote:
> 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
> i
On 04/12/2017 11:13 PM, Marek Szyprowski wrote:
Hi Hoegeun,
On 2017-04-12 15:58, Hoegeun Kwon wrote:
On 04/12/2017 04:22 PM, Andrzej Hajda wrote:
DSIM uses MIC bridge which is between DECON and DSIM, so the driver
should expect bridge node on input side.
Fixes: 86418f9 ("drm: convert drivers
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 +++
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 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 file change
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 semaphore
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
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 acc
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
or new fe
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 |
Hi Shashank,
On 07-04-2017 17:39, Shashank Sharma wrote:
> HDMI source must set output colorspace information in AVI
> infoframes, so that the sink can decode upcoming frames
> accordingly.
>
> As this patch series is adding support for HDMI output modes
> other than RGB, this patch adds a functi
After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so let's
reuse it here.
Also drop drm_unplug_dev, because it would be unused after other changes.
Signed-off-by: Jeffy Chen
After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so let's
reuse it here.
Also drop drm_unplug_dev, because it would be unused after other changes.
Signed-off-by: Jeffy Chen
On Wed, Apr 12, 2017 at 09:40:38AM +0200, Linus Walleij wrote:
> On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote:
> > Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL,
> > which seems to be necessary on this platform. My understanding is that
> > this means that the pix
Hi Daniel,
On 04/12/2017 02:36 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:42AM +0800, Jeffy Chen wrote:
We are freeing all framebuffers in drm_mode_config_cleanup without
sync the drm_file's fbs list.
So if someone try to unbind drm before release drm dev fd, the fbs
list would rem
On 04/12/2017 04:22 PM, Andrzej Hajda wrote:
DSIM uses MIC bridge which is between DECON and DSIM, so the driver
should expect bridge node on input side.
Fixes: 86418f9 ("drm: convert drivers to use of_graph_get_remote_node")
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_
Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes
during unbind/bind drm with/out ui service running.
Changes in v8:
Fix hang when unregistering drm dev with open_count 0
Changes in v7:
Address Sean Paul 's comments.
Update commit message.
Changes in v6:
Address Daniel
Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes
during unbind/bind drm with/out ui service running.
Changes in v9:
Move drm_device_set_plug_state into drm_drv.c .
Changes in v8:
Fix hang when unregistering drm dev with open_count 0.
Changes in v7:
Add drm_device_set_
Hi Daniel,
On 04/12/2017 02:33 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:41AM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so
let'
On Tue, Apr 11, 2017 at 09:24:33AM +0200, Lukas Wunner wrote:
> Hi Nikhil,
>
> On Tue, Apr 11, 2017 at 09:44:35AM +0530, Nikhil Mahale wrote:
> > There is not interest in relaxing the export of refcount_inc, and
> > changing the license of nvidia-drm.ko isn't viable right now.
>
> Why not dual-l
Sorry for that. I'll split the patch and I'll come again ;)
El dia 11/04/2017 22:12, "Karol Herbst" va escriure:
thanks for the work, but could you please split that patch?
It looks like you are doing several things at once and it isn't really
easy to review like this. And it isn't bisectable.
On Tue, Apr 11, 2017 at 05:48:25PM +0200, Christian König wrote:
> Am 24.03.2017 um 16:47 schrieb Bjorn Helgaas:
> >On Mon, Mar 13, 2017 at 01:41:35PM +0100, Christian König wrote:
> >>From: Christian König
> >>
> >>Most BIOS don't enable this because of compatibility reasons.
> >Can you give any
On Tue, Apr 11, 2017 at 1:32 PM, Ilia Mirkin wrote:
> On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater
> wrote:
> > + /* HDMI 3D support */
> > + if ((disp->disp.oclass >= NV50_DISP)
>
> You probably meant G82_DISP. Although I don't know if there were any
> G80's with DP or HDMI
On Tue, Apr 11, 2017 at 02:00:21PM -0700, Eric Anholt wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote:
> >> Russell King - ARM Linux writes:
> >>
> >> > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote:
> >> >> v5: Move regi
We are freeing all framebuffers in drm_mode_config_cleanup without
sync the drm_file's fbs list.
So if someone try to unbind drm before release drm dev fd, the fbs
list would remain some invalid fb references. And that would cause
crash later in drm_fb_release.
Add a sanity check to prevent that.
Hi Shashank,
On 07-04-2017 17:39, Shashank Sharma wrote:
> HDMI displays can support various output types, based on
> the color space and subsampling type. The possible
> outputs from a HDMI 2.0 monitor could be:
> - RGB
> - YCBCR 444
> - YCBCR 422
> - YCBCR 420
>
> This patch adds a drm prop
Hi Daniel,
missed some questions...
On 04/12/2017 04:17 PM, jeffy wrote:
Hi Daniel,
On 04/12/2017 02:33 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:41AM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm io
On Tue, Apr 11, 2017 at 05:37:04PM +0200, Christian König wrote:
> >>+int pci_resize_resource(struct pci_dev *dev, int resno, int size)
> >>+{
> >>+ struct resource *res = dev->resource + resno;
> >>+ u32 sizes = pci_rbar_get_possible_sizes(dev, resno);
> >>+ int old = pci_rbar_get_current_s
Eric Anholt writes:
> Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to
> keep from triggering the hardware addressing bug between of the tile
> binner of the tile alloc memory (where the top 4 bits come from the
> tile state data array's address).
>
> To work around that and a
drm-tip/drm-tip boot: 136 boots: 5 failed, 128 passed with 3 offline
(v4.11-rc6-1923-g57188aaf3b96)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1923-g57188aaf3b96/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1924-g22e5f388a82d)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1924-g22e5f388a82d/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1924-g22e5f388a82d
Git Commit: 22e
On Wed, Apr 12, 2017 at 10:26 AM, Thierry Reding wrote:
> On Tue, Apr 11, 2017 at 12:10:47PM -0500, Rob Herring wrote:
>> On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding wrote:
>> > On Fri, Apr 07, 2017 at 05:44:15AM +1000, Dave Airlie wrote:
>> >> On 5 April 2017 at 16:51, Laurent Pinchart
>> >>
Hi Dave,
Sending this pull a bit early so you can pick up the get_property fix. There are
reports that X fails to start as a result of the bug. The dw-hdmi change gets to
come along for the ride, it's not mission critical, but nice to have for
dw-hdmi platforms with ambitious monitors.
drm-misc-ne
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
>> > fair expectation that our
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
> > fair expectation that our code to handle sync_files will continue to
> > work.
>
drm-tip/drm-tip boot: 130 boots: 2 failed, 128 passed
(v4.11-rc6-1922-gf8d5030b74c1)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-gf8d5030b74c1/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-gf8d5
>
> 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
drm-tip/drm-tip boot: 145 boots: 3 failed, 142 passed
(v4.11-rc6-1922-ga428480d2c4f)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-ga428480d2c4f/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-ga428
The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
only render to buffers that are marked as secure and inaccessible
to the kernel and user through a series of hardware protections. In
practice secure mode is used to draw things like a UI on a secure
video frame.
In order to switc
Hey Rob -
Here is the stack of stuff to add the zap shader for msm-next. I left
the code broken out as the first two changes are merged into the device
specific tree and the third one has been seen before so this should
hopefully cut down on confusion.
The following patches are basically the chan
The 'zap-shader' subnode is used to define a phandle for the
PIL memory region that is required to load GPU secure firwmare images
(known as the "zap shader").
Signed-off-by: Jordan Crouse
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 13 +
1 file changed, 13 insertions
The zap shader firmware name is not platform specific. Move it
to the device table instead.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 24
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h|
Simply the code use snprintf correctly and make sure that we memset
the rest of the segment if the memory size in the ELF file is larger
than the file size.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 70 +--
1 file changed, 35 inserti
Currently we abuse the platform device engine to create a platform
device for the zap shader subnode so that we can isolate the
reserved memory away from the parent GPU device.
It is much safer to create and register a simple child device and use
that instead.
Signed-off-by: Jordan Crouse
---
d
In order to switch the GPU out of secure mode on most systems we
need to load a zap shader into memory and get it authenticated
and into the secure world. All the bits and pieces to do
the load are scattered throughout the kernel, but we need to
bring everything together.
Add a semi-custom loader
On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote:
> 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
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1923-g57188aaf3b96)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1923-g57188aaf3b96/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1923-g57188aaf3b96
Git Commit: 571
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 barring
>> > >> wakeups/polling on semaphore sy
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 barring
> > >> wakeups/polling on semaphore sync_files, and just punting this
> > >> until we need i
On 04/12/2017 01:12 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
>> On 04/12/2017 12:38 PM, Chris Wilson wrote:
>>> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
Both the read/write are missing the dma_buf_begin_cpu_access calls.
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 Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
> On 04/12/2017 12:38 PM, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> >> Both the read/write are missing the dma_buf_begin_cpu_access calls.
> >> When I add those these seem to work well enough
On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> >>
> >> 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
On 04/12/2017 12:38 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
>> On 04/07/2017 02:25 PM, Chris Wilson wrote:
>>> It is expected that processes will pass dma-buf fd between drivers, and
>>> only using the fd themselves for mmaping and synchronisation ioc
On Wed, Apr 12, 2017 at 1:42 PM, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 5:44 PM, Thierry Reding wrote:
>> On Tue, Apr 11, 2017 at 01:56:35PM -0500, Rob Herring wrote:
>>> On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie wrote:
>>> > On 10 April 2017 at 19:03, Laurent Pinchart
>>> > wrote:
>
drm-tip/drm-tip boot: 160 boots: 5 failed, 153 passed with 2 offline
(v4.11-rc6-1920-g1ed4cc0b0d37)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1920-g1ed4cc0b0d37/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> On 04/07/2017 02:25 PM, Chris Wilson wrote:
> > It is expected that processes will pass dma-buf fd between drivers, and
> > only using the fd themselves for mmaping and synchronisation ioctls.
> > However, it may be convenient for an a
This is needed for proper synchronization with display on another DRM
device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
desktop tests on pl111+vc4.
This doesn't yet introduce waits on other device's fences b
If we follow the typical pattern of the base class being the first
member, we can use the default dma_fence_free function.
Signed-off-by: Eric Anholt
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fence.c | 10 ++
1 file c
Without this, polling on the dma-buf (and presumably other devices
synchronizing against our rendering) would return immediately, even
while the BO was busy.
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
Cc: sta...@vger.kernel.org
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: free
If we follow the typical pattern of the base class being the first
member, we can use the default dma_fence_free function.
Signed-off-by: Eric Anholt
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 ++-
Without this, polling on the dma-buf (and presumably other devices
synchronizing against our rendering) would return immediately, even
while the BO was busy.
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
Cc: sta...@vger.kernel.org
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Since I got feedback that the dma_fence .release pattern I followed
was unnecessary, here's a resubmit with that changed and the two
drivers I was looking at cleaned up as well. As before, they're only
compile-tested.
I'd prefer that if msm/etnaviv developers like them, they pull those
two patche
2017-04-10 16:52 GMT+02:00 Vincent Abriou :
> drm/sti driver is now part of drm-misc as a small driver.
>
> Signed-off-by: Vincent Abriou
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ea82b2..66b424a 100644
> --- a/
drm-tip/drm-tip boot: 143 boots: 5 failed, 136 passed with 2 offline
(v4.11-rc6-1916-g53b9521a6f11)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1916-g53b9521a6f11/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
https://bugs.freedesktop.org/show_bug.cgi?id=98629
--- Comment #9 from Emil Velikov ---
Seems like I forgot to mention - drm_chr_dev() itself picks the first unused
major.
So it's not like it's uninitialised, but rather random and non-deterministic.
--
You are receiving this mail because:
You a
>>
>> 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
2017-04-11 22:45 GMT+02:00 Eric Anholt :
> Yannick Fertre writes:
>
>> This controller provides output signals to interface directly a variety
>> of LCD and TFT panels. These output signals are: RGB signals
>> (up to 24bpp), vertical & horizontal synchronisations, data enable and
>> the pixel cloc
drm-tip/drm-tip boot: 138 boots: 5 failed, 132 passed with 1 offline
(v4.11-rc6-1913-gca184421c5d2)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1913-gca184421c5d2/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
On 04/07/2017 02:25 PM, Chris Wilson wrote:
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a test case
https://bugs.freedesktop.org/show_bug.cgi?id=100666
Bug ID: 100666
Summary: amdgpu coolers never stoping linux
Product: DRI
Version: unspecified
Hardware: All
OS: Linux (All)
Status: NEW
Severity: normal
2017-04-11 Daniel Vetter :
> On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote:
> > Gustavo Padovan writes:
> >
> > > From: Gustavo Padovan
> > >
> > > In some cases, like cursor updates, it is interesting to update the
> > > plane in an asynchronous fashion to avoid big delays.
> > >
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1922-gf8d5030b74c1)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-gf8d5030b74c1/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1922-gf8d5030b74c1
Git Commit: f8d
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings
(v4.11-rc6-1922-ga428480d2c4f)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1922-ga428480d2c4f/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1922-ga428480d2c4f
Git Commit: a42
Hi Dave,
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.12-rc1
for you to fetch changes up to e4bac408b08437d19078
On Wed, Apr 12, 2017 at 5:44 PM, Thierry Reding wrote:
> On Tue, Apr 11, 2017 at 01:56:35PM -0500, Rob Herring wrote:
>> On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie wrote:
>> > On 10 April 2017 at 19:03, Laurent Pinchart
>> > wrote:
>> >> Hi Thierry,
>> >>
>> >> On Monday 10 Apr 2017 09:17:59 T
Daniel Vetter writes:
> On Mon, Apr 10, 2017 at 06:44:14PM -0700, Eric Anholt wrote:
>> This is needed for proper synchronization with display on another DRM
>> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
>> new igt vc4_dmabuf_poll testcase, and rendering of one of the
Lucas Stach writes:
> Am Mittwoch, den 12.04.2017, 14:47 +0200 schrieb Daniel Vetter:
>> On Mon, Apr 10, 2017 at 06:44:13PM -0700, Eric Anholt wrote:
>> > Without this, polling on the dma-buf (and presumably other devices
>> > synchronizing against our rendering) would return immediately, even
>>
This adds support for the NLT Technologies NL192108AC18-02D
15.6" LVDS FullHD TFT LCD panel, which can be supported
by the simple panel driver.
Timings are taken from the preliminary datasheet, as a final
one is not yet available.
Signed-off-by: Lucas Stach
---
.../display/panel/nlt,nl192108ac1
https://bugs.freedesktop.org/show_bug.cgi?id=100510
--- Comment #9 from Christian König ---
(In reply to Michel Dänzer from comment #8)
> Thanks, but I actually receive updates via the dri-devel mailing list.
>
> Do we know yet which flags are getting passed to radeon_bo_open for the
> BO(s) in
NLT technologies is the former NEC display business, but changed its
name to NLT Technologies when forming a joint venture with
Shenzhen AVIC OPTOELECTRONICS, Ltd.
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --g
This adds support for the AU Optronics Corporation 31.5"
FHD (1920x1080) LVDS TFT LCD panel, which can be supported
by the simple panel driver.
Signed-off-by: Lucas Stach
---
.../bindings/display/panel/auo,p320hvn03.txt | 7 +
drivers/gpu/drm/panel/panel-simple.c | 31 ++
On 04/12, Neil Armstrong wrote:
> On 04/12/2017 09:40 AM, Linus Walleij wrote:
> > On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote:
> >
> >> Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL,
> >> which seems to be necessary on this platform. My understanding is that
>
From: Colin Ian King
Trivial fix to spelling mistake in DRM_DEBUG_ATOMIC debug message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_atomic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings
(v4.11-rc6-1920-g1ed4cc0b0d37)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1920-g1ed4cc0b0d37/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1920-g1ed4cc0b0d37
Git Commit: 1ed
Hi Dave,
a single fix for the patch merged in rc5. I messed up the error handling
there and Wei helpfully provided a patch to remedy this.
Regards,
Lucas
The following changes since commit 130e35e4bbceb2c04ff0ad9b1a0bcef7acc11498:
Merge branch 'msm-fixes-4.11-rc6' of
git://people.freedesktop
On Thu, 23 Mar 2017, Vincent Abriou wrote:
> On stih407-410 chip family the GDP layers are able to support up to UHD
> resolution (3840 x 2160).
>
> Signed-off-by: Vincent Abriou
> ---
> drivers/gpu/drm/sti/sti_gdp.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
Please en
https://bugs.freedesktop.org/show_bug.cgi?id=100663
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Tue, Apr 11, 2017 at 01:56:35PM -0500, Rob Herring wrote:
> On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie wrote:
> > 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 +0
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings
(v4.11-rc6-1916-g53b9521a6f11)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1916-g53b9521a6f11/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1916-g53b9521a6f11
Git Commit: 53b
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #10 from at...@t-online.de ---
Yes, that works. Valgrind starts the game which takes a long time (about 20
min). But how do I get the log from valgrind now? I started steam in a terminal
but there is only steam and normal game output
On Wed, Apr 12, 2017 at 12:57 AM, Dave Airlie wrote:
> 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 enhance
On 04/12/2017 09:40 AM, Linus Walleij wrote:
> On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote:
>
>> Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL,
>> which seems to be necessary on this platform. My understanding is that
>> this means that the pixel clock is divide
1 - 100 of 150 matches
Mail list logo
