Hi Sean,
On Thursday 23 Feb 2017 10:54:37 Sean Paul wrote:
> On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> >> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> >>> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu
Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is release
https://bugzilla.kernel.org/show_bug.cgi?id=194721
Bug ID: 194721
Summary: Reading /sys/bus/pci/devices/:01:00.0/config wakes
up Radeon dGPU
Product: Drivers
Version: 2.5
Kernel Version: 4.8 and newer
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=194721
Eugene Shalygin (eugene.shaly...@gmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=194721
Eugene Shalygin (eugene.shaly...@gmail.com) changed:
What|Removed |Added
Hardware|All |x86-64
--
On Mon, Feb 27, 2017 at 09:56:56AM +0100, Christian König wrote:
> Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
> > On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> > > Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
> > > > From: Nicolai Hähnle
> > > >
> > > > The vm fault hand
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #3 from Michel Dänzer ---
Please attach the corresponding Xorg log file.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists
On Mon, Feb 27, 2017 at 10:08:47AM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 09:56:56AM +0100, Christian König wrote:
> > Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
> > > On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> > > > Am 18.02.2017 um 23:50 schrieb Nicolai H
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> From: Manasi Navare
>
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
>
The field duplicates drm_dev->mode_config.num_crtc.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 11 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
drivers/gpu/drm/exyn
Since crtc index is stored in drm_crtc pipe field became redundant.
The patch beside removing the field simplifies also
exynos_drm_crtc_get_pipe_from_type.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
These two cleanup patches are based on Shawn's patch [1], which is already
in drm-tip branch. I gu
On Sun, 26 Feb 2017, Daniel Vetter wrote:
> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Rob Clark wrote:
>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter
>> > wrote:
>> >> We're off by one here. We free something that wasn't allocated and we
>> >> do
On Mon, Feb 27, 2017 at 11:18 AM, Jani Nikula
wrote:
> On Sun, 26 Feb 2017, Daniel Vetter wrote:
>> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
>>> On Thu, 16 Feb 2017, Rob Clark wrote:
>>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter
>>> > wrote:
>>> >> We're off by one h
Previously, the overlay plane position would only be updated when the
plane was first enabled or during a modeset. We can instruct the DP to
move the plane also when just updating the EBA.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 8 +---
1 file changed, 5 insertio
Otherwise, if the image base address is kept at zero, and if the user
ignores the error return value, the IPU may be configured to write into
the dma-apbh@0011 region for large frames, which will lock up the
system.
Reported-by: Russell King
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-
The IPU does not natively understand bayer formats, but it can pass them
through unchanged. Add support for setting the image base address and
cropping offset to ipu_cpmem_set_image.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 13 +
1 file changed, 13 insertions
On Mon, Feb 27, 2017 at 5:25 AM, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 11:18 AM, Jani Nikula
> wrote:
>> On Sun, 26 Feb 2017, Daniel Vetter wrote:
>>> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
On Thu, 16 Feb 2017, Rob Clark wrote:
> On Thu, Feb 16, 2017 at
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
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
Hi,
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 would
cause crashes similar to the reported "imxdrm issue on SABRE Lite" [
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
Am Montag, den 27.02.2017, 12:28 +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
Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> 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 commit
Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> 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:
Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> 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:
On Mon, 2017-02-27 at 12:33 +0100, Lucas Stach wrote:
> Am Montag, den 27.02.2017, 12:28 +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 b
https://bugs.freedesktop.org/show_bug.cgi?id=99195
--- Comment #5 from ego.corda...@gmail.com ---
Please fix this bloody bug. I have AMD Radeon 5670 graphic card. I have this
bug on Ubuntu 16.10 x64 and i have it on Ubuntu 17.04 x64 development version.
Now any fresh Linux version is almost unusab
The IPUv3 can read 8-bit alpha values from a separate plane buffer using
a companion IDMAC channel driven by the Alpha Transparency Controller
(ATC) for the graphics channels. The conditional read mechanism allows
to reduce memory bandwidth by skipping reads of color data for
completely transparent
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 second plane.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_fo
The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.
Signed-off-by: Ph
Allow to calculate EBA for planes other than plane 0. This is in
preparation for the following patch, which adds support for separate
alpha planes.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --gi
Op 23-02-17 om 16:24 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote:
>> This introduces a slight behavioral change to rmfb. Instead of
>> disabling a crtc when the primary plane is disabled, we try to
>> preserve it.
>>
>> Apart from old versions of the vmwgf
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 symbols
>>> (functions, global data, etc.) across recen
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #19 from cosiek...@o2.pl ---
Created attachment 129952
--> https://bugs.freedesktop.org/attachment.cgi?id=129952&action=edit
piglit hyperz
Above results are from glxgears.
--
You are receiving this mail because:
You are the assign
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 time, that would be helpful.
> I'm new round here so could you please give me the git commands to
> check out you
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
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
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
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
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.
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
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
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 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
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 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 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: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: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 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: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 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 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
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
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
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:
>
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 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 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 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 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 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 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 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: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 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
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,
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
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
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
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 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
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
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
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=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=99989
Bug ID: 99989
Summary: random crashes during boot
Product: Mesa
Version: unspecified
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
Severity: normal
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
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 +--
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
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
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
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
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
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
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
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
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
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
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
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
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 | 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
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_
1 - 100 of 136 matches
Mail list logo
