From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel users of the dmabuf
by attachments.
However, for many usersp
On Thu, Sep 16, 2021 at 11:43:59AM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a few helpers to count the number of contiguous DMA chunks found in
> an SG table. This is useful to determine whether or not a mapping can be
> used by drivers whose devices need contiguous memory.
[..
On 10/8/21 7:47 PM, guangming@mediatek.com wrote:
From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel user
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
\-- reset
For backwards compatibility with existing igt (
From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel users of the dmabuf
by attachments.
However, for many usersp
Hi Ville,
> > + if (IS_CHERRYVIEW(i915)) {
> > + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> > + intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> > +
> > + for (i = 0; i < 4; i++) {
> > + seq_printf(m, "GT Interrupt IMR %d:\t%08x\
On Fri, Oct 8, 2021 at 3:14 AM Andi Shyti wrote:
>
> Hi Lucas,
>
> > > I am reproposing this patch exactly as it was proposed initially
> > > where the original interfaces are kept where they have been
> > > originally placed. It might generate some duplicated code but,
> > > well, it's debugfs an
On Fri, Oct 08, 2021 at 02:56:31PM -0700, Matt Roper wrote:
> From: Paulo Zanoni
>
> The first step of interrupt handling is to read a tile0 register that
> tells us in which tile the interrupt happened; we can then we read the
> usual interrupt registers from the appropriate tile.
>
> Note that
From: Tvrtko Ursulin
Check how many extra GT tiles are available on the system and setup
register access for all of them. We can detect how may GT tiles are
available by reading a register on the root tile. The same register
returns the tile ID on all tiles.
v2:
- Include some additional refact
If hardware is malfunctioning (e.g., misconfigured clocks?), we can get
stuck here forever, holding various DRM locks and eventually locking up
the entire system. It's better to complain loudly and move on, than to
lock up the system.
In local tests, this operation takes less than 20ms.
Signed-of
From: Venkata Sandeep Dhanalakota
Iterate for_each_gt during release to support multi-tile
devices.
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --g
From: Tvrtko Ursulin
Check how many extra GT tiles are available on the system and setup
register access for all of them. We can detect how may GT tiles are
available by reading a register on the root tile. The same register
returns the tile ID on all tiles.
Bspec: 33407
Original-author: Abdiel
From: Daniele Ceraolo Spurio
Initialization and suspend/resume is replicated per-tile.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++-
drivers/gpu/drm/i
From: Tvrtko Ursulin
Add some basic plumbing to support more than one dynamically allocated
struct intel_gt. Up to four gts are supported in i915->gts[], with slot
zero shadowing the existing i915->gt to enable source compatibility with
legacy driver paths. A for_each_gt macro is added to itera
From: Paulo Zanoni
Loop through all the tiles when initializing and resetting interrupts.
Signed-off-by: Paulo Zanoni
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(
From: Daniele Ceraolo Spurio
In coming patches we'll be doing the actual tile initialization between
these two uncore init phases.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.c | 9 -
drivers/gpu/drm/i915/intel_uncore.c | 17 +
From: Paulo Zanoni
The first step of interrupt handling is to read a tile0 register that
tells us in which tile the interrupt happened; we can then we read the
usual interrupt registers from the appropriate tile.
Note that this is just the first step of handling interrupts properly on
multi-tile
From: Michal Wajdeczko
Update CT debug macros by including tile ID in all messages.
Cc: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/g
From: Paulo Zanoni
We'll be adding multi-tile support soon; on multi-tile platforms
interrupts are per-tile and every tile has the full set of
interrupt registers.
In this commit we start passing intel_gt instead of dev_priv for the
functions that are related to Xe_HP irq handling. Right now we'
On a multi-tile platform, each tile has its own registers + GGTT space,
and BAR 0 is extended to cover all of them. Upcoming patches will start
exposing the tiles as multiple GTs within a single PCI device. In
preparation for supporting such setups, restructure the driver's probe
code a bit.
Onl
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/int
Some of our upcoming platforms, including the Xe_HP SDV, support a
"multi-tile" design. A multi-tile platform is effectively a platform
with multiple GT instances and local memory regions, all behind a single
PCI device. From an i915 perspective, this translates to multiple
intel_gt structures pe
On Fri, 2021-10-08 at 20:40 +, Zack Rusin wrote:
> On Fri, 2021-10-08 at 22:28 +0200, Thomas Hellström wrote:
> > On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote:
> > > This is a largely trivial set that makes vmwgfx support module
> > > reload
> > > and PCI hot-unplug. It also makes IGT's
On 2021-10-08 04:36, Tvrtko Ursulin wrote:
>
> Hi,
>
> Is it my checkout only or this causes a lot of build warnings for everyone?
>
> ./include/drm/drm_dp_helper.h:1120: warning:
> "DP_TEST_264BIT_CUSTOM_PATTERN_7_0" redefined
> 1120 | #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230
>
On 21/10/07 09:37PM, Fernando Ramos wrote:
> ---
> include/drm/drm_mode_config.h | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 48b7de80daf5..b214b07157f2 100644
>
This patch was missing the commit descrip
On Fri, 2021-10-08 at 22:28 +0200, Thomas Hellström wrote:
> On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote:
> > This is a largely trivial set that makes vmwgfx support module reload
> > and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead
> > of kernel oops'ing.
> >
> > The on
On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote:
> This is a largely trivial set that makes vmwgfx support module reload
> and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead
> of kernel oops'ing.
>
> The one "ugly" change is the "Introduce a new placement for MOB page
> tables
Hi Dave, Daniel,
The following changes since commit c3dbfb9c49eef7d07904e5fd5e158dd6688bbab3:
gpu: host1x: Plug potential memory leak (2021-09-16 18:06:52 +0200)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.16-rc1
for you to fet
Hi Dave, Daniel,
More new stuff for 5.16. MCE change has an ack from Boris to merge
through the amdgpu tree.
The following changes since commit 1e3944578b749449bd7fa6bf0bae4c3d3f5f1733:
Merge tag 'amd-drm-next-5.16-2021-09-27' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021
On Thu, Sep 30, 2021 at 01:28:05AM +0300, Dmitry Osipenko wrote:
> Asus Transformer TF700T is a Tegra30 tablet device which uses RGB->DSI
> bridge that requires a precise clock rate in order to operate properly.
> Tegra30 has a dedicated PLL for each display controller, hence the PLL
> rate can be
On Thu, Oct 07, 2021 at 12:35:08PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is responsib
On Wed, Oct 06, 2021 at 08:37:03PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a deregister context H2G is in flight. To do this must
> > issue the deregister H2G from a worker as
Ping
On Fri, Oct 08, 2021 at 10:39:35AM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Update context and full GPU reset to work with multi-lrc. The idea is
> > parent context tracks all the active requests inflight for itself and
> > its' children. The parent context owns th
On 10/4/2021 15:06, Matthew Brost wrote:
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines return
On 10/4/2021 15:06, Matthew Brost wrote:
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_g
On 10/4/2021 15:06, Matthew Brost wrote:
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
Still its' should be its.
requests as need
On Fri, Oct 08, 2021 at 10:20:16AM -0700, John Harrison wrote:
> On 10/7/2021 12:50, John Harrison wrote:
> > On 10/4/2021 15:06, Matthew Brost wrote:
> > > Add multi-lrc context registration H2G. In addition a workqueue and
> > > process descriptor are setup during multi-lrc context registration a
On Thu, 7 Oct 2021 at 21:19, Andrzej Hajda wrote:
>
> On 07.10.2021 13:07, Dave Stevenson wrote:
> > On Tue, 5 Oct 2021 at 22:03, Andrzej Hajda wrote:
> >>
> >> On 05.10.2021 17:32, Dave Stevenson wrote:
> >>> Hi Andrzej
> >>>
> >>> Thanks for joining in the discussion.
> >>>
> >>> On Tue, 5 Oct
There's never a need to access our internal kernel bo's from
user-space. Those objects are used exclusively for internal
support to guest backed surfaces (in otable setup and mob
page tables) and there's no need to have them be of device
type, i.e. mmappable from user-space.
Signed-off-by: Zack Ru
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we
Some of our hosts have a bug where rescaning a pci bus results in stale
fifo memory being mapped on the host. This makes any fifo communication
impossible resulting in various kernel crashes.
Instead of unexpectedly crashing, predictably fail to load the driver
which will preserve the system.
Fix
The ttm mem global state was leaking if the vmwgfx driver load failed.
In case of a driver load failure we have to make sure we also release
the ttm mem global state.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 26 --
TTM during the transition to the new page allocator lost the ability
to constrain the allocations via the lower_mem_limit. The code has
been unused since the change:
256dd44bd897 ("drm/ttm: nuke old page allocator")
and there's no reason to keep it.
Fixes: 256dd44bd897 ("drm/ttm: nuke old page all
This is a largely trivial set that makes vmwgfx support module reload
and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead
of kernel oops'ing.
The one "ugly" change is the "Introduce a new placement for MOB page
tables". It seems vmwgfx has been violating a TTM assumption that
TTM_P
On 10/4/2021 15:06, Matthew Brost wrote:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet
On 10/7/2021 12:50, John Harrison wrote:
On 10/4/2021 15:06, Matthew Brost wrote:
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harr
The pull request you sent on Fri, 8 Oct 2021 13:42:41 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-10-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0068dc8c96688b72cc99470530b384429129950c
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri 08 Oct 09:07 PDT 2021, khs...@codeaurora.org wrote:
> On 2021-10-07 15:34, Stephen Boyd wrote:
> > Quoting khs...@codeaurora.org (2021-10-07 13:28:12)
> > > On 2021-10-07 13:06, Bjorn Andersson wrote:
> > > > On Thu 07 Oct 12:51 PDT 2021, khs...@codeaurora.org wrote:
> > > >
> > > >> On 202
On Fri, Oct 08, 2021 at 01:27:33PM +0200, Andi Shyti wrote:
> +
> + if (IS_CHERRYVIEW(i915)) {
> + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> +intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> +
> + for (i = 0; i < 4; i++) {
> +
On 10/7/2021 18:21, Matthew Brost wrote:
On Thu, Oct 07, 2021 at 03:03:04PM -0700, John Harrison wrote:
On 10/4/2021 15:06, Matthew Brost wrote:
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be conse
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
F
On 2021-10-07 15:34, Stephen Boyd wrote:
Quoting khs...@codeaurora.org (2021-10-07 13:28:12)
On 2021-10-07 13:06, Bjorn Andersson wrote:
> On Thu 07 Oct 12:51 PDT 2021, khs...@codeaurora.org wrote:
>
>> On 2021-10-06 10:31, Bjorn Andersson wrote:
>> > On Wed 06 Oct 08:37 PDT 2021, khs...@codeaur
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
F
On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart
wrote:
>
> Hello,
>
> On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > Hi,
> >
> > Removed my invalid email (I will update files next week).
> >
> > On 08.10.2021 13:14, Jagan Teki wrote:
> > > Hi,
> > >
> > > I think this seems to be
Hey Allen,
I was running the pre-merge checks, and hit some build issues. This
was built against todays drm-misc-next branch, which I would like you
to rebase your patch against.
drivers/gpu/drm/bridge/ite-it6505.c: In function ‘it6505_bridge_atomic_enable’:
drivers/gpu/drm/bridge/ite-it6505.c:29
Hi,
please ignore! I run the command from the history and forgot that
I had to update the patch file. :)
V3 of this patch is coming soon.
Andi
On Fri, Oct 08, 2021 at 01:22:48PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_use
On Thu, 7 Oct 2021 at 05:51, Bjorn Andersson wrote:
>
> On Wed 29 Sep 20:05 PDT 2021, Bjorn Andersson wrote:
>
> > The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> > with the primary purpose of controlling the backlight of the attached
> > panel. Add an implementation that ex
Hello,
On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> Hi,
>
> Removed my invalid email (I will update files next week).
>
> On 08.10.2021 13:14, Jagan Teki wrote:
> > Hi,
> >
> > I think this seems to be a known use case for industrial these days with
> > i.mx8m.
> >
> > The
We are using a timeline-attached struct dma_fence_work to coalesce
dma-fences on eviction. In this mode we will not have a work callback
attached.
Similar to how the dma-fence-chain and dma-fence-array containers do this,
use irq work to signal to reduce latency.
Signed-off-by: Thomas Hellström
-
On eviction, TTM requires that migration fences from the same region are
ordered using dma_fence_is_later(). For request-based fences we therefore
need to use the same context for the migration, but now that we use a
dma_fence_work for error recovery, and, in addition, might need to coalesce
the mi
The TTM managers and, possibly, the gtt address space managers will
need to be able to order fences for async operation.
Using dma_fence_is_later() for this will require that the fences we hand
them are from a single fence context and ordered.
Introduce a struct dma_fence_work_timeline, and a func
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async dma_fence_work that checks the
blit fence for errors and if there are errors p
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous m
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason, and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So after
Move the release callback to after fence signaling to align with
what's done for upcoming VM_BIND user-fence signaling.
Finally call the work callback regardless of whether we have a fence
error or not and update the existing callbacks accordingly. We will
need this to intercept the error for fail
Hi Chun-Kuang,
Thank you to take time to send this, for full series
Tested-by: Enric Balletbo i Serra
Display is now working again.
Thanks,
Enric
Missatge de Chun-Kuang Hu del dia dv., 8
d’oct. 2021 a les 1:53:
>
> Commit c1ec54b7b5af
> ("drm/mediatek: Use mailbox rx_callback instead of c
Quoting Guillaume Ranquet (2021-09-30 17:30:16)
> Hi Chun-Kuang.
>
> Thank you for your input.
> I have tried to find commonalities between the two drivers but I didn't
> find enough shared code to warrant that architecture.
> I'll have another look, especially now that I'm more familiar with the
>
Hi,
Removed my invalid email (I will update files next week).
On 08.10.2021 13:14, Jagan Teki wrote:
Hi,
I think this seems to be a known use case for industrial these days with i.mx8m.
The host DSI would configure with two bridges one for DSI to LVDS
(SN65DSI83) and another for DSI to HDMI
On 30/09/2021 10:31, Enric Balletbo i Serra wrote:
Dear all,
The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mt
[AMD Official Use Only]
Trying with Christian's Gmail, as he still didn't receive previous emails.
From: Das, Nirmoy
Sent: Friday, October 8, 2021 2:17 PM
To: Koenig, Christian
Cc: dri-devel@lists.freedesktop.org ;
intel-...@lists.freedesktop.org ; Maarten
Lan
Hi,
On Thu, Oct 07, 2021 at 09:15:12AM -0700, Bjorn Andersson wrote:
> The one thing that I still don't understand though is, if the typec_mux
> is used by the typec controller to inform _the_ mux about the function
> to be used, what's up with the complexity in typec_mux_match()? This is
> what l
Am 08.10.21 um 12:49 schrieb Tvrtko Ursulin:
On 08/10/2021 11:21, Christian König wrote:
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterato
Am 08.10.21 um 13:20 schrieb Shunsuke Mie:
A comment for the dma_buf_vmap/vunmap() is not catching up a
corresponding implementation.
Signed-off-by: Shunsuke Mie
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
[AMD Official Use Only]
Thanks, Greg and Jani. So I have to do the exact opposite.
We do have some NULL dentry check in the drm code. I will remove those instead.
Regards,
Nirmoy
From: Greg KH
Sent: Friday, October 8, 2021 1:07 PM
To: Jani Nikula
Cc: Das, Nirmo
On 08/10/2021 04:05, Yongqiang Niu wrote:
base v5.15
Yongqiang Niu (2):
soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4
soc: mediatek: mmsys: Add mt8192 mmsys routing table
I'm a bit puzzled that you keep on sending this series while I accepted an older
one long time ago:
http
On 08/10/2021 04:09, yongqiang.niu wrote:
On Fri, 2021-10-01 at 13:00 +0200, Dafna Hirschfeld wrote:
On 30.09.21 17:52, Yongqiang Niu wrote:
This patch add component POSTMASK.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk
On 30/09/2021 17:52, Yongqiang Niu wrote:
Add mtk mutex support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
Applied to v5.15-next/soc
Thanks!
---
drivers/soc/mediatek/mtk-mutex.c | 35
1 file changed,
A comment for the dma_buf_vmap/vunmap() is not catching up a
corresponding implementation.
Signed-off-by: Shunsuke Mie
---
drivers/dma-buf/dma-buf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index beb504a92d60..7
Hi,
I think this seems to be a known use case for industrial these days with i.mx8m.
The host DSI would configure with two bridges one for DSI to LVDS
(SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
can use only one bridge at a time as host DSI support single out port.
So we
On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote:
> On Fri, 08 Oct 2021, Nirmoy Das wrote:
> > Debugfs API returns encoded error instead of NULL.
> > This patch cleanups drm debugfs error handling to
> > properly set dri and its minor's root dentry to NULL.
> >
> > Also do not error out
On Fri, Oct 08, 2021 at 09:17:08AM +0200, Javier Martinez Canillas wrote:
> This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
>
> That change attempted to improve the DRM drivers fbdev emulation device
> names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
>
> But
On 10/6/21 9:18 PM, Thierry Reding wrote:
On Thu, Sep 16, 2021 at 05:55:16PM +0300, Mikko Perttunen wrote:
Add a device tree node for NVDEC on Tegra186, and
device tree nodes for NVDEC and NVDEC1 on Tegra194.
Signed-off-by: Mikko Perttunen
---
v5:
* Change from nvidia,instance to nvidia,host1x
On 08/10/2021 11:21, Christian König wrote:
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and
its
users can observe an incosistent
[AMD Official Use Only]
I sent all the patches to dr-devel. I think there is an issue with our email
server. Thunderbird is asking for a password every few minutes.
https://patchwork.freedesktop.org/series/95603/
Nirmoy
[sending this from my browser]
From: Koeni
Am 08.10.21 um 09:54 schrieb guangming@mediatek.com:
From: Guangming Cao
Because dma-buf.name can be freed in func: "dma_buf_set_name",
so, we need to acquire lock first before we read/write dma_buf.name
to prevent Use After Free(UAF) issue.
Signed-off-by: Guangming Cao
Reviewed-by: Chr
Am 08.10.21 um 11:17 schrieb Nirmoy Das:
Return early if dri minor root dentry is NULL.
CC: Alex Deucher
CC: "Christian König"
CC: "Pan, Xinhui"
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Where are the other patches from the series?
Thanks,
Christian.
---
drivers/gpu/drm/r
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and its
users can observe an incosistent state which makes it impossible to use
safely.
Hi Lucas,
> > I am reproposing this patch exactly as it was proposed initially
> > where the original interfaces are kept where they have been
> > originally placed. It might generate some duplicated code but,
> > well, it's debugfs and I don't see any issue. In the future we
> > can transform the
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and its
users can observe an incosistent state which makes it impossible to use
safely. Such as:
<6> [187.517041] [IGT] gem_sync: execut
On Thu, Sep 30, 2021 at 05:58:16PM -0700, Matt Roper wrote:
> The I915_TILING_* definitions in the uapi header are intended solely for
> tiling modes that are visible to the old de-tiling fence ioctls. Since
> modern hardware does not support de-tiling fences, we should not add new
> definitions f
On Fri, 08 Oct 2021, Nirmoy Das wrote:
> Debugfs API returns encoded error instead of NULL.
> This patch cleanups drm debugfs error handling to
> properly set dri and its minor's root dentry to NULL.
>
> Also do not error out if dri/minor debugfs directory
> creation fails as a debugfs error is no
Hi
Am 08.10.21 um 11:17 schrieb Nirmoy Das:
Debugfs API returns encoded error instead of NULL.
This patch cleanups drm debugfs error handling to
properly set dri and its minor's root dentry to NULL.
Also do not error out if dri/minor debugfs directory
creation fails as a debugfs error is not a
Hi Dave & Daniel,
Here goes the first PR towards 5.16.
As for the big things, this adds encrypted PXP (Protected Xe Path)
support for Gen12 integrated. Take a look at the "drm/i915/pxp: add
PXP documentation" for further details and the Mesa changes for how
the uAPI will look like.
Then adds DG1
Return early if crtc or connector's debugfs root dentries are NULL.
CC: Thierry Reding
CC: David Airlie
CC: Daniel Vetter
CC: Jonathan Hunter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/tegra/dc.c | 5 +
drivers/gpu/drm/tegra/dsi.c | 4
drivers/gpu/drm/tegra/hdmi.c | 5 +
Return early if dri minor root dentry is NULL.
CC: Zhenyu Wang
CC: Zhi Wang
CC: Jani Nikula
CC: Joonas Lahtinen
CC: Rodrigo Vivi
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gvt/debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
2 fil
Return early if dri minor root dentry is NULL.
CC: Russell King
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/armada/armada_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
b/drivers/gpu/drm/armada
Return early if dri minor root dentry is NULL.
CC: Alex Deucher
CC: "Christian König"
CC: "Pan, Xinhui"
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/r100.c | 9 +
drivers/gpu/drm/radeon/r300.c | 3 +++
drivers/gpu/drm/radeon/r420.c | 3 +++
drivers/
Debugfs API returns encoded error instead of NULL.
This patch cleanups drm debugfs error handling to
properly set dri and its minor's root dentry to NULL.
Also do not error out if dri/minor debugfs directory
creation fails as a debugfs error is not a fatal error.
CC: Maarten Lankhorst
CC: Maxime
Applied to drm-misc-next
On Thu, 7 Oct 2021 at 21:51, Marek Vasut wrote:
>
> On 10/6/21 11:47 AM, Robert Foss wrote:
> >>
> > On Tue, 7 Sept 2021 at 04:40, Marek Vasut wrote:
> >>
> >> Move detach implementation from sn65dsi83_remove() to dedicated
> > .detach callback. There is no functional
1 - 100 of 107 matches
Mail list logo
