Fix the kbuild test rebot reported warnings:
- symbol was not declared. Should it be static?
- missing braces around initializer
Depends on:
- https://patchwork.freedesktop.org/series/58976/
Reported-by: kbuild test robot
Signed-off-by: James (Qian) Wang
---
From: "james qian wang (Arm Technology China)"
Fixed the warnings: Function parameter or member 'xxx' not described
when make htmldocs
This patch depends on:
- https://patchwork.freedesktop.org/series/54448/
- https://patchwork.freedesktop.org/series/54449/
-
The pull request you sent on Wed, 24 Apr 2019 11:21:44 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ba25b50d582ff6c6021eee80824134aeb9ab8785
Thank you!
--
Deet-doot-dot, I am a bot.
From: Dave Airlie
The legacy device list and pci legacy init/exit don't need to
be built if not supporting legacy.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_pci.c | 8 ++--
include/drm/drm_device.h | 10 +++---
include/drm/drm_pci.h | 2 ++
3 files changed, 11
>> -drm_sched_stop(>sched, >base);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
HW fence are already forced completion, then we can just disable irq
Hi Dave,
Just log cleanups patches of Exynos KMS and DMA drivers
including one trivial style fixup.
Please kindly let me know if there is any problem.
Resend changelog:
- Fixed two build warnings by removing unused variables,
and confirmed no build warning messages.
- Rebased on top
Hi Dave,
19. 4. 24. 오전 11:03에 Dave Airlie 이(가) 쓴 글:
> Hi Inki,
> CC [M] drivers/gpu/drm/exynos/exynos_drm_scaler.o
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:
> In function ‘rotator_unbind’:
>
Hi Inki,
CC [M] drivers/gpu/drm/exynos/exynos_drm_scaler.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:
In function ‘rotator_unbind’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21:
warning: unused variable ‘drm_dev’
Hi Deepak,
On Wed, 24 Apr 2019 01:31:59 + Deepak Singh Rawat wrote:
>
> Sorry missed that part and missed your email context about commiter and
> not the author. I think at this point nothing can be done?
Probably, I am pretty sure that Dave does not rebase the drm tree.
--
Cheers,
Stephen
On Thu, Apr 18, 2019 at 10:12 AM Brian Masney wrote:
>
> Add new backlight bindings for the TI LM3630A dual-string white LED.
>
> Signed-off-by: Brian Masney
> ---
> Changes since v4:
> - Drop $ref from led-sources
> - Drop description from reg of i2c address
> - Expand description of reg for
On Wed, 24 Apr 2019 at 11:13, Dave Airlie wrote:
>
> I've been looking a bit at 5.0 for a few things recently, and I've
> noticed it shipped with a bunch of regressions, that I'm trying to
> smash.
>
> udl driver regression due to gem unlocked cleanup
> udl driver unload regression due to other
On Wed, 2019-04-24 at 11:12 +1000, Stephen Rothwell wrote:
> Hi Deepak,
>
> On Wed, 24 Apr 2019 00:36:19 + Deepak Singh Rawat <
> dra...@vmware.com> wrote:
> >
> > On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> > >
> > > Commit
> > >
> > > a9f58c456e9d ("drm/vmwgfx: Be more
Hey Linus,
We interrupt your regularly scheduled drm fixes for a regression special.
The first is for a fix in i915 that had unexpected side effects
fallout in the userspace X.org modesetting driver where X would no
longer start. I got tired of the nitpicking and issued a large hammer
on it. The
I've been looking a bit at 5.0 for a few things recently, and I've
noticed it shipped with a bunch of regressions, that I'm trying to
smash.
udl driver regression due to gem unlocked cleanup
udl driver unload regression due to other unplug changes
i915 + atomic x.org modesetting driver break
i915
Hi Deepak,
On Wed, 24 Apr 2019 00:36:19 + Deepak Singh Rawat wrote:
>
> On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> >
> > Commit
> >
> > a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> > resources")
>
> Actully the Signed-off-by: is not missing see
>
On Wed, 24 Apr 2019 at 02:18, Emil Velikov wrote:
>
> On Tue, 23 Apr 2019 at 15:06, Gerd Hoffmann wrote:
> >
> > On Tue, Apr 23, 2019 at 12:55:07PM +0100, Emil Velikov wrote:
> > > On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann wrote:
> > > >
> > > > Hi,
> > > >
> > > > > > The DRI3 code
On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> resources")
Hi Stephen,
Actully the Signed-off-by: is not missing see
https://bugs.freedesktop.org/show_bug.cgi?id=110457
--- Comment #6 from Yury Zhuravlev ---
Vega56
Ryzen 2700x
Kernel 5.0.3
Mesa latest master git
libdrm latest master git
llvm 8
I have the same problem then I use DXVK for the free version of Assasin Creed.
[ 3137.670744]
Hi all,
Commit
a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying resources")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpUd72C3gb_z.pgp
Description: OpenPGP digital signature
___
dri-devel mailing
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the driver_data
value to not be a global variable. Instead the driver_data value
is accessed via the of_device_get_match_data() when needed.
Cc: Xinliang Liu
Cc: Rongrong
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch adds a flag to the
device specific driver data so that we can conditionally
register the connectors at init.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Cc:
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
dev->driver_data to point to a drm_device, not ade_data.
Thus we set the driver data to drm device after alloc.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct kirin_dc_ops to struct kirin_drm_data and cleans
up the related variable names.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Cc: David
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
alloc/clean_hw_ctx functions to be called via driver_data
specific funciton pointers.
This will allow the ade_drm_init to later be made generic and
moved to
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the mode config
initialization values into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc:
The 'return 0' in kirin_drm_platform_probe() is unreachable
code, so remove it.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Suggested by: Xu YiPing
Signed-off-by: John Stultz
---
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the max_width
and max_height values used in kirin_drm_mode_config_inita to
hardware specific driver data.
This will make it easier to add support for new devices
via a new
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes funcitons
to pass the kirin_driver_data as a prameter.
This will allow those funcitons to be later moved to the
generic kirin_drm_drv.c
Cc: Xinliang Liu
Cc: Rongrong Zou
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the drm_driver
structure to be under device specific driver data.
This will allow us to more easily add support for kirin960
hardware with later patches.
Cc: Xinliang Liu
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the crtc
and plane funcs/helper_funcs to the struct kirin_drm_data.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Xinliang
The workqueue used to reset the display when we hit an LDI
underflow error is ADE specific, so since this patch series
works to make the kirin_crtc structure more generic, move the
workqueue to the ade_hw_ctx structure instead.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the channel
format arrays into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Xinliang Liu
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization routines so the devm_request_irq() function
is called as part of the allocation function.
This will be needed in the future when we will have different
From: Da Lv
The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).
After lots of analysis by HiSi
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch removes the out_format
field in the struct ade_crtc, which was only ever set to
LDI_OUT_RGB_888.
Thus this patch removes the field and instead directly uses
LDI_OUT_RGB_888.
Cc:
From: Xu YiPing
In a few functions, we pass in a struct ade_crtc, which we only
use to get to the underlying struct ade_hw_ctx.
Thus this patch refactors the functions to just take the
struct ade_hw_ctx directly.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Cc: David
The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
driver, so cut out the middleman and condense the config
logic down.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Signed-off-by: John Stultz
---
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames
ade_crtc/plane_init kirin_plane/crtc_init, as they will later be
moved to kirin drm drv and shared with the kirin960 hardware
support.
Cc: Xinliang Liu
Cc: Rongrong Zou
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves some shared
structures and helpers to the common kirin_drm_drv.h
These structures will later used by both kirin620 and
future kirin960 driver
Cc: Xinliang Liu
Cc: Rongrong
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the number of
planes and the primary plane value to the kirin_drm_data
structure
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization function to dynamically allocate the ade_hw_ctx
structure previously kept as part of struct ade_data.
This is done so that later we can have the hw_ctx
This patchset contains one fix (in the front, so its easier to
eventually backport), and a series of changes from YiPing to
refactor the kirin drm driver so that it can be used on both
kirin620 based devices (like the original HiKey board) as well
as kirin960 based devices (like the HiKey960
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_crtc to kirin_crtc.
The struct kirin_crtc will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_plane to kirin_plane.
The struct kirin_plane will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #6 from Julien Isorce ---
Thx for the suggestion, I submitted patches here
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/721.
--
You are receiving this mail because:
You are the assignee for the
Hi Daniel/Dave,
The vmwgfx-next changes for 5.2:
Resource dirtying improvement by Thomas,
user-space error logging improvement and
some other minor fixes.
The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
Merge tag 'drm-misc-next-2019-04-04' of
On Tue, Apr 23, 2019 at 11:01 PM Deepak Singh Rawat wrote:
>
> On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> > I'll merge it, but it appears patchwork failed to find this pull
> > request.
> >
> > What version of git was used to generate it?
>
> git version 2.17.1
Looks like windows
On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> I'll merge it, but it appears patchwork failed to find this pull
> request.
>
> What version of git was used to generate it?
git version 2.17.1
>
> Dave.
>
> On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawat
> wrote:
> >
> > It seems
I'll merge it, but it appears patchwork failed to find this pull request.
What version of git was used to generate it?
Dave.
On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawat wrote:
>
> It seems this got missed, If no one has any objection I will submit the
> patches via drm-mics route.
>
>
On Tue, Apr 23, 2019 at 08:50:35PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 12:00:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This could probably be done with Kconfig somehow, but I failed in my
> > first 2 minute attempt.
> >
> > Signed-off-by: Dave Airlie
>
>
Hi Dave.
On Tue, Apr 23, 2019 at 12:00:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves the legacy dev reinit into a legacy inline,
> also removes some unneeded inlines now.
This comment looks like it belogns to an older iteration
of the patch.
Sam
Hi Dave.
On Tue, Apr 23, 2019 at 12:00:36PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This will allow easier removal later.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_drv.c| 10 +++---
> drivers/gpu/drm/drm_legacy.h | 14 ++
> 2 files changed, 17
Hi Dave.
Micro nit..
On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This allows them to be removed later.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_drv.c| 7 +++
> drivers/gpu/drm/drm_legacy.h | 10 ++
> 2 files
Hi Jacopo,
Thank you for the patch.
On Tue, Apr 23, 2019 at 06:56:00PM +0200, Jacopo Mondi wrote:
> On Tue, Apr 23, 2019 at 05:46:51PM +0300, Laurent Pinchart wrote:
> > On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> >> On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart
On Tue, Apr 23, 2019 at 5:45 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> > >> On Thu, Apr
On Tue, Apr 23, 2019 at 7:17 PM Nicolas Dufresne wrote:
>
> Le mardi 23 avril 2019 à 17:09 +0200, Daniel Vetter a écrit :
> > On Tue, Apr 23, 2019 at 4:28 PM Nicolas Dufresne
> > wrote:
> > > Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > > > Hi,
> > > >
> > > > On Tue,
On Tue, Apr 23, 2019 at 04:53:53PM +0200, Noralf Trønnes wrote:
> Non-atomic drivers like ast doesn't have connector->state set resulting
> in a NULL pointer deref:
>
> [ 29.609593] BUG: unable to handle kernel NULL pointer dereference at
> 0010
> [ 29.609619] Call Trace:
> [
On Tue, Apr 23, 2019 at 08:45:11PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This allows them to be removed later.
> >
> > Signed-off-by: Dave Airlie
>
> vmwgfx still uses these? Is the plan to burn that down :-)
>
On Tue, Apr 23, 2019 at 12:00:41PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This removes these unless legacy is enabled.
>
> The lock count init is unneeded anyways since it's kzalloc.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_auth.c | 4 ++--
>
On Tue, Apr 23, 2019 at 12:00:40PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This places a bunch of the legacy members of drm_device into
> only being there when legacy is enabled.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_legacy.h | 20
>
On Tue, Apr 23, 2019 at 12:00:39PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> If you don't want the legacy drivers, then lets get rid of all the
> legacy codepaths from the core module.
>
> This drop the size of drm.ko for me by about 10%.
> 38051574224192 392129 5fbc1
>
On Tue, Apr 23, 2019 at 12:00:38PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This could probably be done with Kconfig somehow, but I failed in my
> first 2 minute attempt.
>
> Signed-off-by: Dave Airlie
config DRM_ATI_PCIGART
bool
default y
depens on PCI &&
On Tue, Apr 23, 2019 at 12:00:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves the legacy dev reinit into a legacy inline,
> also removes some unneeded inlines now.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_file.c | 24
>
On Tue, Apr 23, 2019 at 12:00:36PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This will allow easier removal later.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_drv.c| 10 +++---
> drivers/gpu/drm/drm_legacy.h | 14 ++
> 2 files changed, 17
On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This allows them to be removed later.
>
> Signed-off-by: Dave Airlie
vmwgfx still uses these? Is the plan to burn that down :-)
Probably easier to add a todo.rst item to clean that up than do it
yourself.
On Tue, Apr 23, 2019 at 12:00:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This makes it easier to remove legacy code later.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_auth.c | 14 +-
> drivers/gpu/drm/drm_legacy.h | 1 +
> drivers/gpu/drm/drm_lock.c
Paul Kocialkowski writes:
> The binner BO is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
>
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left, using a kref. Protect the logic
Hi,
Le mardi 23 avril 2019 à 10:14 -0700, Chen-Yu Tsai a écrit :
> On Tue, Apr 23, 2019 at 10:06 AM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > >
> > > On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > >
On Tue, Apr 23, 2019 at 10:06 AM Paul Kocialkowski
wrote:
>
> Hi,
>
> Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> > > wrote:
> > > > Our
On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> If a MMU is shared between multiple GPUs, all of them need to flush their
> TLBs, so a single marker that gets reset on the first flush won't do.
> Replace the flush marker with a sequence number, so that it's possible to
> check if the TLB
Hi,
Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> > wrote:
> > > Our components may still be using the DRM device driver (if only to
> > > access our
On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> There is no need for each GPU to have it's own cmdbuf suballocation
> region. Only allocate a single one for the the etnaviv virtual device
> and share it across all GPUs.
>
> Signed-off-by: Lucas Stach
> ---
>
Hi,
Le mardi 23 avril 2019 à 13:22 +0200, Thomas Zimmermann a écrit :
> Hi
>
> Am 17.04.19 um 09:54 schrieb Maxime Ripard:
> > Move the DRM formats API to turn this into a more generic image formats API
> > to be able to leverage it into some other places of the kernel, such as
> > v4l2 drivers.
Hi Laurent,
On Tue, Apr 23, 2019 at 05:46:51PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> > On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart wrote:
> > > Add support for the V4L2_PIX_FMT_RGBA555, V4L2_PIX_FMT_RGBX555,
Hi,
Le dimanche 21 avril 2019 à 01:40 +0300, Laurent Pinchart a écrit :
> Hi Paul,
>
> On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > And a
Hi,
Le mardi 23 avril 2019 à 18:45 +0300, Laurent Pinchart a écrit :
> Hi Daniel,
>
> On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> > > >
On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
>
> Signed-off-by: Lucas Stach
> ---
>
Hi,
Le mardi 23 avril 2019 à 17:02 +0100, Daniel Stone a écrit :
> Hi Laurent,
>
> On Tue, 23 Apr 2019 at 16:54, Laurent Pinchart
> wrote:
> > On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> > > On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> > > Totally. Let's take
On Tue, 23 Apr 2019 at 15:06, Gerd Hoffmann wrote:
>
> On Tue, Apr 23, 2019 at 12:55:07PM +0100, Emil Velikov wrote:
> > On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > The DRI3 code extensively uses prime_handle_to_fd and
> > > > > prime_fd_to_handle for
Hi Laurent,
On Tue, 23 Apr 2019 at 16:54, Laurent Pinchart
wrote:
> On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> > On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> > Totally. Let's take DRM_FORMAT_XRGB + I915_FORMAT_MOD_Y_TILED as
> > an example. [... details ...]
>
>
No, i mean the actual HW fence which signals when the job finished execution on
the HW.
Andrey
On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the
reason of hw reset?
Original Message
Subject: Re:
Hi Daniel,
On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > - drm fourcc code doesn't actually define the drm_format_info
> > uniquely, drivers
Hi Daniel,
On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> >> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> >>> On Thu, Apr 18, 2019 at
do you mean fence timer? why not stop it as well when stopping sched for the
reason of hw reset?
Original Message
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)"
On 4/22/19 8:59 AM, Zhou, David(ChunMing) wrote:
> +Monk to response this patch.
>
>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> For later driver's reference to see if the fence is signaled.
>>
>> v2: Move parent fence put to resubmit jobs.
>>
>> Signed-off-by: Andrey Grodzovsky
>>
On Tue, Apr 23, 2019 at 4:28 PM Nicolas Dufresne wrote:
>
> Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote:
> > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote:
> > > > Hi Paul,
> > > >
>
>3. If we have a ticket we grab a reference to the first BO on the LRU, drop
>the LRU lock and try to grab the reservation lock with the ticket.
The BO on LRU is already locked by cs user, can it be dropped here by DC user?
and then DC user grab its lock with ticket, how does CS grab it again?
On 4/23/19 10:44 AM, Zhou, David(ChunMing) wrote:
This patch is to fix deadlock between fence->lock and sched->job_list_lock,
right?
So I suggest to just move list_del_init(_job->node) from
drm_sched_process_job to work thread. That will avoid deadlock described in the
link.
Do you mean
Den 23.04.2019 16.17, skrev Thomas Zimmermann:
> Hi
>
> Am 07.04.19 um 18:52 schrieb Noralf Trønnes:
>> It is generic code and having it in the helper will let other drivers
>> benefit from it.
>>
>> One change was necessary assuming this to be true:
>> INTEL_INFO(dev_priv)->num_pipes ==
Hi Andrey,
On Tue, Apr 23, 2019 at 11:19:17AM +0300, Andrey Gusakov wrote:
> On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> >> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> >> the ANSI 8B10B
Hi,
On Tue, 2019-04-23 at 10:28 -0400, Nicolas Dufresne wrote:
> Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote:
> > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote:
> > > > Hi Paul,
> >
On Mon, Apr 22, 2019 at 07:56:26PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST, make the IDR
> non-cyclic. That way, hotplug cycling MST devices won't needlessly
> increment the minor version index.
>
> Signed-off-by: Leo Li
I don't
Non-atomic drivers like ast doesn't have connector->state set resulting
in a NULL pointer deref:
[ 29.609593] BUG: unable to handle kernel NULL pointer dereference at
0010
[ 29.609619] Call Trace:
[ 29.609630] ? drm_helper_probe_single_connector_modes+0x27f/0x680
[
On Mon, Apr 22, 2019 at 07:56:27PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> To give identifiable attributes to MST DP aux devices, we can use the
> MST relative address. Expose this function for later use.
>
> Signed-off-by: Leo Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4
On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David
It's possible that the job does
Am 23.04.19 um 16:12 schrieb Grodzovsky, Andrey:
On 4/23/19 8:32 AM, Koenig, Christian wrote:
Well you at least have to give me time till after the holidays to get
going again :)
Not sure exactly jet why we need patch number 5.
Probably you missed the mail where I pointed out a bug I found
Hi Jacopo,
On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart wrote:
> > Add support for the V4L2_PIX_FMT_RGBA555, V4L2_PIX_FMT_RGBX555,
> > V4L2_PIX_FMT_ABGR555, V4L2_PIX_FMT_XBGR555, V4L2_PIX_FMT_BGRA555 and
> >
This patch is to fix deadlock between fence->lock and sched->job_list_lock,
right?
So I suggest to just move list_del_init(_job->node) from
drm_sched_process_job to work thread. That will avoid deadlock described in the
link.
Original Message
Subject: Re: [PATCH v5 3/6]
Well that's not so easy of hand.
The basic problem here is that when you busy wait at this place you can
easily run into situations where application A busy waits for B while B
busy waits for A -> deadlock.
So what we need here is the deadlock detection logic of the ww_mutex. To
use this we
Since the OOM interrupt directly deals with the binner bo, it doesn't
make sense to try and handle it without a binner buffer registered.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c
1 - 100 of 198 matches
Mail list logo
