Am 14.04.21 um 08:46 schrieb Felix Kuehling:
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. S
Hi
Am 07.04.21 um 21:49 schrieb Felix Kuehling:
On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They
don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ g
On Tue, 13 Apr 2021 16:11:29 +0200
Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some drive
On Wed, 14 Apr 2021 at 08:13, Neil Armstrong wrote:
>
> Hi Rob,
>
> Le 13/04/2021 à 22:21, Robert Foss a écrit :
> > Hey Neil & Phong,
> >
> > Thanks for submitting this series!
> >
> >> +
> >> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> >> + .attach = it66121_bridge_att
On 14/04/2021 10:06, Robert Foss wrote:
> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong wrote:
>>
>> Hi Rob,
>>
>> Le 13/04/2021 à 22:21, Robert Foss a écrit :
>>> Hey Neil & Phong,
>>>
>>> Thanks for submitting this series!
>>>
+
+static const struct drm_bridge_funcs it66121_bridge_funcs
On 13/04/2021 18:03, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote:
>> From: Phong LE
>>
>> Add the ITE bridge HDMI it66121 bindings.
>>
>> Signed-off-by: Phong LE
>> Signed-off-by: Neil Armstrong
>> ---
>> .
Le mer. 14 avril 2021 à 8:17, Neil Armstrong
a écrit :
Hi,
Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
Hi Neil,
I get build failures locally:
drivers/gpu/drm/bridge/ite-it66121.c: In function
‘it66121_hw_reset’:
drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit
declarat
Hi Neil,
On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
> On 14/04/2021 10:06, Robert Foss wrote:
> > On Wed, 14 Apr 2021 at 08:13, Neil Armstrong
> > wrote:
> >> Le 13/04/2021 à 22:21, Robert Foss a écrit :
> >>> Hey Neil & Phong,
> >>>
> >>> Thanks for submitting this series!
Am 2021-04-14 um 3:44 a.m. schrieb Thomas Zimmermann:
> Hi
>
> Am 07.04.21 um 21:49 schrieb Felix Kuehling:
>> On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
>>> On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They
> don't have a G
On 2021.04.13 14:18:48 +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
>
> drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function
> 'ppgtt_set_guest_root_entry' [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/i915
On 12/04/2021 17:29, Jassi Brar wrote:
> On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu
> wrote:
>>
>> This series base linux 5.12-rc2
>> these patches will cause home ui flick when cursor moved,
>> there is no fix solution yet, revert these patches first.
>>
>> change since v1:
>> add mtk-gce.t
On Tue, Apr 13, 2021 at 11:49:02AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatical
On Tue, Apr 13, 2021 at 11:49:03AM +0200, Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also m
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none
On Wed, Apr 14, 2021 at 10:24:22AM +0800, Liu Ying wrote:
> Hi Daniel,
>
> On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > > > Am Dienstag, dem 13.04.2
On Wed, Apr 14, 2021 at 02:46:20AM -0400, Felix Kuehling wrote:
> Pages in SG BOs were not allocated by TTM. So don't count them against
> TTM's pages limit.
>
> Signed-off-by: Felix Kuehling
This sounds like papering over the lack of shrinker in ttm. Do we
guarantee that someone else has alread
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > Pages in SG BOs were not allocated by TTM. So don't count them against
> > TTM's pages limit.
> >
> > Signed-off-by: Felix Kuehling
>
> Reviewed-by: Christian König
>
> Going to
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Chris
On Wed, Apr 14, 2021 at 06:36:55AM +, Zhang, Tina wrote:
> Hi Gerd,
>
> Speaking of the modifier, we notice that the virtio-gpu driver's
> mode_config.allow_fb_modifiers = false, which means virtio-gpu doesn't
> support modifier. With mode_config.allow_fb_modifiers=false, the DRM
> Modifier AP
On Tue, Apr 13, 2021 at 04:50:08AM -0300, Melissa Wen wrote:
> By using drmm_universal_plane_alloc instead of
> drm_universal_plane_init, we let the DRM infrastructure handles
> resource allocation and cleanup. We can also get rid of some
> code repetitions for plane cleanup, improving code maintai
On Tue, Apr 13, 2021 at 04:53:43AM -0300, Melissa Wen wrote:
> Generalize variables and function names used for planes composition
> (from cursor to plane), since we will reuse the operations for both
> cursor and overlay types.
>
> No functional change.
>
> Signed-off-by: Melissa Wen
Reviewed-
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
>
> The alignment is a constant property and shouldn't change.
>
> Signed-off-by: Christian König
What is page alignment here? Is it just for HW restrictions, say if it
requires 64K pages with the same physical alignment for VRAM or
something?
On Tue, Apr 13, 2021 at 04:54:52AM -0300, Melissa Wen wrote:
> Add support for composing XRGB888 planes in addition to the
> ARGB format. In the case of an XRGB plane at the top, the
> composition consists of just copying the RGB values of a
> pixel from src to dst, without the need for alpha b
Am 14.04.21 um 11:46 schrieb Matthew Auld:
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
The alignment is a constant property and shouldn't change.
Signed-off-by: Christian König
What is page alignment here? Is it just for HW restrictions, say if it
requires 64K pages with the same ph
On Tue, Apr 13, 2021 at 04:56:02AM -0300, Melissa Wen wrote:
> Add support to overlay plane, in addition to primary and cursor
> planes. In this approach, the plane composition still requires an
> active primary plane and planes are composed associatively in the
> order: (primary <- overlay) <- cur
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
>
> Add a separate manager for the system domain and make function tables
> mandatory.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/Makefile | 2 +-
> drivers/gpu/drm/ttm/ttm_device.c | 17 +-
> drivers
On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
>
> Signed-of
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> > > Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > > > Pages in SG BOs were not allocated by TTM. So don't count th
Am 14.04.21 um 12:05 schrieb Matthew Auld:
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
Add a separate manager for the system domain and make function tables
mandatory.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_devic
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not alloc
On Wed, 14 Apr 2021 11:08:15 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
>
> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> >> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> >>>
Am 14.04.21 um 14:25 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +020
On Wed, Apr 14, 2021 at 2:43 PM Christian König
wrote:
>
> Am 14.04.21 um 14:25 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 12:49 PM Christian König
> > wrote:
> >> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> Am
Am 14.04.21 um 14:47 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 2:43 PM Christian König
wrote:
Am 14.04.21 um 14:25 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christ
Hi Thomas,
On Mon, Apr 12, 2021 at 11:44:05AM +0200, Thomas Zimmermann wrote:
>
>
> Am 17.03.21 um 16:43 schrieb Maxime Ripard:
> > We're going to need to tell whether we want to run with a full or
> > limited range RGB output in multiple places in the code, so let's create
> > a helper that wil
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrice
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Signed-off-by: Maxime Ripard
---
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
In order to support a YUV output, we're going to need to have access to
the bridge state in the vc4_hdmi_set_avi_infoframe function. Since we
also need the connector state in that function, let's pass the full
atomic state.
While we're at it, since a
On Wed, 14 Apr 2021 at 10:57, Christian König
wrote:
>
> Am 14.04.21 um 11:46 schrieb Matthew Auld:
> > On Tue, 13 Apr 2021 at 14:53, Christian König
> > wrote:
> >> The alignment is a constant property and shouldn't change.
> >>
> >> Signed-off-by: Christian König
> > What is page alignment her
Am 2021-04-14 um 8:25 a.m. schrieb Daniel Vetter:
>> Sorry I though that this would be obvious :)
>>
>> I've already pushed the patch in the morning, but going to keep that in
>> mind for the next time.
> I'll keep reminding you to pls elaborate more in commit messages, it's
> coming up every once
On Wed, Apr 14, 2021 at 3:51 AM Matthias Brugger wrote:
>
>
>
> On 12/04/2021 17:29, Jassi Brar wrote:
> > On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu
> > wrote:
> >>
> >> This series base linux 5.12-rc2
> >> these patches will cause home ui flick when cursor moved,
> >> there is no fix solutio
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #12 from Alexander von Gluck (kallis...@unixzen.com) ---
A new motherboard later.. and after enabling 64-bit PCIe stuff the card posts.
ArchLinux 5.11.13
[4.689213] nouveau :0d:00.0: enabling device ( -> 0002)
[4.689
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only set
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #13 from Ilia Mirkin (imir...@alum.mit.edu) ---
See comment #3 - it explains what you need to copy in nouveau to try to load
it.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching
On 12/04/2021 10:05, Matthew Auld wrote:
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Since stolen can now be device local-memory underneath, we should try to
enforce any min_page_size restrictions when allocating pages.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 in
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #14 from Ilia Mirkin (imir...@alum.mit.edu) ---
Also, wow, BAR1 = 16GB?? Normally it's like 256MB. No wonder your TB setup had
issues.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are wat
Hi All,
Here is the privacy-screen related code which I last posted in August
of last year. To the best of my knowledge there is consensus about /
everyone is in agreement with the new userspace API (2 connector properties)
this patch-set add (patch 1 of the series).
The blocker the last time was
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the dr
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
lo
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans d
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
include/drm/drm_privacy_screen_consume
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Sign
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(&state->base, connector, ...
drm_connector_update
Am 2021-04-14 um 3:33 a.m. schrieb Christian König:
> Am 14.04.21 um 08:46 schrieb Felix Kuehling:
>> amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The
>> dmabuf->resv
>> must not be held by the caller or dma_buf_detach will deadlock. This is
>> probably not the right fix. I get a recur
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Reviewed-by: Philip Yang
On 12/04/2021 10:05, Matthew Auld wrote:
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
-
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Ve
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #15 from Alexander von Gluck (kallis...@unixzen.com) ---
Applied my patch above to ArchLinux (5.11.13-arch1-1) and gave it a whirl. Got
a little information from nouveou before the system hard locks up.
nouveau :0d:00.0: enabling
On 14/04/2021 10:16, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
>> On 14/04/2021 10:06, Robert Foss wrote:
>>> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong
>>> wrote:
Le 13/04/2021 à 22:21, Robert Foss a écrit :
> Hey Neil & Ph
On 12/04/2021 10:05, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +--
driv
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
After reading drm vma manager, I understand it uses rbtree
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
This shortcut is no longer needed with access managed progerly by KFD.
Reviewed-by: Philip Yang
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 fi
Am 2021-04-14 um 11:37 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> DRM allows access automatically when it creates a GEM handle for a BO.
>> KFD BOs don't have GEM handles, so KFD needs to manage access manually.
>
> After reading drm vma manager, I understand
Am 2021-04-14 um 11:21 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
>> to access the BO through the corresponding file descriptor.
>>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gp
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
>
>
> On 12/04/2021 10:05, Matthew Auld wrote:
> > From: Venkata Sandeep Dhanalakota
> >
> > Determine the possible coherent map type based on object location,
> > and if target has llc or if user requires an always coherent
> > mapping.
> >
> >
On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote:
> As pointed out by the documentation for drm_dp_aux_register(),
> drm_dp_aux_init() should be used in situations where the AUX channel for a
> display driver can potentially be registered before it's respective DRM
> driver. This is the c
Hi Neil,
Le mer. 14 avril 2021 à 8:17, Neil Armstrong
a écrit :
Hi,
Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
Hi Neil,
I get build failures locally:
drivers/gpu/drm/bridge/ite-it66121.c: In function
‘it66121_hw_reset’:
drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit
On 2021-04-13 20:17, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-13 16:11:30)
At dongle unplug, dp initializes audio_comp followed by sending
disconnect
event notification to audio and to make sure audio had shutdown
completely
by wait for audio completion notification at display_disable(
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (57):
staging: r8192U_core: Remove two unused variables 'ret' and
'reset_status'
staging: android: ashmem: Supply description for
Fixes the following W=1 kernel build warning(s):
drivers/staging/fbtft/fb_ili9320.c: In function ‘read_devicecode’:
drivers/staging/fbtft/fb_ili9320.c:25:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Cc: Greg Kroah-Hartman
Cc: dri-devel@lists.freedesktop.org
Cc: linu
On Tue, 6 Apr 2021 16:40:23 -0300
Jason Gunthorpe wrote:
> vfio_mdev has a number of different objects: mdev_parent, mdev_type and
> mdev_device.
>
> Unfortunately the types of these have been erased in various places
> throughout the API, and this makes it very hard to understand this code or
On Wed, 2021-04-14 at 18:49 +0200, Thierry Reding wrote:
> On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote:
> > As pointed out by the documentation for drm_dp_aux_register(),
> > drm_dp_aux_init() should be used in situations where the AUX channel for a
> > display driver can potentially
+mesa-dev and some Intel mesa people.
On Wed, Apr 14, 2021 at 5:23 AM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for mm
Add panel backlight control using DPCD registers on the DisplayPort aux
channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/Kconfig| 8 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_aux_backlight.c | 191 +
inclu
Add support to control the backlight of the eDP panel connected to
the ti-sn65dsi86 bridge through aux channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 ++
2 files changed, 27 insertions(+)
The backlight level of an eDP panel can be controlled through the AUX
channel using DPCD registers of the panel.
The capability for the Source device to adjust backlight characteristics
within the panel, using the Sink device DPCD registers is indicated by
the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit
If the panel connected to the bridge supports backlight control
using DPCD registers on the DisplayPort aux channel, setting
"use-aux-backlight" property in the bridge node will enable the
registration of a DP aux backlight device from the bridge driver.
Signed-off-by: Rajeev Nandan
---
.../devi
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase t
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_start_audio()
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 1 +
drive
Quoting Kuogee Hsieh (2021-04-13 16:11:44)
> Make sure main link is in connection state before start aux
> read/write operation to avoid unnecessary long delay due to
> main link had been unplugged.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> drivers/gp
Quoting Kuogee Hsieh (2021-04-14 14:02:34)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the dongl
Quoting Kuogee Hsieh (2021-04-14 14:02:50)
> Initialize audio_comp when audio starts and wait for audio_comp at
> dp_display_disable(). This will take care of both dongle unplugged
> and display off (suspend) cases.
>
> Changes in v2:
> -- add dp_display_start_audio()
>
> Signed-off-by: Kuogee Hs
This series adds support to use devcoredump for DPU driver. It introduces
the msm_disp_snapshot module which assists in the capturing of register dumps
during
error scenarios. When a display related error happens, the msm_disp_snapshot
module
captures all the relevant register dumps along with th
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Rename the drm_atomic_print_state() to drm_atomic_print_new_state()
so that it reflects its functionality bett
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a list of blocks to store the hardware block infor
Add snapshot points across dpu driver to trigger dumps when critical
errors are hit.
changes in v4:
- change the callers to use the new snapshot macro
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +++---
drivers/gpu/drm/msm/disp/dpu1/dp
On Mon, Apr 12, 2021 at 10:36 PM Vivek Kasireddy
wrote:
> If support for Blob resources is available, then dumb BOs created
> by the driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update
> as the device may have created a shared mapping. (
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a li
Hi Andrzej,
On Tue, Apr 06, 2021 at 06:52:07PM +0200, Andrzej Hajda wrote:
> Hello again after easter,
>
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have, how it is enabled/power controlled.
>
> W dniu
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> Unpreparing and re-preparing a panel can be a really heavy
> operation. Panels datasheets often specify something on the order of
> 500ms as the delay you should insert after turning off the pane
Hi Dmitry
Thanks for the review.
On 2021-04-14 17:16, Dmitry Baryshkov wrote:
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
-
Hi,
On Tue, Apr 6, 2021 at 9:52 AM Andrzej Hajda wrote:
>
> Hello again after easter,
Sorry, I was out last week and I'm just getting back to this now.
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have,
1 - 100 of 148 matches
Mail list logo
