Hi,
I noticed a serious graphics performance regression between 4.14 and
4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
causes scrolling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've narr
On 04/06/2018 03:11 AM, 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 the intel side there seems to be the idea t
Hi, Daniel!
It seems that this series misses xen-front's
"Use simple_display_pipe prepare_fb helper" change?
Thank you,
Oleksandr
On 04/05/2018 06:44 PM, Daniel Vetter wrote:
Hi all,
Somewhat motivated (but only really tangentially) by the dirtyfb
discussion with Rob and Thomas I started digg
Hi Jean,
yeah, that is a known problem. Using huge pages improves the performance
because of better TLB usage, but for the cost of higher allocation overhead.
What we found is that firefox is doing something rather strange by
allocating large textures and then just trowing them away again imm
https://bugs.freedesktop.org/show_bug.cgi?id=105911
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
Produ
Hi Jean,
found the bug reports.
Here is the original bug report from the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=198511
And here is an fdo bug report where we tried to investigate the root
cause, but didn't had time for that yet:
https://bugs.freedesktop.org/show_bug.cgi?id=1050
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #6 from Matthias Nagel ---
(In reply to Michel Dänzer from comment #5)
> Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section
> Monitor for the second DVI output, because it has a different name.
I know, but that's
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #7 from Michel Dänzer ---
(In reply to Matthias Nagel from comment #6)
> > BTW, does it still work with the 4.16 kernel and amdgpu.dc=0?
>
> Yes it does. (But of course with a wrong layout, because DVI-I is renamed to
> DVI-D-1)
Re
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #8 from Matthias Nagel ---
> Really? It's surprising that the output name would change even with DC
> disabled.
Sorry, my fault. I tampered with the xorg.conf to match it the new naming with
DC enabled.
BTW, another interesting poi
/0day-ci/linux/commits/Ville-Syrjala/drm-arc-Stop-consulting-plane-fb/20180406-155056
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x010-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to
On 05/04/18 23:29, Mauro Carvalho Chehab wrote:
> This driver builds cleanly with COMPILE_TEST, and it is
> needed in order to allow building drivers/media omap2
> driver.
>
> So, change the logic there to allow building it.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/video/fbdev/o
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 18f0a58d75166238d433efce0215b078d0b38e25
commit: 16052f0791cc439eefc9fdfb784db44044ad948e [21/83] drm/amd/display: fix
Polaris 12 bw bounding box
config: i386-randconfig-b0-04061423 (attached as .config)
compiler: gcc-
Hi,
> > * The general interface should be able to express sharing from any
> > guest:guest, not just guest:host. Arbitrary G:G sharing might be
> > something some hypervisors simply aren't able to support, but the
> > userspace API itself shouldn't make assumptions or restrict tha
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
> correctly you must be able to modify the page tables entries and move the
> pages backing them around.
>
> For example try to use fork
On 04/06/2018 12:07 PM, Gerd Hoffmann wrote:
Hi,
* The general interface should be able to express sharing from any
guest:guest, not just guest:host. Arbitrary G:G sharing might be
something some hypervisors simply aren't able to support, but the
userspace API itself shoul
On Thu, Apr 5, 2018 at 5:44 PM, Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter
> Cc: Linus Walleij
Elegant!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.o
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
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trøn
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 for you.
>>
>> Or you write the full-blown userptr implementation, including mmu_notifier
>> support (see i915 or amdgpu), but that also requires Ch
Quoting Jordan Crouse (2018-04-05 23:06:53)
> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
> > The i915 DRM driver very cleverly used ascii85 encoding for their
> > GPU state file. Move the encode functions to a general header file to
> > support other drivers that might be intere
Quoting Jordan Crouse (2018-04-05 23:00:48)
> +struct drm_print_iterator {
> + void *data;
> +
> + ssize_t start;
> + ssize_t offset;
> + ssize_t remain;
> +};
Neat, we should be able to use to replace struct
drm_i915_error_state_buf (or at least the seq_file side).
-Chris
Quoting Chris Wilson (2018-04-06 11:42:25)
> Quoting Jordan Crouse (2018-04-05 23:00:48)
> > +struct drm_print_iterator {
> > + void *data;
> > +
> > + ssize_t start;
> > + ssize_t offset;
> > + ssize_t remain;
> > +};
>
> Neat, we should be able to use to replace struct
>
Quoting Jordan Crouse (2018-04-05 23:00:49)
> +struct msm_gpu_state {
> + struct timeval time;
My recommendation would be to make this a kreffed struct. You already
have multiple uncoordinated consumers so managing the lifetime would
seem to be a point of concern?
-Chris
Quoting Jordan Crouse (2018-04-05 23:00:50)
> diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
> b/drivers/gpu/drm/msm/msm_debugfs.c
> index ba74cb4f94df..fd535dab3d5b 100644
> --- a/drivers/gpu/drm/msm/msm_debugfs.c
> +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> @@ -25,13 +25,22 @@ static int msm_gpu_
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 for you.
> >>
> >> Or you write the full-blown userptr implementation, inclu
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Paweł (pawel.p...@gmail.com) changed:
What|Removed |Added
CC||pawel.p...@gmail.com
--- C
Quoting Jordan Crouse (2018-04-05 23:00:53)
> Convert the format of the 'show' debugfs file and the crash
> dump to a format resembling YAML. This should be easier to
> parse and be more flexible for future changes and expansions.
>
> Signed-off-by: Jordan Crouse
+1, I've been trying to work up
On 04/06/2018 12:07 PM, Gerd Hoffmann wrote:
I'm not sure we can create something which works on both kvm and xen.
The memory management model is quite different ...
On xen the hypervisor manages all memory. Guests can allow other guests
to access specific pages (using grant tables). In theor
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_object *xen_obj)
+{
+ grant_ref_t priv_gref_head;
+ int ret, j, cur_ref, num_pa
Hi,
On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
Hi,
I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very similar to the DragonBoard 410c. In my setup, a DSI
display is directly connected to the SoC, and the video link is stable.
However, when the host
Hi Mauro,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING 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
Hi,
> > I fail to see any common ground for xen-zcopy and udmabuf ...
> Does the above mean you can assume that xen-zcopy and udmabuf
> can co-exist as two different solutions?
Well, udmabuf route isn't fully clear yet, but yes.
See also gvt (intel vgpu), where the hypervisor interface is abs
Hi Jordan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robclark/msm-next]
[also build test WARNING on next-20180406]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
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/28/18 16:35, Emil Velikov wrote:
On 28 March 2018 at 11:27, Laszlo Ersek wrote:
> On 03/28/18 03:24, Emil Velikov wrote:
>>>
>> Gen
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
correctly you must be able to modify the page tables entries and move the
pages backing the
On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
Hi,
I fail to see any common ground for xen-zcopy and udmabuf ...
Does the above mean you can assume that xen-zcopy and udmabuf
can co-exist as two different solutions?
Well, udmabuf route isn't fully clear yet, but yes.
See also gvt (intel vgp
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/28/18 16:35, Emil Velikov wrote:
> On 28 March 2018 at 11:27, Laszlo Ersek
Hi,
> What I could see as justified is a loud comment in drm_virtio_init(),
> just above the call to drm_dev_set_unique(), explaining why it is
> necessary to set "unique" manually. The reason is that virtio-vga
> technically has "virtio_bus", not "pci_bus_type", for bus type, and so
> the gener
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
>
Sorry for the mess
subject should have been
Subject: [PATCH 0/7] V3M-Eagle display enablement
I copied the wrong one from another cover letter...
On Fri, Apr 06, 2018 at 03:08:05PM +0200, Jacopo Mondi wrote:
> Hello,
>this series enables HDMI display on V3M Eagle board.
>
> The series is
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 15:41:57 EEST Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
> ---
> drive
On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> the next patch...
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:08 EEST Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Define the generic R8A77970 part of the DU device node.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:06 EEST Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in
> the next patch...
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Sign
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:09 EEST Jacopo Mondi wrote:
> From: Niklas Söderlund
>
> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> the it to the LVDS output of the DU. While at it align the endpoint name
> of the du to du_out_lvds
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:10 EEST Jacopo Mondi wrote:
> Enable DU for Renesas R-Car V3M Eagle board.
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --g
Hi again,
On Friday, 6 April 2018 16:45:16 EEST Laurent Pinchart wrote:
> On Friday, 6 April 2018 16:08:10 EEST Jacopo Mondi wrote:
> > Enable DU for Renesas R-Car V3M Eagle board.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 11 +
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:11 EEST Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> decoder, connected to the on-chip LVDS encoder output on one side
> and to the not-yet-described HDMI encoder ADV7511W on the other
Hi Jacopo,
Thank you for the patch.
On Friday, 6 April 2018 16:08:12 EEST Jacopo Mondi wrote:
> From: Niklas Söderlund
>
> Enable HDMI output adding the HDMI connector and the ADV7511W, connected
> to THC63LVD1024 LVDS decoder output.
>
> Signed-off-by: Niklas Söderlund
> Signed-off-by: Jacop
Hi Jacopo,
On Friday, 6 April 2018 16:08:05 EEST Jacopo Mondi wrote:
> Hello,
>this series enables HDMI display on V3M Eagle board.
>
> The series is based on Geert's "renesas-drivers-2018-04-03-v4.16" with
> THC63LVD1024 driver on top (cfr. my in review series:
> "[PATCH v7 0/2] drm: Add Th
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #9 from Harry Wentland ---
Can you capture the 4.16 dmesg with DC again with the amdgpu.dc_log=1 module
option?
Do you see any activity on dmesg with dc_log=1 when you hotplug the
non-detected display?
--
You are receiving this ma
Hi Laurent,
On Fri, Apr 06, 2018 at 04:53:43PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Friday, 6 April 2018 16:08:05 EEST Jacopo Mondi wrote:
> > Hello,
> >this series enables HDMI display on V3M Eagle board.
> >
> > The series is based on Geert's "renesas-drivers-2018-04-03-v4.16"
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #15 from Harry Wentland (harry.wentl...@amd.com) ---
We reproduced the issue and have someone looking into it.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Laurent,
On Fri, Apr 06, 2018 at 04:51:11PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Friday, 6 April 2018 16:08:12 EEST Jacopo Mondi wrote:
> > From: Niklas Söderlund
> >
> > Enable HDMI output adding the HDMI connector and the ADV7511W, connected
> > to
The Versatile Express has 8 MB of dedicated video RAM (VRAM)
on the motherboard, which is what we should be using for the
PL111 if available. On this platform, the memory backplane
is constructed so that only this memory will work properly
with the CLCD on the motherboard, using any other memory
re
The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) CLCD instances out to the single SiI9022
bridge.
Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then p
Hi Laurent,
On Fri, Apr 06, 2018 at 04:15:35PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed
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 documentation
> for a bridge directly connected to a crtc.
>
> Signed-off-by: Philippe Cornu
> ---
> This patch is linked to the discussion https://lkml
https://bugs.freedesktop.org/show_bug.cgi?id=99403
--- Comment #7 from i...@yahoo.com ---
It's not driver specific bug.
I should have followed the hint that there is a registry entry to workaround
this problem with wined3d. It turns out that this registry entry is
specifically for this bug. The a
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 documentation
>> for a bridge directly connected to a crtc.
>>
>> Signed-off-by: P
Hi Jacopo,
(CC'ing Mark Brown)
On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote:
> On Fri, Apr 06, 2018 at 04:15:35PM +0300, Laurent Pinchart wrote:
> > On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote:
> >> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>
> >>
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
slow DMA path as well.
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, only when Power well #1 is enabled and cdclk
> >> is enabled. Using the I9
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 de Goede wrote:
> >> Hi,
> >>
> >> On 04-04-18 17:50, Ville Syrjälä wrote:
> >>> On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goe
Hi Laurent,
Thanks for the updates
On 05/04/18 10:18, Laurent Pinchart wrote:
> In order to make the vsp1_du_setup_lif() easier to read, and for
> symmetry with the DRM pipeline input setup, move the pipeline output
> setup code to a separate function.
>
> Signed-off-by: Laurent Pinchart
> Revi
Hi Laurent,
Thanks for this enhancement.
On 05/04/18 10:18, Laurent Pinchart wrote:
> We will soon need to return more than a boolean completion status from
> the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a
> bitfield to prepare for that. No functional change is introduced
Hi Laurent,
On 05/04/18 10:18, Laurent Pinchart wrote:
> Display list completion is already reported to the frame end handler,
> but that mechanism is global to all display lists. In order to implement
> BRU and BRS reassignment in DRM pipelines we will need to commit a
> display list and wait for
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 Pinchart
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++--
d
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/d
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
Cc: Jim Bride
Cc: Jose Abreu
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Thierry Reding
From: Ville Syrjälä
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we matc
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of s
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.
To avoid this, a new drm client cap is required to enable a
From: Ankit Nautiyal
This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_modes.c | 47 +
i
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is n
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio information, from a
connector's modeli
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch add
Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT
This patch is causing failure of IGT test kms_3d. The kms_3d test
expects the no. of 3d modes to be 13.
(The test has hard-coded value for expected no. of 3d modes as 13)
But due to the addition of "matching aspect_ratio" in drm_mode_equal in
this patch, the total no. of
modes in the connect
On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
> This patch is causing failure of IGT test kms_3d. The kms_3d test
> expects the no. of 3d modes to be 13.
>
> (The test has hard-coded value for expected no. of 3d modes as 13)
>
> But due to the addition of "matching aspect_ra
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/
From: Sergei Shtylyov
Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
the next patch...
Based on the original (and large) patch by Daisuke Matsushita
.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts
Hello,
this new version moves the driver and its bindings to use semi-standard
names for powerdown and output enable GPIOs, as result of the discussion with
Laurent, Vladimir and Rob. I kept the actual pin names in the bindings
description for reference, even if there are no huge ambiguities on
From: Niklas Söderlund
Enable HDMI output adding the HDMI connector and the ADV7511W, connected
to THC63LVD1024 LVDS decoder output.
Signed-off-by: Niklas Söderlund
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 51 +-
1 file changed,
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
>
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Any reason why
echo never
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to the not-yet-described HDMI encoder ADV7511W on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a d
Hello,
this series enables HDMI display on V3M Eagle board.
The series is based on Geert's "renesas-drivers-2018-04-03-v4.16" with
THC63LVD1024 driver on top (cfr. my in review series:
"[PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge")
This series includes some preliminary work
Hi Ville,
On Thu, 2018-04-05 at 22:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to stop using plane->fb with atomic driver, so stop looking at
> it.
>
> I have no idea what this code is trying to achieve. There is no
> corresponding check in the enable path. Also since
> arc
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time? Right
now the recent kernels are making Firefox pretty much unusable for me.
I've been able to revert the patch from 4.15 but it's not really a
long-term solution.
You mention that the purpose of the patch is to impr
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
1 file changed, 60 insertions(+
From: Niklas Söderlund
Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
the it to the LVDS output of the DU. While at it align the endpoint name
of the du to du_out_lvds0 which is used in other Renesas DTS files to
describe this link.
Signed-off-by: Niklas Söderlund
---
a
From: Sergei Shtylyov
Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in
the next patch...
Based on the original (and large) patch by Daisuke Matsushita
.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot
Enable DU for Renesas R-Car V3M Eagle board.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 3c5f
The dependency of DRM_OMAP = n can be relaxed for just
compilation test.
This allows building the omap3isp driver with allyesconfig
on ARM.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
From: Sergei Shtylyov
Define the generic R8A77970 part of the DU device node.
Based on the original (and large) patch by Daisuke Matsushita
.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 28 +++
Reviewed-by: Deepak Rawat
>
> From: Ville Syrjälä
>
> The only caller of vmw_kms_update_implicit_fb() is the page_flip
> hook which itself gets called with the plane mutex already held.
> Hence we can look at plane->state safely. Toss in a lockdep assert
> to make the situation more clear.
>
https://bugs.freedesktop.org/show_bug.cgi?id=105869
--- Comment #7 from Jan Vesely ---
(In reply to Lyberta from comment #6)
> I'm 100% sure it is PulseWave because that's the only kernel I use to one of
> my programs and it still crashes at cl::Program::build.
Is the posted snippet all that is
When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought t
1 - 100 of 123 matches
Mail list logo
