Hi guys,
Mareks IOCTL proposal looks really good to me.
Please note that we already have sync_obj support for the CS IOCTL in
the 4.13 branch and this work is based on top of that.
UMD don't need to construct ip_type/ip_instance/ctx_id/ring
Well the UMD does want to construct ip_type/ip_inst
Hi Emil,
On 2017-09-12 17:02, Emil Velikov wrote:
Hi Marek,
Just a couple of small suggestions - this is by no means a proper review.
Thanks, I really appreciate your suggestions! I've tried to make userspace
API 32/64bit agnostic, but it looks that I still need to learn a bit in this
area.
Hi Noralf,
Thank you for the patches.
On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:
> Hi,
>
> I want to start out by saying that this patchset is low priority for me
> and if no one has interest or time to review this, that is just fine. I
> was in the flow and just typed it o
Hi Marek,
You're doing same things with me, see my "introduce syncfile as fence
reuturn" patch set, which makes things more simple, we just need to
directly return syncfile fd to UMD when CS, then the fence UMD get will
be always syncfile fd, UMD don't need to construct
ip_type/ip_instance/ct
Hi Dave,
A few fixes for 4.14. Nothing too major.
The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f:
Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next
(2017-08-23 05:32:26 +1000)
are available in the git repository at:
git://people.freede
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Michel Dänzer changed:
What|Removed |Added
Product|Mesa|DRI
Version|17.1
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Michel Dänzer changed:
What|Removed |Added
Attachment #134181|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #7 from Michel Dänzer ---
With xf86-video-amdgpu 1.3.0 or newer:
xrandr --output --set TearFree on # or off / auto
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #6 from Niklas Haas ---
Neat, thanks!
(I also noticed an _ICC_PROFILE setting there, I wonder if that refers to the
X11 atom or if there's some sort of built-in ICC profile querying mechanism
inherent to RandR anyway, offtopic)
Hi Noralf,
Thank you for the patch.
On Monday, 11 September 2017 19:37:45 EEST Noralf Trønnes wrote:
> GEM lookup failure can easily be triggered by userspace so make
> it a debug message, not an error message.
>
> Also remove unnecessary inner parentheses and fix alphabetical
> struct declarati
Hi Noralf,
Thank you for the patch.
On Monday, 11 September 2017 19:37:44 EEST Noralf Trønnes wrote:
> Make the docs read a little better.
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Daniel Vetter
> ---
>
> Changes:
> Addressed Daniel's comments.
>
> drivers/gpu
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #5 from Alex Deucher ---
(In reply to Niklas Haas from comment #4)
> How does this work? I'm not seeing anything related to TearFree or driver
> options in `xrandr --help`.
>
> (Avoiding the use of a xorg.conf would indeed be nice,
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #4 from Niklas Haas ---
How does this work? I'm not seeing anything related to TearFree or driver
options in `xrandr --help`.
(Avoiding the use of a xorg.conf would indeed be nice, since it would prevent
me from having to mess aroun
Hi Sylwester,
On 09/11/2017 06:35 PM, Sylwester Nawrocki wrote:
On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.
Signed-off-by: Hoegeun Kwon
---
drivers/media/platform/ex
On 09/10/2017 04:57 AM, kbuild test robot wrote:
Hi Hoegeun,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #3 from Alex Deucher ---
(In reply to Niklas Haas from comment #1)
> Seems like this is an expected behavior when TearFree is disabled. Manually
> enabling TearFree in xorg.conf appears to solve my issue.
You can dynamically enable
https://bugs.freedesktop.org/show_bug.cgi?id=102681
Niklas Haas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #2 from Niklas Haas ---
(Including the P.s., I might add)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=102681
--- Comment #1 from Niklas Haas ---
Seems like this is an expected behavior when TearFree is disabled. Manually
enabling TearFree in xorg.conf appears to solve my issue.
--
You are receiving this mail because:
You are the assignee for the bug.
On 09/12/2017 11:19 AM, Jani Nikula wrote:
> Patch 1 is v3 of [1]. There are no functional changes to the previous
> version, just a rebase and a slight refresh of the commit message and
> comments. I think the conclusion from the discussion was that this
> should work just fine. At least one use
Hi Linus,
Thank you for the patch.
On Friday, 1 September 2017 12:40:37 EEST Linus Walleij wrote:
> This adds device tree bindings for the Texas Instruments
> THS8134A and THS8134B VGA DACs by extending and renaming the
> existing bindings for THS8135.
>
> These DACs are used for the VGA outputs
Hi Linus,
Thank you for the patch.
On Friday, 1 September 2017 12:40:58 EEST Linus Walleij wrote:
> This extends the dumb VGA DAC bridge to handle the THS8134A
> and THS8134B VGA DACs in addition to those already handled.
>
> The THS8134A, THS8134B and as it turns out also THS8135 need to
> have
Hi Hean Loong,
On Monday, 4 September 2017 09:09:11 EEST Ong, Hean Loong wrote:
> On Mon, 2017-08-28 at 13:06 +0800, Ong, Hean Loong wrote:
> > On Thu, 2017-08-24 at 12:39 +0300, Laurent Pinchart wrote:
> >> On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote:
> >>>
> >>> Hi Laurent,
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #6 from Justin Mitzel ---
Created attachment 134182
--> https://bugs.freedesktop.org/attachment.cgi?id=134182&action=edit
Output of journalctl -k
Thought I'd add this for good measure.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #5 from Justin Mitzel ---
Created attachment 134181
--> https://bugs.freedesktop.org/attachment.cgi?id=134181&action=edit
Current Xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #4 from Justin Mitzel ---
Created attachment 134180
--> https://bugs.freedesktop.org/attachment.cgi?id=134180&action=edit
The Dmesg output
--
You are receiving this mail because:
You are the assignee for the bug._
On Tue, Sep 05, 2017 at 11:43:04AM +0300, Mikko Perttunen wrote:
> Add the Tegra186-specific hypervisor-related register range
> properties.
>
> Signed-off-by: Mikko Perttunen
> ---
> v2:
> - Dropped incorrect note about cells properties.
>
> .../devicetree/bindings/display/tegra/nvidia,tegra20
On Tue, Sep 05, 2017 at 03:12:30PM +0800, Hean-Loong, Ong wrote:
> From: Ong Hean Loong
>
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height and
https://bugs.freedesktop.org/show_bug.cgi?id=102552
--- Comment #8 from Pauk Denis ---
I have sent version patch to mesa-...@lists.freedesktop.org.
https://patchwork.freedesktop.org/series/30086/
--
You are receiving this mail because:
You are the assignee for the bug._
From: Marek Olšák
---
amdgpu/amdgpu.h| 20
amdgpu/amdgpu_cs.c | 12
2 files changed, 32 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b44b9b6..979acfc 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1354,6 +1354,26 @@ int amdgpu_
From: Marek Olšák
---
include/drm/drm.h | 24
xf86drm.c | 22 ++
xf86drm.h | 3 +++
3 files changed, 49 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index bf3674a..4da1667 100644
--- a/include/drm/drm.h
+++ b/incl
From: Marek Olšák
---
amdgpu/amdgpu.h| 30 ++
amdgpu/amdgpu_cs.c | 20
2 files changed, 50 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 238b1aa..b44b9b6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1383,6 +1383
From: Marek Olšák
---
amdgpu/amdgpu.h | 14 ++
amdgpu/amdgpu_cs.c | 22 ++
include/drm/amdgpu_drm.h | 21 +
3 files changed, 57 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 979acfc..23cde10 100644
--- a/amd
From: Marek Olšák
For amdgpu.
drm_syncobj_create is renamed to drm_syncobj_create_as_handle, and new
helpers drm_syncobj_create and drm_syncobj_get_handle are added.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/drm_syncobj.c | 49 +++
include/drm/drm_
From: Marek Olšák
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/drm_syncobj.c | 33 +++--
include/drm/drm_syncobj.h | 1 +
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0bb17
From: Marek Olšák
for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 61 +
drivers/gpu/drm/amd/amdgpu/am
On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > > > Use the POWER_DOWN_PHY an
https://bugzilla.kernel.org/show_bug.cgi?id=196733
Liberty (mrlhwlibe...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > > set power states for
https://bugs.freedesktop.org/show_bug.cgi?id=102659
--- Comment #3 from vilsol2...@gmail.com ---
To add to my original. I have been using this laptop on Win for a while, and it
still works just fine, so I am sure it is not the GPU at fault.
--
You are receiving this mail because:
You are the ass
https://bugzilla.kernel.org/show_bug.cgi?id=196777
--- Comment #3 from Krzysztof Nowicki (kri...@op.pl) ---
(In reply to Gerd Hoffmann from comment #2)
> can you check whenever this patch fixes it?
>
> https://www.kraxel.org/cgit/linux/commit/?h=drm-qxl-
> atomic&id=b16a0bb7a9d54d9dd256059b35adf6
On 12 September 2017 at 18:47, Colin Ian King wrote:
> On 12/09/17 18:42, Thomas Hellstrom wrote:
>> Hi, Colin,
>>
>> On 09/12/2017 07:35 PM, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> mmap'ing the device multiple times will spam the kernel log with the
>>> DRM_ERROR message about illegal
On 12/09/17 18:42, Thomas Hellstrom wrote:
> Hi, Colin,
>
> On 09/12/2017 07:35 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> mmap'ing the device multiple times will spam the kernel log with the
>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> How are you hitting this? Mult
Hi, Colin,
On 09/12/2017 07:35 PM, Colin King wrote:
From: Colin Ian King
mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space.
How are you hitting this? Multiple mappings should be fine as long as
mapping offsets are
On Mon, Sep 11, 2017 at 01:25:45PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
>
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this ca
From: Colin Ian King
mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space. Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.
Signed-off-by: Colin Ian King
---
driver
From: Colin Ian King
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed")
https://bugs.freedesktop.org/show_bug.cgi?id=102684
Bug ID: 102684
Summary: Monitor sometimes cuts to black after idling overnight
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: N
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
Hi
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 6d5104c5a6b56385426e15047050584794bb6254 upstream.
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent notice
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't h
https://bugs.freedesktop.org/show_bug.cgi?id=102683
Bug ID: 102683
Summary: mpv confuses the frequency scaling, leading to
freqyency flapping and missed vsyncs
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Fri, Sep 01, 2017 at 11:40:37AM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Texas Instruments
> THS8134A and THS8134B VGA DACs by extending and renaming the
> existing bindings for THS8135.
>
> These DACs are used for the VGA outputs on the ARM reference
> designs such
https://bugs.freedesktop.org/show_bug.cgi?id=102681
Bug ID: 102681
Summary: OpenGL applications not vsyncing correctly when the
window size doesn't perfectly match the screen
Product: Mesa
Version: 17.2
Hardware: Other
On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > set power states for downstream sinks. Apart from giving us the ability
> > to set po
On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> set power states for downstream sinks. Apart from giving us the ability
> to set power state for individual sinks, this fixes the below test for
> me
>
>
On Thu, Aug 31, 2017 at 05:55:19PM +0200, Boris Brezillon wrote:
> Document the bindings used for the Cadence DSI bridge.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> - Fix clock names in the example
> - Document how to represent DSI devices that are controller through
> an exter
Hi Lucas
2017-09-11 15:10 GMT+02:00 Lucas Stach :
> Hi Christian,
>
> Am Donnerstag, den 31.08.2017, 18:08 +0200 schrieb Christian Gmeiner:
>> 2017-08-25 11:06 GMT+02:00 Christian Gmeiner :
>
> [...]
>
>> It looks like I have screwed up patches 03 and 04 - used v1 ones
>> instead of v2 :/
>> I wil
Some performance register are debug register and they need to
be enabled in order to be functional.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv
We increment the minor driver version so userspace can detect perfmon support.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index fa9b5f4b0ccb..2345c71e164a 100644
--- a/drivers/
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index ac92684ee7af..fa9b5f4b0ccb 100644
--- a/
As done by Vivante kernel driver.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 842b6642d
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index c32ad2608d4e..ac92684ee7af 100644
--- a/
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 43d1c4b0c01a..c32ad2608d4e 100644
--- a/drivers/gpu/d
We need to iterate over all pixel pipelines to get overall value.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnav
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index e01eb7447005..f23bc056a680 100644
--- a/
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 16
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 3e
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index f23bc056a680..43d1c4b0c01a 100644
--- a/
With 'sync points' we can sample the reqeustes perform signals
before and/or after the submited command buffer.
Changes v2 -> v3:
- fixed indentation and init nr_events to 1
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 102 +++---
driv
Changes from v1 -> v2:
- renamed submit_perfmon_request() to submit_perfmon_validate()
- extended flags validation
- added comment about offset 0
- moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs.
Changes from v2 -> v3:
- fixed flags validation
Signed-off-by: Christian Gme
In order to support performance counters in a sane way we need to provide
a method to sync the GPU with the CPU. The GPU can process multpile command
buffers/events per irq. With the help of a 'sync point' we can trigger an event
and stop the GPU/FE immediately. When the CPU is done with is process
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 41e12f2a1dbd..212e1cee61fa 100644
--- a/
Results in less code as the users do not set every struct member to 0/NULL.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gp
In a perfect world we would be able to read GPU registers of interest
via the command stream with a 'read-register' command/package. For perf
counters it is a must to read them synchronized with the GPU to put the
values in relation to a draw command. As Vivante GPUs do not provide this
functionali
This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
of struct etnaviv_perfmon elements gets used.
Changes from v1 -> v2:
- make use of goto as requested by Lucas
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 ++-
drivers/gpu/
Check if the selected domain and signal combination exists.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 15 +++
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gp
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 4
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 12
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
index 80d7807
Sadly we can not read any registers via command stream so we need
to extend the drm_etnaviv_gem_submit struct with performance monitor
requests. Those requests gets process before or after the actual
submitted command stream.
The Vivante kernel driver has a special ioctl to read all perfmon
regist
Make it possible that userspace can query all performance domains and
its signals. This information is needed to sample those signals via
submit ioctl.
At the moment no performance domain is available.
Changes from v1 -> v2:
- use a 16 bit value for signals
- fix padding issues
- add id member
This makes it possible to allocate multiple events under the event
spinlock. This change is needed to support 'sync'-points.
Changes v2 -> v3:
- wait for the completion of all events
- use 10sec timeout regardless of the number of events
- removed validation if there are enough free events
- fixed
This is prep work to be able to allocate multiple events in one go.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 +--
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 --
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a
Hi Marek,
Just a couple of small suggestions - this is by no means a proper review.
On 12 September 2017 at 09:08, Marek Szyprowski
wrote:
> This patch adds Exynos IPP v2 subsystem and userspace API.
>
> New userspace API is focused ONLY on memory-to-memory image processing.
> The two remainging
On Thu, Aug 31, 2017 at 01:01:54PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
>
> Signed-off-by: Hans Verkuil
> ---
> .../devicetree/bindings/media/
On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote:
> On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> > That said, I'm not sure how useful the information is - perhaps
> > it's
> > better to drop it all together?
>
> Or a WARN_ONCE().
It's userspace calling into the driver wit
On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> That said, I'm not sure how useful the information is - perhaps it's
> better to drop it all together?
Or a WARN_ONCE().
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=102650
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Colin,
On 12 September 2017 at 10:45, Colin King wrote:
> From: Colin Ian King
>
> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
> log with qxl_mmap information messages. The following example code
> illustrates this:
>
> int main(void)
> {
> int fd = open("/dev/dri/c
On 12 September 2017 at 14:37, Maarten Lankhorst
wrote:
> When we want to make drm_atomic_commit interruptible, there are a lot of
> places that call the lock function, which we don't have control over.
>
> Rather than trying to convert every single one, it's easier to toggle
> interruptible waiti
drm_atomic_commit could previous have always failed when waits failed,
but locking was always done uninterruptibly. Add infrastructure to make
it possible for callers to choose interruptible locking, and convert the
5 most common ioctl's to use it.
All other atomic helpers can be converted when ad
Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.
Signed-off-by: Maarten Lankhorst
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/
Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and
handle drm_modeset_backoff which can now fail by returning the error.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
When we want to make drm_atomic_commit interruptible, there are a lot of
places that call the lock function, which we don't have control over.
Rather than trying to convert every single one, it's easier to toggle
interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
called with DRM
On 12.09.2017 14:50, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Since HDMI can handle these modes despite of MIXER limitations lets
>> enable them.
> lets --> let's
>
> Reviewed-by: Tobias Jakobi
Thanks for review, I will apply all your grammar/style suggestions in
next
This tests the various parts of atomic that I want to make
interruptible. Running with --debug shows the stats from
__igt_sigiter_continue, which can be used to make sure that
we don't fall over.
The default igt kms helpers use drmIoctl, which is not intercepted
by igt_while_interruptible. Only ig
On 12.09.2017 14:50, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
>> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
>> can be enabled by manipulating timings of HDMI. To do it
>> adjusted_mode shou
On 12.09.2017 14:41, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> crtc::mode_fixup callback is required by crtcs which use internally
>> different mode than requested by user - case of Exynos Mixer.
> "...which internally use a different..."
>
>
> Reviewed-by: Tobias Jakobi
1 - 100 of 131 matches
Mail list logo
