https://bugs.freedesktop.org/show_bug.cgi?id=109923
Bug ID: 109923
Summary: Chromium shows blackscreen on sketchfab like sites
(WebGL?) (rx460, 18.50-725072, 7/2/2019)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #24 from Adrian Garay ---
Since I didn't clearly specify above, my result was with amd-staging-drm-next,
but the behavior is identical to the current 5.0 release. When the screen goes
blank the machine stops responding, but it appea
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #23 from Adrian Garay ---
I am on firmware F.20 and the above does not work for me. I still see the
scrambled line of garbage at boot, but instead of crashing my screen just goes
blank.
If I add modprobe.blacklist=amdgpu to the ke
On Fri, Feb 22, 2019 at 10:37 AM Rob Herring wrote:
> There is not any simple panel binding really. This originated I think
> from a 'simple-panel' compatible that was originally attempted. What we
> have is a collection of common properties for panels which panel
> bindings can use. And we have
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #22 from Adrian Garay ---
Created attachment 143560
--> https://bugs.freedesktop.org/attachment.cgi?id=143560&action=edit
logged when modprobe amdgpu is run
--
You are receiving this mail because:
You are the assignee for the bug
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists
https://bugzilla.kernel.org/show_bug.cgi?id=201957
John Doe (anode@gmail.com) changed:
What|Removed |Added
CC||anode@gmail.com
---
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c9115f8904eef0f880d3b4f8306f553b1bb1c532
commit: 0629ed786b3faa5e968d81c22a388958801db25a [673/688] drm/amdgpu: free
PDs/PTs on demand
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/li
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c9115f8904eef0f880d3b4f8306f553b1bb1c532
commit: c9115f8904eef0f880d3b4f8306f553b1bb1c532 [2/2] drm/amdgpu: XGMI pstate
switch initial support
reproduce:
# apt-get install sparse
git checkout c9115f8
On Thu, Mar 7, 2019 at 9:11 AM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote:
> >>
> >> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> >> OpenGL vertex shader processing and PP is for fragment shader
> >> processing. Each
https://bugzilla.kernel.org/show_bug.cgi?id=202799
Bug ID: 202799
Summary: amd/dc: right monitor sometimes never comes back up on
dual-display setup after locking session
Product: Drivers
Version: 2.5
Kernel Version: 5.0
On Wed, Mar 6, 2019 at 6:50 PM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > From: Noralf Trønnes
> >
> > This adds a library for shmem backed GEM objects.
> >
> > v7:
> > - Use write-combine for mmap instead. This is the more common
> > case. (robher)
> >
> > v6:
> > - Fix uninitialized va
On 2019-03-04 10:09, Sean Paul wrote:
On Wed, Feb 13, 2019 at 05:19:13PM -0800, Jeykumar Sankaran wrote:
encoder->crtc is not really meaningful for atomic path. Use
crtc->encoder_mask to identify the crtc attached with
an encoder.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/
On Thu, Mar 7, 2019 at 8:15 AM Dave Airlie wrote:
>
> > +#endif
> > diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> > new file mode 100644
> > index ..05f8c910d7fb
> > --- /dev/null
> > +++ b/include/uapi/drm/lima_drm.h
> > @@ -0,0 +1,164 @@
> > +/* SPDX-Licens
On Thu, Mar 7, 2019 at 8:08 AM Dave Airlie wrote:
>
> On Thu, 7 Mar 2019 at 09:46, Rob Herring wrote:
> >
> > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote:
> > >
> > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> > > OpenGL vertex shader processing and PP is for fragmen
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c9115f8904eef0f880d3b4f8306f553b1bb1c532
commit: 73eaf1e03db0ef8fb44dcaa391cbcf1a219f299f [672/688] drm/amdgpu: allocate
VM PDs/PTs on demand
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
ker
When panel probe happens after DSI probe, the DSI probe
is deferred as per current design. In the probe defer path
dsi device is destroyed. This NULL dsi device could be
deferenced by the panel probe in the mipi_dsi_attach path.
Check for NULL dsi device before accessing it.
Reported-by: Jeffrey
Rob Herring writes:
> On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote:
>>
>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>> OpenGL vertex shader processing and PP is for fragment shader
>> processing. Each processor has its own MMU so prcessors work in
>> virtual addres
Rob Herring writes:
> From: Noralf Trønnes
>
> This adds a library for shmem backed GEM objects.
>
> v7:
> - Use write-combine for mmap instead. This is the more common
> case. (robher)
>
> v6:
> - Fix uninitialized variable issue in an error path (anholt).
> - Add a drm_gem_shmem_vm_open() to
> +#endif
> diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> new file mode 100644
> index ..05f8c910d7fb
> --- /dev/null
> +++ b/include/uapi/drm/lima_drm.h
> @@ -0,0 +1,164 @@
> +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> +/* Copyr
On Thu, 7 Mar 2019 at 09:46, Rob Herring wrote:
>
> On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote:
> >
> > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> > OpenGL vertex shader processing and PP is for fragment shader
> > processing. Each processor has its own MMU so prce
On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote:
>
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one
Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.
The new property doesn't control the mode of operation, it only
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c |
On the D3 SoC the LVDS PHY must be enabled in the same register write
that enables the LVDS output. Skip writing the LVEN bit independently
on that platform, it will be set by the write that sets LVRES.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 ++--
1 file
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 46 +
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the
new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and
new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them
through the code.
This effectively changes the value of
Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.
Signed-off-by: Laurent Pinch
From: Stefan Agner
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity (DRM_BUS_F
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64
In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.
To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in th
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77995-draak.dts | 21 ++
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 ++
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/dr
The D3 and E3 SoCs have different pixel clock frequency limits for the
LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode
fixup implementation accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 9 +++--
1 file changed, 7 insertions(+), 2
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: Laurent Pinchart
The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros
and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock
edge data and sync signals are driven. They are however used in some
drivers to define on which pixel clock edge data and sync signals are
sampled, which s
Hello everybody,
This patch series implements support for LVDS dual-link mode in the
R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
LVDS decoder driver. I decided to tag it with RFC as it includes an
extension to the drm_bridge API.
LVDS dual-link is a mode of operation
From: Noralf Trønnes
This adds a library for shmem backed GEM objects.
v7:
- Use write-combine for mmap instead. This is the more common
case. (robher)
v6:
- Fix uninitialized variable issue in an error path (anholt).
- Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
of
On 03/01, Maarten Lankhorst wrote:
> Convert vkms to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohamm
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis"
>>>
>>> This framework allows a unified userspace interface for dma-buf
>>> exporters, allowing userland to allocate specific type
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP
de
https://bugs.freedesktop.org/show_bug.cgi?id=109331
andrew.m.mcma...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>
> On 3/5/19 2:54 PM, John Stultz wrote:
> > From: "Andrew F. Davis"
> >
> > This framework allows a unified userspace interface for dma-buf
> > exporters, allowing userland to allocate specific types of
> > memory for use in dma-buf sharing
On Mon, Mar 4, 2019 at 9:24 PM Maxime Ripard wrote:
>
> On Sun, Mar 03, 2019 at 11:05:23PM +0530, Jagan Teki wrote:
> > Loop N1 instruction delay for burst mode devices are computed
> > based on horizontal sync and porch timing values.
> >
> > The current driver is using u16 type for computing thi
The R-Car DU driver assumes that a bridge is always connected to the DU
output. This is valid for the LVDS and HDMI outputs, but the DPAD
outputs can be connected directly to a panel, in which case no bridge is
available.
To support this use case, detect whether the entities connected to the
DU DP
On 3/6/19 12:19 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>>
>> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
>>> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
Add very trivial allocation test for dma-heaps.
TODO: Need to actually do s
https://bugs.freedesktop.org/show_bug.cgi?id=109834
Andre Klapper changed:
What|Removed |Added
Priority|high|medium
--
You are receiving this mail
Hi Brian,
On Wed, Mar 06, 2019 at 11:05:05AM +, Brian Starkey wrote:
> On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> >> On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 2
On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>
> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
> > Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> >>
> >> Add very trivial allocation test for dma-heaps.
> >>
> >> TODO: Need to actually do some validation on
> >> the returned dma-buf
https://bugs.freedesktop.org/show_bug.cgi?id=109695
--- Comment #10 from Dylan Baker ---
We're getting down to just a few bugs blocking 19.0, so I'm pinging those bugs
to see what the progress is?
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=109834
--- Comment #2 from pearlydragon ---
Open drivers doesnt contained icd and loader.
Or I find source ,but it compile in 10GB - I have only 4GB in root.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Liviu,
On Wed, Mar 06, 2019 at 02:20:51PM +, Liviu Dudau wrote:
> On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> >> On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 22,
https://bugs.freedesktop.org/show_bug.cgi?id=109493
--- Comment #7 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=109493
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #6 from Martin Peres
Maxime Ripard writes:
> [ Unknown signature status ]
> On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote:
>> Maxime Ripard writes:
>>
>> > [ Unknown signature status ]
>> > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
>> >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt
Qiang Yu writes:
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one GP but multiple PP (max 4 for
Maxime Ripard writes:
> The preferred bpp for the fbdev emulation buffer has been 32 so far, which
> means that by default we will allocate an 8MB buffer with a 1920x1080
> resolution.
>
> Worse this memory will be allocated from the CMA pool, and will never be
> freed even if we don't use the fb
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #36 from quirin.blae...@freenet.de ---
Bug is still alive. v5.0
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> > +
> > + printf("Allocating 1 MEG\n");
> > + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
> > + if (ret)
> > + goto out;
> > +
> > + /
On Wed, Mar 6, 2019 at 8:12 AM Benjamin Gaignard
wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> > +/**
> > + * DOC: DMABUF Heaps Userspace API
> > + *
> > + */
> > +
> > +/* Currently no flags */
> > +#define DMA_HEAP_VALID_FLAGS (0)
>
> I think here you need to allow flags like O_
https://bugs.freedesktop.org/show_bug.cgi?id=109922
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109922
Bug ID: 109922
Summary: Failed to get GBM bo for flip to new front.
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>
>> Add very trivial allocation test for dma-heaps.
>>
>> TODO: Need to actually do some validation on
>> the returned dma-buf.
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> C
On 3/5/19 2:54 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can
> all
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> Add very trivial allocation test for dma-heaps.
>
> TODO: Need to actually do some validation on
> the returned dma-buf.
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
>
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its own device node, which a
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin G
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> This patch adds system heap to the dma-buf heaps framework.
>
> This allows applications to get a page-allocator backed dma-buf
> for non-contiguous memory.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its or
https://bugs.freedesktop.org/show_bug.cgi?id=109887
--- Comment #4 from kgkggl+bugs.freedesktop@gmail.com ---
(In reply to fin4478 from comment #3)
> You need to have a kernel command line parameter and c is used to commit
> changes. See: https://wiki.archlinux.org/index.php/AMDGPU#Overclockin
On 3/6/19 1:37 AM, Cui, Flora wrote:
> deadlock test for sdma will cause gpu recoverty.
> disable the test for now until GPU reset recovery could survive at least
> 1000 times test.
Can you specify what issues you see and on what ASIC ?
Andrey
>
> v2: add modprobe parameter
>
> Change-Id: I9ada
Hi Jyri,
I also implemented HDMI audio support for sii902x to enable audio on a
STM32 board. As you submitted your patches first, I will align on it.
I had a first look at the current patch and I have some comments below.
I will review more in details and make some tests, asap.
I agree with Laur
On Wed, 2019-03-06 at 15:02 +0100, Maxime Ripard wrote:
> The preferred bpp for the fbdev emulation buffer has been 32 so far, which
> means that by default we will allocate an 8MB buffer with a 1920x1080
> resolution.
>
> Worse this memory will be allocated from the CMA pool, and will never be
>
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
ie. MXR_CFG_LAYER_UPDATE_C
https://bugs.freedesktop.org/show_bug.cgi?id=109834
--- Comment #1 from fin4...@hotmail.com ---
AMD has open source drivers for gaming. Amdgpu-pro is for CAD software etc.
Steam games are for Debian based distributions, see system requirements.
--
You are receiving this mail because:
You are the
On 2019-03-06 1:41 p.m., Paul Menzel wrote:
> On 03/05/19 20:07, Alex Deucher wrote:
>> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:
>
>>> Using the MST display Dell UP3214Q (two panels) with an AMD system,
>>> the virtual monitor object is not created. GDM and Xfce consider both
>>> panels a
https://bugs.freedesktop.org/show_bug.cgi?id=109887
--- Comment #3 from fin4...@hotmail.com ---
You need to have a kernel command line parameter and c is used to commit
changes. See: https://wiki.archlinux.org/index.php/AMDGPU#Overclocking
--
You are receiving this mail because:
You are the assi
On Tuesday, 2019-03-05 21:54:47 +0530, Mamta Shukla wrote:
> Add overlay plane support in vkms aligned with cursor and primary
> plane with module option 'enable_overlay' to enable/disable overlay
> plane while testing.
>
> This currently passes plane-position-covered-pipe-A-plane subtest
> from I
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu,
On Wed, Feb 20, 2019 at 09:56:39AM -0800, Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > Hi,
> >
> > Here is a fourth iteration of the VC4 load tracking series, which was
> > initially developed by Boris Brezillon and that I have now taken over.
> >
> > This new iteration takes in account c
On 6.3.2019 15.57, Arnd Bergmann wrote:
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did
The preferred bpp for the fbdev emulation buffer has been 32 so far, which
means that by default we will allocate an 8MB buffer with a 1920x1080
resolution.
Worse this memory will be allocated from the CMA pool, and will never be
freed even if we don't use the fbdev emulation. Therefore, reducing
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=i
Hi,
On Fri, Feb 08, 2019 at 11:55:41AM +, Robert Chiras wrote:
> Hi Guido
>
> On Vi, 2019-02-08 at 12:40 +0100, Guido Günther wrote:
> > Hi Robert,
> > On Wed, Feb 06, 2019 at 03:28:07PM +, Robert Chiras wrote:
> > >
> > > Hi Guido,
> > >
> > > Thanks for picking this up. It's interestin
https://bugs.freedesktop.org/show_bug.cgi?id=109921
Martin Peres changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=109921
Bug ID: 109921
Summary: [CI][Runner] Do not mistake KERN_NOTICE for a WARNING
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
Hi Russell,
Am Mittwoch, den 06.03.2019, 13:20 + schrieb Russell King - ARM Linux admin:
> On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> > Hi Russell,
> >
> > Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> > admin:
> > > I'm not sure when this ha
Hi Laurent!
On Wed, Mar 06, 2019 at 03:13:55PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> > On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > > The R-Car DU driver assumes that a bridge is always connected to
On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote:
> Maxime Ripard writes:
>
> > [ Unknown signature status ]
> > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
> >> >
> >> > Maxime Ripard writes:
> >> >
> >> > > In
On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> Hi Russell,
>
> Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> admin:
> > I'm not sure when this happened, only that it happened sometime
> > overnight. It was left running an Xfce desktop having only log
Hi Jacopo,
On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs
Hi Kieran,
On Wed, Mar 06, 2019 at 10:07:12AM +, Kieran Bingham wrote:
> On 02/03/2019 16:17, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs can be connected d
Dear Alex,
On 03/05/19 20:07, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:
>> Using the MST display Dell UP3214Q (two panels) with an AMD system,
>> the virtual monitor object is not created. GDM and Xfce consider both
>> panels as separate screens (`xrandr --listmonit
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #2 from Eero Tamminen ---
Hangs are still happening with the latest Mesa (43f40dc7cb234e) and drm-tip
kernel (v5.0) git versions in Manhattan test offscreen versions.
--
You are receiving this mail because:
You are the assignee for
Hi,
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On
https://bugs.freedesktop.org/show_bug.cgi?id=109850
Andre Klapper changed:
What|Removed |Added
Blocks||
Referenced Bugs:
https://bugs.freede
Hi Dave, Daniel,
A few extra patches for the 5.1 merge window.
Thanks!
Maxime
drm-misc-next-fixes-2019-03-06:
- Properly mark the ptr_to_compat argument with the __user tag
- Merge __drm_atomic_helper_disable_all into drm_atomic_helper_disable_all
The following changes since commit 6649a95d35d8
https://bugs.freedesktop.org/show_bug.cgi?id=109863
Andre Klapper changed:
What|Removed |Added
Component|/dev/null |Two
Alias|osamamumta...@gm
Hi Laurent,
On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> The R-Car DU driver assumes that a bridge is always connected to the DU
> output. This is valid for the LVDS and HDMI outputs, but the DPAD
> outputs can be connected directly to a panel, in which case no bridge is
> a
Hi, Wangyan:
On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> From: chunhui dai
>
> We should not change the rate of parent for hdmi phy when
> doing round_rate for this clock. The parent clock of hdmi
> phy must be the same as it. We change it when doing set_rate
> only.
>
> Signed-off
1 - 100 of 174 matches
Mail list logo
