On 24/02/17 10:54 AM, Michael Zoran wrote:
> Commonly used desktop environments such as xfce4 and gnome
> on debian sid can flood the graphics drivers with cursor
> updates.
FWIW, this has nothing to do with the desktop environment or indeed the
client side at all. Translating input to HW cursor m
https://bugs.freedesktop.org/show_bug.cgi?id=99969
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Mon, Feb 20, 2017 at 2:32 PM, Daniel Vetter wrote:
> I thought about this some more, I think what we need to fix this mess
> properly is:
> - mode_valid helper callbacks for crtc, encoder, bridges, with the
> same interface as for connectors.
> - calling all these new mode_valid hooks from the
On 17-02-27 17:13:41, Ville Syrjälä wrote:
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This
https://bugs.freedesktop.org/show_bug.cgi?id=99969
--- Comment #1 from laurie ---
Problem seems to be solved with kernel update to 4.10.0.1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@l
On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote:
> Hi Daniel,
>
> We have ACKs on the userspace design from both Adams and Eric.
> Is this enough to merge the kernel patches?
>
> I spoke to Eric briefly about this and he gave me a verbal r-b as well.
> He said the userspace patches
https://bugzilla.kernel.org/show_bug.cgi?id=194721
--- Comment #5 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
And the second problem is even worse: if the dGPU was disabled using acpi_call,
any read from that file hangs the reading process somewhere in the kernel. This
also was neither th
https://bugzilla.kernel.org/show_bug.cgi?id=194721
--- Comment #4 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
Yes, 17.0.0. But does it matter? The problem manifests itself when I do
$ cat /sys/bus/pci/devices/:01:00.0/config
or lspci does read this file.
--
You are receiving this m
https://bugzilla.kernel.org/show_bug.cgi?id=194721
--- Comment #3 from Michel Dänzer (mic...@daenzer.net) ---
Are both laptops using the same version of Mesa?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-dev
https://bugzilla.kernel.org/show_bug.cgi?id=194721
--- Comment #2 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
Excuse me, but as it is written in the bug report, this was never the case
before, and does not happen on my second (almost identical) laptop which runs
Gentoo and kernel 4.10.0 r
Joe Perches (2):
drm: Use pr_cont where appropriate
gpu: drm: Convert printk(KERN_ to pr_
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-
drivers/gpu/drm/amd/amd
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/
Using 'printk("\n")' is not preferred anymore and
using printk to continue logging messages now produces
multiple line logging output unless the continuations
use KERN_CONT.
Convert these uses to appropriately use pr_cont or a
single printk where possible.
Miscellanea:
o Use a temporary const ch
https://bugs.freedesktop.org/show_bug.cgi?id=99195
--- Comment #6 from Michel Dänzer ---
Somebody who can reproduce this needs to bisect it.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #6 from Michel Dänzer ---
This could be due to a fundamental incompatibility between DRI3 and EXA (as it
is used by the radeon driver). That incompatibility is the reason for the
radeon(4) manpage saying:
Note: DRI3 may not work cor
https://bugs.freedesktop.org/show_bug.cgi?id=99970
Michel Dänzer changed:
What|Removed |Added
Attachment #129953|text/x-log |text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=194721
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
This is https://bugs.freedesktop.org/show_bug.cgi?id=98502 .
I suspect reading the config file always powered up the GPU, but Mesa only
recently started reading the file.
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=99841
Michel Dänzer changed:
What|Removed |Added
Component|Driver/nouveau |DRM/other
Product|xorg
On Mon, Feb 27, 2017 at 06:21:05PM +0100, Hans Verkuil wrote:
> On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote:
> > I'm afraid that I walked away from this after it became clear that there
> > was little hope for any forward progress being made in a timely manner
> > for multiple reasons (m
Daniel Vetter schreef op zo 26-02-2017 om 21:00 [+0100]:
> On Fri, Feb 24, 2017 at 12:52:53AM +, Pandiyan, Dhinakaran wrote:
> >
> > On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote:
> > >
> > > Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]:
> > > >
> > > > On Mon, Feb 1
On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote:
> On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > >
> > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-02-15 at 16:53 +0530, Arc
On Wed, Feb 01, 2017 at 04:17:21PM +0530, Archit Taneja wrote:
Hi Archit,
> Hi,
>
> Some minor comments:
Thank you for the review!
>
> On 01/28/2017 07:51 PM, Peter Senna Tschudin wrote:
> > The video processing pipeline on the second output on the GE B850v3:
> >
> > Host -> LVDS|--(STDP402
On Mon, Feb 27, 2017 at 05:08:41PM +0100, Daniel Vetter wrote:
> On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > Add support for video hotplug detect and EDID/ELD notifiers, which is used
> > to convey information from video drivers to their CEC and au
Thanks Phillip
I'll test it as soon as I can.
On Mon, Feb 27, 2017 at 1:13 PM, Philipp Zabel wrote:
> Hi Dan,
>
> On Mon, 2017-02-27 at 11:43 +, Dan MacDonald wrote:
>> Hi Phillipp
>>
>> It sounds like you need me to test a new kernel build with these patches now?
>
> if you could find the t
Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
Signed-off-by: Lorenzo Stoakes
---
drivers/gpu/drm/via/via_dmablit.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --
Hi Phillipp
It sounds like you need me to test a new kernel build with these patches now?
I'm new round here so could you please give me the git commands to
check out your patches / tree as well as any kernel config options
I'll need to ensure are enabled for full imxdrm / SABRE Lite support.
I
https://bugs.freedesktop.org/show_bug.cgi?id=99747
APoliTech changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99747
--- Comment #6 from APoliTech ---
Sorry for the late response, but I expected the new version of the kernel in
ubuntu 17.04
This problem seems to be fixed after the Kernel: 4.10.0-8-generic x86_64 (64
bit gcc: 6.3.0) update
Tested on 2 separate p
On Sat, Feb 25, 2017 at 11:36 AM, Daniel Vetter wrote:
> On Fri, Feb 24, 2017 at 05:25:16PM -0800, John Stultz wrote:
>> In some cases I've been seeing a race where two framebuffers
>> would be initialized, as kirin_fbdev_output_poll_changed()
>> might get called quickly in succession, resulting i
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane,
Boris Brezillon writes:
> An HLCDC layers in Atmel's nomenclature is either a DRM plane or a 'Post
> Processing Layer' which can be used to output the results of the HLCDC
> composition in a memory buffer.
>
> atmel_hlcdc_layer.c was designed to be generic enough to be re-usable in
> both cases,
https://bugs.freedesktop.org/show_bug.cgi?id=4
--- Comment #1 from Ernst Sjöstrand ---
I downloaded it from here:
https://www.epicgames.com/unrealtournament/forums/showthread.php?12011-Unreal-Tournament-Pre-Alpha-Playable-Build
And followed instructions here:
https://www.gamingonlinux.com/ar
https://bugs.freedesktop.org/show_bug.cgi?id=4
Bug ID: 4
Summary: Unreal Tournament 2016 segfaults with sisched
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Now that atomic support is implemented, enable the atomic flag.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 67e94f4f3ce8..215ef00
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 47 +--
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index f86e194ed797..2cd14bebc49c 100644
-
In the qxl atomic model, the primary doesn't stay pinned all the time,
instead it is only pinned/unpinned between prepare_fb and cleanup_fb.
So, we no longer need a final unpin of the primary framebuffer when
disabling the crtc.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_
Now that the state objects are wired up, we can move to the final atomic
handlers.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 52c4e643331a..f86e194ed797 100644
--- a/drivers/gpu/drm/qxl/qxl
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index d5a00b6a07ea..d1c12ac222b7 100644
--- a/drivers/gpu/drm/qxl/qxl_display.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 09c076f5a792..d5a00b6a07ea 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 88 +++
1 file changed, 16 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 8ccf62ae0efd..b23979fad1e2 100644
There are no device specific flags that we need to keep track of here.
Let it vanish.
Signed-off-by: Gabriel Krisman Bertazi
Reviewed-by: Gustavo Padovan
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
drivers/gpu/drm/qxl/qxl_kms.c | 5 +
3 files changed, 3
In preparation for atomic conversion, let's use the transitional atomic
helpers drm_plane_helper_update/disable.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 441 +-
drivers/gpu/drm/qxl/qxl_drv.h | 5 -
2 files changed,
qxl don't have support for hardware vblanks so we can't initialize it
here, otherwise we risk getting stuck in drm_wait_one_vblank.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 20
drivers/gpu/drm/qxl/qxl_drv.c | 8 +---
2 files cha
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 101 +-
1 file changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index fef464730c9b..8ccf62ae0efd 100644
Every attempt to pin/unpin objects in memory requires
qxl_bo_reserve/unreserve calls around the pinning operation to protect
the object from concurrent access, which causes that call sequence to be
reproduced every place where pinning is needed. In some cases, that
sequence was not executed correc
Let's expose the primary plane initialization inside the qxl driver in
preparation for universal planes and atomic.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_display.c | 71 ++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --g
Hi,
This is a resend of the qxl atomic modesetting patchset to include the
reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next.
This series implements support for Atomic Modesetting in the QXL driver.
The first 4 patches in the series are some cleanups to prepare the
grou
If fbdev emulation is disabled, the QXL shutdown path will try to clean
a framebuffer that wasn't initialized, hitting the Oops below. The
problem is that even when FBDEV_EMULATION is disabled we allocate the
qfbdev strutucture, but we don't initialize it. The fix is to stop
allocating the memory
The HDMI encoder IP embeds all needed blocks to output audio, with a
custom DAI called MAI moving audio between the two parts of the HDMI
core. This driver now exposes a sound card to let users stream audio
to their display.
Using the hdmi-codec driver has been considered here, but MAI meant
havi
From: Boris Brezillon
Add the dmas and dma-names properties to support HDMI audio.
Signed-off-by: Boris Brezillon
Signed-off-by: Eric Anholt
---
v2: no changes
arch/arm/boot/dts/bcm283x.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot
From: Boris Brezillon
These are optional, but necessary for HDMI audio support.
Signed-off-by: Boris Brezillon
Signed-off-by: Eric Anholt
Acked-by: Rob Herring
---
v2: no changes
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
danvet asked me a while ago to try generating documentation with the
new RST-based infrastructure. I had a couple of hours to do some
editing, so here it is.
So far I'm not including any kerneldoc for functions. I don't think I
have enough documentation coverage yet to make it useful to start
in
This doesn't yet produce coherent documentation of the module, but at
least gets the kerneldoc built and somewhat glued together.
Signed-off-by: Eric Anholt
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/vc4.rst | 86 +
2 files changed, 87
I'm going to hook vc4 up to the sphinx build, so clean up its comments
to not generate warnings when we do.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_bo.c | 5 -
drivers/gpu/drm/vc4/vc4_dsi.c | 5 +++--
drivers/gpu/drm/vc4/vc4_gem.c | 26 +--
This makes for more sensible documentation of the whole module than
jumping straight into the details of display.
Signed-off-by: Eric Anholt
---
Documentation/gpu/vc4.rst | 3 +++
drivers/gpu/drm/vc4/vc4_drv.c | 16
2 files changed, 19 insertions(+)
diff --git a/Documentat
I had written most of my comments as if I was describing the
individual code files the way I used to for doxygen, while for RST we
want to describe things in a more chapter/section way where there's no
obvious relation to .c files.
Additionally, several of the files had stub descriptions that I've
https://bugs.freedesktop.org/show_bug.cgi?id=99989
Bug ID: 99989
Summary: random crashes during boot
Product: Mesa
Version: unspecified
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #5 from cosiek...@o2.pl ---
Created attachment 129962
--> https://bugs.freedesktop.org/attachment.cgi?id=129962&action=edit
DRI2 Xorg.log
Is there anything more needed?
If you want more tests or you want me to redo previous tests or
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #30 from cosiek...@o2.pl ---
Created attachment 129963
--> https://bugs.freedesktop.org/attachment.cgi?id=129963&action=edit
piglit mesa at e54b2e902aba22f697c0ba8622cd0a905f1edfff
I also tested mesa before the commit which broke my
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #20 from cosiek...@o2.pl ---
Is there anything else needed?
If you want more tests or you want me to redo previous tests or if you are
unsure about results, I'm happy to help.
--
You are receiving this mail because:
You are the assig
On Mon, Feb 20, 2017 at 05:08:37PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre
> ---
> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7
> +++
> 1 file changed, 7 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/amp
On Mon, Feb 27, 2017 at 10:28:21AM -0800, Clint Taylor wrote:
> On 02/27/2017 09:41 AM, Ville Syrjälä wrote:
> > On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor
> >>
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> >> chan
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #24 from intermedi...@hotmail.com ---
Hi Alex,
did the last test. i been downgraded the kernel to 4.0.0 rc3 it was working
kernel on g5 quad . i been used it to made this guide in past you can see it
here:https://ubuntuforums.org/sho
On 02/27/2017 09:41 AM, Ville Syrjälä wrote:
On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as th
On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format. Rockchip's vop support this video format(little
> endian only) as the input video format.
>
> P016 is a p
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #23 from intermedi...@hotmail.com ---
Created attachment 129957
--> https://bugs.freedesktop.org/attachment.cgi?id=129957&action=edit
no more cafedead but only fbdev
Hi Alex,
just finished to made the test.
removed the mesa the iss
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane,
On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 27, 2017 at 05:08:41PM +0100, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote:
>>> From: Hans Verkuil
>>>
>>> Add support for video hotplug detect and EDID/ELD notifiers, which is used
>>> to
On Fri, Feb 17, 2017 at 07:28:27PM +0100, Lucas Stach wrote:
> On i.MX6 QuadPlus the IPU needs to know which PRG has to be
> used for this IPU instance. Add a "fsl,prg" property containing
> a phandle pointing to the correct PRG device.
Is there already a new compatible string? If not, add one. If
On Fri, Feb 17, 2017 at 07:28:25PM +0100, Lucas Stach wrote:
> This adds the the devicetree binding for the Prefetch Resolve Gasket,
> as found on i.MX6 QuadPlus.
> The PRG is fairly simple in that it only has a configuration register
> range and two clocks, one for the AHB slave port and one for t
On Fri, Feb 17, 2017 at 07:28:23PM +0100, Lucas Stach wrote:
> The Prefetch Resolve Engine is a prefetch and tile resolve engine
> which prefetches display data from DRAM to an internal SRAM region.
> It has a single clock for configuration register access and the
> functional units. A single share
On Fri, Feb 17, 2017 at 11:46:51AM +0100, Benjamin Gaignard wrote:
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
>
> Upda
On Mon, Feb 27, 2017 at 05:19:21PM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> > On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > > Handle debugfs override edid
On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote:
> Disabling planes will consist of two steps as of the following patch.
> First, the DP is asked to stop at the next vblank, and then, after the
> vblank the associated IDMAC channel is idle and can be disabled.
> To avoid further commi
On Mon, Feb 27, 2017 at 12:52:46PM +0100, Philipp Zabel wrote:
> Some hardware can read the alpha components separately and then
> conditionally fetch color components only for non-zero alpha values.
> This patch adds fourcc definitions for two-plane RGB formats with an
> 8-bit alpha channel on a s
On Mon, Feb 27, 2017 at 07:30:24AM -0600, Rob Herring wrote:
> On Sun, Feb 26, 2017 at 2:11 PM, Daniel Vetter wrote:
> > On Fri, Feb 24, 2017 at 10:31:25AM -0600, Rob Herring wrote:
> >> On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard
> >> wrote:
> >> > Lots of calls to of_platform_populate()
On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > Handle debugfs override edid and firmware edid at the low level to
> > > transparently and completel
On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
Hi Dave,
drm-misc-next-fixes-2017-02-27:
Misc fixes for the 4.11 merge window.
- vmwgfx drm_control node compat patch
- rockchip&zte fixes
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
massive fumble. oops)
Nothing major outstanding afaik.
Cheers, Daniel
The followin
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #22 from intermedi...@hotmail.com ---
Hi Alex,
i made many tests about and understand the issue on 8x slot (black screen with
only pulse cursor) probably is gaven by Mesa package.
I found this issue on 7750 pratically there when radeo
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engin
On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > Handle debugfs override edid and firmware edid at the low level to
> > transparently and completely replace the real edid. Previously, we
> > practically only used the m
On Thu, Feb 09, 2017 at 05:39:18PM +0100, Maxime Ripard wrote:
> Allow to provide an optional memory region to allocate from for our DRM
> driver.
>
> Signed-off-by: Maxime Ripard
Fixed the conflicts and applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
htt
On Wed, Feb 15, 2017 at 05:40:29PM -0600, Rob Herring wrote:
> On Thu, Feb 09, 2017 at 05:39:22PM +0100, Maxime Ripard wrote:
> > The Mali GPU in the A33 has various operating frequencies used in the
> > Allwinner BSP.
> >
> > Add them to our DT.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> >
On Thu, Feb 09, 2017 at 05:39:21PM +0100, Maxime Ripard wrote:
> Device frequency scaling is implemented through devfreq in the kernel,
> which requires CONFIG_PM_OPP.
>
> Let's select it.
>
> Signed-off-by: Maxime Ripard
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Ker
On Thu, Feb 09, 2017 at 05:39:20PM +0100, Maxime Ripard wrote:
> The operating-points-v2 binding gives a way to provide the OPP of the GPU.
> Let's use it.
>
> Signed-off-by: Maxime Ripard
Applied with Rob Acked-by.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
On Thu, Feb 09, 2017 at 05:39:16PM +0100, Maxime Ripard wrote:
> The reserved memory bindings allow us to specify which memory areas our
> buffers can be allocated from.
>
> Let's use it.
>
> Signed-off-by: Maxime Ripard
Applied with Rob Acked-by.
Maxime
--
Maxime Ripard, Free Electrons
Embe
On Thu, Feb 09, 2017 at 05:39:15PM +0100, Maxime Ripard wrote:
> The Mali clock rate was improperly assumed to be 408MHz, while it was
> really 384Mhz, 408MHz being the "extreme" frequency, and definitely not
> stable.
>
> Switch for the stable, correct frequency for the GPU.
>
> Signed-off-by: M
On Sunday, 2017-02-26 12:51:03 +0300, Andrey Ponomarenko wrote:
> Hello,
>
> I'd like to present the ABI Navigator project to search for binary symbols
> (functions, global data, etc.) across recent versions of the libdrm and other
> open-source libraries: https://abi-laboratory.pro/index.php?vi
On 27 February 2017 at 12:30, Rob Clark wrote:
> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko
> wrote:
>> 26.02.2017, 22:15, "Daniel Vetter":
>>> On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko:
Hello,
I'd like to present the ABI Navigator project to search for binary
Am Montag, den 27.02.2017, 14:14 +0100 schrieb Philipp Zabel:
> When disabling the foreground DP channel during a modeset, the DC is
> already disabled without waiting for end of frame. There is no reason
> to wait for a frame boundary before updating the DP registers in that
> case.
> Add support
On Sun, Feb 26, 2017 at 2:11 PM, Daniel Vetter wrote:
> On Fri, Feb 24, 2017 at 10:31:25AM -0600, Rob Herring wrote:
>> On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard
>> wrote:
>> > Lots of calls to of_platform_populate() are not unbalanced by a call
>> > to of_platform_depopulate(). This cr
On Sun, 26 Feb 2017, Enrico Mioso wrote:
> Hello. I am not using this computer actively and can't report easily
> on the state of the screen. Still, I observed the following situation
> in the system's dmesg: running the stock Archlinux Kernel. This is an
> Apple MacMini system, booted via an EF
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #4 from cosiek...@o2.pl ---
Created attachment 129953
--> https://bugs.freedesktop.org/attachment.cgi?id=129953&action=edit
DRI3 Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
The DP channel disable code tried to busy wait for the DP sync flow end
interrupt status bit when disabling the partial plane without a full
modeset. That never worked reliably, and it was disabled completely by
the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch,
causing ipu_wai
Hi,
second try. This time keeping the IPU_SRM_PRI2 register values intact.
This series fixes an issue with the IPU DC/DP/IDMAC disable sequence. The
interrupt waiting code didn't work as expected, sometimes causing busy waits
longer than the timeout in drm_atomic_helper_wait_for_vblanks, which wo
From: Lucas Stach
This has never worked properly, as the IRQ got retriggered immediately
on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
the DC channel at any point in time.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dc.c | 61
Disabling planes will consist of two steps as of the following patch.
First, the DP is asked to stop at the next vblank, and then, after the
vblank the associated IDMAC channel is idle and can be disabled.
To avoid further commits being awoken out of their wait for dependencies
too early, we should
When disabling the foreground DP channel during a modeset, the DC is
already disabled without waiting for end of frame. There is no reason
to wait for a frame boundary before updating the DP registers in that
case.
Add support to apply updates immediately. No functional changes, yet.
Signed-off-by
1 - 100 of 136 matches
Mail list logo
