Hi, Yongqiang:
On Tue, 2019-04-16 at 16:33 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> > From: Yongqiang Niu
> >
> > Respect page offset for PRIME mmap calls
>
> Reviewed-by: CK Hu
This patch looks independent, so I've
Hi, Yongqiang:
On Tue, 2019-04-16 at 16:24 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> > From: Yongqiang Niu
> >
> > display hardware clock will not unprepare when
> > crtc is disable, until crtc is destroyed.
> > with this
From: "Lowry Li (Arm Technology China)"
Komeda series hardware doesn't support Rot90 for AFBC wide block. So
add limitation check to reject it if such configuration has been posted.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 15
From: "Lowry Li (Arm Technology China)"
- Adds rotation property to plane.
- Komeda display rotation support diverges from the specific formats,
so need to check the user required rotation type with the format caps
and reject the commit if it can not be supported.
- In the layer validate flow,
Hi,
This serie aims at adding the support for rotation on Komeda driver.
For rotation, D71 doesn't support Rot90 for AFBC wide block. So this patch
set also includes the limitation check.
This patch series depends on:
- https://patchwork.freedesktop.org/series/59915/
-
https://bugs.freedesktop.org/show_bug.cgi?id=109022
e88z4 changed:
What|Removed |Added
Version|18.3|git
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #6 from Andrew Sheldon ---
I get similar symptoms with Assassins Creed: Unity run under DXVK (with RADV).
The issue doesn't occur with LLVM8, and seems to be a regression in LLVM9 since
it worked fine with the last compile of LLVM9
Hi Lucas,
On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> We have been looking at how to support DCSS in mainline for a while,
> but most of the actual work got pushed behind in schedule due to other
> priorities.
I have some time to contribute. Would you suggest how I should
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #21 from e88z4 ---
Hi,
I uploaded the apitrace in my google drive.
https://drive.google.com/file/d/1hg1ep4rJ2Y_g7WmA_HbmNndrHd-x7Etc/view?usp=sharing
When I replayed the trace, I was able to produce the error.
My system is
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #20 from e88z4 ---
Hi Timothy,
I have tried your suggestion on the other bug reporting
https://bugs.freedesktop.org/show_bug.cgi?id=110472
You suggested to add an environment variable
https://bugs.freedesktop.org/show_bug.cgi?id=110711
--- Comment #3 from Timothy Arceri ---
(In reply to Petr Sebor from comment #2)
> Whoops, this one got unnoticed (unreported?) for quite some time it seems.
> However, the game is still evolving and the rendering code improving over
> the
https://bugs.freedesktop.org/show_bug.cgi?id=110711
--- Comment #2 from Petr Sebor ---
Whoops, this one got unnoticed (unreported?) for quite some time it seems.
However, the game is still evolving and the rendering code improving over the
years. If there is a performance overhead tied together
https://bugzilla.kernel.org/show_bug.cgi?id=203731
--- Comment #1 from Gluzskiy Alexandr (sss123n...@list.ru) ---
Created attachment 282973
--> https://bugzilla.kernel.org/attachment.cgi?id=282973=edit
photo
monitor photo
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=203731
Bug ID: 203731
Summary: amdgpu wrong refresh rate for hdmi output with
deepcolor turned on
Product: Drivers
Version: 2.5
Kernel Version: 4.19.45
Hardware: All
Make sure (of/i2c/platform)_device_id tables are NULL terminated.
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
+++
Hi all.
Please see mail below - is it OK to extend drm_bus_flags to
represent "SHARP signals"?
Paul (and I) could not find any better way to let the panel tell the
display driver that it requires the special SHARP signals.
This has been pending almost a month now and it would only be fair
to
Hi Torsten.
> index ..9cb30962032e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(c) 2017 Icenowy Zheng
> + *
> + * Based on analogix-anx78xx.c, which is:
> + *
https://bugs.freedesktop.org/show_bug.cgi?id=110712
Haxk20 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #17 from tempel.jul...@gmail.com ---
I applied your patch and patches 1 and 3 of that series on linux 5.2-rc2, but
it unfortunately doesn't show any effect:
-There is still the mouse input issue for the games described in this
The tda988x i2c chip registers are accessed through a
paged register scheme. The kernel regmap abstraction
supports paged accesses. Replace this driver's
dedicated i2c access functions with a standard i2c
regmap.
Pros:
- dedicated i2c access code disappears: accesses now
go through
Remove indirect reg_read/_write() calls, and replace them
with direct calls to regmap functions.
For the sake of readability, keep the following indirect
register access calls:
- reg_set()
- reg_clear()
- reg_write16()
Signed-off-by: Sven Van Asbroeck
---
drivers/gpu/drm/i2c/tda998x_drv.c |
On Sat, May 25, 2019 at 03:52:10PM -0700, Andrew Morton wrote:
> On Fri, 24 May 2019 09:44:55 -0300 Jason Gunthorpe wrote:
>
> > Now that -mm merged the basic hmm API skeleton I think running like
> > this would get us quickly to the place we all want: comprehensive in tree
> > users of hmm.
> >
On Mon, May 27, 2019 at 03:39:31PM -0300, Fabio Estevam wrote:
> The prototype for 'drm_timeout_abs_to_jiffies' is provided by
> the header.
>
> Include this header to fix the following sparse warning:
>
> drivers/gpu/drm/drm_syncobj.c:937:13: warning: symbol
> 'drm_timeout_abs_to_jiffies' was
On Mon, May 27, 2019 at 03:37:14PM -0300, Fabio Estevam wrote:
> The 'clips' member is a pointer, so assign NULL instead of 0.
>
> This fixes the following sparse warning:
>
> drivers/gpu/drm/drm_damage_helper.c:289:31: warning: Using plain integer as
> NULL pointer
>
> Signed-off-by: Fabio
https://bugs.freedesktop.org/show_bug.cgi?id=106302
--- Comment #3 from Pierre-Eric Pelloux-Prayer ---
I agree but "D.3.1 Determining Completion of Changes to an object" says: "The
contents of an object T are considered to have been changed once a command such
as described in section D.3 has
The prototype for 'drm_timeout_abs_to_jiffies' is provided by
the header.
Include this header to fix the following sparse warning:
drivers/gpu/drm/drm_syncobj.c:937:13: warning: symbol
'drm_timeout_abs_to_jiffies' was not declared. Should it be static?
Signed-off-by: Fabio Estevam
---
https://bugzilla.kernel.org/show_bug.cgi?id=203627
Arne Fahrenwalde (macgene...@macgeneral.de) changed:
What|Removed |Added
CC|
The 'clips' member is a pointer, so assign NULL instead of 0.
This fixes the following sparse warning:
drivers/gpu/drm/drm_damage_helper.c:289:31: warning: Using plain integer as
NULL pointer
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/drm_damage_helper.c | 2 +-
1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=110635
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #5 from
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #16 from Nicholas Kazlauskas ---
Created attachment 144354
--> https://bugs.freedesktop.org/attachment.cgi?id=144354=edit
0001-drm-amd-display-Allow-fast-updates-again-for-swappin.patch
Sure, you can try the patch I've attached
On Mon, May 27, 2019 at 08:18:35AM +0200, Daniel Vetter wrote:
> On Sun, May 26, 2019 at 07:35:28PM +0200, Sam Ravnborg wrote:
> > While removing use of drmP.h from files in drm/* I
> > noticed that I had to add the same include files due to
> > dependencies in the header files.
> >
> > It is
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #15 from tempel.jul...@gmail.com ---
Well, hope on the horizon.
If applying debug patches would be helpful for trying to shed light into this
issue, I would of course do it.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110777
Bug ID: 110777
Summary: Kernel 5.1-5.2 MCLK stuck at 167MHz Vega 10 (56)
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi Lucas,
On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 08.05.2019, 19:18 +0200 schrieb Guido Günther:
> > Hi,
> > On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> > > This adds initial support for the NWL MIPI DSI Host controller found on
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #14 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #13)
> Thanks for letting me know!
> Could you please provide me with a loose estimate if those general atomic
> modesetting performance limitations can be
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #13 from tempel.jul...@gmail.com ---
Thanks for letting me know!
Could you please provide me with a loose estimate if those general atomic
modesetting performance limitations can be overcome in the next months? Would
really put my
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #12 from Nicholas Kazlauskas ---
I'm wondering if this is the async cursor update bug again. Maybe something
with WINE or the game is trying to swap cursor buffers frequently and it's
interacting with the cursor double buffering in
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #11 from tempel.jul...@gmail.com ---
Happens also with plain wined3d inside official Steam Proton builds. In case of
Skyrim, it is also affects the rendering performance and thus is visible in the
frametime graph (unlike Hitman 2
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #45 from Ondrej Lang ---
I just came across this article, which seems to suggest a fix for the issue
mentioned in this thread is coming in a future linux-firmware update:
On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote:
>
> Hi all,
>
> I've a workstation which has internal VGA that is detected as AST 2400 and
> with it EDID has been always quite flaky (except for some time it worked
> with 4.14 long enough that I thought the problems would be past until the
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 5:27 PM, Emil Velikov wrote:
> > On 2019/05/27, Thomas Hellstrom wrote:
> > > On 5/27/19 2:35 PM, Emil Velikov wrote:
> > > > Hi Thomas,
> > > >
> > > > On 2019/05/27, Thomas Hellstrom wrote:
> > > >
> > > > > > I think we might be talking past
From: Icenowy Zheng
The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on
H6 is on a co-packaged AC200 chip, and it's not really internal (it's
connected via RMII at PA GPIO bank).
Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.
Signed-off-by: Icenowy
From: Icenowy Zheng
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.
This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not
From: Ondrej Jirman
Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus using a gpio to be able
to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to
model this.
Add binding documentation for optional
From: Ondrej Jirman
This series implements support for Xunlong Orange Pi 3 board.
Unfortunately, this board needs some small driver patches, so I have
split the boards DT patch into chunks that require patches for drivers
in various subsystems.
Suggested merging plan/dependencies:
- stmmac
From: Ondrej Jirman
Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
for the DDC bus to be usable.
Add support for hdmi-connector node's optional ddc-en-gpios property to
support this use case.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55
From: Ondrej Jirman
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time,
but we can only specify a single phy-supply in the DT.
This can be achieved by making one regulator depedning on the other via
From: Ondrej Jirman
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
This is realized by the ddc-en-gpios property.
Signed-off-by: Ondrej Jirman
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts
On 5/27/19 5:27 PM, Emil Velikov wrote:
On 2019/05/27, Thomas Hellstrom wrote:
On 5/27/19 2:35 PM, Emil Velikov wrote:
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
I think we might be talking past each other, let's take a step back:
- as of previous patch, all of vmwgfx ioctls size
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 15:26 schrieb Emil Velikov:
> > On 2019/05/27, Daniel Vetter wrote:
> >> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> >>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> From: Emil Velikov
>
> Currently
Hi!
Dne ponedeljek, 20. maj 2019 ob 15:37:51 CEST je Neil Armstrong napisal(a):
> In order to support the HDMI2.0 YUV420, YUV422 and the 10bit, 12bit and
> 16bits outpu use cases, add support for the recently introduced bridge
> callback format_set().
>
> This callback will setup the new input
Hi!
Thanks for working on this!
Dne ponedeljek, 20. maj 2019 ob 15:37:50 CEST je Neil Armstrong napisal(a):
> This patch adds a new format_set() callback to the bridge ops permitting
> the encoder to specify the new input format and encoding.
>
> This allows supporting the very specific HDMI2.0
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 2:35 PM, Emil Velikov wrote:
> > Hi Thomas,
> >
> > On 2019/05/27, Thomas Hellstrom wrote:
> >
> > > > I think we might be talking past each other, let's take a step back:
> > > >
> > > > - as of previous patch, all of vmwgfx ioctls size is
On Mon, May 27, 2019 at 3:42 PM Koenig, Christian
wrote:
>
> Am 27.05.19 um 15:26 schrieb Emil Velikov:
> > On 2019/05/27, Daniel Vetter wrote:
> >> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> >>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> From: Emil Velikov
>
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #4 from tempel.jul...@gmail.com ---
It looks a lot like it that AMD_DEBUG=nodma prevents the artifacts from
occurring.
--
You are receiving this mail because:
You are the assignee for the
On Mon, May 27, 2019 at 4:01 PM Thomas Hellstrom wrote:
>
> On 5/27/19 3:16 PM, Daniel Vetter wrote:
> > On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote:
> >> On 5/27/19 10:17 AM, Emil Velikov wrote:
> >>> From: Emil Velikov
> >>>
> >>> There are cases (in mesa and applications)
On 21/05/2019 17:18, Andrzej Hajda wrote:
DisplayPort spec talks about doing the display-props reading and EDID reading
when
handling HPD.
I think it would be best to change the code so that we read display props and
EDID in HPD,
but so that we also can read them later (when needed, probably
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #10 from tempel.jul...@gmail.com ---
Nope, not related to it. Happens also with stable versions.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi Daniel, hi Dave,
please pull in this fix for a kernel crashing vmalloc buffer overrun in
the etnaviv devcoredump code.
Regards,
Lucas
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #9 from tempel.jul...@gmail.com ---
Until I get a new GPU or a FreeSync display, I use amdgpu.dc=1 only for testing
purposes. So I can't judge if this is a regression or has always existed.
But I gave Linux 4.19.46 LTS a try and it
On 5/27/19 3:16 PM, Daniel Vetter wrote:
On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote:
On 5/27/19 10:17 AM, Emil Velikov wrote:
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
On Mon, May 27, 2019 at 3:42 PM Pintu Agarwal wrote:
>
> On Mon, May 27, 2019 at 12:41 PM Pintu Agarwal wrote:
> >
> > Dear All,
> >
> > I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
> > platform running.
> > The board is connected to one LCD screen and one HDMI monitor.
> > It
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can drop the
The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 5 +++--
1
Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sii902x.c |
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c
I think these should be ready for applying to drm-misc.
Changes since v7:
- Debased on top of the lasts drm-misc-next and tested
- "dt-bindings: display: sii902x: Add HDMI audio bindings"
- Dropped off "or higher to avoid conflict with video ports"
and added "Reviewed-by: Rob Herring "
The sii902x chip family supports also HDMI audio. Add binding for
describing the necessary i2s and mclk wiring for it.
Signed-off-by: Jyri Sarha
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/sii902x.txt | 40 +++
1 file changed, 40 insertions(+)
diff --git
Remove trailing white space from sii902x display bridge binding.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 5/27/19 2:35 PM, Emil Velikov wrote:
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
I think we might be talking past each other, let's take a step back:
- as of previous patch, all of vmwgfx ioctls size is consistently
handled by the core
I don't think I follow you here, AFAICT
Am 27.05.19 um 15:26 schrieb Emil Velikov:
> On 2019/05/27, Daniel Vetter wrote:
>> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
>>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
From: Emil Velikov
Currently one can circumvent DRM_AUTH, when the ioctl is exposed
Am Mittwoch, den 08.05.2019, 19:18 +0200 schrieb Guido Günther:
> Hi,
> On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found on
> > i.MX8
> > SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP core can
On Mon, May 27, 2019 at 3:26 PM Daniel Vetter wrote:
>
> On Mon, May 27, 2019 at 01:52:05PM +0100, Emil Velikov wrote:
> > On 2019/05/27, Koenig, Christian wrote:
> > > Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > > > On 2019/05/27, Koenig, Christian wrote:
> > > >> Am 27.05.19 um 10:17 schrieb
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> > Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > > From: Emil Velikov
> > >
> > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > > render node. A seemingly
On Mon, May 27, 2019 at 01:52:05PM +0100, Emil Velikov wrote:
> On 2019/05/27, Koenig, Christian wrote:
> > Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > > On 2019/05/27, Koenig, Christian wrote:
> > >> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > >>> From: Emil Velikov
> > >>>
> > >>>
On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can
On Mon, May 27, 2019 at 06:51:18AM +, james qian wang (Arm Technology
China) wrote:
> On Fri, May 24, 2019 at 03:12:26PM +0300, Ville Syrjälä wrote:
> > On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> > > Hi,
> > >
> > > On Tue, May 21, 2019 at 09:45:58AM +0100, james qian
On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't
On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
>
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #8 from Nicholas Kazlauskas ---
Do you happen to know if this was a regression?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if the
Hi Yannick,
and thank you for your patch.
Tested successfully on stm32f too.
Acked-by: Philippe Cornu
Tested-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:21 PM, Yannick Fertré wrote:
> These new physical operations are helpful to power_on/off the dsi
> wrapper. If the dsi wrapper is powered
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > On 2019/05/27, Koenig, Christian wrote:
> >> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> >>> From: Emil Velikov
> >>>
> >>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> >>>
Hi Yannick,
and thank you for your patch.
Tested successfully on stm32f too.
Reviewed-by: Philippe Cornu
Tested-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:21 PM, Yannick Fertré wrote:
> Add power on & off optional physical operation functions, helpful to
> program specific registers of
On 5/27/19 10:17 AM, Emil Velikov wrote:
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
> > I think we might be talking past each other, let's take a step back:
> >
> > - as of previous patch, all of vmwgfx ioctls size is consistently
> > handled by the core
>
> I don't think I follow you here, AFAICT patch 3/5 only affects and
>
Hi Yannick,
Thank you for your patch
Acked-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:14 PM, Yannick Fertré wrote:
> Print display controller hardware version in debug mode only.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/ltdc.c | 2 +-
> 1 file changed, 1
Hi Benjamin,
Many thanks for this fix (and more generally for pushing STM patches on
misc :-)
Acked-by: Philippe Cornu
Philippe :-)
On 5/27/19 1:58 PM, Benjamin Gaignard wrote:
> From: Benjamin Gaignard
>
> Restore calls to clk_{enable/disable} deleted after applying the wrong
> version of
Am 27.05.19 um 14:10 schrieb Emil Velikov:
> On 2019/05/27, Christian König wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> There are cases (in mesa and applications) where one would open the
>>> primary node without properly authenticating the client.
>>>
>>>
Am 27.05.19 um 14:05 schrieb Emil Velikov:
> On 2019/05/27, Koenig, Christian wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
>>> render node. A seemingly deliberate design decision.
>>>
On 2019/05/27, Christian König wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if the
The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
Linux, with a matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard
---
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can drop the DRM_AUTH all together
remove duplicate entry of soc15.h. Issue identified by includecheck
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index c763733..d723332
Hi Rob,
On Wed, 22 May 2019 at 21:27, Rob Herring wrote:
>
> On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote:
> >
> > Hi,
> >
> > The Allwinner H6 has a Mali-T720 MP2 which should be supported by
> > the new panfrost driver. This series fix two issues and introduce the
> > dt-bindings but
Hi Nasser,
No, problem was not solved and I left it as priorities of my work changed.
Best Regards,
Vikash
On Mon, May 27, 2019 at 3:08 AM nasser afshin
wrote:
> Hi Vikash,
>
> As it's been quite a while, I want to know if the problem is solved
> successfully
> If so, could you please shed
Quoting Sean Paul (2019-05-24 10:32:18)
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating the debug directory under /sys/kernel/debug/ and
> instead creates the directory under the correct node in
>
On Tue, 16 Apr 2019 20:38:35 +0200 Christian König wrote:
> @ -331,14 +282,19 @@ EXPORT_SYMBOL(drm_gem_map_dma_buf);
> * @sgt: scatterlist info of the buffer to unmap
> * @dir: direction of DMA transfer
> *
> - * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
> - *
asic_reg/nbio/nbio_6_1_offset.h is included twice.
Issue identified by includecheck
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h
1 - 100 of 174 matches
Mail list logo
