https://bugzilla.kernel.org/show_bug.cgi?id=199157
--- Comment #5 from Kyle De'Vir (kyle.de...@mykolab.com) ---
This is the first time I've seen it happening on DC, so I decided to just throw
it up as bug report.
At the time, I was browsing on Firefox Nightly, while listening to some music
with M
Reviewed-by: Shashank Sharma
Regards
Shashank
On 3/23/2018 11:55 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Since we may attempt to reconfigure SCDC when the sink has already been
disconnected we probably shouldn't scare the user with errors in dmesg
that are 100% expected in that case. Jus
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #8 from leozinho29...@hotmail.com ---
$ sudo cat /sys/devices/power/events/energy-gpu.scale
2.3283064365386962890625e-10
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #7 from Chris Wilson ---
And for completeness: cat /sys/devices/power/events/energy-gpu.scale
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
Hi Lucas,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180323]
[cannot apply to v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #6 from leozinho29...@hotmail.com ---
The lines
fprintf(stderr, "rapl_type_id()=%"PRIx64",
rapl_gpu_power()=%"PRIx64"\n",
rapl_type_id(), rapl_gpu_power());
made the overlay fail to build. I have changed that
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #5 from Chris Wilson ---
Add a couple of printfs,
diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..e6ac728a 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -117,8 +117,12 @@ int power_init(struct power *power)
Hi Simon,
On 23/03/18 08:51, Simon Horman wrote:
> On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
>> The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
>> bus, however in low power mode the ADV7513 will reset it's slave maps to
>> use the hardware defined default
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #4 from leozinho29...@hotmail.com ---
With this change it is showing the values as expected, 350 mW instead of
35000 mW.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #3 from Chris Wilson ---
Ok, try changing intel-gpu-tools:
diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..e02edec8 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -116,7 +116,8 @@ int power_init(struct power *p
On 2018-03-22 11:23 AM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Vill
https://bugs.freedesktop.org/show_bug.cgi?id=105718
Shmerl changed:
What|Removed |Added
OS|All |Linux (All)
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #2 from leozinho29...@hotmail.com ---
I suppose drm-tip is this: https://cgit.freedesktop.org/drm-tip
I have tried to use that kernel but intel-gpu-overlay is still showing the
super high values. Both older versions of intel-gpu-over
From: Ville Syrjälä
Since we may attempt to reconfigure SCDC when the sink has already been
disconnected we probably shouldn't scare the user with errors in dmesg
that are 100% expected in that case. Just leave it up to the caller
whether to print an error message or not, and just output debug
me
Display controller's power resources and bus
bandwidth voting is controlled by DPU device.
Remove DPU RSC (hardware block for DPU power
resource control) device support.
Signed-off-by: Rajesh Yadav
---
.../devicetree/bindings/display/msm/dpu-rsc.txt| 96 --
1 file changed
MSM display controller hardware (DPU) has an inbuilt RSC block
which can control power resources and bus bandwidth voting
w/o driver intervention.
Downstream driver relies on RSC hardware block for controlling
these resources for better power benefits.
Since, DPU driver controls these resources,
Hi Nipun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri, Mar 23, 2018 at 05:00:11PM +, Daniel Stone wrote:
> Hi,
>
> On 23 March 2018 at 14:49, Ville Syrjälä
> wrote:
> > On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
> >> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> >> + r->handles[i] = 0;
> >> +
Hi,
On 23 March 2018 at 14:49, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
>> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
>> + r->handles[i] = 0;
>> + r->pitches[i] = 0;
>> + r->offsets[i] = 0;
>> +
https://bugs.freedesktop.org/show_bug.cgi?id=105718
Bug ID: 105718
Summary: amdgpu reported fan speed looks too high (dual fan
Sapphire Pulse Vega 56)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote:
> There was some discussion on the dim-tools list about splitting the
> dri-devel list to drm core and drivers lists [1]. Moving the discussion
> to the list in question seems prudent. ;)
>
> I freely admit I don't have the time or inter
Den 23.03.2018 16.35, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems s
There was some discussion on the dim-tools list about splitting the
dri-devel list to drm core and drivers lists [1]. Moving the discussion
to the list in question seems prudent. ;)
I freely admit I don't have the time or interest in reading the patches
for other drivers than i915, but I do glanc
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavio
Hi Nipun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
My apologies, but I found a few more things that look strange and should
be cleaned up. Sorry for this iterative review approach, but I think we're
slowly getting there.
Thank you for reviewing!
Cheers, Daniel
---
+static int xen_drm_drv_dumb_create(struct drm_file *filp,
+
On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> Quoting Matt Roper (2018-03-17 02:08:57)
> > This is the fourth iteration of the work previously posted here:
> > (v1)
> > https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> > (v2)
> > https://www.mail
On Fri, Mar 23, 2018 at 03:58:06PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
> >
> > Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> > >>
> > >> Den 22.03.2018 21.27, skrev Ville
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems simpler to split the fb->dirty() into a tinydrm
Hi Dave,
Last pull for 4.17. Highlights:
- Vega12 support
- A few more bug fixes and cleanups for powerplay
The following changes since commit 6da2b9332c572fcda94de9631f8fa514f574388a:
amdgpu/dm: Default PRE_VEGA ASIC support to 'y' (2018-03-16 16:16:50 -0500)
are available in the git reposi
On Fri, Mar 23, 2018 at 01:46:16PM +, Daniel Stone wrote:
> Mirroring addfb2, add tests for the new ioctl which will return us
> information about framebuffers containing multiple buffers, as well as
> modifiers.
lgtm
Reviewed-by: Ville Syrjälä
Maybe we also want to encode my earlier 'getfb2
On 23 March 2018 at 14:53, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 01:46:14PM +, Daniel Stone wrote:
>> +/**
>> + * Find and return an arbitrary valid property ID.
>> + */
>> +static uint32_t get_prop_id(int fd)
>
> get_any_prop_id() or something like that maybe?
Yeah, a good choice of
On Fri, Mar 23, 2018 at 01:46:14PM +, Daniel Stone wrote:
> We'll want to reuse this, so split it out into a (smaller!) helper.
>
> Signed-off-by: Daniel Stone
> ---
> tests/kms_getfb.c | 36 +++-
> 1 file changed, 19 insertions(+), 17 deletions(-)
>
> diff -
https://bugzilla.kernel.org/show_bug.cgi?id=199157
--- Comment #4 from Harry Wentland (harry.wentl...@amd.com) ---
I have one of the first R7 1700 at home on have only seen the marginality
problem affecting gcc and bash while compiling something multi-threaded. Never
noticed it crashing the kernel
Hi Ville,
On 23 March 2018 at 14:42, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct
>> dr
On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> over addfb.
>
> Signed-off-by: Daniel Stone
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 2 +
> drivers/gpu/drm/drm_framebuffer.c | 109
> +
On Fri, Mar 23, 2018 at 01:45:51PM +, Daniel Stone wrote:
> Make it a little more clear what's going on inside of getfb, and also
> make it easier to add alternate paths to get a handle in future.
>
> Signed-off-by: Daniel Stone
Much better.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/
On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
>
> Signed-off-by: Daniel Stone
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-...@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=105712
--- Comment #1 from Chris Wilson ---
Please try drm-tip as the interface intel-gpu-overlay uses has finally been
upstreamed, hopefully it's just that.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=105712
Bug ID: 105712
Summary: intel-gpu-overlay is showing insane power consumption
amounts
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
>
> On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gvt/scheduler.c
> >
> > between commit:
> >
> > fa3dd623e559 ("d
On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
>
> Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> >>
> >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> >>> From: Ville Syrjälä
> >>>
> >>> mipi_dbi_enable_flush() wan
On 23 March 2018 at 13:42, Daniel Stone wrote:
> This submission rights that historical wrong, which allows Xorg
> -background none to continue to work in the face of exotic buffers.
> I've written patches to Xorg to use this as UABI verification, and
> I'll post a link to that very shortly.
Et v
Mirroring addfb2, add tests for the new ioctl which will return us
information about framebuffers containing multiple buffers, as well as
modifiers.
Signed-off-by: Daniel Stone
---
tests/kms_getfb.c | 91 +++
1 file changed, 91 insertions(+)
d
This depends on unmerged kernel code, so.
---
include/drm-uapi/amdgpu_drm.h | 1 +
include/drm-uapi/drm.h | 1 +
include/drm-uapi/drm_mode.h| 9 ++---
include/drm-uapi/etnaviv_drm.h | 1 +
include/drm-uapi/msm_drm.h | 9 -
include/drm-uapi/virtgpu_drm.h | 1 +
6 files
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
drive
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_debugfs.c
We'll want to reuse this, so split it out into a (smaller!) helper.
Signed-off-by: Daniel Stone
---
tests/kms_getfb.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
index c5968e75..a9852626 100644
-
Make it a little more clear what's going on inside of getfb, and also
make it easier to add alternate paths to get a handle in future.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_framebuffer.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff
getfb2 allows us to pass multiple planes and modifiers, just like addfb2
over addfb.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_crtc_internal.h | 2 +
drivers/gpu/drm/drm_framebuffer.c | 109
drivers/gpu/drm/drm_ioctl.c | 2 +
include/u
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
This depends on unmerged kernel API so should not be merged.
---
include/drm/drm.h | 1 +
xf86drmMode.c | 40 ++
Hi,
AddFB is single-planar, with no offset and only depth/bpp rather than
an explicit format, so we now have AddFB2 which can carry multiple
planes, an explicit format and also a modifier. At the time we never
actually did GetFB2 to go with GetFB.
This submission rights that historical wrong, whic
Den 23.03.2018 12.31, skrev Ville Syrjälä:
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
Den 22.03.2018 21.27, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us
Add support for sun4i DRM driver merged for Linux 4.7.
Signed-off-by: Jonathan Liu
---
tests/util/kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index 8b3e7878..ffae2531 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -144,6 +144,7 @@ static
From: Hans Verkuil
The meson-gx boards have two CEC controllers: the DesignWare controller
and a meson-specific controller. Disable the DW controller since the
CEC line is hooked up to the meson controller.
Signed-off-by: Hans Verkuil
Acked-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/m
From: Hans Verkuil
Some boards (amlogic) have two CEC controllers: the DesignWare controller
and their own CEC controller (meson ao-cec).
Since the CEC line is not hooked up to the DW controller we need a way
to disable that controller. This patch series adds the cec-disable
property for that pu
From: Hans Verkuil
If the cec-disable property was set, then disable the DW CEC
controller. This is needed for boards that have their own
CEC controller.
Signed-off-by: Hans Verkuil
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
1 file changed, 2 insertions
From: Hans Verkuil
Some boards have both a DesignWare and their own CEC controller.
The CEC pin is only hooked up to their own CEC controller and not
to the DW controller.
Add the cec-disable property to disable the DW CEC controller.
This particular situation happens on Amlogic boards that hav
From: Tomi Valkeinen
A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.
Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's
On Tuesday 20 March 2018 01:11 AM, Sibi S wrote:
This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now re
Quoting Matt Roper (2018-03-17 02:08:57)
> This is the fourth iteration of the work previously posted here:
> (v1)
> https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> (v2)
> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
> (v3) https://
On 21/03/18 11:27, Stephen Rothwell wrote:
> Hi all,
>
> A series of commits
>
> a82f034765fa ("drm: omapdrm: Split init and cleanup from probe and remove
> functions")
> to
> 663ac57b285d ("drm: omapdrm: venc: Allocate the venc private data structure
> dynamically")
>
> are missing a Sign
On Thu, Mar 22, 2018 at 08:42:11AM +0100, Thomas Hellstrom wrote:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently xf86-video-vmware leaves the mode->type uninitialized
> > when feeding the mode to the kernel. Thus we have no choice but
> > to accept the ga
Since we enforce that "vma->vm_pgoff" has to be zero it means we don't
need an additional cap on the upper bound.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae916e0..a6732bffb2e2 100644
--- a/drivers/gpu/drm/g
This has a static checker warning because "frev" and "crev" can be
uninitialized if "info" is NULL. I just changed the order of the checks
so that we check "info" first.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/h
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
>
>
> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > From: Ville Syrjälä
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane
On 21 March 2018 at 21:12, Ville Syrjala wrote:
> Apparently xf86-video-vmware leaves the mode->type uninitialized
> when feeding the mode to the kernel. Thus we have no choice but
> to accept the garbage in. We'll just ignore any of the bits we
> don't want. The mode type is just a hint anyway, a
Op 22-03-18 om 08:42 schreef Thomas Hellstrom:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Apparently xf86-video-vmware leaves the mode->type uninitialized
>> when feeding the mode to the kernel. Thus we have no choice but
>> to accept the garbage in. We'll just ign
Hi,
On Wed, Mar 21, 2018 at 04:29:03PM +0100, Paul Kocialkowski wrote:
> This introduces a dedicated ioctl for allocating tiled buffers in the
> Allwinner MB32 format, that comes with a handful of specific
> constraints. In particular, the stride of the buffers is expected to be
> aligned to 32 by
On Wed, Mar 21, 2018 at 04:29:01PM +0100, Paul Kocialkowski wrote:
> The frontend supports many YUV formats as input and also contains a
> color-space converter (CSC) block that can convert YUV input into
> RGB output. It also allows scaling between the input and output for
> every possible combina
On Wed, Mar 21, 2018 at 04:29:00PM +0100, Paul Kocialkowski wrote:
> This moves the various helpers and tables related to format detection
> and conversion to a dedicated file, while adding a bunch of new helpers
> (especially for YUV and tiling support) along the way.
The addition of new helpers
On Wed, Mar 21, 2018 at 04:28:59PM +0100, Paul Kocialkowski wrote:
> In order to check whether the frontend supports a specific format, an
> explicit list and a related helper are introduced.
>
> They are then used to determine whether the frontend can actually support
> the requested format when
On Wed, Mar 21, 2018 at 04:28:58PM +0100, Paul Kocialkowski wrote:
> In order to check whether the backend supports a specific format, an
> explicit list and a related helper are introduced.
>
> They are then used to determine whether the frontend should be used for
> a layer, when the format is n
On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
> The YUV channel was only disabled in sun4i_backend_update_layer_formats,
> which is not called when the frontend is selected.
>
> Thus, creating a layer with a YUV format handled by the backend and then
> switching to a format th
On Wed, Mar 21, 2018 at 04:28:55PM +0100, Paul Kocialkowski wrote:
> This adds a dedicated function for disabling the layer video channel
> from the frontend to the backend. It is called automatically on an
> atomic update, as to disable the frontend by default (it will be enabled
> later on in the
https://bugs.freedesktop.org/show_bug.cgi?id=105617
--- Comment #5 from Marta Löfstedt ---
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_6/fi-cnl-y3/igt@kms_cursor_...@cursor-128x42-offscreen.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_6/fi-cnl-y3/igt@kms_f...@2x-flip-vs-rmfb-interrup
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #47 from taij...@posteo.de ---
(In reply to Harry Wentland from comment #46)
> The backlight patch has been stuck in our submission queue for a while but
> it's in our internal repo. It should be part of the next set of DC patches,
>
On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Define unique compatible string for the DMM in DRA7xx family.
>
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
>
> Signed-of
On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
>
> This patch changes DMM driver to access DMM r
https://bugs.freedesktop.org/show_bug.cgi?id=104193
Józef Kucia changed:
What|Removed |Added
Summary|[radeonsi] The Witcher 3|[radeonsi] The Witcher 3
Hi Rob,
On 23/03/18 03:23, Rob Herring wrote:
>> Ok, I think the description was a bit unclear. So, the driver can do
>> this just fine, it can reserve hw planes dynamically when needed. The
>> problem is the userspace.
>>
>> When a DRM application starts, it sees a bunch of planes, and can see o
The last level system cache can be partitioned to 32
different slices of which GPU has two slices preallocated.
The "gpu" slice is used for caching GPU buffers and
the "gpuhtw" slice is used for caching the GPU SMMU
pagetables. This patch talks to the core system cache
driver to acquire the slice
Add the registers needed for configuring the system cache slice info and
other parameters in the GPU.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adren
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_drv.c | 8
drivers/gpu/drm/msm/msm_d
Some hardware variants contain a system level cache or the last level
cache(llc). This cache is typically a large block which is shared by multiple
clients on the SOC. GPU uses the system cache to cache both the GPU data
buffers(like textures) as well the SMMU pagetables. This helps with
improved r
Allow different Adreno targets the ability to pass
specific mmu features to the generic layers. This will
help conditionally configure certain iommu features for
certain Adreno targets.
Also Add a few simple support functions to support a bitmask of
features that a specific MMU implementation supp
Add client side bindings required for the GPU to use the last level
system cache. Also add a register range in the GPU CX domain.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts
87 matches
Mail list logo
