Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 7.2216)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build
Em Sat, 07 Apr 2018 14:46:56 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Friday, 6 April 2018 18:33:20 EEST Mauro Carvalho Chehab wrote:
> > The dependency of DRM_OMAP = n can be relaxed for just
> > compilation test.
> >
> > This allows building the omap3i
Hello, I tested upcoming 4.17 kernel preview and I had regression in
i915 similar to
https://lists.freedesktop.org/archives/dri-devel/2017-November/159207.html
I reported issue here: https://bugzilla.kernel.org/show_bug.cgi?id=199315
Manjaro Linux x86_64
[fademind@manjaro ~]$ pacman -Q|grep linu
Hi Eric et al,
In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B
on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4,
tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y
< 0) [1], which therefore seems false-positive.
Git history doesn't turn u
Greetings,
Box is i4790 w. GTX 980 running virgin master (.today).
All I have to do to trigger a slew of these warnings is to fire up
firefox, point it at a youtube clip, and let it autoplay while I do
routine kernel merge/build maintenance. nouveau doesn't seem to care
deeply, but moans again a
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 8.8719)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 5.3825)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Failed to apply! Possible
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 6.1286)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Failed to apply! Possible
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'm running 4.15.0 with the "offending"
patch revert
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 23.2149)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 13.9476)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Failed to apply! Possible
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: cc6b741c6f63 drm: sti: remove useless fields from vtg structure.
The bot has also determined it's probably a bug fixing patch. (score: 96.6729)
The bot has tested the following tre
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 15.6725)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Failed to apply! Possible
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 94.5181)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 22.9952)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Failed to apply! Possible
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 6a1c9510694f drm/amdkfd: Adding new IOCTL for scratch memory v2.
The bot has also determined it's probably a bug fixing patch. (score: 20.4472)
The bot has tested the following tre
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.16 next-20180406]
[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/
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #15 from jian-h...@endlessm.com ---
Created attachment 138692
--> https://bugs.freedesktop.org/attachment.cgi?id=138692&action=edit
tested with Linux kernel 4.16+ (commit
f8cf2f16a7c95acce497bfafa90e7c6d8397d653)
I have tried Linux
https://bugzilla.kernel.org/show_bug.cgi?id=199319
--- Comment #6 from m...@rainer-finke.de ---
The flickering that is happening from time to time is probably the same as in
the bug report https://bugzilla.kernel.org/show_bug.cgi?id=199101.
So only the flickering when night shift is enabled on Pl
On Fri, Apr 06, 2018 at 03:28:27PM +, Philippe CORNU wrote:
> Hi Laurent,
>
> On 04/06/2018 04:53 PM, Laurent Pinchart wrote:
> > Hi Philippe,
> >
> > Thank you for the patch.
> >
> > On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote:
> >> This patch clarifies the adjusted_mode
https://bugzilla.kernel.org/show_bug.cgi?id=199319
Michel Dänzer (mic...@daenzer.net) changed:
What|Removed |Added
CC||harry.wentl...@amd.co
On Fri, Apr 06, 2018 at 12:54:22PM +0200, Gerd Hoffmann wrote:
> On Fri, Apr 06, 2018 at 10:52:21AM +0100, Daniel Stone wrote:
> > Hi Gerd,
> >
> > On 14 March 2018 at 08:03, Gerd Hoffmann wrote:
> > >> Either mlock account (because it's mlocked defacto), and get_user_pages
> > >> won't do that f
https://bugs.freedesktop.org/show_bug.cgi?id=105883
--- Comment #8 from Michel Dänzer ---
Is CONFIG_DRM_AMD_DC_DCN1_0 enabled in the kernel build configuration in both
cases?
--
You are receiving this mail because:
You are the assignee for the bug.___
On Thu, Apr 05, 2018 at 05:11:17PM -0700, Matt Roper wrote:
> On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
> > Pulling this out of the shadows again.
> >
> > We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
> > from Matt and Dongwong.
> >
> > At least from th
On Fri, Apr 06, 2018 at 02:24:46PM +0200, Christian König wrote:
> Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann:
> >Hi,
> >
> > > The pages backing a DMA-buf are not allowed to move (at least not without
> > > a
> > > patch set I'm currently working on), but for certain MM operations to work
On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> > >> On Mon, Mar 26, 2018 at 06:03:20PM +010
On Fri, Apr 06, 2018 at 01:56:15PM +0100, Emil Velikov wrote:
> Hi Laszlo,
>
> On 6 April 2018 at 13:15, Laszlo Ersek wrote:
> > On 04/04/18 19:29, Laszlo Ersek wrote:
> >> Hi Emil,
> >>
> >> On 04/03/18 19:13, Emil Velikov wrote:
> >>> On 29 March 2018 at 12:17, Laszlo Ersek wrote:
> On 03
On Fri, Apr 06, 2018 at 02:25:08PM +0300, Oleksandr Andrushchenko wrote:
> On 04/03/2018 12:47 PM, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > > +static int to_refs_grant_foreign_access(struct xen_gem_obj
On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> >
> >
> > On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:
> > > On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> > >> HDCP1.4 key can be loaded,
On Sat, Apr 07, 2018 at 11:34:57AM +0200, Hans de Goede wrote:
> Hi,
>
> On 06-04-18 18:06, Ville Syrjälä wrote:
> > On Thu, Apr 05, 2018 at 01:37:31PM +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 04-04-18 22:49, Ville Syrjälä wrote:
> > > > On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans
On Thu, Apr 05, 2018 at 11:59:57PM +, Deepak Singh Rawat wrote:
> > plane damage.
> >
> > On 04/05/2018 09:52 AM, Daniel Vetter wrote:
> > >
> > > TYPE_PLANE I have no idea who needs that. I suggest we just drop it.
> >
> > I'm assuming CRTC plane coordinates here. They are used for uploading
On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> Hi Daniel, all,
>
> On Thu, 2018-04-05 at 15:44 +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 11:10:03AM +, Alexey Brodkin wrote:
> > > Hi Daniel, Lucas,
> > >
> > > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wr
On Thu, Apr 05, 2018 at 11:07:19PM +, Deepak Singh Rawat wrote:
> >
> > On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
> > > From: Lukasz Spintzyk
> > >
> > > Optional plane property to mark damaged regions on the plane in
> > > framebuffer coordinates of the framebuffer attach
On Thu, Apr 05, 2018 at 11:55:29PM +, Deepak Singh Rawat wrote:
> >
> > On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote:
> > > This patch adds a helper which should be called by driver which enable
> > > damage (by calling drm_plane_enable_damage_clips) from atomic_check
> > > hoo
On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote:
> On 05/04/18 19:50, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> omap_framebuffer_get_next_connector() uses plane->fb which we want to
> >> deprecate for a
On Fri, Apr 06, 2018 at 11:42:42AM +0200, Noralf Trønnes wrote:
>
> Den 05.04.2018 17.44, skrev Daniel Vetter:
> > There's nothing tinydrm specific to this, and there's a few more
> > copies of the same in various other drivers.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Gustavo Padovan
> > C
On Fri, Apr 06, 2018 at 10:38:38AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
>
> It seems that this series misses xen-front's
> "Use simple_display_pipe prepare_fb helper" change?
Hm indeed, I guess I was on an older tree. Will follow up. Care to review
the other patches meanwhile?
-Dan
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/driv
On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> The mode and ajusted_mode passed to the bridge .mode_set() operation
> should never be modified by the bridge (and are not in any of the
> existing bridge drivers). Make them const to make this clear.
>
> Signed-off-by: Laurent Pi
On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > should never be modified by the bridge (and are not in any of the
> > existing bridge drivers).
On Fri, Apr 06, 2018 at 04:56:48PM -0700, Keith Packard wrote:
> (This is an RFC on whether this pair of ioctls seems reasonable. The
> code compiles, but I haven't tested it as I'm away from home this
> weekend.)
>
> I'm rewriting my implementation of the Vulkan EXT_display_control
> extension, w
On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> > > Hi Daniel, all,
>
> [snip]
>
> > > Ok it was quite some time ago so I forgot about th
On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > > should never be modif
Hi Rob,
On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote:
> On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > no
https://bugzilla.kernel.org/show_bug.cgi?id=199319
--- Comment #8 from m...@rainer-finke.de ---
The random flickering every 30 seconds is the same from my point of view. What
is different on my setup is that Plasma-Wayland with night shift enabled with a
changed color flickers with every mouse mov
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'
Hi Daniel,
On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> >> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> >>> The mode and ajusted
On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote:
> On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote:
> > Same on the mandatory/optional VCC supply thing. Let's try to make
> > next version the final one. If the optional property with the dummy
> > regulator doesn't satisfy
On 9 April 2018 at 09:26, Daniel Vetter wrote:
>> - point drm_device::dev to the parent of the virtio_device
>> The biggest hack imaginable, if even possible.
>
> What would/could break if we do this? Why is this a hack?
It _feels_ very hacky to reach/store the parent of the _parent_ device giv
https://bugs.freedesktop.org/show_bug.cgi?id=105950
Bug ID: 105950
Summary: radeonsi: OpenCL not working correctly on a big endian
machine
Product: Mesa
Version: 17.3
Hardware: PowerPC
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=105589
Marta Löfstedt changed:
What|Removed |Added
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@
https://bugs.freedesktop.org/show_bug.cgi?id=105950
--- Comment #1 from Bas Vermeulen ---
Created attachment 138697
--> https://bugs.freedesktop.org/attachment.cgi?id=138697&action=edit
Patch for si_vgt_param_key endian fix
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105950
--- Comment #2 from Bas Vermeulen ---
Created attachment 138698
--> https://bugs.freedesktop.org/attachment.cgi?id=138698&action=edit
Patch for dispatch_packet endianness fix
--
You are receiving this mail because:
You are the assignee for t
https://bugzilla.kernel.org/show_bug.cgi?id=199319
Mike Lothian (m...@fireburn.co.uk) changed:
What|Removed |Added
CC||m...@fireburn.co.uk
https://bugzilla.kernel.org/show_bug.cgi?id=199319
--- Comment #10 from Mike Lothian (m...@fireburn.co.uk) ---
I should add this is 4.16-rc7 (agd5f's 4.18-wip branch) Qt 5.10, KDE frameworks
5.44, Plasma 5.12.4, Xorg 1.19.5 using the modesetting DDX (I'll try the Intel
& AMDGPU DDXs tonight.
--
On 9 April 2018 at 11:24, Emil Velikov wrote:
> On 9 April 2018 at 09:26, Daniel Vetter wrote:
>
>>> - point drm_device::dev to the parent of the virtio_device
>>> The biggest hack imaginable, if even possible.
>>
>> What would/could break if we do this? Why is this a hack?
>
> It _feels_ very h
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #6 from Jason Playne ---
Can Confirm that this problem still persists on Kernel 4.16.1 and Mesa 18
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Sergey Kondakov (virtuous...@gmail.com) changed:
What|Removed |Added
CC||virtuous...@gmai
Hi Peter,
On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
> On 2018-04-04 14:35, Peter Rosin wrote:
> > On 2018-04-04 11:07, Laurent Pinchart wrote:
> >> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> >>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
> On
On Monday 09 April 2018 04:28 PM, Daniel Mack wrote:
Hi Archit,
Thanks a lot for your reply.
On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:
On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very s
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #80 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #79)
> Hi Jerome
>
> Not really, I am waiting for some feedback from Andrey.
>
>
> With the env. variable:
>
> GALLIUM_DDEBUG=flu
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #7 from Zach Tibbitts ---
This issue is also persisting with the latest update to Civ VI, including the
Rise and Fall expansion.
--
You are receiving this mail because:
You are the assignee for the bug._
Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/
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 replaced with the corresponding
helper function.
V3:
Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
1 file changed, 29 insertions(+), 213 deletions(-)
diff --git
Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 15 +++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 --
drivers/gpu/drm/msm/dsi/dsi_host.c | 218 ++
On 04/05/2018 10:44 AM, Daniel Vetter wrote:
There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trø
This patch clarifies the adjusted_mode documentation
for bridges.
Signed-off-by: Philippe Cornu
Signed-off-by: Laurent Pinchart
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge:
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
>
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dsi/dsi
https://bugzilla.kernel.org/show_bug.cgi?id=199319
zxvfxwing (zxvfxw...@protonmail.com) changed:
What|Removed |Added
CC||zxvfxw...@protonmai
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clip
On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen wrote:
> 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
On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
> If the bridge changes the bus format, allow this to be described in
> the bridge, instead of providing false information about the bus
> format of the connector or panel.
I guess this is dead, but I'll comment here anyway because this
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #17 from MirceaKitsune ---
I have a very important preliminary result: Today I tested the last amdgpu
parameters on the list, and seem to have found a set that greatly mitigates the
problem. Those parameters have given me up to 144 m
Daniel J Blueman writes:
> During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
> freed leading to leaking many 128B allocations. Fix the memory leak by
> releasing it at teardown time.
Reviewed, added a Fixes tag, and pushed to drm-misc-fixes. Thanks!
signature.asc
Descri
Adding dri-devel, which I should've included from the start.
On 2018-04-09 03:56 PM, Harry Wentland wrote:
> === What is adaptive sync and VRR? ===
>
> Adaptive sync has been part of the DisplayPort spec for a while now and
> allows graphics adapters to drive displays with varying frame timings.
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #18 from Alex Deucher ---
(In reply to MirceaKitsune from comment #17)
> I will continue trying different values and seeing how tweaking them changes
> the issue. Please let me know what you think.
Those parameters are not used on y
Daniel J Blueman writes:
> Hi Eric et al,
>
> In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B
> on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4,
> tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y
> < 0) [1], which therefore seems false
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #19 from MirceaKitsune ---
(In reply to Alex Deucher from comment #18)
> Those parameters are not used on your chip.
That would be quite something, since after setting them I've clearly seen an
enormous difference. I will investigat
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if
On Fri, Mar 30, 2018 at 07:18:19PM +0200, Sebastian Reichel wrote:
> Merge "rotation" property description into common panel
> binding.
>
> Suggested-by: Rob Herring
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/display/panel/panel-common.txt | 12
>
> D
https://bugs.freedesktop.org/show_bug.cgi?id=104597
Timothy Arceri changed:
What|Removed |Added
CC||c...@fuckyouprius.com
--- Comment #17
Signed-off-by: Eric Anholt
Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace")
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..7c95ed5c5cac 100644
--- a/dr
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms. Switch to a constant size array
instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
d
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
This was a little hard to figure out but I think 32 should be a
c
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to t
On 2018-04-09 08:28, Jordan Crouse wrote:
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise it leads to silent timeouts increasing display
turn ON time.
Signed-off-by: Abhinav Kumar
---
On Tue, Apr 03, 2018 at 12:15:25PM +0200, Lukasz Majewski wrote:
> This commit adds support for AUO's 7.0" display.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../bindings/display/panel/auo,g070vvn01 | 30 +
.txt
> drivers/gpu/drm/panel/panel-simple.c
On Tue, Apr 03, 2018 at 03:29:19PM +0200, Maxime Ripard wrote:
> The MBUS clock is used by the MBUS controller, so let's export it so that
> we can use it in our DT node.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/clk/sunxi-ng/ccu-sun5i.h | 4
> include/dt-bindings/clock/sun5i-cc
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
>
> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> > === What is adaptive sync and VRR? ===
> >
> > Adapti
https://bugs.freedesktop.org/show_bug.cgi?id=104216
--- Comment #23 from Germano Massullo ---
Trying to get some answers from Mozilla developers
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c17
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c18
--
You are receiving this mail bec
The GPU subsystem node was a workaround to have a central device to
bind V3D and display to. Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm283x.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9d293decf8d3..869bf350d42
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf94d139..2
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 5d404d3139a4624892a12683240abfae931ee849
commit: 9c1f5ab7dcce1b9ddb9321b328c5445238450671 [95/120] drm/amd/display: add
delay between panel pwr off to on.
config: i386-allyesconfig (attached as .config)
compiler: gcc-7
Boris Brezillon writes:
> Hello,
>
> This is an attempt at simplifying the async page flip handling in VC4
> in order to get rid of vc4_queue_seqno_cb() and its dependencies and
> rely on fences instead.
>
> The reason I'm sending this as an RFC is because I'm pretty sure we can
> put some of the
On 2018-04-08 09:36, Archit Taneja wrote:
Hi Abhinav,
Thanks for posting this driver. Some comments below.
On Saturday 07 April 2018 12:36 PM, Abhinav Kumar wrote:
From: Archit Taneja
Add support for truly dual DSI video mode panel
panel used in MSM reference platforms >
Signed-off-by: Archi
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 24110c70630998dc83da23cae910a9538f54ef64
commit: 0547606296e739e875a294d786233bf2e6680421 [12/33] drm/amd/display:
Refactor FreeSync module
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 5d404d3139a4624892a12683240abfae931ee849
commit: 2852a36199784540a872f42fa6dc7d8d51eee0d8 [43/120] drm/amd/display: Add
vline IRQ programming for DCN
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn
1 - 100 of 141 matches
Mail list logo
