Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on s
On Mon, 20 May 2019 18:11:07 +0200
Daniel Vetter wrote:
> On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > On Thu, 16 May 2019 14:24:55 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > On Wed, 15 May 2019 10:
Am 21.05.19 um 01:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
On Mon, 20 May 2019, Gwan-gyeong Mun wrote:
> VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
> Packet). In order to generalize SDP packet structure name, it renames
> struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
> different usages, each SDP type has
On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
>
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the fr
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> In tc_bridge_mode_set callback, we store the pointer to the given
> drm_display_mode, and use the mode later. Storing a pointer in such a
> way looks very suspicious to me, and I have observed odd issues where
> the timings were apparently (at least most
When unloading the bochs-drm driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.
Correct this by calling drm_atomic_helper_shutdown() in
bochs_pci_remove().
The issue is caused by the interaction of two previous
This patch removes IO_TLB_SEGPAGES which is no longer used since
commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
IO_TLB_SEGPAGES should be defined on swiotlb side if it is required in the
future.
Signed-
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.3-wip
head: 8dcf1d70d7d7058b54e1356297f201cb7ba6d14f
commit: 399abb79bbdece4bdcb35a5f2983b2335410eeec [159/169] drm/scheduler:
rework job destruction
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC
On Mon, May 20, 2019 at 7:19 PM Pan, Xinhui wrote:
>
> Daniel, what you are talking about is totally wrong.
> 1) AFAIK, only one zero-size array can be in the end of a struct.
> 2) two struct_size will add up struct itself twice. the sum is wrong then.
>
> No offense. I can't help feeling lucky th
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
Documentation/devicetree/bindings/vendor-prefixes.txt
between commit:
8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
from Linus' tree and commits:
b4a2c0055a4f ("dt-bindings: Add vendor prefix
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
between commit:
56965ce261af ("drm/amdgpu: cancel late_init_work before gpu reset")
from the amdgpu tree and commit:
1d721ed679db ("drm/amdgpu: Avoid HW reset if guilty jo
On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
>
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been s
From: Icenowy Zheng
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.
This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on
From: Ondrej Jirman
Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus using a gpio to be able
to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to
model this.
Add binding documentation for optional ddc-en-gpi
From: Icenowy Zheng
The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on
H6 is on a co-packaged AC200 chip, and it's not really internal (it's
connected via RMII at PA GPIO bank).
Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.
Signed-off-by: Icenowy Zhen
From: Ondrej Jirman
This series implements support for Xunlong Orange Pi 3 board.
Unfortunately, this board needs some small driver patches, so I have
split the boards DT patch into chunks that require patches for drivers
in various subsystems.
Suggested merging plan/dependencies:
- stmmac pat
From: Ondrej Jirman
Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
for the DDC bus to be usable.
Add support for hdmi-connector node's optional ddc-en-gpios property to
support this use case.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55
From: Ondrej Jirman
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time,
but we can only specify a single phy-supply in the DT.
This can be achieved by making one regulator depedning on the other via
From: Ondrej Jirman
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
This is realized by the ddc-en-gpios property.
Signed-off-by: Ondrej Jirman
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts
Daniel, what you are talking about is totally wrong.
1) AFAIK, only one zero-size array can be in the end of a struct.
2) two struct_size will add up struct itself twice. the sum is wrong then.
No offense. I can't help feeling lucky that you are in intel.
发件人: Daniel Vetter 代表 Daniel Vetter
发
After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
only deleted when the timeout handler is able to be cancelled
successfully.
In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
job cleanup would be skipped which may result in memory leaks.
Add the handling
On Tue, May 21, 2019 at 12:51 AM Erico Nunes wrote:
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
> job cleanup wo
Daniel, your idea is obviously and totally wrong. There can NOT be more than
one zero-size array in a struct.
Nack for them all.
From: Daniel Vetter on behalf of Daniel Vetter
Sent: Tuesday, May 21, 2019 12:28:07 AM
To: Pan, Xinhui
Cc: Deucher, Alexander; Koeni
After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
only deleted when the timeout handler is able to be cancelled
successfully.
In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
job cleanup would be skipped which may result in memory leaks.
Add the handling
After "5918045c4ed4 drm/scheduler: rework job destruction", lima started
to leak memory due to buffers not being destroyed after job execution in
the drm scheduler.
This started happening because the drm scheduler only destroyed buffers
after cancelling the job timeout handler, and for lima this ha
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
v2: Rebase
Sig
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job d
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return va
On Mon, May 20, 2019 at 8:41 PM Daniel Vetter wrote:
>
> On Sun, May 19, 2019 at 03:51:05PM +0200, Sam Ravnborg wrote:
> > The following patchset remove use of the deprecated drmP.h
> > header file in the gma500 driver.
> > As preparation an empty header file is removed and a dependency on
> > drm
On Mon, May 20, 2019 at 10:59:35PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:51 PM Imre Deak wrote:
> >
> > On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote:
> > > > On Mon, May 20, 2019 at 09:23:00PM +0200, Danie
https://bugs.freedesktop.org/show_bug.cgi?id=110671
--- Comment #7 from Tomas Bzatek ---
The offending commit is
commit 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1
Author: Wenjing Liu
Date: Fri Jan 18 18:19:51 2019 -0500
drm/amd/display: determine if a pipe is synced by plane state
--
You
On Mon, May 20, 2019 at 10:51 PM Imre Deak wrote:
>
> On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote:
> > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre De
On Mon, May 20, 2019 at 07:23:55PM +0200, Andrea Parri wrote:
> These barriers only apply to the read-modify-write operations; in
> particular, they do not apply to the atomic_set() primitive.
>
> Replace the barriers with smp_mb()s.
>
> Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5
On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote:
> > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > > On Mon, May 20, 2019 at 08:37:46PM +0200, D
https://bugs.freedesktop.org/show_bug.cgi?id=110671
--- Comment #6 from Tomas Bzatek ---
Manual bisect so far:
good 0f74e484912626 drm/amd/display: 3.2.15
bad cf7d98d254e9ff drm/amd/display: 3.2.16
--
You are receiving this mail because:
You are the assignee for the bug.__
On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote:
> On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > > On Mon, May 20, 2019 at 08:41:09PM +0300, I
On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > We allowed modesetting an unregiste
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On Mon, May 20, 2019 at 9:24 PM Koenig, Christian
wrote:
>
> Am 20.05.19 um 18:26 schrieb Daniel Vetter:
> > [CAUTION: External Email]
> >
> > On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
> >> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> >>> The new interf
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
Am 20.05.19 um 18:26 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
>> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
>>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
>>> GEM VRA
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > We allowed modesetting an unregistered connector only in the case the
> > > mode is getting disabled on th
Hi Daniel.
On Mon, May 20, 2019 at 08:45:26PM +0200, Daniel Vetter wrote:
> On Sun, May 19, 2019 at 04:20:30PM +0200, Sam Ravnborg wrote:
> > While removing use of drmP.h from files in drm/* I
> > noticed that I had to add the same include files due to
> > build errors in the header files.
> >
>
On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > We allowed modesetting an unregistered connector only in the case the
> > mode is getting disabled on the connector.
> >
> > The reason for this check was the lack of pro
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
https://bugs.freedesktop.org/show_bug.cgi?id=110702
Pierre Ossman changed:
What|Removed |Added
Summary|segfault in radeonsi HEVC |segfault in radeonsi HEVC
On Sun, May 19, 2019 at 04:20:30PM +0200, Sam Ravnborg wrote:
> While removing use of drmP.h from files in drm/* I
> noticed that I had to add the same include files due to
> build errors in the header files.
>
> It is better to let the header files include what is necessary
> and let the users pu
On 5/20/19 12:41 PM, Alex Deucher wrote:
> On Fri, May 17, 2019 at 8:43 AM xiaolinkui wrote:
>>
>> Use struct_size() helper to keep code simple.
>>
Again, this is not the reason why this helper was created.
>> Signed-off-by: xiaolinkui
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +-
On Sun, May 19, 2019 at 03:51:05PM +0200, Sam Ravnborg wrote:
> The following patchset remove use of the deprecated drmP.h
> header file in the gma500 driver.
> As preparation an empty header file is removed and a dependency on
> drm_os_linux.h is dropped.
> The list of include files are sorted and
On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
>
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been s
Thierry,
On Mon, Apr 8, 2019 at 7:39 AM Doug Anderson wrote:
>
> Thierry,
>
> On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding
> wrote:
> >
> > On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > > From: Sean Paul
> > >
> > > This patch adds a new subnode to simple-panel allowin
On Mon, May 20, 2019 at 12:22:35AM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Sun, May 19, 2019 at 08:36:36PM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> >
> > While touching the list of include files:
> > - Divide include fil
Hi Daniel.
On Mon, May 20, 2019 at 07:29:52PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > > With the recursion broken in the previous patch we can drop the
> > > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > >
On Fri, May 17, 2019 at 8:43 AM xiaolinkui wrote:
>
> Use struct_size() helper to keep code simple.
>
> Signed-off-by: xiaolinkui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
This patch results in the following build error:
DESCEND
We allowed modesetting an unregistered connector only in the case the
mode is getting disabled on the connector.
The reason for this check was the lack of proper refcounting for the
backing memory objects. That problem has been solved meanwhile so there
is no reason any more to reject the modesett
On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> > With the recursion broken in the previous patch we can drop the
> > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > prevention was it's only job.
> >
> When grepping for FBINFO_MISC_USEREVENT I get a few h
On Mon, May 20, 2019 at 7:08 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> While browsing this nice patch series I stumbled upon a detail.
>
> On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> > With
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter
> >
Hi Daniel.
> With the recursion broken in the previous patch we can drop the
> FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> prevention was it's only job.
>
When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
in the patch below:
drivers/video/fbdev/core/fbc
On Mon, May 20, 2019 at 1:04 PM Weitao Hou wrote:
>
> fix eror to error
>
> Signed-off-by: Weitao Hou
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/d
Hi Daniel.
While browsing this nice patch series I stumbled upon a detail.
On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> With
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built
https://bugs.freedesktop.org/show_bug.cgi?id=110713
ki...@lytoria.de changed:
What|Removed |Added
CC||ki...@lytoria.de
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=110717
Bug ID: 110717
Summary: [Regression][bisected] Patch: update buffer
descriptors ... causes hangs
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: A
On Fri, May 17, 2019 at 04:44:30PM +, Pan, Xinhui wrote:
> I am going to put more members which are also array after this struct,
> not only obj[]. Looks like this struct_size did not help on multiple
> array case. Thanks anyway.
You can then add them up, e.g
On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
> > GEM VRAM pin/unpin functions that do not reserve the BO during validation.
> > The m
Le lundi 20 mai 2019 à 18:11 +0200, Daniel Vetter a écrit :
> On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > On Thu, 16 May 2019 14:24:55 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > On Wed, 15 May 2019 10:24
On Mon, May 20, 2019 at 11:15:05AM -0300, Fabio Estevam wrote:
> On Tue, Apr 23, 2019 at 8:03 AM Thierry Reding
> wrote:
> >
> > On Mon, Feb 18, 2019 at 09:27:04PM -0300, Fabio Estevam wrote:
> > > VXT Ltd is a manufacturer of projected capacitive touch panel
> > > and display solutions: http://w
On Fri, May 17, 2019 at 01:17:03PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > It turns out that the bochs and vbox drivers automatically reserved and
> > unreserved the BO from within their pin and unpin functions. The other
> > drivers; ast, hibmc and mgag200; performed reservation explicitly. Wit
On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
> GEM VRAM pin/unpin functions that do not reserve the BO during validation.
> The mgag200 driver requires this behavior for its cursor handling. The
> pat
On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> On Thu, 16 May 2019 14:24:55 +0200
> Daniel Vetter wrote:
>
> > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > On Wed, 15 May 2019 10:24:49 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Wed, May 15, 2
https://bugs.freedesktop.org/show_bug.cgi?id=107084
--- Comment #5 from Pierre-Eric Pelloux-Prayer ---
Doesn't seem to hang the system anymore (RX580, mesa daa85a882, Linux 5.0).
--
You are receiving this mail because:
You are the assignee for the bug.___
On 5/19/19 6:55 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190517:
>
> Non-merge commits (relative to Linus' tree): 553
> 519 files changed, 11723 insertions(+), 3396 deletions(-)
>
>
>
> I have created
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 15 +--
drivers/gpu/drm/meson/meson_crtc.h | 15 +--
drivers/gpu/drm/meson/meson_drv.c | 15 +--
drivers/gpu/drm/meson/meson_drv.h | 14 +-
drivers/gpu/drm/
On Tue, Apr 23, 2019 at 8:03 AM Thierry Reding wrote:
>
> On Mon, Feb 18, 2019 at 09:27:04PM -0300, Fabio Estevam wrote:
> > VXT Ltd is a manufacturer of projected capacitive touch panel
> > and display solutions: http://www.vxt.com.tw/
> >
> > Reviewed-by: Otavio Salvador
> > Reviewed-by: Rob He
Thanks, Murray,
I'll include in the next vmwgfx-fixes pull request.
On Mon, 2019-05-20 at 21:57 +1200, Murray McAllister wrote:
> If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
> of SVGA3D_INVALID_ID, and a shader type of
> SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
>
https://bugs.freedesktop.org/show_bug.cgi?id=110701
LoneVVolf changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=108824
LoneVVolf changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #9 from LoneVVolf ---
reverting commit
https://cgit.freedesktop.org/mesa/mesa/commit/?id=78e35df52aa2f7d770f929a0866a0faa89c261a9
solves the visual corruption and gets rid of the gpu fault messages in dmesg.
As that commit is 2/2 of
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
This patch adds a new format_set() callback to the bridge ops permitting
the encoder to specify the new input format and encoding.
This allows supporting the very specific HDMI2.0 YUV420 output mode
when the bridge cannot convert from RGB or YUV444 to YUV420.
In this case, the encode must downsam
The Synopsys DW-HDMI CSC does not support downsampling to YUV420, so
the encoder must downsamle before, feeding the controller with a YUV420
pixel stream.
The encoder must declare the new bus format enc encoding the bridge, in
order to take it in account.
To solve this, a new format_set() bridge
In order to support the HDMI2.0 YUV420, YUV422 and the 10bit, 12bit and
16bits outpu use cases, add support for the recently introduced bridge
callback format_set().
This callback will setup the new input format and encoding from encoder,
then these information will be used instead of the default
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
On Mon, May 20, 2019 at 08:14:03AM -0500, Rob Herring wrote:
> On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
> >
> > The '#address-cells' and '#size-cells' properties were not defined in
> > the lm3630a bindings and would cause the following error when
> > attempting to validate the examples
On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
>
> The '#address-cells' and '#size-cells' properties were not defined in
> the lm3630a bindings and would cause the following error when
> attempting to validate the examples against the schema:
>
> Documentation/devicetree/bindings/leds/backlig
There is a DRM version of the mxsfb driver for quite some time
at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
the fbdev version any longer.
Remove the fbdev mxsfb driver in favour of the DRM version.
Signed-off-by: Fabio Estevam
---
drivers/video/fbdev/Kconfig | 13 +-
dr
Hi all,
In commit
0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
signaler")
Fixes tag
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading
On Mon, May 20, 2019 at 01:20:45PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> > drm_format_info_plane_cpp() basically just returns the cpp array content
> > found in the drm_format_info structure.
> >
> > Since it's pretty trivial, let's remove the fun
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_height/width functions were operating on the
> format's fourcc and was doing a lookup to retrieve the drm_format_info
> structure and return the cpp.
>
> However, this is inefficient since in most cases, we will have
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> The current link training code does unnecessary retry-loops, and does
> extra writes to the registers. It is easier to follow the flow and
> ensure it's similar to Toshiba's documentation if we deal with LT inside
> tc_main_link_enable() function.
>
> Th
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> drm_format_info_plane_cpp() basically just returns the cpp array content
> found in the drm_format_info structure.
>
> Since it's pretty trivial, let's remove the function and have the users use
> the array directly
Reviewed-by: Paul Kocialkows
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_cpp function was operating on the format's
> fourcc and was doing a lookup to retrieve the drm_format_info structure and
> return the cpp.
>
> However, this is inefficient since in most cases, we will have the
> drm_
On Friday, May 17, 2019 4:32:35 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> > From: Janusz Krzysztofik
> >
> > During i915_driver_unload(), GEM contexts are verified restrictively
> > inside i915_gem_fini() if they don't consume shared resources which
> > shou
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> Link training will sometimes fail if the DP link is enabled when
> tc_main_link_enable() is called. The driver makes sure the DP link is
> disabled when the DP output is disabled, and we never enable the DP
> without first disabling it, so this should ne
1 - 100 of 179 matches
Mail list logo
