On 2019/10/4 上午4:18, Davidlohr Bueso wrote:
The vhost_umem interval tree really wants [a, b) intervals,
not fully closed as currently. As such convert it to use the
new interval_tree_gen.h, and also rename the 'last' endpoint
in the node to 'end', which both a more suitable name for
the half
https://bugs.freedesktop.org/show_bug.cgi?id=111506
--- Comment #2 from Andrew Sheldon ---
Looks to be fixed by commit 109b3e3e13507ad0908ff00bc7eb759ed41b88be
drm/amd/display: Improve LFC behaviour
It now smoothly transitions between LFC and VRR without flickering.
--
You are receiving this
On 2019/10/1 上午5:36, Alex Williamson wrote:
On Fri, 27 Sep 2019 16:25:13 +
Parav Pandit wrote:
Hi Alex,
-Original Message-
From: Alex Williamson
Sent: Tuesday, September 24, 2019 6:07 PM
To: Jason Wang
Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
Hi Dave, Daniel,
New stuff for 5.5. There's an export of a cgroup function that
Tejun acked for merging through the drm tree. kfd uses it to handle
permissions in containers since there is only one /dev/kfd.
The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed:
Merge
Some VOP's (such as px30) dclk_pol bit is at the last.
So it is necessary to distinguish dclk_pol and pin_pol.
Signed-off-by: Nickey Yang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 12 +++---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 8 +++-
Nickey Yang (1):
drm/rockchip: vop: add the definition of dclk_pol
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 12 +++---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 8 +++-
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 45 ++---
3 files changed, 43 insertions(+), 22
Hi Laurent Pinchart, thanks for your comments.
On Wed, Oct 09, 2019 at 03:10:03PM +0300, Laurent Pinchart wrote:
> Hi Xin Ji,
>
> Thank you for the patch.
>
> On Wed, Oct 09, 2019 at 09:27:07AM +, Xin Ji wrote:
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for
Hi Dan Carpenter, sorry for that, I send the wrong patch, I didn't
correctly merge the changed code. Will send the new patch based on your
new comments.
Thanks,
Xin
On Wed, Oct 09, 2019 at 02:30:32PM +0300, Dan Carpenter wrote:
> Are you sure you sent the correct patch? This has many of the
Hi Dave, Daniel,
Just a single fix this week for 5.4.
The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.4-2019-10-09
for
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release"
passed 3 arguments, but takes just 2
183 |
On Wed, Oct 9, 2019 at 10:57 PM Daniel Vetter wrote:
>
> On Fri, Sep 27, 2019 at 08:09:52AM +0800, Qiang Yu wrote:
> > On Thu, Sep 26, 2019 at 11:01 PM Rob Herring wrote:
> > >
> > > On Thu, Sep 26, 2019 at 9:12 AM Qiang Yu wrote:
> > > >
> > > > Do not use user space bo handles directly and
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
between commit:
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
from the drm tree and commit:
5facae4f3549 ("locking/lockdep: Remove unused @nested argument
Hello Sean,
Thanks for the thourough review.
On Wed, 9 Oct 2019 at 15:01, Sean Paul wrote:
>
> On Tue, Oct 08, 2019 at 08:00:37PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> >
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/gpu/drm/i915/i915_vma.h:35,
from drivers/gpu/drm/i915/gt/uc/intel_guc.h:17,
from drivers/gpu/drm/i915/gt/uc/intel_uc.h:9,
On Tue, Oct 01, 2019 at 06:39:22PM -0500, Adam Ford wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Logic PD Type 28 display.
>
> Signed-off-by: Adam Ford
> ---
> V4: Update per Rob H's suggestions and copy other panel yaml example from
> 5.4-rc1
> V3:
On Tue, 2019-10-08 at 21:26 +, Mikita Lipski wrote:
>
> On 08.10.2019 12:24, Lyude Paul wrote:
> > ...
> > yikes
> > I need to apologize because I was going through my email and I realized
> > you
> > _did_ respond to me earlier regarding some of these questions, it just
> > appears
> > the
oh, completely forgot about this one
Reviewed-by: Lyude Paul
On Thu, 2019-10-10 at 00:41 +0200, Daniel Vetter wrote:
> Private atomic objects have grown their own locking with
>
> commit b962a12050a387e4bbf3a48745afe1d29d396b0d
> Author: Rob Clark
> Date: Mon Oct 22 14:31:22 2018 +0200
>
>
On Wed, Oct 09, 2019 at 03:10:49PM +, Simon Ser wrote:
> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
>
> The unspoken, legacy rule used in the past was to make user-space figure
> out
Private atomic objects have grown their own locking with
commit b962a12050a387e4bbf3a48745afe1d29d396b0d
Author: Rob Clark
Date: Mon Oct 22 14:31:22 2018 +0200
drm/atomic: integrate modeset lock with private objects
which means we're no longer relying on connection_mutex for mst state
On Fri, Nov 16, 2018 at 7:44 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Add modeset lock checks to functions that could be called outside the
> core atomic stack.
>
> Changes in v2:
> - None
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++
>
Hi Zhengbin,
Thank you for the patch.
On Tue, Oct 08, 2019 at 03:15:49PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c: In function hdmi4_audio_config:
> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c:689:6: warning: variable err
Hi Zhengbin,
Thank you for the patch.
On Tue, Oct 08, 2019 at 03:15:48PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/omapdrm/dss/hdmi5_core.c: In function hdmi5_audio_config:
> drivers/gpu/drm/omapdrm/dss/hdmi5_core.c:812:6: warning: variable err
Hi Zhengbin,
Thank you for the patch.
On Tue, Oct 08, 2019 at 03:15:47PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/omapdrm/dss/dsi.c: In function dsi_proto_timings:
> drivers/gpu/drm/omapdrm/dss/dsi.c:3562:46: warning: variable tclk_trail set
>
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP. This is because the reset
logic is not correct per the hardware documentation.
The documentation states that after asserting reset, software should wait
some time (no
Hi Zhengbin,
Thank you for the patch.
On Tue, Oct 08, 2019 at 03:15:46PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/omapdrm/omap_fb.c: In function
> omap_framebuffer_update_scanout:
> drivers/gpu/drm/omapdrm/omap_fb.c:130:16: warning: variable
On Wed, Oct 09, 2019 at 05:01:20PM -0400, Daniele Castagna wrote:
> On Wed, Oct 9, 2019 at 1:34 PM Matt Roper wrote:
> >
> > The previous version of this series was posted in February here:
> >
> > https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html
> >
> > Right
On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
wrote:
>
> I misunderstood and was talking about the ksv validation specifically
> (usage of drm_hdcp_check_ksvs_revoked()).
Hm for that specifically I think you want to do both, i.e. both
consult your psp, but also check for revoked ksvs with
I misunderstood and was talking about the ksv validation specifically
(usage of drm_hdcp_check_ksvs_revoked()).
For the defines I will create patches to use drm_hdcp where it is usable.
Bhawan
On 2019-10-09 2:43 p.m., Daniel Vetter wrote:
> On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
>
https://bugs.freedesktop.org/show_bug.cgi?id=111948
Bug ID: 111948
Summary: [Vega10][bisected] Vega56 VM_L2_PROTECTION_FAULT when
logging into KDE with kernel 5.3.0-rc1 and newer
Product: DRI
Version: DRI git
Hardware:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: f083b6658742d4d00d585fa5d608a5f56ebcaa32
commit: ad1afcdf30608bd5148c54893257cc2ef1655c4b [2128/3930] drm/amd/autoconf:
generate config.h for in-tree build
config: x86_64-randconfig-a001-201940 (attached as
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: f083b6658742d4d00d585fa5d608a5f56ebcaa32
commit: 10cd967026a0af92aaa97858d0e1826c13f8e9a5 [3861/3930] drm/amdgpu: fix
documentation for amdgpu_gem_prime_export
reproduce: make htmldocs
If you fix the issue,
On Thu, Oct 03, 2019 at 11:47:30AM -0700, Douglas Anderson wrote:
> I'm embarassed to say that even though I've touched
> vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
> stupid glaring bug in it. Specifically, on veyron_minnie (with all
> the latest display timings) we want
On Wed, Oct 09, 2019 at 06:13:13PM +0200, Daniel Vetter wrote:
> On Mon, Oct 07, 2019 at 11:19:01AM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following warning:
> > ../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments
> > found
> >
> > Fixes:
Hey! Re: our discussion about this at XDC, I think I'm going to drop this
patch and just fix KASAN so it prints the hashed pointer as well, I'll cc you
on the patches for that as well
On Fri, 2019-09-27 at 10:25 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyude Paul wrote:
On Wed, Oct 09, 2019 at 10:51:26AM +0200, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Jean-Jacques Hiblot
>
> ---
>
> .../leds/backlight/led-backlight.yaml | 55 +++
> 1 file changed, 55
On Wed, Oct 09, 2019 at 10:51:25AM +0200, Jean-Jacques Hiblot wrote:
> LED properties must be named "leds" in the same way that PWM, clocks or
> PHY properties are names respectively "pwms", "clocks" and "phys".
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Jean-Jacques Hiblot
> ---
>
Hi Tomi
On Thu, Oct 03, 2019 at 08:56:15AM +0300, Tomi Valkeinen wrote:
> Hi Sam,
>
> On 20/08/2019 13:37, Sam Ravnborg wrote:
>
> > > @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct
> > > drm_bridge *bridge)
> > > drm_panel_unprepare(panel_bridge->panel);
> > > }
https://bugs.freedesktop.org/show_bug.cgi?id=111555
--- Comment #7 from Tako Marks ---
I ran into this issue when messing around with my BIOS settings. Not sure if
helpful but when I had the option Decode Above 4G (64bit adressing on PCI bus?)
on my Gigabyte Aorus B450 I experienced the same
On Wed, Oct 9, 2019 at 8:52 PM Greathouse, Joseph
wrote:
>
> > From: Daniel Vetter On Behalf Of Daniel Vetter
> > Sent: Wednesday, October 9, 2019 11:07 AM
> > On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > > On Wed, Oct 09,
On Fri, 2019-09-27 at 09:52 -0400, Sean Paul wrote:
> 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
> From: Daniel Vetter On Behalf Of Daniel Vetter
> Sent: Wednesday, October 9, 2019 11:07 AM
> On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> > >> On 2019-10-09
On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
wrote:
>
> Hi,
>
> The reason we don't use drm_hdcp is because our policy is to do hdcp
> verification using PSP/HW (onboard secure processor).
i915 also uses hw to auth, we still use the parts from drm_hdcp ...
Did you actually look at what's in
On Fri, Oct 4, 2019 at 9:44 AM Steven Price wrote:
>
> devm_regulator_get() is used to populate pfdev->regulator which ensures
> that this cannot be NULL (a dummy regulator will be returned if
> necessary). So remove the check in panfrost_devfreq_target().
>
> Signed-off-by: Steven Price
> ---
>
On Wed, Oct 9, 2019 at 4:45 AM Steven Price wrote:
>
> Panfrost uses multiple schedulers (one for each slot, so 2 in reality),
> and on a timeout has to stop all the schedulers to safely perform a
> reset. However more than one scheduler can trigger a timeout at the same
> time. This race
https://bugs.freedesktop.org/show_bug.cgi?id=111913
--- Comment #10 from Stefan Rehm ---
Correction: the exact frequency reported by xrandr is 59.95
I took Andrew Sheldon`s advice and experimented a bit with refresh rates and
resolutions. Turns out, that the problem does not occur in lower
On 10/8/19 10:00 PM, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 12:17 PM Jacek Anaszewski
> wrote:
>>
>> On 10/8/19 5:00 PM, Rob Herring wrote:
>>> On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
Rob,
On 08/10/2019 14:51, Jean-Jacques Hiblot wrote:
> Hi Rob,
On 10/9/19 1:37 PM, Ayan Halder wrote:
> On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
>> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
>>> Hello Christoph, everyone,
>>>
>>> On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
Here is yet another pass at the
Hi,
The reason we don't use drm_hdcp is because our policy is to do hdcp
verification using PSP/HW (onboard secure processor).
Bhawan
On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
>> Hi,
>>
>> Static analysis with Coverity has
https://bugzilla.kernel.org/show_bug.cgi?id=205147
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Jani Nikula
>Sent: Wednesday, October 9, 2019 11:38 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Nikula, Jani ; Sam Ravnborg
>Subject: [Intel-gfx] [PATCH
https://bugzilla.kernel.org/show_bug.cgi?id=205147
Bug ID: 205147
Summary: Unable to shut down - radeon_drv.c -
radeon_suspend_kms()
Product: Drivers
Version: 2.5
Kernel Version: 5.3.5
Hardware: x86-64
On Tue, Oct 08, 2019 at 08:00:37PM -0300, Ezequiel Garcia wrote:
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some
On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> > Hello Christoph, everyone,
> >
> > On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
> > >
> > > Here is yet another pass at the dma-buf heaps patchset Andrew
> > > and
From: "Lowry Li (Arm Technology China)"
[ Upstream commit 8581d51055a08cc6eb061c8856062290e8582ce4 ]
Adds the check if the writeback_job with an empty fb, then it should
be freed in atomic_check phase.
With this change, the driver users will not check empty fb case any more.
So refined
From: "Lowry Li (Arm Technology China)"
[ Upstream commit b1066a123538044117f0a78ba8c6a50cf5a04c86 ]
During it signals the completion of a writeback job, after releasing
the out_fence, we'd clear the pointer.
Check if fence left over in drm_writeback_cleanup_job(), release it.
Signed-off-by:
On Wed, Oct 09, 2019 at 08:39:26AM -0700, Stephen Boyd wrote:
> Quoting Brian Masney (2019-10-08 23:05:20)
> > On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > > Quoting Brian Masney (2019-10-06 18:45:08)
> > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > >
On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> Hi,
>
> Static analysis with Coverity has detected a potential issue with
> function validate_bksv in
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> commit:
>
> commit
On Wed, Oct 09, 2019 at 11:05:31AM -0500, Rob Herring wrote:
> On Wed, Oct 9, 2019 at 10:07 AM Daniel Vetter wrote:
> >
> > On Fri, Sep 27, 2019 at 09:46:11PM +0800, Qiang Yu wrote:
> > > drm_gem_objects_lookup does not use user space bo handles
> > > directly and left the user to kernel copy
Applied. thanks!
Alex
On Tue, Oct 8, 2019 at 8:36 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.c:25:
>
On Tue, Oct 08, 2019 at 06:51:54PM +0200, Sam Ravnborg wrote:
> On Mon, Oct 07, 2019 at 07:12:22PM +0200, Sam Ravnborg wrote:
> > One user of drmP.h sneaked in after the merge window.
> > Drop the use of drmP.h and delete the header file for good.
> >
> > Small band-aid on top of not going to xdc
On Mon, Oct 07, 2019 at 11:19:01AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Fixes the following warning:
> ../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments
> found
>
> Fixes: 9ef8a9dc4b21 ("drm: Extract drm_atomic_state_helper.[hc]")
> Cc: Ville Syrjälä
> Cc:
On Fri, Oct 04, 2019 at 03:25:00PM +0300, Lionel Landwerlin wrote:
> On 04/10/2019 15:16, Zbigniew Kempczyński wrote:
> > Remove dead code, likely overseened during review process.
> >
> > Signed-off-by: Zbigniew Kempczyński
> > Cc: Chunming Zhou
> > Cc: Daniel Vetter
> > Cc: Jason Ekstrand
>
On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> On 2019-10-09 11:34, Daniel Vetter wrote:
> > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> >> On 2019-10-09 6:31, Daniel Vetter wrote:
> >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
>
On Wed, Oct 9, 2019 at 10:07 AM Daniel Vetter wrote:
>
> On Fri, Sep 27, 2019 at 09:46:11PM +0800, 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
On Fri, Oct 04, 2019 at 01:01:36PM +0100, Tvrtko Ursulin wrote:
>
> On 04/10/2019 12:17, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-10-04 12:07:10)
> > > Quoting Tvrtko Ursulin (2019-10-04 10:15:20)
> > > >
> > > > On 03/10/2019 22:01, Chris Wilson wrote:
> > > > > A few callers need to
On 2019-10-09 11:34, Daniel Vetter wrote:
> On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
>> On 2019-10-09 6:31, Daniel Vetter wrote:
>>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
The description sounds reasonable to me and maps well to the CU masking
On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> From: Daniel Stone
>
> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> over addfb.
>
> Changes since v1:
> - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> - update ioctl number
>
>
On Thu, Oct 03, 2019 at 11:46:28AM -0700, Juston Li wrote:
> Depends on ummerged kernel code for getfb2
>
> Rest of drm.h taken from:
> commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
> Author: Linus Torvalds
> Date: Mon Sep 30 10:35:40 2019 -0700
>
> Linux 5.4-rc1
>
> Signed-off-by:
On Wed, Oct 09, 2019 at 12:46:07PM +0100, Ben Dooks wrote:
> The a5xx_show and a5xx_gpu_state_put objects are not exported
> outside of the file, so make them static to avoid the following
> warnings from sparse:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:1292:5: warning: symbol
>
On Tue, Oct 01, 2019 at 03:27:41PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 30, 2019 at 10:18:17PM -0400, Martin Peres wrote:
> > On 30/09/2019 19:13, Matt Roper wrote:
> > > CRTC background color kernel patches were written about 2.5 years ago
> > > and floated on the upstream mailing list, but
On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
> While working on TTM cleanups I've found that the io_reserve_lru used by
> Nouveau is actually not working at all.
>
> In general we should remove driver specific handling from the memory
> management, so this patch moves the
Quoting Brian Masney (2019-10-08 23:05:20)
> On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > Quoting Brian Masney (2019-10-06 18:45:08)
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > index 7fc23e422cc5..af02eace14e2
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
v2: move unlikely() to drm_debug_enabled()
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++--
Mostly for improved documentation, convert the debug category macros
into an enum. Drop unused DRM_UT_NONE. Document previously undocumented
categories.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_print.c | 4 +-
include/drm/drm_print.h | 101 ++--
2
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Acked-by: Alex Deucher
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c |
drm_debug_enabled() is the way to check. __drm_debug is now reserved for
drm print code only. No functional changes.
v2: Rebase on move unlikely() to drm_debug_enabled()
Acked-by: Alex Deucher
Reviewed-by: Eric Engestrom
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_print.c | 8
We don't want people calling the functions directly. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_print.c | 8
include/drm/drm_print.h | 22 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git
Add new struct drm_device based logging macros modeled after the core
kernel device based logging macros. These would be preferred over the
drm printk and struct device based macros in drm code, where possible.
We have existing drm specific struct device based logging functions, but
they are too
In preparation for adding struct drm_device based logging, group the
existing functions by prink or struct device based logging. No
functional changes.
Signed-off-by: Jani Nikula
---
include/drm/drm_print.h | 135 ++--
1 file changed, 74 insertions(+), 61
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Reviewed-by: Eric Engestrom
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c
For starters some fairly benign cleanup, and a proposal for new struct
drm_device based drm logging macros analoguous to core kernel struct
device based macros.
BR,
Jani.
Jani Nikula (8):
drm/i915: use drm_debug_enabled() to check for debug categories
drm/nouveau: use drm_debug_enabled() to
On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> On 2019-10-09 6:31, Daniel Vetter wrote:
> > On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> >>
> >> The description sounds reasonable to me and maps well to the CU masking
> >> feature in our GPUs.
> >>
> >> It
On 2019-10-09 6:31, Daniel Vetter wrote:
> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
>>
>> The description sounds reasonable to me and maps well to the CU masking
>> feature in our GPUs.
>>
>> It would also allow us to do more coarse-grained masking for example to
>>
On Sun, Sep 29, 2019 at 10:09:43PM +0900, Norbert Preining wrote:
> Dear all,
>
> (please Cc)
Adding intel-gfx.
-Daniel
>
> linux 5.3.1
> Debian/sid
> Lenovo X260
> [2.472152] i915 :00:02.0: vgaarb: deactivate vga console
> [2.473035] [drm] Supports vblank timestamp caching Rev 2
On Wed, Oct 09, 2019 at 11:08:45AM -0400, Kenny Ho wrote:
> Hi Daniel,
>
> Can you elaborate what you mean in more details? The goal of lgpu is
> to provide the ability to subdivide a GPU device and give those slices
> to different users as needed. I don't think there is anything
>
On Mon, Sep 30, 2019 at 07:56:13AM -0400, Ilia Mirkin wrote:
> On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey wrote:
> >
> > Hi James,
> >
> > On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
> > China) wrote:
> > > This function is used to convert drm_color_ctm S31.32
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
Hi Daniel,
Can you elaborate what you mean in more details? The goal of lgpu is
to provide the ability to subdivide a GPU device and give those slices
to different users as needed. I don't think there is anything
controversial or vendor specific here as requests for this are well
documented.
Hi Dave and Daniel,
Apologies for missing last week, but this was not something I wanted to do from
XDC :-)
Lots happening in this pull, the highlights are Thomas' work on gem vram
objects, Lyude starting to push the big MST series, Gerd's ttm and virtio
refactors, and komeda improvements.
One
On Fri, Sep 27, 2019 at 09:46:11PM +0800, 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
On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul 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
On Fri, Sep 27, 2019 at 08:09:52AM +0800, Qiang Yu wrote:
> On Thu, Sep 26, 2019 at 11:01 PM Rob Herring wrote:
> >
> > On Thu, Sep 26, 2019 at 9:12 AM Qiang Yu wrote:
> > >
> > > Do not use user space bo handles directly and left the user
> > > to kernel copy work to drivers calling this
https://bugs.freedesktop.org/show_bug.cgi?id=111921
--- Comment #10 from Rémi Verschelde ---
(In reply to Andrey Grodzovsky from comment #9)
>
> So i guess the problem only happens when you run in DRI PRIME mode when
> different apps render of off different GPUs ?
Probably, but that's the only
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> These new format is supported by some rockchip socs:
>
> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>
> Signed-off-by: Sandy Huang
> ---
>
On Thu, Sep 19, 2019 at 12:02:12PM +0200, Gerd Hoffmann wrote:
> Add mmap callback to struct drm_gem_object_funcs, which is supposed to
> handle the vma setup. It will be used by both normal fops->mmap (via
> drm_gem_mmap_obj()) and prime mmap (via drm_gem_prime_mmap()).
>
> For starters the
On Wed, Oct 09, 2019 at 03:21:06PM +0200, Christian König wrote:
> Am 08.10.19 um 17:16 schrieb Daniel Vetter:
> > On Wed, Sep 18, 2019 at 07:55:23PM +0200, Christian König wrote:
> > > The ww_mutex framework allows for detecting deadlocks when multiple
> > > threads try to acquire the same set of
https://bugs.freedesktop.org/show_bug.cgi?id=111921
--- Comment #9 from Andrey Grodzovsky ---
(In reply to Rémi Verschelde from comment #8)
> (In reply to Andrey Grodzovsky from comment #2)
> > Hey, I noticed a lot of 'amdgpu :01:00.0: GPU pci config reset' there.
>
> These actually happen
On Wed, Oct 09, 2019 at 03:10:09PM +0200, Christian König wrote:
> Am 08.10.19 um 11:25 schrieb Daniel Vetter:
> > On Thu, Aug 29, 2019 at 04:29:15PM +0200, Christian König wrote:
> > > This way we can even pipeline imported BO evictions.
> > >
> > > v2: Limit this to only cases when the parent
On Wed, Oct 09, 2019 at 02:48:20PM +0200, Noralf Trønnes wrote:
> Den 09.10.2019 12.45, skrev Daniel Vetter:
> > On Tue, Oct 01, 2019 at 04:07:38PM +0200, Noralf Trønnes wrote:
> >> Hi drm-misc maintainers,
> >>
> >> I have just applied a patch to drm-misc-next that as it turns out should
> >>
Include rockchip_drm_drv.h for definition of vop_platform_driver
to avoid the following sparse warning:
drivers/gpu/drm/rockchip/rockchip_vop_reg.c:982:24: warning: symbol
'vop_platform_driver' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Sandy Huang
Cc: "Heiko
1 - 100 of 177 matches
Mail list logo
