https://bugzilla.kernel.org/show_bug.cgi?id=205043
Bug ID: 205043
Summary: Plugging in AC adapter after boot causes ´*ERROR*
suspend of IP block failed -22´ error
Product: Drivers
Version: 2.5
Kernel Version: 5.3.1-050301-generi
On Sun, 29 Sep 2019 20:30:44 +
Simon Ser wrote:
> Hi,
>
> > On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote:
> > > Currently the property docs don't specify whether it's okay for two
> > > planes to
> > > have the same zpos value and what user-space should expect in this case.
>
https://bugzilla.kernel.org/show_bug.cgi?id=205043
--- Comment #1 from Utku Helvacı (proje@outlook.com) ---
My discrete gpu is RX 540, My computer is Acer Aspire 5 A515-41G-T48Q
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=111858
Bug ID: 111858
Summary: [ICL] IGT tests kms_ccs and kms_frontbuffer_tracking
fail on latest drm-tip kernel
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu wrote:
>
> This causes kernel crash when testing lima driver.
>
> Cc: Christian König
> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a
> bit")
> Signed-off-by: Qiang Yu
Selftest for this would be lovely, now that the basic i
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
Right; I never did this cleanup for not
https://bugs.freedesktop.org/show_bug.cgi?id=111860
Bug ID: 111860
Summary: Crasg in AMDGPU after resume on VegaM
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: not set
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #1 from Dimitar Atanasov ---
CPU is 8706G.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
Hi Karol,
On Fri, Sep 27, 2019 at 11:53:48PM +0200, Karol Herbst wrote:
> > What exactly is the serious issue? I guess it's that the rescan
> > doesn't detect the GPU, which means it's not responding to config
> > accesses? Is there any timing component here, e.g., maybe we're
> > missing some d
Hi Kevin,
On 25/09/2019 21:31, Kevin Hilman wrote:
> From: Kevin Hilman
>
> On some SoCs, the VPU is in a power-domain and needs runtime PM
> enabled and used in order to keep the power domain on.
>
> Signed-off-by: Kevin Hilman
> ---
> drivers/gpu/drm/meson/meson_drv.c | 4
> 1 file cha
Am 29.09.19 um 09:40 schrieb Huang, Ray:
Mark a job as secure, if and only if the command
submission flag has the secure flag set.
v2: fix the null job pointer while in vmid 0
submission.
v3: Context --> Command submission.
v4: filling cs parser with cs->in.flags
v5: move the job secure flag set
https://bugs.freedesktop.org/show_bug.cgi?id=111860
Andre Klapper changed:
What|Removed |Added
Summary|Crasg in AMDGPU after |Crash in AMDGPU after
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wrong (sample clk_set_xyz call sequence, expected results via
clk_get_xyz, and what fails), I
From: Peter Ujfalusi
Set memory bandwidth limit to filter out resolutions above 720p@60Hz to
avoid underflow errors due to the bandwidth needs of higher resolutions.
am43xx can not provide enough bandwidth to DISPC to correctly handle
'high' resolutions.
Signed-off-by: Peter Ujfalusi
Signed-of
Am 30.09.19 um 09:22 schrieb Daniel Vetter:
> On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu wrote:
>> This causes kernel crash when testing lima driver.
>>
>> Cc: Christian König
>> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a
>> bit")
>> Signed-off-by: Qiang Yu
> Self
The LVDS encoders on RZ/G2N SoC is similar to R-Car M3-N. Add support for
RZ/G2N (R8A774B1) SoC to the LVDS encoder driver.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/r
On Mon, Sep 30, 2019 at 10:05 AM Mika Westerberg
wrote:
>
> Hi Karol,
>
> On Fri, Sep 27, 2019 at 11:53:48PM +0200, Karol Herbst wrote:
> > > What exactly is the serious issue? I guess it's that the rescan
> > > doesn't detect the GPU, which means it's not responding to config
> > > accesses? Is
Document the RZ/G2N (R8A774B1) LVDS bindings.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
b/Documentation/devicetree/bindings/d
Document the RZ/G2N (R8A774B1) SoC in the R-Car DU bindings.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/di
This patch series aims to add binding/driver support for
R8A774B1(a.k.a RZ/G2N) DU (which is very similar to the R8A77965 DU);
it has one RGB output, one LVDS output and one HDMI output.
Biju Das (4):
dt-bindings: display: renesas: du: Document the r8a774b1 bindings
drm: rcar-du: Add R8A774B1
Add support for the R8A774B1 DU (which is very similar to the R8A77965 DU
except that it lacks TCON and CMM); it has one RGB output, one LVDS output
and one HDMI output.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 30 ++
1 file changed, 30 inse
Hi Andrey,
On 27/09/2019 22:55, Grodzovsky, Andrey wrote:
> Can you please use addr2line or gdb to pinpoint where in
> drm_sched_increase_karma you hit the NULL ptr ? It looks like the guilty
> job, but to be sure.
Did a new run from 5.3:
[ 35.971972] Call trace:
[ 35.974391] drm_sched_in
Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
>> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
>> used in a driver.
>>
> As far as I can see by your second patch QXL is just using exported
> (that is not internal) functions.
> Not that the idea of making them internal is
On Mon, Sep 30, 2019 at 11:15:48AM +0200, Karol Herbst wrote:
> On Mon, Sep 30, 2019 at 10:05 AM Mika Westerberg
> wrote:
> >
> > Hi Karol,
> >
> > On Fri, Sep 27, 2019 at 11:53:48PM +0200, Karol Herbst wrote:
> > > > What exactly is the serious issue? I guess it's that the rescan
> > > > doesn't
Document RZ/G2N (R8A774B1) SoC bindings.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
b/Documentation/devicetree/bindings
>
> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
> >> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> >> used in a driver.
> >>
> > As far as I can see by your second patch QXL is just using exported
> > (that is not internal) functions.
> > Not that the idea of making
Hi,
On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> wrote:
> >
> > Hi,
> >
> > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
> > >> On Mon, Sep 09, 2019 at 01:42:53PM
On Fri, Sep 27, 2019 at 02:22:24AM +, james qian wang (Arm Technology
China) wrote:
> On Wed, Sep 25, 2019 at 09:48:11AM +, Brian Starkey wrote:
> > Hi James,
> >
> > On Tue, Sep 24, 2019 at 02:13:27AM +, james qian wang (Arm Technology
> > China) wrote:
> > >
> > > Hi Brian:
> > >
If use_mclk is false, mclk_mode is written to a register without
initialization. This doesn't cause any ill effects as the written value
is not used when use_mclk is false.
To fix this, write use_mclk only when use_mclk is true.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi
Currently the HDMI driver uses always limited range RGB output. This
patch improves the behavior by using limited range only if the output is
identified as a HDMI display, and VIC > 1.
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 121 ++
Commit d49cd15550d9d4495f6187425318c245d58cb63f ("OMAPDSS: DISPC: lock
access to DISPC_CONTROL & DISPC_CONFIG") added locking to
mgr_fld_write(). This was needed in omapfb times due to lack of good
locking, especially in the case of both V4L2 and fbdev layers using the
DSS driver.
This is not need
Avoid unnecessary copy in mgr_fld_read/write by taking a pointer to the
reg_resc and using that.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/dr
From: Jyri Sarha
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/
Hi,
This is v2 of the series. Changes compared to v1:
Dropped (Jyri will work on them):
- drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
- drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Added:
- drm/omap: avoid copy in mgr_fld_read/write
- drm/
OMAP2 and OMAP3/AM4 have limitations with the scaler:
- OMAP2 can only scale XRGB
- OMAP3/AM4 can only scale XRGB, RGB565, YUYV and UYVY
The driver doesn't check these limitations, which leads to sync-lost
floods.
This patch adds a check for the pixel formats when scaling.
Signed-off-by:
On Fri, Sep 27, 2019 at 06:28:51PM -0700, Jeykumar Sankaran wrote:
> The mode_config max width/height values determine the maximum
> resolution the pixel reader can handle.
Not according to the docs I "fixed" a while ago.
> But the same values are
> used to restrict the size of the framebuffer cr
From: Alejandro Hernandez
A "HDMI I2C Master Error" is sometimes reported with the current DDC SCL
timings. The current settings for a 10us SCL period (100 KHz) causes the
error with some displays. This patch increases the SCL signal period
from 10us to 10.2us, with the new settings the error is
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> These new format is supported by some rockchip socs:
>
> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/dr
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
that's
Hi James,
On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm_color_ctm S31.32 sign-magnitude
> value to komeda required Q2.12 2's complement
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../arm/
Hi Laurent,
On 07/07/2019 21:18, Laurent Pinchart wrote:
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In or
https://bugzilla.kernel.org/show_bug.cgi?id=205049
Bug ID: 205049
Summary: garbled graphics
Product: Drivers
Version: 2.5
Kernel Version: 5.2.15-200
Hardware: x86-64
OS: Linux
Tree: Mainline
Status
https://bugzilla.kernel.org/show_bug.cgi?id=205049
--- Comment #1 from le...@onet.pl ---
Created attachment 285243
--> https://bugzilla.kernel.org/attachment.cgi?id=285243&action=edit
output of uname -a with garbled graphics
--
You are receiving this mail because:
You are watching the assignee
On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey wrote:
>
> Hi James,
>
> On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
> China) wrote:
> > This function is used to convert drm_color_ctm S31.32 sign-magnitude
> > value to komeda required Q2.12 2's complement
> >
> > Signe
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #5 from Doug Ty ---
I've been getting this too with Minecraft:
https://bugs.freedesktop.org/show_bug.cgi?id=111669
For my particular case at least, AMD_DEBUG=nodma seems to fix it
--
You are receiving this mail because:
You are
Fix both the string and the struct member being printed.
Changes since v1:
- Now with a bonus grammar fix, too.
Fixes: 264b9436d23b ("drm/komeda: Enable writeback split support")
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 4 ++--
1 file cha
https://bugs.freedesktop.org/show_bug.cgi?id=111869
--- Comment #1 from Doug Ty ---
Created attachment 145594
--> https://bugs.freedesktop.org/attachment.cgi?id=145594&action=edit
divide-error_09-30.txt
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=111869
Bug ID: 111869
Summary: Navi "divide error" hang
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: not set
Priori
https://bugs.freedesktop.org/show_bug.cgi?id=111869
--- Comment #2 from Doug Ty ---
Created attachment 145595
--> https://bugs.freedesktop.org/attachment.cgi?id=145595&action=edit
divide-error_09-30-x2.txt
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #63 from Doug Ty ---
(In reply to Matthias Müller from comment #58)
> Don't know where to report as the navi-firmware is not in the
> kernel-firmware, yet?
Not sure if this is correct, but I've created a separate issue for these
"di
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
>
> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 27/09/2019 18:47, Tomi Valkeinen wrote:
> >> On 27/09/2019 18:37, Tero Kristo wrote:
> >>
> >>> If you can provide details about what clock framework / driver does
> >>> wrong (samp
On 30/09/2019 15:41, Adam Ford wrote:
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wr
On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > > On Tue, Sep 17, 2019 a
On Fri, Sep 27, 2019 at 09:39:48AM -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov
> wrote:
> >
> > > Call it "walk_page_mapping()". And talk extensively about how the
> > > locking differs a lot from the usual "walk_page_vma()" things.
> >
> > Walking mappings o
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch should be functional co
That is not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++
include/drm/ttm/ttm_bo_api.h | 5 --
in
On Mon, Sep 30, 2019 at 7:48 AM Tero Kristo wrote:
>
> On 30/09/2019 15:41, Adam Ford wrote:
> > On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
> >>
> >> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On 27/09/2019 18:47, Tomi Valkeinen wrote:
> On 27/09/2019 18:37, Ter
Hi Steven,
On 27/09/2019 17:00, Steven Price wrote:
> On 27/09/2019 12:48, Neil Armstrong wrote:
>> Hi,
>>
>> On 27/09/2019 13:27, Neil Armstrong wrote:
>>> Hi Steven,
>>>
>>> Thanks for your prompt reaction !
>>>
>>> On 27/09/2019 12:48, Steven Price wrote:
On 27/09/2019 10:55, Steven Price
On 26/09/2019 23:08, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
>> use the correct max fractional PLL value for G12A VPU.
>>
>> With this fix, we can finally setup the 1024x768-60 mode.
>>
>> Fixes: 202b9808f8ed ("drm/mes
Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
>> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
>>> As far as I can see by your second patch QXL is just using exported
>>> (that is not internal)
>
> On 05.09.19 15:34, Jaak Ristioja wrote:
> > On 05.09.19 10:14, Gerd Hoffmann wrote:
> >> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
> >>> Hello!
> >>>
> >>> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> >>> I originally filed the issue on Launch
On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch:
On Fri, Sep 20, 2019 at 10:15:41AM +0800, Qiang Yu wrote:
> Hi guys,
>
> I'd like to know the status of this patch? I expect a v2 adding some
> comments/macros about the high bit plan would be enough?
>
> @Raymond & @Brian do you still need another long process to send out a
> v2 patch? If so, I
> Am 30.09.2019 um 10:53 schrieb Tero Kristo :
>
> The best action here is probably to drop the max-div value for this clock to
> 16. Can someone check this with their display setup and see what happens?
> Attached patch should do the trick.
I have checked on GTA04 and OpenPandora (DM3730 res
On 9/6/19 2:47 PM, John Stultz wrote:
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a d
From: Ville Syrjälä
Add a helper to translate a rectangle to an absolute position.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6195820aa5c5..fc7c14627ee2 100644
From: Ville Syrjälä
Add a helper to initialize a rectangle from x/y/w/h information.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fc7c14627ee2..cd0106135b6a 1
From: Ville Syrjälä
Use the newly introduced drm_rect_translate_to() instead
of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_displ
From: Ville Syrjälä
Use the new drm_rect_init() helper where appropriate.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/dri
On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller wrote:
>
>
> > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> >
> > The best action here is probably to drop the max-div value for this clock
> > to 16. Can someone check this with their display setup and see what
> > happens? Attached patch s
On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > >
> > > The best action here is probably to drop the max-div value for this clock
> > > to 16. Can someone check this
On Mon, Sep 30, 2019 at 9:04 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
> >
> > On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> > wrote:
> > >
> > >
> > > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > > >
> > > > The best action here is probably to drop
From: Arnd Bergmann
This was apparently dropped by accident in a recent
cleanup, causing a build failure in some configurations now:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
function 'devm_pinctrl_get_select_default'
[-Werror,-Wimplicit-function-declaration
On 30/09/2019 17:12, Adam Ford wrote:
I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.
Sorry for all the spam, but I moved both of them to 31 from 32, and it
als
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I can get the div to 31.
You can see this from the clock register 0x48004e40 (CM_CLKSEL_DSS). The
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> +static int system_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> + struc
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + s
> Am 30.09.2019 um 16:27 schrieb Tomi Valkeinen :
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
>> Let's see what Tero says, but yeah, something is odd here. I expected the
>> max divider to be 16 with Tero's patch, but I don't see it having that
>> effect. I can get the div to 31.
>> You
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
> > Let's see what Tero says, but yeah, something is odd here. I expected
> > the max divider to be 16 with Tero's patch, but I don't see it having
> > that effect. I can get the div to 31.
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #6 from Marko Popovic ---
(In reply to Doug Ty from comment #5)
> I've been getting this too with Minecraft:
> https://bugs.freedesktop.org/show_bug.cgi?id=111669
>
> For my particular case at least, AMD_DEBUG=nodma seems to fix i
Since we now have bindings for Mali Midgard GPUs, let's use them to
describe Juno's GPU subsystem, if only because we can. Juno sports a
Mali-T624 integrated behind an MMU-400 (as a gesture towards
virtualisation), in their own dedicated power domain with DVFS
controlled by the SCP.
CC: Liviu Duda
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
CC: Rob Herring
CC: Tomeu Vizoso
Signed-off-by: Robin Murphy
---
This isn't really
On Mon, Sep 30, 2019 at 05:15:53PM +0300, Jyri Sarha wrote:
> From: Arnd Bergmann
>
> This was apparently dropped by accident in a recent
> cleanup, causing a build failure in some configurations now:
>
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
> function '
Neil Armstrong writes:
> Hi Kevin,
>
> On 25/09/2019 21:31, Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> On some SoCs, the VPU is in a power-domain and needs runtime PM
>> enabled and used in order to keep the power domain on.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> drivers/gpu/drm/me
> Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
> >> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
> >>> As far as I can see by your second patch QXL is just using exported
> >>> (that is
Bring dmabuf sharing through implementing prime_import_sg_table callback.
This will help to validate userspace conformance in prime configurations
without using any actual hardware (e.g. in the cloud).
This enables kms_prime IGT testcase on vkms.
V2:
- Rodrigo: styleguide + return code check
V3:
Hi,
On Tue, Sep 24, 2019 at 02:40:54PM +0200, megous hlavni wrote:
> > > On first run of the X server, only the black screen and the layer
> > > containing the cursor is visible. Switching to console and back
> > > corrects the situation.
> > >
> > > I have dumped registers, and found out this
still happens with your patch applied. The machine simply gets shut down.
dmesg can be found here:
https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt
If there are no other things to try out, I will post the up
On 30/09/2019 16:24, Robin Murphy wrote:
> Although going full "dma-coherent" ends badly due to GEM objects still
> being forcibly mapped non-cacheable, we can at least take advantage of
> Juno's ACE-lite integration to skip cache maintenance for pagetables.
>
> CC: Rob Herring
> CC: Tomeu Vizoso
On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> still happens with your patch applied. The machine simply gets shut down.
>
> dmesg can be found here:
> https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gist
From: Christian König
This feature is only used by vmwgfx and superflous for everybody else.
v2: use vmw_buffer_object instead of vmw_user_bo.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 --
drivers/gpu/drm/ttm/ttm_bo_util.c
On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
wrote:
>
> On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > still happens with your patch applied. The machine simply gets shut down.
> >
> > dmesg can be found here:
> > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33e
Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
denote the 16x16 block u-interleaved format used in Arm Utgard and
Midgard GPUs.
Changes from v1:-
1. Reserved the upper four bits (out of the 56 bits assigned to each vendor)
to denote the category of Arm specific modifiers. Current
Hi Ayan,
Could we preserve Ray's authorship on this patch?
On Mon, Sep 30, 2019 at 04:44:38PM +, Ayan Halder wrote:
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Changes from v1:-
>
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explenation of the issue as a in-code comment
RFC comment (copied from last sent):
We are quite sure that there is a higher amount of bridges affected by th
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
>
> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
> to cover cases when a THP is mapped with PTEs. To me it's not a big
> stretch to make it cover multiple pages too.
I agree that is closer, but it does make fo
On Mon, Sep 30, 2019 at 04:24:58PM +0100, Robin Murphy wrote:
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own d
On 9/30/19 7:12 PM, Linus Torvalds wrote:
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
to cover cases when a THP is mapped with PTEs. To me it's not a big
stretch to make it cover multiple pages too.
I agre
On Mon, Sep 30, 2019 at 10:25 AM Robin Murphy wrote:
>
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own dedicat
On Mon, Sep 30, 2019 at 11:26 AM Steven Price wrote:
>
> On 30/09/2019 16:24, Robin Murphy wrote:
> > Although going full "dma-coherent" ends badly due to GEM objects still
> > being forcibly mapped non-cacheable, we can at least take advantage of
> > Juno's ACE-lite integration to skip cache main
1 - 100 of 131 matches
Mail list logo
