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_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1
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 divided from clcdclk instead of
> apb_pclk. Do you agree?
Am 12.04.2017 um 05:58 schrieb Dave Airlie:
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
drm_mode_create_tile_group() uses error pointers, it doesn't return
NULL. I re-arranged it a tiny bit to be more clear.
Fixes: 40d9b043a89e ("drm/connector: store tile information from displayid
(v3)")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_e
On Wed, Apr 12, 2017 at 11:33:50AM +0300, Dan Carpenter wrote:
> drm_mode_create_tile_group() uses error pointers, it doesn't return
> NULL. I re-arranged it a tiny bit to be more clear.
>
> Fixes: 40d9b043a89e ("drm/connector: store tile information from displayid
> (v3)")
> Signed-off-by: Dan
On 11/04/17 03:48 PM, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anythin
Hi Daniel,
On Tuesday 11 Apr 2017 11:03:33 Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> > freedesktop.org has adopted a formal&enforced code of conduct:
> >
> > https://www.fooishbar.org/blog/fdo-contributor-covenant/
> > https://www.freedesktop.org/wiki
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1910-gf20d867a1202)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-gf20d867a1202/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1910-gf20d867a1202
Git Commit: f20
Am Mittwoch, den 12.04.2017, 00:31 + schrieb Wei Yongjun:
> From: Wei Yongjun
>
> Add the missing unlock before return from function etnaviv_gpu_submit()
> in the error handling case.
>
> Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with
> GPU mutex")
> Signed-off-by: Wei
Am 12.04.2017 um 06:57 schrieb 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
Hi Philipp,
Am Montag, den 10.04.2017, 11:15 +0200 schrieb Philipp Zabel:
> Import the etnaviv header changes from kernel commits 9ad59fea162c
> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
> ("drm/etnaviv: submit support for out-fences") for fence fd support.
>
> The drm_etnavi
https://bugs.freedesktop.org/show_bug.cgi?id=100510
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=100510
--- Comment #7 from Christian König ---
Created attachment 130810
--> https://bugs.freedesktop.org/attachment.cgi?id=130810&action=edit
Final solution.
--
You are receiving this mail because:
You are the assignee for the bug.
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1910-g02b830fd67a6)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-g02b830fd67a6/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1910-g02b830fd67a6
Git Commit: 02b
On Wed, Apr 12, 2017 at 11:55:24AM +0200, Christian König wrote:
> Am 12.04.2017 um 06:57 schrieb Dave Airlie:
> >+static int amdgpu_sem_lookup_and_remove(struct amdgpu_cs_parser *p,
> >+ uint32_t handle)
> >+{
> >+int r;
> >+struct dma_fence *old_fence;
> >
Am 12.04.2017 um 12:18 schrieb Chris Wilson:
On Wed, Apr 12, 2017 at 11:55:24AM +0200, Christian König wrote:
Am 12.04.2017 um 06:57 schrieb Dave Airlie:
+static int amdgpu_sem_lookup_and_remove(struct amdgpu_cs_parser *p,
+ uint32_t handle)
+{
+ int r;
On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote:
> 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 behaviou
This is required to for i915 to convert connector properties to atomic.
Signed-off-by: Maarten Lankhorst
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c | 8
include/drm/drm_connector.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_at
Den 11.04.2017 07.29, skrev Laurent Pinchart:
Hi Noralf,
On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote:
Display panels can be oriented many ways, especially in the embedded
world. The rotation property is a way to describe this orientation.
The counter clockwise direction is chosen bec
https://bugs.freedesktop.org/show_bug.cgi?id=100663
Bug ID: 100663
Summary: mesa trunk breaks RS780
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: mediu
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
> while the BO was busy.
>
> Signed-off-by: Eric Anholt
> Cc: sta...@vger.kernel.org
> Cc: Lucas
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 glmark2
> desktop tests on pl
On Tue, Apr 11, 2017 at 10:43:35AM -0700, Eric Anholt wrote:
> Chris Wilson 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
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
> > while the BO was busy.
>
tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj
head: 58ec426a9ee099705987657cfad202b5bd96e363
commit: d9029ccba2bd5d542d384335f3d6e761bd1b3bee [5/8] sync_file: add support
for a semaphore object (v2)
reproduce:
# apt-get install sparse
git checkout d9029ccba2
Hi Daniel,
On 11 April 2017 at 13:03, Sumit Semwal wrote:
> On 11 April 2017 at 12:38, Daniel Stone wrote:
>> Hi,
>>
>> On 11 April 2017 at 07:48, Daniel Vetter wrote:
>>> Note: As Daniel Stone mentioned in the announcement fd.o admins
>>> started chatting with the communities their hosting, wh
Hi Tomi,
On 04/10/2017 01:59 PM, Tomi Valkeinen wrote:
> On 08/04/17 13:11, Hans Verkuil wrote:
>
>> So, this is a bit of a blast from the past since the omap4 CEC development
>> has been on hold for almost a year. But I am about to resume my work on this
>> now that the CEC framework was merged.
Hi Dave,
On 12 April 2017 at 05:57, Dave Airlie wrote:
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> +};
I think this struct need a __u32 pad as well.
Thanks
Emil
__
On 04/12/2017 03:03 PM, Hans Verkuil wrote:
> Hi Tomi,
>
> On 04/10/2017 01:59 PM, Tomi Valkeinen wrote:
>> On 08/04/17 13:11, Hans Verkuil wrote:
>>
>>> So, this is a bit of a blast from the past since the omap4 CEC development
>>> has been on hold for almost a year. But I am about to resume my w
On 12 April 2017 at 11:08, Lucas Stach wrote:
> Hi Philipp,
>
> Am Montag, den 10.04.2017, 11:15 +0200 schrieb Philipp Zabel:
>> Import the etnaviv header changes from kernel commits 9ad59fea162c
>> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
>> ("drm/etnaviv: submit support for
drm-tip/drm-tip boot: 111 boots: 1 failed, 110 passed
(v4.11-rc6-1910-gf20d867a1202)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-gf20d867a1202/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-gf20d
https://bugs.freedesktop.org/show_bug.cgi?id=100663
--- Comment #1 from Emil Velikov ---
octoploid don't think we have many people working on r600, so if you can track
down the commit that caused the regression that will be appreciated.
git bisect should be done in ~7 steps.
--
You are receivi
On 12/04/17 16:03, Hans Verkuil wrote:
> I noticed while experimenting with this that tpd_disconnect() in
> drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c isn't called when
> I disconnect the HDMI cable. Is that a bug somewhere?
>
> I would expect that tpd_connect and tpd_disconnect are bal
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
Acked-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.
drm-tip/drm-tip boot: 115 boots: 1 failed, 114 passed
(v4.11-rc6-1910-g02b830fd67a6)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-g02b830fd67a6/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1910-g02b8
https://bugs.freedesktop.org/show_bug.cgi?id=100663
octoploid changed:
What|Removed |Added
CC||octopl...@yandex.com
--- Comment #2 from oc
Hi Stephen,
can you please add imx-drm/next and etnaviv/next to the linux-next tree?
Both trees stage patches which will eventually feed into Dave Airlie's
drm-next tree.
https://git.pengutronix.de/git/pza/linux imx-drm/next
https://git.pengutronix.de/git/lst/linux etnaviv/next
Regards,
Lucas
On 04/12/2017 03:21 PM, Tomi Valkeinen wrote:
> On 12/04/17 16:03, Hans Verkuil wrote:
>
>> I noticed while experimenting with this that tpd_disconnect() in
>> drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c isn't called when
>> I disconnect the HDMI cable. Is that a bug somewhere?
>>
>> I wo
Hi Dave, I've had most of these ready for more than a week now, but
there was no use sending them as you were away. Fixes all around, except
not so much display stuff this time. Hopefully winding down for this
cycle now.
BR,
Jani.
The following changes since commit 0abfe7e2570d7c729a7662e82c09a2
On Wed, Apr 12, 2017 at 4:06 PM, Jani Nikula wrote:
>
> Hi Dave, I've had most of these ready for more than a week now, but
> there was no use sending them as you were away. Fixes all around, except
> not so much display stuff this time. Hopefully winding down for this
> cycle now.
The rcu fix fr
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 to use of_graph_get_remote_node")
Signed-off-by:
On Wed, Apr 12, 2017 at 04:08:15PM +0200, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 4:06 PM, Jani Nikula wrote:
> >
> > Hi Dave, I've had most of these ready for more than a week now, but
> > there was no use sending them as you were away. Fixes all around, except
> > not so much display stuf
https://bugs.freedesktop.org/show_bug.cgi?id=100663
octoploid changed:
What|Removed |Added
CC||hi-an...@yandex.ru
Summary|mesa
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1913-gca184421c5d2)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1913-gca184421c5d2/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1913-gca184421c5d2
Git Commit: ca1
On Wed, Apr 12, 2017 at 04:56:21PM +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's
> reuse it here.
>
> Also drop drm_unplug_dev, be
https://bugs.freedesktop.org/show_bug.cgi?id=100510
Michel Dänzer changed:
What|Removed |Added
CC|mic...@daenzer.net |
--- Comment #8 from Michel Dänzer ---
On Mon, Apr 10, 2017 at 01:37:01PM +0100, Chris Wilson wrote:
> On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> > Yet again I've proven that I can't negate conditions :(
> >
> > Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> > ioctl")
>
> You also get to
Motivated by a request from Eric.
Cc: Eric Anholt
Cc: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
drivers/gpu/drm/drm_color_mgmt.c| 9 ++---
include/drm/drm_crtc.h | 31 +--
3 files changed,
Hi Lucas,
On Wed, 12 Apr 2017 15:59:44 +0200 Lucas Stach wrote:
>
> can you please add imx-drm/next and etnaviv/next to the linux-next tree?
>
> Both trees stage patches which will eventually feed into Dave Airlie's
> drm-next tree.
>
> https://git.pengutronix.de/git/pza/linux imx-drm/next
>
>
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
> >> wrote:
> >> > As the DRM LVDS panel driver uses a different a
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=100663
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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
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
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
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
>
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 ++
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
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
>>
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
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
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
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
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
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.
> > >
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
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
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
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
>>
>> 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
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
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
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/
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
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 ++-
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
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
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 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:
>
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 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 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 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 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 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 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
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 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
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
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
1 - 100 of 150 matches
Mail list logo
