On Thu, 2 Nov 2023 at 09:32, Danilo Krummrich wrote:
>
> GPUVM provides common infrastructure to track external and evicted GEM
> objects as well as locking and validation helpers.
>
> Especially external and evicted object tracking is a huge improvement
> compared to the current brute force
On Thu, 2 Nov 2023 at 09:31, Danilo Krummrich wrote:
>
> Use drm_gpuvm_range_valid() in order to validate userspace requests.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
On Thu, 2 Nov 2023 at 09:31, Danilo Krummrich wrote:
>
> Allocate struct nouveau_uvmm separately in preparation for subsequent
> commits introducing reference counting for struct drm_gpuvm.
>
> While at it, get rid of nouveau_uvmm_init() as indirection of
> nouveau_uvmm_ioctl_vm_init() and
Drm lru manager provides generic functions to manage lru list,
and function to evict a lru entity. But how to evict an entity
is implemented in an entity's sub-class. This patch introduces
a few function pointers to drm lru entity for this purpose. Those
functions are abstracted from the current
Replace struct ttm_resource::lru with drm lru entity. Replace
struct ttm_resource_manager::lru[] with drm lru manager. Remove
ttm_lru_bulk_move functions and definitions as those are moved
to drm lru manager.
Some of ttm resource, ttm bo and ttm device functions are re-written
using drm lru
Implement ttm_mem_evict_valuable, ttm_mem_evict_entity and
ttm_mem_evict_busy_entity. Those are callback functions from
drm lru manager. Register those functions during drm lru entity
initialization. Those 3 functions are splitted from original
ttm_mem_evict_first function.
Reimplemented
Add a weak reference of lru manager to ttm resource manager,
and add a function to set lru manager for ttm resource manager.
Signed-off-by: Oak Zeng
---
include/drm/ttm/ttm_resource.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/drm/ttm/ttm_resource.h
Since TTM resource LRU list is moved to drm LRU manager layer,
use drm lru manager iterator instead of TTM resource manager
iterator. TTM resource manager iterator is deleted. No function
change.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ++--
TTM_MAX_BO_PRIORITY and TTM_NUM_MEM_TYPES are move from ttm to
drm, so:
s/TTM_MAX_BO_PRIORITY/DRM_MAX_LRU_PRIORITY
s/TTM_NUM_MEM_TYPES/DRM_NUM_MEM_TYPES
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
Initialize lru_mgr for each memory type or memory region. Also set
ttm_resource_manager's weak reference to drm lru manager.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 6 ++
Add a struct drm_device *drm parameter to function
ttm_range_man_init, ttm_range_man_fini, ttm_sys_man_init,
and ttm_sys_man_free. This drm parameter will be used
in the coming patches to retrieve and initialize drm
lru manager.
Signed-off-by: Oak Zeng
---
We plan to implement xe driver's shared virtual memory
manager (aka SVM) without buffer object concept. This
means we won't build our shared virtual memory manager
upon TTM infrastructure like amdgpu does.
Even though this approach is more efficient, it does
create a problem for memory eviction
In the coming patches, we will share the lru list b/t
ttm bo based memory allocator and hmm/svm based memory
allocator. Thus lru_lock (which is used mainly to protect
the lru list) is moved from struct ttm_device to struct
drm_device, so this lock can be shared b/t those two
memory allocators.
To
drm LRU manager is introuced for resource eviction purpose. It maintains
a LRU list per resource type. It provides functions to add or remove
resource to or from the list. It also provides function to retrieve the
first entity on the LRU list.
drm LRU manager also provides functions for bulk
Change the 3rd parameter of ttm_device_init from
struct device * to struct drm_device *. This is
a prepare work for moving lru_lock from ttm_device
to drm_device.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 2
Hi Hsin-Yi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[cannot apply to linus/master v6.6 next-20231101]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On 10/5/23 18:15, Melissa Wen wrote:
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
On 10/31/ , Christian König wrote:
> Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
> >
> >
> > On Tue, Oct 31, 2023 at 2:57 PM Christian König
> > wrote:
> >
> > Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> > > The current amdgpu_gem_va_update_vm only tries to perform
> >
Use Macro DRM_FORMAT_MAX_PLANES instead of 4, to improve modifiability.
Signed-off-by: Peng Hao
---
drivers/gpu/drm/drm_framebuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index
On 2023-11-01 20:10, Danilo Krummrich wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a credit
> limit that corresponds to the number of jobs which can be sent to the
> hardware.
>
> This implies
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sent to the
hardware.
This implies that for each job, drivers need to account for the maximum
GPUVM provides common infrastructure to track external and evicted GEM
objects as well as locking and validation helpers.
Especially external and evicted object tracking is a huge improvement
compared to the current brute force approach of iterating all mappings
in order to lock and validate the
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design patterns commonly used by drivers, which
can
Add an abstraction layer between the drm_gpuva mappings of a particular
drm_gem_object and this GEM object itself. The abstraction represents a
combination of a drm_gem_object and drm_gpuvm. The drm_gem_object holds
a list of drm_gpuvm_bo structures (the structure representing this
abstraction),
Implement reference counting for struct drm_gpuvm.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 44 +++---
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 +---
include/drm/drm_gpuvm.h| 31 +-
3 files
Introduce flags for struct drm_gpuvm, this required by subsequent
commits.
Reviewed-by: Boris Brezillon
Reviewed-by: Thomas Hellström
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 3 +++
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
include/drm/drm_gpuvm.h
Allocate struct nouveau_uvmm separately in preparation for subsequent
commits introducing reference counting for struct drm_gpuvm.
While at it, get rid of nouveau_uvmm_init() as indirection of
nouveau_uvmm_ioctl_vm_init() and perform some minor cleanups.
Signed-off-by: Danilo Krummrich
---
DRM GEM objects private to a single GPUVM can use a shared dma-resv.
Make use of the shared dma-resv of GPUVM rather than a driver specific
one.
The shared dma-resv originates from a "root" GEM object serving as
container for the dma-resv to make it compatible with drm_exec.
In order to make
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and evicted object handling and GEM validation.
Reviewed-by: Boris Brezillon
Reviewed-by: Thomas Hellström
Signed-off-by: Danilo Krummrich
---
Use drm_gpuvm_range_valid() in order to validate userspace requests.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 17 +
drivers/gpu/drm/nouveau/nouveau_uvmm.h | 3 ---
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git
Drivers may use this function to validate userspace requests in advance,
hence export it.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 14 +-
include/drm/drm_gpuvm.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
Don't always WARN in drm_gpuvm_check_overflow() and separate it into a
drm_gpuvm_check_overflow() and a dedicated
drm_gpuvm_warn_check_overflow() variant.
This avoids printing warnings due to invalid userspace requests.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 20
Use drm_WARN() and drm_WARN_ON() variants to indicate drivers the
context the failing VM resides in.
Reviewed-by: Boris Brezillon
Reviewed-by: Thomas Hellström
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 32 ++
Currently GPUVM offers common infrastructure to track GPU VA allocations
and mappings, generically connect GPU VA mappings to their backing
buffers and perform more complex mapping operations on the GPU VA space.
However, there are more design patterns commonly used by drivers, which
can
On 2023-10-31 22:23, Danilo Krummrich wrote:
> Hi Luben,
>
[snip]
>>> @@ -187,12 +251,14 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq
>>> *rq,
>>> /**
>>> * drm_sched_rq_select_entity_rr - Select an entity which could provide a
>>> job to run
>>> *
>>> + * @sched: the gpu
The gt wedged could be triggered by missing guc firmware file, HW not
working, etc. Once triggered, it means all gt usage is dead, therefore we
can't enable pxp under this fatal error condition.
v2: Updated commit message.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/pxp/intel_pxp.c |
Hi all,
On Wed, 18 Oct 2023 12:46:36 +1100 Stephen Rothwell
wrote:
>
> On Fri, 13 Oct 2023 11:46:02 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > arch/ia64/include/asm/fb.h
> >
> > between commit:
> >
> > cf8e8658100d
On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz wrote:
>
> Without this fix the 5120x1440@240 timing of these monitors
> leads to screen flickering.
>
> Cc: sta...@vger.kernel.org # 6.1+
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
> Co-developed-by: Harry Wentland
> Signed-off-by:
Hi all,
On Tue, 24 Oct 2023 11:52:06 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/msm/msm_drv.c
>
> between commit:
>
> cd61a76c210a ("drm/msm: dynamically allocate the drm-msm_gem shrinker")
>
> from the mm-stable
On 11/1/2023 2:23 PM, Dmitry Baryshkov wrote:
On Wed, 1 Nov 2023 at 21:56, Abhinav Kumar wrote:
On 11/1/2023 12:39 PM, Dmitry Baryshkov wrote:
On Wed, 1 Nov 2023 at 20:43, Abhinav Kumar wrote:
On 10/31/2023 1:19 AM, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 22:24, Abhinav
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If a hard-coded mode is present, unset the preferred bit of the modes read
from edid.
Signed-off-by: Hsin-Yi Wang
---
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/panel/panel-edp.c | 68
Add a few generic edp panels used by mt8186 chromebooks.
Besides, modify the following panel:
- AUO 0x235c B116XTN02 renamed to B116XTN02.3.
- AUO 0x405c B116XAK01 adjust the timing to delay_200_500_e50. According
to the datasheet: T3=200, T12=500, T7_max = 50.
Signed-off-by: Hsin-Yi Wang
---
This series contains 3 patches:
1. Add a few new generic edp panels.
2. Support a new quirk to override the mode read from edid
3. Unset preferred mode from edid if hard-coded mode presents.
Hsin-Yi Wang (3):
drm/panel-edp: Add several generic edp panels
drm/panel-edp: Add override_edid_mode
On Wed, 1 Nov 2023 at 21:56, Abhinav Kumar wrote:
>
>
>
> On 11/1/2023 12:39 PM, Dmitry Baryshkov wrote:
> > On Wed, 1 Nov 2023 at 20:43, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 10/31/2023 1:19 AM, Dmitry Baryshkov wrote:
> >>> On Mon, 30 Oct 2023 at 22:24, Abhinav Kumar
> >>> wrote:
Without this fix the 5120x1440@240 timing of these monitors
leads to screen flickering.
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Co-developed-by: Harry Wentland
Signed-off-by: Harry Wentland
Signed-off-by: Hamza Mahfooz
---
On 11/1/23 20:45, Thomas Hellström wrote:
On Wed, 2023-11-01 at 18:21 +0100, Danilo Krummrich wrote:
On 11/1/23 17:38, Thomas Hellström wrote:
On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
On 10/31/23 11:32, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo
When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist
yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as
the connector type.
However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the
connector type.
Signed-off-by: Paul Cercueil
---
On Sun, Oct 22, 2023 at 08:02:36PM +0200, Thomas Hellström wrote:
> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
>
> The document describes and discuss the locking used during exec-
> functions, evicton and for
On 11/1/2023 12:39 PM, Dmitry Baryshkov wrote:
On Wed, 1 Nov 2023 at 20:43, Abhinav Kumar wrote:
On 10/31/2023 1:19 AM, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 22:24, Abhinav Kumar wrote:
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
Three different features,
On Wed, 2023-11-01 at 18:21 +0100, Danilo Krummrich wrote:
> On 11/1/23 17:38, Thomas Hellström wrote:
> > On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
> > > On 10/31/23 11:32, Thomas Hellström wrote:
> > > > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > > > Add an
On Wed, 1 Nov 2023 at 20:43, Abhinav Kumar wrote:
>
>
>
> On 10/31/2023 1:19 AM, Dmitry Baryshkov wrote:
> > On Mon, 30 Oct 2023 at 22:24, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
> >>> Three different features, DPU_SSPP_SCALER_QSEED3,
The pull request you sent on Tue, 31 Oct 2023 15:07:23 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-10-31-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7d461b291e65938f15f56fe58da2303b07578a76
Thank you!
--
Deet-doot-dot, I am a bot.
On 10/9/2023 9:56 AM, Dmitry Baryshkov wrote:
Enable the SmartDMA / multirect support on the SM8450 platform to
support higher resoltion modes.
resoltion -> resolution
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 16
1 file
On 10/13/2023 1:25 AM, Dan Carpenter wrote:
This NULL check was required when it was added, but we shuffled the code
around and now it's not. The inconsistent NULL checking triggers a
Smatch warning:
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:847 mdp5_init() warn:
variable
On 10/31/2023 1:19 AM, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 22:24, Abhinav Kumar wrote:
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
On 2023-10-31 5:38 p.m., Teres Alexis, Alan Previn wrote:
On Fri, 2023-10-27 at 10:13 +0300, Jani Nikula wrote:
On Thu, 26 Oct 2023, Zhanjun Dong wrote:
alan:snip
I'll note that nobody checks intel_pxp_init() return status, so this
silently skips PXP.
BR,
Jani.
alan:snip
+ if
Hi,
On 11/1/23 18:20, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi,
>
> This contains two patches that bring simplefb up to feature parity with
> simpledrm. The patches add support for the "memory-region" property that
> provides an alternative to the "reg" property to describe the
Hi,
On 11/1/23 17:50, Thierry Reding wrote:
> On Thu, Oct 26, 2023 at 02:50:27PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> Thank you for your patches.
>>
>> On 10/11/23 16:38, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> The simple-framebuffer device tree bindings document the
On 11/1/23 10:56, Thomas Hellström wrote:
On Wed, 2023-11-01 at 10:41 +0100, Thomas Hellström wrote:
Hi, Danilo,
On Tue, 2023-10-31 at 18:52 +0100, Danilo Krummrich wrote:
On 10/31/23 17:45, Thomas Hellström wrote:
On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
On 10/31/23
On 11/1/23 17:38, Thomas Hellström wrote:
On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
On 10/31/23 11:32, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
Add an abstraction layer between the drm_gpuva mappings of a
particular
drm_gem_object and
From: Thierry Reding
The simple-framebuffer device tree bindings document the power-domains
property, so make sure that simplefb supports it. This ensures that the
power domains remain enabled as long as simplefb is active.
v2: - remove unnecessary call to simplefb_detach_genpds() since that's
From: Thierry Reding
The simple-framebuffer bindings specify that the "memory-region"
property can be used as an alternative to the "reg" property to define
the framebuffer memory used by the display hardware. Implement support
for this in the simplefb driver.
Reviewed-by: Hans de Goede
From: Thierry Reding
Hi,
This contains two patches that bring simplefb up to feature parity with
simpledrm. The patches add support for the "memory-region" property that
provides an alternative to the "reg" property to describe the memory
used for the framebuffer and allow attaching the
On 2023-10-17 17:13, Felix Kuehling wrote:
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian
On Thu, Oct 26, 2023 at 02:50:27PM +0200, Hans de Goede wrote:
> Hi,
>
> Thank you for your patches.
>
> On 10/11/23 16:38, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The simple-framebuffer device tree bindings document the power-domains
> > property, so make sure that simplefb
On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
> On 10/31/23 11:32, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Add an abstraction layer between the drm_gpuva mappings of a
> > > particular
> > > drm_gem_object and this GEM object
On 10/25/2023 2:23 AM, Dmitry Baryshkov wrote:
While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
support setting the DP subconnector type") I had the patch [1] in my
tree. I haven't noticed that it was a dependency for the commit in
question. Mea culpa.
Since the patch has
On 10/25/2023 2:23 AM, Dmitry Baryshkov wrote:
From: Abel Vesa
In case of the eDP connection there is no subconnetor and as such no
subconnector property. Put drm_dp_set_subconnector_property() calls
under the !is_edp condition.
Fixes: bfcc3d8f94f4 ("drm/msm/dp: support setting the DP
Current Hyper-V code for CoCo VMs uses ioremap_cache() to map normal memory as
decrypted.
ioremap_cache() is ideally used to map I/O device memory when it has the
characteristics
of normal memory. It should not be used to map normal memory as the returned
pointer
has the __iomem attribute.
Fix
On Tue, Oct 31, 2023 at 02:53:35PM -0300, Maíra Canal wrote:
> I would like to ask the device tree maintainers if you are willing
> to take this through your tree or should I push the entire series
> through drm-misc/drm-misc-next.
dt-binding patches almost never go through Rob's tree, usually
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 10.08.23 06:19, Thorsten Leemhuis wrote:
> On 10.08.23 05:03, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>> [...]
>> [1]:
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote:
> tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
> returns immediately as there's no reason to do any register changes.
>
> However, the code checks for 'crtc->state->enable',
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:46AM +0200, Tomi Valkeinen wrote:
> The IRQ setup code is overly complex. All we really need to do is
> initialize the related fields in struct tidss_device, and request the
> IRQ.
>
> We can drop all the HW accesses, as they are
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:45AM +0200, Tomi Valkeinen wrote:
> Add a helper function, dispc_is_idle(), which returns whether the DSS is
> idle (i.e. is any video port enabled).
>
> For now we add a call to it in the suspend and resume callbacks, and
> print
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:44AM +0200, Tomi Valkeinen wrote:
> The probe function calls dispc_softreset() before runtime PM is enabled
> and without enabling any of the DSS clocks. This happens to work by
> luck, and we need to make sure the DSS HW is active
On 01/11/2023 10:06, Jani Nikula wrote:
On Wed, 01 Nov 2023, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
removed some code.
Signed-off-by: Tvrtko Ursulin
\o/
Reviewed-by: Jani Nikula
Could I persuade
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:43AM +0200, Tomi Valkeinen wrote:
> K2G doesn't have softreset feature. Instead of having every caller of
> dispc_softreset() check for K2G, move the check into dispc_softreset(),
> and make dispc_softreset() return 0 in case of
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:42AM +0200, Tomi Valkeinen wrote:
> Return an error value from dispc_softreset() so that the caller can
> handle the errors.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/tidss/tidss_dispc.c | 17 -
>
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:41AM +0200, Tomi Valkeinen wrote:
> We do a DSS reset in the middle of the dispc_init(). While that happens
> to work now, we should really make sure that e..g the fclk, which is
> acquired only later in the function, is enabled
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:40AM +0200, Tomi Valkeinen wrote:
> No need to initialize the ret to 0 in dispc_softreset().
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/tidss/tidss_dispc.c | 2 +-
> 1 file changed,
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:39AM +0200, Tomi Valkeinen wrote:
> Use runtime PM autosuspend feature, with 1s timeout, to avoid
> unnecessary suspend-resume cycles when, e.g. the userspace temporarily
> turns off the crtcs when configuring the outputs.
>
>
Hi Tomi,
Thank you for the patch.
On Wed, Nov 01, 2023 at 11:17:38AM +0200, Tomi Valkeinen wrote:
> Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync(), which
> will handle error situations better. Also fix the return, as there
> should be no reason for the current complex return.
>
Hi Marek,
I would like to recompile and install the kernel 6.6 on my ARM
Chromebook. I would like to know if your patch has been accepted and
included there. Thanks.
On Wed, Nov 1, 2023 at 8:48 AM Chuck Zmudzinski wrote:
>
> On 10/31/2023 8:08 AM, Marek Szyprowski wrote:
> > Hi,
> >
> > On
Thomas Zimmermann writes:
> Do not acquire a reference on the module that provides a client's
> callback functions in drm_client_init(). The additional reference
> prevents the user from unloading the callback functions' module and
> thus creating dangling pointers.
>
> This is only necessary if
On 31.10.23 14:17, Huacai Chen wrote:
Hi, Jaak and Evan,
On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen wrote:
On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja wrote:
On 26.10.23 03:58, Huacai Chen wrote:
Hi, Jaak,
On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja wrote:
On 25.10.23 16:23,
On 31/10/2023 10:33, AngeloGioacchino Del Regno wrote:
>> Anyway, as for the GPU_PM_CLK_DIS feature - I feel like being
>> extremely careful
>> with this is still a good idea... thing is, even if we're sure that
>> the GPU itself
>> is fine with us turning off/on clocks (even aggressively), I'm
Hi,
On 11/1/23 11:20, Hans de Goede wrote:
> Hi,
>
> On 11/1/23 10:32, Andy Shevchenko wrote:
>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>> On 10/31/23 17:07, Hans de Goede wrote:
On 10/24/23 18:11, Andy Shevchenko wrote:
> On Tue, Oct 24, 2023 at 06:57:38PM
Hi,
On 11/1/23 11:34, Ville Syrjälä wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
On 10/31/23 17:07, Hans de Goede wrote:
> On 10/24/23
Contain struct drm_flip_task and its helper functions
drm_flip_work_allocate_task() and drm_flip_work_queue_task() within
drm_flip_work.c There are no callers outside of the flip-work code.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_flip_work.c | 27
Say that drm_flip_work_commit() is safe to call in atomic context. Turn
the name into a hyperlink.
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
include/drm/drm_flip_work.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Remove several public interfaces from the DRM flip-task code and
fix the documentation.
v2:
* documentation fixes (Daniel)
Thomas Zimmermann (2):
drm: Remove struct drm_flip_task from DRM interfaces
drm: Fix flip-task docs
drivers/gpu/drm/drm_flip_work.c | 27
On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/1/23 10:32, Andy Shevchenko wrote:
> > On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
> >> On 10/31/23 17:07, Hans de Goede wrote:
> >>> On 10/24/23 18:11, Andy Shevchenko wrote:
> On Tue, Oct 24,
Hi,
On 11/1/23 10:32, Andy Shevchenko wrote:
> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>> On 10/31/23 17:07, Hans de Goede wrote:
>>> On 10/24/23 18:11, Andy Shevchenko wrote:
On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>
> ...
>
>>> As for the
From: Farah Kassabri
Use a predefined mask which set the device critical boot errors.
Driver will fail and stop its loading, only upon detecting at least
one of those errors defined in this mask.
Signed-off-by: Farah Kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
From: farah kassabri
When working on a bare-metal system, if FLR will happen the firmware
will handle it and driver will have no knowledge of it, and this will
cause two issues:
1.The driver will be in operational state while it should be in reset.
This will cause the heartbeat mechanism to
On Wed, 01 Nov 2023, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
> code")
> removed some code.
>
> Signed-off-by: Tvrtko Ursulin
\o/
Reviewed-by: Jani Nikula
Could I persuade you to move for_each_engine(),
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
removed some code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
On Wed, 2023-11-01 at 10:41 +0100, Thomas Hellström wrote:
> Hi, Danilo,
>
> On Tue, 2023-10-31 at 18:52 +0100, Danilo Krummrich wrote:
> > On 10/31/23 17:45, Thomas Hellström wrote:
> > > On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> > > > On 10/31/23 12:25, Thomas Hellström
Hi, Danilo,
On Tue, 2023-10-31 at 18:52 +0100, Danilo Krummrich wrote:
> On 10/31/23 17:45, Thomas Hellström wrote:
> > On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> > > On 10/31/23 12:25, Thomas Hellström wrote:
> > > > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
>
1 - 100 of 129 matches
Mail list logo
