Hi Rohan
First of all, I'm not in a position to merge new ioctls, so take my
review with a grain of salt. You should get a review from one of the DRM
maintainers. If no one shows up, ping danvet on IRC.
Am 26.09.19 um 17:36 schrieb Rohan Garg:
DRM_IOCTL_BO_SET_LABEL lets you label GEM object
https://bugzilla.kernel.org/show_bug.cgi?id=203471
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #19 from Haxk20 (haxk...@gmail.com) ---
And yes im running linux kernel from master so the DRM patches for
scatther/gather are there. Still tearing even tho they are there.
Help ?
--
You are receiving this mail because:
You are watch
https://bugzilla.kernel.org/show_bug.cgi?id=203471
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Kernel Version|5.1 rc6 and |git master
https://bugs.freedesktop.org/show_bug.cgi?id=111747
--- Comment #8 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- TGL: igt@* -incomplete - Abort requested by .* terminating children -}
{+ TGL: igt@* -incomplete - Abort requested by .* terminating children +}
On 9/26/19 8:54 AM, Tomi Valkeinen wrote:
On 03/09/2019 17:23, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the path.
On Mon, Sep 02, 2019 at 03:53:54PM +0300, Tomi Valkeinen wrote:
From: Alejandro Hernandez
A "HDMI I2C Master Error" is sometimes reported with the current DDC
SCL
timing
From: "Angelo G. Del Regno"
MSM8956/APQ8056 has DSI version 3:10040002 (DSI 6G V1.4.2), featuring
two DSIs. It needs three clocks (mdp_core, iface, bus), one GDSC and
two vregs, VDDA at 1.2V and VDDIO at 1.8V.
Signed-off-by: Angelo G. Del Regno
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 22 ++
From: "Angelo G. Del Regno"
The Adreno 510 GPU is a stripped version of the Adreno 5xx,
found in low-end SoCs like 8x56 and 8x76, which has 256K of
GMEM, with no GPMU nor ZAP.
Also, since the Adreno 5xx part of this driver seems to be
developed with high-end Adreno GPUs in mind, and since this
is
The lockdep_assert_irqs_disabled() check is needless. The previous
lockdep_assert_held() check ensures that the lock is acquired and while
the lock is acquired lockdep also prints a warning if the interrupts are
not disabled if they have to be.
These IRQ-off asserts trigger on PREEMPT_RT because th
Two locking related changed which popped up on PREEMPT_RT.
Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Currently, when allocating the memory for BO by Mesa, the lima kernel
driver set only GFP_DMA32 flag; and this allocation may fail when the
memory is relatively adequate, thus retrying is needed.
Add the GFP flags for retrying memory allocation.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/
From: AngeloGioacchino Del Regno
This patch series enables support for MSM8956/76 and its Adreno 510
GPU on the current DRM driver.
The personal aim is to upstream MSM8956 as much as possible.
This code has been tested on two Sony phones featuring the Qualcomm
MSM8956 SoC.
Changes in v2:
- MDP
From: "Angelo G. Del Regno"
Some SoCs, like MSM8956/8976 (and APQ variants), do feature these
clocks and we need to enable them in order to get the hardware to
properly work.
Signed-off-by: Angelo G. Del Regno
---
Documentation/devicetree/bindings/display/msm/mdp5.txt | 2 ++
drivers/gpu/drm/
From: "Angelo G. Del Regno"
The 28nm PLL has a different iospace on MSM/APQ family B SoCs:
add a new configuration and use it when the DT reports the
"qcom,dsi-phy-28nm-hpm-fam-b" compatible.
Signed-off-by: Angelo G. Del Regno
---
.../devicetree/bindings/display/msm/dsi.txt| 1 +
drivers/
From: "Angelo G. Del Regno"
Add the configuration entries for the MDP5 v1.11, found on MSM8956
and APQ8056.
Signed-off-by: Angelo G. Del Regno
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 99
1 file changed, 99 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp
The function intel_engine_breadcrumbs_irq() is always invoked from an interrupt
handler and for that reason it invokes (as an optimisation) only spin_lock()
for locking assuming that the interrupts are already disabled. The
function intel_engine_signal_breadcrumbs() is provided to disable
interrupt
(dropping folks who're probably not interested...)
On 26/09/2019 17:12, Adam Ford wrote:
On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen wrote:
On 25/09/2019 23:51, Adam Ford wrote:
Has anyone debugged why the hang is happening?
I started to debug this, but I got distracted when I noticed t
On Fri, Sep 06, 2019 at 07:18:06AM +, Lowry Li (Arm Technology China) wrote:
> This is a SW workaround for shadow un-flushed when together with the
> DOU Timing-disable.
>
> D71 HW doesn't update shadow registers when display output is turned
> off. So when we disable all pipeline components t
On 2019/9/25 下午10:11, Rob Miller wrote:
> > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
>
> This seems rather unrefined. We're registering interdependent data in
> separate calls. All drivers need to make both of these calls. I'm not
>
On Tue, Sep 24, 2019 at 11:30:30PM -0500, Navid Emamdoost wrote:
> In komeda_wb_connector_add if drm_writeback_connector_init fails the
> allocated memory for kwb_conn should be released.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 +++-
Hi Christian,
In v5.3, running dEQP triggers the following kernel crash :
[ 20.224982] Unable to handle kernel NULL pointer dereference at virtual
address 0038
[...]
[ 20.291064] Hardware name: Khadas VIM2 (DT)
[ 20.295217] Workqueue: events drm_sched_job_timedout
[...]
[ 20.
On 2019/9/25 上午7:06, Alex Williamson wrote:
On Tue, 24 Sep 2019 21:53:30 +0800
Jason Wang wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
include/linux/mdev.h| 2 +
include/linux/vi
Hi
Am 17.09.19 um 15:06 schrieb Daniel Vetter:
On Thu, Sep 12, 2019 at 08:42:28AM +0200, Thomas Zimmermann wrote:
Before updating the display from the console's shadow buffer, the dirty
worker now waits for vblank. This allows several screen updates to pile
up and acts as a rate limiter.
v2:
This patch only moves around code for easier review of later patches. No
functional cahnges are made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ast/a
By putting cursor BOs at the high end of the video memory, we can avoid
memory fragmentation. Starting at the low end, contiguous video memory is
available for framebuffers.
The patch also simplifies the buffer swapping by splitting
struct ast_private.cursor_cache BO into two separate boffer objec
Separating the cursor's move() function from the show() function in
preparation of further rework of the cursor update code.
'Showing' the cursor from within the move() function is required to
update the cursor position.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 5 ++
Selecting the correct offset for the new cursor image is not relevant
outside of ast_show_cursor(). Let the function do the work.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 57 ++
1 file changed, 31 insertions(+), 26 deletions(-)
diff -
A call to ast's show-cursor function now receives the cursor image
and updates the buffer. The change splits off image update and
base-address update into separate functions.
v3:
* move ast_{show,hide}_cursor() in a previous patch
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast
(was: drm/ast/mgag200: Place cursor BOs at VRAM high-end)
This patchset cleans up the memory management of HW cursors in ast. It
further moves the allocated cursor BOs to the of the video RAM to reduce
memory fragmentation.
The ast driver manages cursor memory in a dedicated GEM VRAM buffer
objec
Moving the cursor initialization and cleanup into separate functions
makes the overall code slightly more readable.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 28
drivers/gpu/drm/mgag200/mgag200_drv.h| 2 ++
drivers/gpu/drm/mgag2
Separating the management of buffer objects from updating the hardware
cursor buffer gives the code more structure. While doing this, we can
further split the image-update code into code for writing the buffer,
setting the base scan-out address, and enabling the cursor. The first
two operations are
By putting cursor BOs at the high end of the video memory, we can avoid
memory fragmentation. Starting at the low end, contiguous video memory is
available for framebuffers.
The patch also simplifies the buffer swapping and aligns it with the
ast driver. If there are more drivers with similar requ
Although the driver source code is fairly inconsistent wrt naming, the
prefix should be mgag200. Rename cursor functions accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 19 ---
drivers/gpu/drm/mgag200/mgag200_drv.h| 6 +++---
driv
The double-buffered cursor image is currently stored in video memory
by creating two BOs and pinning them to VRAM. The exact location is
chosen by VRAM helpers. The pinned cursor BOs can conflict with
framebuffer BOs and prevent the primary plane from displaying its
framebuffer.
As a first step to
Selecting the correct BO for the new cursor image is not relevant
outside of mgag200_show_cursor(). Let the function do the work.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 120 +++
1 file changed, 56 insertions(+), 64 deletions(-)
diff -
Adding mgag200_move_cursor() makes the cursor code more consistent and
will become handy when we move to universal cursor planes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 29
1 file changed, 20 insertions(+), 9 deletions(-)
diff --
(was: drm/ast/mgag200: Place cursor BOs at VRAM high-end)
This patchset cleans up the memory management of HW cursors in mgag200. It
further moves the allocated cursor BOs to the of the video RAM to reduce
memory fragmentation.
The mgag200 driver manages cursor memory in dedicated GEM VRAM buffer
Hi John,
On Thu, Sep 26, 2019 at 02:36:33PM -0700, John Stultz wrote:
> On Mon, Sep 23, 2019 at 3:12 PM Brian Starkey wrote:
> >
> > I didn't see any response about using the test harness. Did you decide
> > against it?
>
> Hey! Spent a little time looking at this bit and just wanted to reply
>
On 9/27/19 7:55 AM, Thomas Hellström (VMware) wrote:
On 9/27/19 12:20 AM, Linus Torvalds wrote:
On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
wrote:
Well, we're working on supporting huge puds and pmds in the graphics
VMAs, although in the write-notify cases we're looking at here,
When the compiler decides not to inline the Chunky-to-Planar core
functions, the build fails with:
c2p_planar.c:(.text+0xd6): undefined reference to `c2p_unsupported'
c2p_planar.c:(.text+0x1dc): undefined reference to `c2p_unsupported'
c2p_iplan2.c:(.text+0xc4): undefined reference to
On 27/09/2019 09:12, Neil Armstrong wrote:
> Hi Christian,
>
> In v5.3, running dEQP triggers the following kernel crash :
>
> [ 20.224982] Unable to handle kernel NULL pointer dereference at virtual
> address 0038
> [...]
> [ 20.291064] Hardware name: Khadas VIM2 (DT)
> [ 20.2
The Xylon LogiCVC is a display controller implemented as programmable
logic in Xilinx FPGAs.
Signed-off-by: Paul Kocialkowski
---
.../display/xylon,logicvc-display.yaml| 313 ++
1 file changed, 313 insertions(+)
create mode 100644
Documentation/devicetree/bindings/displ
This series introduces support for the LogiCVC display controller.
The controller is a bit unusual since it is usually loaded as
programmable logic on Xilinx FPGAs or Zynq-7000 SoCs.
More details are presented on the main commit for the driver.
More information about the controller is available on
Introduces a driver for the LogiCVC display controller, a programmable
logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
Xilinx FPGAs. The controller is mostly configured at logic synthesis
time so only a subset of configuration is left for the driver to
handle.
The following f
On 27/09/2019 10:55, Steven Price wrote:
[...]
> One obvious issue with the DRM scheduler is that there is a call to
> cancel_delayed_work() in drm_sched_stop() which to me looks like it
> should be cancel_delayed_work_sync() to ensure that the timeout handling
> has completed.
>
> However in the
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #18 from Leon ---
I have the same problem. Sapphire 5700 XT Nitro, x470 motherboard (asrock
taichi), running arch with kernel 5.3.1. My resolution is 2560x1440 144Hz, with
30Watts idle and 70 Celsius at the memory :( ... Unlike you c
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #19 from Leon ---
By the way, since I have a x470 mb, it cannot be related to PCI express 4.0.
It's also not related to dual displays, since I'm running just one.
--
You are receiving this mail because:
You are the assignee for the
Hi Steven,
Thanks for your prompt reaction !
On 27/09/2019 12:48, Steven Price wrote:
> On 27/09/2019 10:55, Steven Price wrote:
> [...]
>> One obvious issue with the DRM scheduler is that there is a call to
>> cancel_delayed_work() in drm_sched_stop() which to me looks like it
>> should be cance
https://bugs.freedesktop.org/show_bug.cgi?id=111747
--- Comment #9 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- TGL: igt@* -incomplete - Abort requested by .* terminating children -}
{+ TGL: igt@* -incomplete - Abort requested by .* terminating children +}
Hi,
On 27/09/2019 13:27, Neil Armstrong wrote:
> Hi Steven,
>
> Thanks for your prompt reaction !
>
> On 27/09/2019 12:48, Steven Price wrote:
>> On 27/09/2019 10:55, Steven Price wrote:
>> [...]
>>> One obvious issue with the DRM scheduler is that there is a call to
>>> cancel_delayed_work() in
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
>
> On 26/09/2019 17:12, Adam Ford wrote:
>
> >> And what is the hdmi5_configure there? I don't see anything in the
> >> driver that would print hdmi5_configure. And, of course, there's no
> >> hdmi5 on that platform. Hmm, ok... it's from compo
On Thu, Sep 26, 2019 at 01:16:55PM -0700, Linus Torvalds wrote:
> On Thu, Sep 26, 2019 at 1:09 PM Thomas Hellström (VMware)
> wrote:
> >
> > That said, if people are OK with me modifying the assert in
> > pud_trans_huge_lock() and make __walk_page_range non-static, it should
> > probably be possib
Am 26.09.19 um 23:44 schrieb Ben Skeggs:
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
>> Hi guys,
>>
>> while working through more old TTM functionality I stumbled over the
>> io_reserve_lru.
>>
>> Basic idea is that when this flag is set the driver->io_mem_reserve()
>> callback can re
On Thu, Sep 26, 2019 at 03:20:42PM -0700, Linus Torvalds wrote:
> On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
> wrote:
> >
> > Well, we're working on supporting huge puds and pmds in the graphics
> > VMAs, although in the write-notify cases we're looking at here, we would
> > probabl
On Fri, Sep 27, 2019 at 2:55 AM Tomi Valkeinen wrote:
>
> (dropping folks who're probably not interested...)
>
> On 26/09/2019 17:12, Adam Ford wrote:
> > On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen
> > wrote:
> >>
> >> On 25/09/2019 23:51, Adam Ford wrote:
> >>
> Has anyone debugged why
On Fri, Sep 20, 2019 at 03:11:34PM +, Mihail Atanassov wrote:
> Fix both the string and the struct member being printed.
>
> Fixes: 264b9436d23b ("drm/komeda: Enable writeback split support")
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
That is needed by at least a cleanup in radeon.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 ++-
include/drm/ttm/ttm_bo_api.h| 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
inde
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
Not functional change, but only compile tested.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
d
Just a drive-by comment:
On Sat, Aug 24, 2019 at 11:54 AM Sam Ravnborg wrote:
> We will also start to see new drivers where there will be support
> for more than one type of connector interface.
>
> Like for example ili9322:
> - 8-bit serial RGB interface
> - 24-bit parallel RGB interface
> -
On Fri, Sep 27, 2019 at 02:02:59AM +, james qian wang (Arm Technology
China) wrote:
> On Thu, Sep 26, 2019 at 11:51:21AM +, Liviu Dudau wrote:
> > On Thu, Sep 26, 2019 at 10:00:22AM +, Lowry Li (Arm Technology China)
> > wrote:
> > > Hi Lowry,
> > > On Wed, Sep 25, 2019 at 10:24:58AM
Hi Linus,
On Fri, 27 Sep 2019 at 13:37, Linus Walleij wrote:
> Also the ILI9322 can actually set up gamma correction which is
> very nice for professional applications. I haven't seen any way for
> DRM to do gamma correction properly or any framework for it
> to adjust and propagate gamma to/from
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #54 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sergey Kondakov from comment #53)
> Or any of these ?
> options amdgpu cik_support=1 si_support=1 msi=1 disp_priority=2 dpm=1
> runpm=1 sched_policy=1 compute_multipipe=1 v
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #55 from Tom Seewald (tseew...@gmail.com) ---
(In reply to Sergey Kondakov from comment #53)
> Created attachment 285209 [details]
> dmesg_2019-09-26-amdgpu-old_dereference_on_patched_5.3.1
>
> After about a day of uptime my patched 5
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
Instead call the qxl_ttm_io_mem_reserve() function directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_drv.h| 2 ++
drivers/gpu/drm/qxl/qxl_object.c | 11 +--
drivers/gpu/drm
Those are not supposed to be used by drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 086ba2c2f60b..2eca752c39e9 100644
--- a/drivers/g
On Wed, Sep 25, 2019 at 5:53 PM Lyude Paul wrote:
>
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
> Change
On Wed, Sep 25, 2019 at 05:00:00PM -0400, Lyude Paul wrote:
> On Wed, 2019-09-25 at 15:27 -0400, Sean Paul wrote:
> > On Tue, Sep 03, 2019 at 04:45:54PM -0400, Lyude Paul wrote:
> > > Since we're going to be implementing suspend/resume reprobing very soon,
> > > we need to make sure we are extra ca
On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote:
> On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote:
> > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote:
> > > When reprobing an MST topology during resume, we have to account for the
> > > fact that while we were suspended it
On 27/09/2019 15:13, Adam Ford wrote:
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform. Hmm
v2:
use drm_gem_objects_lookup_user instead of
drm_gem_objects_lookup.
Cc: Eric Anholt
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/v3d/v3d_gem.c | 49 +++
1 file changed, 3 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/d
drm_gem_objects_lookup does not use user space bo handles
directly and left the user to kernel copy work to a new
interface drm_gem_objects_lookup_user.
This is for driver like lima which does not pass gem bo
handles continously in an array in ioctl argument.
v2:
1. add drm_gem_objects_lookup_use
By using shared drm helpers:
1. drm_gem_objects_lookup
2. drm_gem_(un)lock_reservations
3. drm_gem_shmem_helpers
we can simplify lima driver a lot and benifit from updates to
these functions.
drm_gem_objects_lookup need a refine in order to be used by lima.
Note:
1. changes to panfrost and v3d ar
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 5 ++-
drivers/gpu/drm/lima/lima_gem.c | 73 +++--
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index 75ec703d22e0..cc85
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_gem.c | 64 -
1 file changed, 6 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index eb70e4429588..3cc1870862c3 100644
--- a/drivers/gpu/drm/lima/l
Do not need to maintain our own shmem memory management
code as drm_gem_shmem_helpers provides it. And we can
also benifit from the work of others with shared code.
This is also a preparation for implementing buffer madv.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Kconfig | 1 +
This prevent CMA printing dumy "PFNs busy" info which is
caused by alloc fail re-try case.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 2 +-
drivers/gpu/drm/lima/lima_vm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets dss1_alwon_fck_3430es2 rate to 2700 or
27870967,
On Fri, Sep 13, 2019 at 4:45 PM Alex Deucher wrote:
>
> On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul wrote:
> >
> > Currently, every single piece of code in amdgpu that loops through
> > connectors does it incorrectly and doesn't use the proper list iteration
> > helpers, drm_connector_list_iter_beg
On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote:
> Finally! For a very long time, our MST helpers have had one very
> annoying issue: They don't know how to reprobe the topology state when
> coming out of suspend. This means that if a user has a machine connected
> to an MST topology and
On 27/09/2019 14:46, Qiang Yu wrote:
> drm_gem_objects_lookup does not use user space bo handles
> directly and left the user to kernel copy work to a new
> interface drm_gem_objects_lookup_user.
>
> This is for driver like lima which does not pass gem bo
> handles continously in an array in ioctl
On 27/09/2019 14:46, Qiang Yu wrote:
> v2:
> use drm_gem_objects_lookup_user instead of
> drm_gem_objects_lookup.
>
> Cc: Eric Anholt
> Signed-off-by: Qiang Yu
Looks familiar :)
Nit: please write a commit message. But otherwise:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/v3d/v3d_gem
On Thu, Sep 26, 2019 at 6:52 PM Lyude Paul wrote:
>
> kfree() checks this automatically.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Alex Deucher
And applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 ++
> 1 file changed, 2 insertions(+), 4 de
On Thu, Sep 26, 2019 at 6:52 PM Lyude Paul wrote:
>
> We are supposed to be atomic after all. We'll need this in a moment for
> the next commit.
>
> Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +-
> 1 file change
On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyude Paul wrote:
> Currently we only print mstb/port pointer addresses in our malloc and
> topology refcount functions using the hashed-by-default %p, but
> unfortunately if you're trying to debug a use-after-free error caused by
> a refcounting error then
On 27/09/2019 15:44, Daniel Stone wrote:
Hi Linus,
On Fri, 27 Sep 2019 at 13:37, Linus Walleij wrote:
Also the ILI9322 can actually set up gamma correction which is
very nice for professional applications. I haven't seen any way for
DRM to do gamma correction properly or any framework for it
t
From: Maciej Falkowski
Convert Samsung Image Scaler to newer dt-schema format.
Signed-off-by: Maciej Falkowski
Signed-off-by: Marek Szyprowski
---
v3:
- Fixed description of 'clocks' property:
rather than 'mscl clock', 'pclk clock'
- Added empty line within if-else statement
- Added 'additiona
From: Maciej Falkowski
Convert Samsung 2D Graphics Accelerator to newer dt-schema format
Signed-off-by: Maciej Falkowski
---
v3:
- Merged two if-statements with single if-else statement
- Added 'additionalProperties: false'
- Listed all missing 'properties' in properties scope
Best regards,
Ma
Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume.
Works perfectly with this workaround applied.
RFC comment:
We are quite sure that there is a higher amount of bridges affected by this,
but I was only testing it on my own machine for now.
I've stresstested runpm by doing
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #146 from Alex Deucher ---
(In reply to tom91136 from comment #145)
> @Alex any plans for the patches to be merged for 5.4 or even backported to
> 5.3 at some point?
Already merged to 5.4. I'll take a look at older kernels as well.
On Tue, Sep 03, 2019 at 04:46:05PM -0400, Lyude Paul wrote:
> For very subtle mistakes with topology refs, it can be rather difficult
> to trace them down with the debugging info that we already have. I had
> one such issue recently while trying to implement suspend/resume
> reprobing for MST, and
On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski wrote:
>
> From: Maciej Falkowski
>
> Convert Samsung Image Scaler to newer dt-schema format.
>
> Signed-off-by: Maciej Falkowski
> Signed-off-by: Marek Szyprowski
> ---
> v3:
> - Fixed description of 'clocks' property:
> rather than 'mscl clock',
On 27/09/2019 12:48, Neil Armstrong wrote:
> Hi,
>
> On 27/09/2019 13:27, Neil Armstrong wrote:
>> Hi Steven,
>>
>> Thanks for your prompt reaction !
>>
>> On 27/09/2019 12:48, Steven Price wrote:
>>> On 27/09/2019 10:55, Steven Price wrote:
>>> [...]
One obvious issue with the DRM scheduler
On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski wrote:
>
> From: Maciej Falkowski
>
> Convert Samsung 2D Graphics Accelerator to newer dt-schema format
>
> Signed-off-by: Maciej Falkowski
> ---
> v3:
> - Merged two if-statements with single if-else statement
> - Added 'additionalProperties: false
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #147 from ReddestDream ---
> Already merged to 5.4. I'll take a look at older kernels as well.
@Alex Deucher Thanks so much for all your help! :)
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=110674
Anthony Rabbito changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 27/09/2019 17:00, Steven Price wrote:
> On 27/09/2019 12:48, Neil Armstrong wrote:
>> Hi,
>>
>> On 27/09/2019 13:27, Neil Armstrong wrote:
>>> Hi Steven,
>>>
>>> Thanks for your prompt reaction !
>>>
>>> On 27/09/2019 12:48, Steven Price wrote:
On 27/09/2019 10:55, Steven Price wrote:
On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> This commit is seperate from the previous one to make it easier to
> revert in the future. Basically, there's multiple userspace applications
> that interpret possible_crtcs very wrong:
>
> https://gitlab.freedesktop.org/xorg/xserver/me
On 27/09/2019 16:47, Tomi Valkeinen wrote:
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets dss1_alw
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wrong (sample clk_set_xyz call sequence, expected results via
clk_get_xyz, and what fails), I can take a look at it. Just reporting
arbitrary display driver issues I won't be able to deb
>
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
As far as I can see by your second patch QXL is just using exported
(that is not internal) functions.
Not that the idea of making them internal is bad but this comment is
a wrong statement.
> Inst
1 - 100 of 145 matches
Mail list logo
