From: Benjamin Gaignard
Restore calls to clk_{enable/disable} deleted after applying the wrong
version of the patch
Fixes: fd6905fca4f0 ("drm/stm: ltdc: remove clk_round_rate comment")
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/ltdc.c | 2 ++
1 file changed, 2 insertions(+)
Hi all,
left over from my previous Teres-I device tree series, here comes
the revised anx6345 node for the Teres-I, along with the driver.
The innolux panel attached to it is already known; pinebooks can be
enabled on top of this series, once their panels are introduced.
Changes from the
fix below warnings reported by coccicheck
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c:1057:1-3:
WARNING: PTR_ERR_OR_ZERO can be used
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:1846:6:
warning: symbol 'deallocate_hiq_sdma_mqd' was not declared. Should it be
static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 ++-
1
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
problems reappeared also with 4.14). Thus, I've provided
On Tue, 16 Apr 2019 20:38:32 +0200 Christian König wrote:
> @@ -688,9 +689,9 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (attach->sgt)
> return attach->sgt;
>
> - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>
fix below warning reported by coccicheck
./drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:1364:3-5: WARNING:
possible condition with no effect (if == else)
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 8 +---
1 file changed, 1 insertion(+), 7
From tho...@m3y3r.de Sun May 26 13:49:04 2019
Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated
To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch,
dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
VirtIO DRM driver crashes when setting specific 16.16 fixed-point
property values
When running a virtual machine with a VirtIO GPU, it's possible to
crash the entire VM by setting the value of a 16.16 fixed-point
property to any value below 65536 (1.0 in 16.16 format or 0x0001).
As a specific
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.c: In function
dpp_get_optimal_number_of_taps:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.c:137:11: warning:
variable pixel_width set but not used [-Wunused-but-set-variable]
On Tue, 16 Apr 2019 20:38:34 +0200 Christian König wrote:
> + /**
> + * @unpin_dma_buf:
> + *
> + * This is called by dma_buf_unpin and lets the exporter know that an
> + * importer doesn't need to the DMA-buf to stay were it is any more.
> + *
s/need to/need/
On 2019/05/27, Jani Nikula wrote:
> On Mon, 27 May 2019, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary and render
> > nodes, thus we can drop
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 authentication succeeds, but there's
also cases we simply forget to do it.
On Mon, May 27, 2019 at 9:17 AM Daniel Vetter wrote:
>
> On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > Good work, nice cleanup all over.
> >
> > A few comments to a few patches - not something that warrant a
> > new series to be posted as long as it is fixed
https://bugs.freedesktop.org/show_bug.cgi?id=110712
--- Comment #2 from Haxk20 ---
Moved the bug over to mesa as this is mesa bug. Sorry for reporting it
incorrectly the first time.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110712
Haxk20 changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Hi,
On Mon, May 27, 2019 at 10:24:02AM +0800, Shawn Guo wrote:
> On Wed, May 08, 2019 at 07:18:27PM +0200, Guido Günther wrote:
> > If somebody is working on DCSS support it'd be cool to know since this
>
> I have some time slots here and will start looking at it, if no one else
> is already
Hi, Emil,
On Mon, 2019-05-27 at 10:08 +0100, Emil Velikov wrote:
> On 2019/05/25, Thomas Hellstrom wrote:
> > On Sat, 2019-05-25 at 00:39 +0200, Thomas Hellström wrote:
> > > Hi, Emil
> > >
> > > On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> > > > On 2019/05/24, Thomas Hellstrom
* Tomi Valkeinen [190527 10:51]:
> Hi,
>
> On 23/05/2019 23:07, Sebastian Reichel wrote:
> > Hi,
> >
> > Here is another round of the DSI command mode panel patchset
> > integrating the feedback from PATCHv5. The patches are based
> > on v5.2-rc1 tag. It does not contain the patches required
Vikash,
As it's been quite a while, I want to know if the problem is solved
successfully If so, could you please shed some light on the problem
solving path?
Working on a custom hardware based on TI AM5728, and having the same
problem at hand, I just was curious if some one has been able
Use drm_atomic_helper_check_plane_state()
to sanity check the plane state.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
https://bugs.freedesktop.org/show_bug.cgi?id=107296
vono changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #14 from vono
https://bugs.freedesktop.org/show_bug.cgi?id=107209
vono changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107209
--- Comment #3 from vono ---
Same here on Fedora 30 with kernel 5.0.17-300.fc30.x86_64
[drm] DM_PPLIB: values for Invalid clock
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB:
On 5/24/19 5:28 PM, Daniel Vetter wrote:
> Hi Daniel,
>
> On Fri, May 24, 2019 at 3:14 PM Daniel Thompson
> wrote:
>>
>> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
>>> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
>>>
>>> The justification is that if hw
Thanks for the comments, but you are looking at a completely outdated
patchset.
If you are interested in the newest one please ping me and I'm going to
CC you when I send out the next version.
Christian.
Am 25.05.19 um 03:04 schrieb Hillf Danton:
On Tue, 16 Apr 2019 20:38:31 +0200
On Mon, May 27, 2019 at 11:11:18AM +0200, Linus Walleij wrote:
> On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote:
>
> > Drop use of the deprecated drmP.h header file.
> >
> > While touching the list of include files:
> > - Divide include files in blocks of linux/* video/* drm/* etc.
> > Be
Am 24.05.19 um 23:34 schrieb Kuehling, Felix:
> On 2019-05-23 5:06 a.m., Christian König wrote:
>> [CAUTION: External Email]
>>
>> Leaving BOs on the LRU is harmless. We always did this for VM page table
>> and per VM BOs.
>>
>> The key point is that BOs which couldn't be reserved can't be
Hi,
On 23/05/2019 23:07, Sebastian Reichel wrote:
Hi,
Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv5. The patches are based
on v5.2-rc1 tag. It does not contain the patches required for
OMAP3 support (it needs a workaround for a hardware bug)
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 (details in follow-up patch)
> yet not all userspace
MTP SDM845 panel seems to need additional delay to bring panel
to a workable state. Running modetest without this change displays
blurry artifacts.
Signed-off-by: Vivek Gautam
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 1 +
1 file changed, 1 insertion(+)
diff --git
These patches fix a bug concerning an access issue to display controler (ltdc)
registers.
If the physical layer of the DSI is started too early then the fifo DSI are full
very quickly which implies ltdc register's access hang up. To avoid this
problem, it is necessary to start the DSI physical
These new physical operations are helpful to power_on/off the dsi
wrapper. If the dsi wrapper is powered in video mode, the display
controller (ltdc) register access will hang when DSI fifos are full.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 21
Add power on & off optional physical operation functions, helpful to
program specific registers of the DSI physical part.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8
include/drm/bridge/dw_mipi_dsi.h | 2 ++
2 files changed, 10
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 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d24ffc2..16b1103 100644
---
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 have DRM + Wayland setup for display.
> Also, I noticed that it have
Hi Emil,
19. 5. 27. 오후 5:17에 Emil Velikov 이(가) 쓴 글:
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
>>From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Inki Dae
> Cc:
On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
>
> While touching the list of include files:
> - Divide include files in blocks of linux/* video/* drm/* etc.
> Be consistent in the order of the blocks
> - Sort individual blocks of include
On 2019/05/25, Thomas Hellstrom wrote:
> On Sat, 2019-05-25 at 00:39 +0200, Thomas Hellström wrote:
> > Hi, Emil
> >
> > On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> > > On 2019/05/24, Thomas Hellstrom wrote:
> > > > On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote:
> > > > > On
Hi,
On 25/05/2019 17:56, Matteo Croce wrote:
On Sat, May 25, 2019 at 9:30 AM Hariprasad Kelam
wrote:
fix below warnings reported by coccicheck
Hi,
a similar patch was nacked because it makes backports more difficult:
On Mon, 27 May 2019, Emil Velikov wrote:
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Note: the outstanding DRM_AUTH
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Cc: David Airlie
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)
yet not all userspace checks if it's authenticated, but instead uses
uncommon
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Tobias Jakobi
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark
Cc: Sean Paul
Cc: freedr...@lists.freedesktop.org
Cc: David Airlie
Cc:
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.
The former was a case for Mesa where it did
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV htere is no distinction between primary and render
nodes, thus we can drop the token.
Note: authentication is required on a single ioctl, due to a bug in
userspace. The issue has
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Qiang Yu
Cc: l...@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: David Airlie
Cc:
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- (badly coped) legacy DRI1 ioctl, which is a
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- legacy DRI1 ioctl, which is already neutered
On Mon, May 27, 2019 at 09:11:26AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote:
> > this driver is pretty horrible from a design pov, and needs a complete
> > overhaul. Concrete thing that annoys me is that it looks at
> > registered_fb, which is an
On Mon, May 27, 2019 at 09:10:10AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote:
> > Simply because olpc never unregisters the damn thing. It also
> > registers the framebuffer directly by poking around in fbdev
> > core internals, so it's all around
On Mon, May 27, 2019 at 09:08:58AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote:
> > I honestly have no idea what the subtle differences between
> > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
> > it looks like both
On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> Good work, nice cleanup all over.
>
> A few comments to a few patches - not something that warrant a
> new series to be posted as long as it is fixed before the patches are
> applied.
Hm yeah good idea, I'll add that
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 have DRM + Wayland setup for display.
Also, I noticed that it have two dri interface:
/dev/dri/card0
/dev/dri/card1
I am not very familiar
On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote:
> this driver is pretty horrible from a design pov, and needs a complete
> overhaul. Concrete thing that annoys me is that it looks at
> registered_fb, which is an internal thing to fbmem.c and fbcon.c. And
> ofc it gets the lifetime
On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote:
> Simply because olpc never unregisters the damn thing. It also
> registers the framebuffer directly by poking around in fbdev
> core internals, so it's all around rather broken.
>
> Signed-off-by: Daniel Vetter
> Cc: Jens Frederich
On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote:
> I honestly have no idea what the subtle differences between
> con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
> it looks like both vc->vc_display_fg and con_driver_map are protected
> by the console_lock, so
Hi Daniel.
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.
> >
>
On Mon, May 27, 2019 at 08:13:06AM +0200, Daniel Vetter wrote:
> On Sat, May 25, 2019 at 05:01:59PM +0200, Sam Ravnborg wrote:
> > Hi Daniel
> >
> > > It's dead code, and removing it avoids me having to understand
> > > what it's doing with lock_fb_info.
> >
> > I pushed the series through my
Hi Daniel.
> But I indeed forgot
> to delete the initial assignment of info at the function start. Is that
> what you mean here?
Yes.
Sam
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 wang (Arm Technology
> > China) wrote:
> > > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder
On Fri, May 24, 2019 at 02:46:50PM -0400, Tyler Slabinski wrote:
> VirtIO DRM driver crashes when setting specific 16.16 fixed-point
> property values
>
> When running a virtual machine with a VirtIO GPU, it's possible to
> crash the entire VM by setting the value of a 16.16 fixed-point
>
On Sun, 26 May 2019 at 08:41, Ilia Mirkin wrote:
>
> Higher layers tend to add a lot of modes not actually in the EDID, such
> as the standard DMT modes. Changing this would be extremely intrusive to
> everyone, so just force the scaler more often. There are no practical
> cases we're aware of
On Sat, 25 May 2019 at 03:35, Gustavo A. R. Silva
wrote:
>
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace the following form:
>
>
On Mon, May 27, 2019 at 05:37:54AM +0430, 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 some light on the problem solving path?
Can you please explain "the problem"? Your subject isn't
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 better to let the header files be self-contained and
> let the users pull in
On Sat, May 25, 2019 at 05:01:59PM +0200, Sam Ravnborg wrote:
> Hi Daniel
>
> > It's dead code, and removing it avoids me having to understand
> > what it's doing with lock_fb_info.
>
> I pushed the series through my build tests which include the sh
> architecture.
>
> One error and one warning
On Sat, May 25, 2019 at 05:38:26PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> One detail I noticed while brosing the changes.
>
> >
> > @@ -1064,9 +1062,13 @@ static void fbcon_init(struct vc_data *vc, int init)
> > int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
> > int
On Sat, 25 May 2019 at 01:15, Emil Velikov wrote:
>
> On 2019/05/23, Ben Skeggs wrote:
> > On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
> > >
> > > From: Emil Velikov
> > >
> > > Cc: Ben Skeggs
> > > Cc: nouv...@lists.freedesktop.org
> > > Signed-off-by: Emil Velikov
> > Thanks!
> >
>
101 - 174 of 174 matches
Mail list logo
