On 11/30/2021 6:46 PM, Christoph Hellwig wrote:
> I still think this goes into the wrong direction.
>
> Something closer to your first version that also saves away the
> gvt->mmio.mmio_attribute flags in the core i915 module, and which
> splits the MMIO table into one that contains just the offset,
On 16/12/2021 17:12, Rob Herring wrote:
> On Thu, Dec 16, 2021 at 10:16 AM Steven Price wrote:
>>
>> panfrost_copy_in_sync() takes the number of fences from user space
>> (in_sync_count) and used to kvmalloc() an array to hold that number of
>> fences before processing them. This provides an easy
On 16/12/2021 17:49, Alyssa Rosenzweig wrote:
>> This provides an easy method for user
>> space to trigger the OOM killer (by temporarily allocating large amounts
>> of kernel memory)
>
> panfrost user space has a lot of easy ways to trigger to the OOM killer
> unfortunately if this is someth
On 16/12/2021 20:30, John Harrison wrote:
On 12/16/2021 00:47, Tvrtko Ursulin wrote:
On 15/12/2021 22:45, john.c.harri...@intel.com wrote:
From: John Harrison
A fault injection probe test hit a BUG_ON in a GuC error path. It
showed that the GuC code could potentially attempt to do many thin
On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote:
> However this one is harder to fix without setting an arbitrary cap on
> the number of BOs during a sumbit. I'm not sure how other drivers handle
> this - the ones I've looked at so far all have the same issue. There's
> obviously the l
On 17/12/2021 09:10, Dan Carpenter wrote:
> On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote:
>> However this one is harder to fix without setting an arbitrary cap on
>> the number of BOs during a sumbit. I'm not sure how other drivers handle
>> this - the ones I've looked at so far all
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us movin
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but s
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
On Fri, Dec 17, 2021 at 09:16:19AM +, Steven Price wrote:
> On 17/12/2021 09:10, Dan Carpenter wrote:
> > On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote:
> >> However this one is harder to fix without setting an arbitrary cap on
> >> the number of BOs during a sumbit. I'm not sure
From: Guangming
Currently, there is no size check for allocation.
If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally, and we couldn't find the correct
memory usage by dma-buf
On 17/12/2021 09:28, Dan Carpenter wrote:
> On Fri, Dec 17, 2021 at 09:16:19AM +, Steven Price wrote:
>> On 17/12/2021 09:10, Dan Carpenter wrote:
>>> On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote:
However this one is harder to fix without setting an arbitrary cap on
th
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> i915_vma_wait_for_bind needs the vma lock held, fix the caller.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> We will need the lock to unbind the vma, and wait for bind to complete.
> Remove the special casing for the !ww path, and force ww locking for all.
>
> Changes since v1:
> - Pass err to for_i915_gem_ww handling for -EDEADLK handling.
>
> S
Currently we allow rediculous ammounts of kernel memory being allocated
via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
some reasonable limits in to fix this.
The commandstream size is limited to 64KB, which was already a soft limit
on older kernels after which the kernel
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking w
On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote:
> > Document new optional sound-dai-cells property of HDMI node. This node will
> > be used as endpoint of HDMI sound DAI graph.
> It's probably best for this to go th
On 17/12/2021 11:06, Tvrtko Ursulin wrote:
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were b
On 14/12/2021 15:38, Robin Murphy wrote:
...
IOMMU/DT folks, any thoughts about this approach? The patches that are
of interest outside of Host1x/TegraDRM specifics are patches 1, 2, 4,
and 5.
FWIW it looks fairly innocuous to me. I don't understand host1x -
neither hardware nor driver ab
Hi,
I'm just letting you know that drm-misc-next-fixes is now open for bug
fixes. -rc6 will presumably be tagged this weekend, which means that
drm-next is in feature freeze until the next -rc1 comes out.
The transition from/to drm-misc-fixes-next often results in patches that
are applied to
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we require locking to evict, multiple vmas from the same object
> might not be evicted. This is expected and required, because execbuf will
> move to short-term pinning by using the lock only. This will cause these
> tests to fail
17.12.2021 14:12, Mark Brown пишет:
> On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
>> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote:
>>> Document new optional sound-dai-cells property of HDMI node. This node will
>>> be used as endpoint of HDMI sound DAI graph.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
"unbind kill"
> because we're removing short term pinning, we may have to unbind the
> object from gtt manually, using a i915_gem_evict_vm() call.
>
> Signed-off-by: Maa
On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote:
> 17.12.2021 14:12, Mark Brown пишет:
> > On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
> >> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote:
> >>> Document new optional sound-dai-cells property of HD
17.12.2021 15:02, Thierry Reding пишет:
> On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote:
>> 17.12.2021 14:12, Mark Brown пишет:
>>> On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote:
> Document
17.12.2021 09:04, Vinod Koul пишет:
> On 16-12-21, 17:29, Dmitry Osipenko wrote:
>> 15.12.2021 22:19, Dmitry Osipenko пишет:
>>> 15.12.2021 21:57, Mark Brown пишет:
On Sat, Dec 04, 2021 at 05:37:03PM +0300, Dmitry Osipenko wrote:
> I based S/PDIF patches on Arnd's Bergmann patch from
6-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unb
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is done
by the execlists backend.
This way we have notion of where the hangs are before the GuC gains
support for proper error capture.
Ping - any interest to lo
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> We're working on requiring the obj->resv lock during unbind, fix
> the shrinker to take the objectl ock.
lock
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> This is required for i915_gem_evict_vm, to be able to evict the entire VM,
> including objects that are already locked to the current ww ctx.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> i915_gem_evict_vm will need to be able to evict objects that are
> locked by the current ctx. By testing if the current context already
> locked the object, we can do this correctly. This allows us to
> evict the entire vm even if we alrea
The lvds.yaml file so far was both defining the generic LVDS properties
(such as data-mapping) that could be used for any LVDS sink, but also
the panel-lvds binding.
That last binding was to describe LVDS panels simple enough, and had a
number of other bindings using it as a base to specialise it
Following the previous patch, let's introduce a generic panel-lvds
binding that documents the panels that don't have any particular
constraint documented.
Reviewed-by: Rob Herring
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Added missing compatible
- Fixed lint
---
.../bindings/di
On 2021-12-17 2:37, Javier Martinez Canillas wrote:
According to disable Documentation/admin-guide/kernel-parameters.txt,
this
parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated
rendering
and only the system framebuffer will b
Hi,
This is another attempt at supporting the LVDS dual-link output on the
Allwinner A20.
Let me know what you think,
Maxime
Changes from v5:
- Rebased on current next
- Enhanced the property binding description
Changes from v4:
- Rebased on 5.15
Changes from v3:
- Reintroduce the endp
of_graph_get_port_by_id doesn't modify the device_node pointer it takes
as argument, so we can make it const.
Signed-off-by: Maxime Ripard
---
drivers/of/property.c| 2 +-
include/linux/of_graph.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/property.c
The drm_of_lvds_get_dual_link_pixel_order() function took so far the
device_node of the two ports used together to make up a dual-link LVDS
output.
This assumes that a binding would use an entire port for the LVDS output.
However, some bindings have used endpoints instead and thus we need to
opera
The current code to parse the DT, deal with the older device trees, and
register either the RGB or LVDS output has so far grown organically into
the bind function and has become quite hard to extend properly.
Let's move it into a single function that grabs all the resources it needs
and registers
The A20 and other SoC with two TCONs (A31, R40, etc.) can use its second
TCON as the secondary LVDS link in a dual-link setup, with the TCON0 being
the main link. Extend a bit the parsing code to leverage the DRM dual-link
code, register only the LVDS output on the primary TCON, and add the needed
The Allwinner SoCs with two TCONs and LVDS output can use both to drive an
LVDS dual-link. Add a new property to express that link between these two
TCONs.
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
.../bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 ++
1 fi
For the sake of the example, let's enable an LVDS Dual-Link display on a
Cubieboard.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 69 +
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boo
The A20 second TCON (TCON1) can be used as a secondary output to drive a
dual-link LVDS output. Let's add it to our capabilities.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Because we will start to require the obj->resv lock for unbinding,
> ensure these shrinker functions also take the lock.
>
> This requires some function signature changes, to ensure that the
> ww context is passed around, but is mostly str
Hi Dave, Daniel,
The following changes since commit 136057256686de39cc3a07c2e39ef6bc43003ff6:
Linux 5.16-rc2 (2021-11-21 13:47:39 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-5.17-rc1
for you to fetch changes up to d210919db
Hi Javier,
looks good already. Some comments are below.
Am 17.12.21 um 01:37 schrieb Javier Martinez Canillas:
According to disable Documentation/admin-guide/kernel-parameters.txt, the
nomodeset parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode chan
Hi Daniel,
looks like this is going nowhere and you don't seem to have time to review.
What can we do?
Thanks,
Christian.
Am 07.12.21 um 13:33 schrieb Christian König:
Hi Daniel,
just a gentle ping that you wanted to take a look at this.
Not much changed compared to the last version, only a
Remove custom ast_init() and ast_exit() functions and initialize the
module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/
Provide helper macros to register PCI-based DRM drivers. The new
macros behave like module_pci_driver() with an additional test if
DRM modesetting has been enabled.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-internals.rst | 6 ++
include/drm/drm_module.h| 95
Remove custom bochs_init() and bochs_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/bochs.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/driv
This is an RFC patchset to complement the helper macros provided
in [1]. The module helpers create module init and exit helpers that
respect the kernel parameters that enable/disable DRM drivers.
There's one more patch that prepares qxl by moving some code around.
It's required to make use of the
Remove custom vbox_init() and vbox_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbo
Remove custom qxl_init() and qxl_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers
Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro
respects drm_firmware_drivers_only() and fails if the flag has been set.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --gi
Remove custom vmwgfx_init() and vmwgfx_exit() functions and initialize
the module with DRM_module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx
added some CCs Geert added in his reply
On 07.12.21 08:20, Thorsten Leemhuis wrote:
>
> [TLDR: adding this regression to regzbot; most of this mail is compiled
> from a few templates paragraphs some of you might have seen already.]
>
> Hi, this is your Linux kernel regression tracker speaking.
Remove custom mgag200_init() and mgag200_exit() functions and initialize
the module with DRM_module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mgag20
Remove custom cirrus_init() and cirrus_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/dri
Move the array qxl_ioctl to qxl_drv.c and initialize the num_ioctls
field of struct drm_driver at runtime. Replaces the current fragile
ioctl setup and allows for generating the module init/exit code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c | 12 +-
drivers/g
On Fri, Dec 17, 2021 at 03:46:21PM +0100, Thorsten Leemhuis wrote:
> added some CCs Geert added in his reply
>
> On 07.12.21 08:20, Thorsten Leemhuis wrote:
> >
> > [TLDR: adding this regression to regzbot; most of this mail is compiled
> > from a few templates paragraphs some of you might have s
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us movin
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but s
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
On 17-12-2021 14:55, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> Because we will start to require the obj->resv lock for unbinding,
>> ensure these shrinker functions also take the lock.
>>
>> This requires some function signature changes, to ensure that the
>
From: Markus Schneider-Pargmann
DP_INTF is similar to DPI but does not have the exact same feature set
or register layouts.
DP_INTF is the sink of the display pipeline that is connected to the
DisplayPort controller and encoder unit. It takes the same clocks as
DPI.
Signed-off-by: Markus Schnei
From: Markus Schneider-Pargmann
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms, as a normal display port and as an
embedded display
From: Markus Schneider-Pargmann
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split in
From: Markus Schneider-Pargmann
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
From: Markus Schneider-Pargmann
This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the mt8195. The phy is integrated into the
DisplayPort controller and will be created by the mtk-dp driver. This
driver expects a struct regmap to be able to work on the
From: Markus Schneider-Pargmann
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
It supports the mt8195, the external DisplayPort units. It offers
hot-plug-detection, audio up to 8 channels, and DisplayPort 1.4 with up
to 4 lanes.
The driver creates a child device for the phy.
This adds support of eDP panel to the mt8195 DP driver.
This driver is based on an initial version by
Jason-JH.Lin .
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 102 +-
1 file changed, 73 insertio
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> the special handling, all callers use the defaults anyway. We only remap
> in ggtt, so default case will fall through.
>
> Because we still don't require locking i
On 17-12-2021 12:58, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> Now that we cannot unbind kill the currently locked object directly
> "unbind kill"
>
>> because we're removing short term pinning, we may have to unbind the
>> object from gtt manually, using a
to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Javier-Martinez-Canillas/drm-Make-drivers-to-honour-the-nomodeset-paramete
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
>
> On 14/12/2021 15:07, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Log engine resets done by the GuC firmware in the similar way it is done
> > by the execlists backend.
> >
> > This way we have notion of where the han
From: Thierry Reding
Convert the Tegra host1x controller bindings from the free-form text
format to json-schema.
This also adds the missing display-hub DT bindings that were not
previously documented.
Signed-off-by: Thierry Reding
---
Changes in v4:
- add interconnect, interconnect-names, oper
On Fri, Dec 17, 2021 at 05:43:20PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> This also adds the missing display-hub DT bindings that were not
> previously documented.
>
> Signed-off-b
From: Thierry Reding
LEDs can use rfkill events as a trigger source, so document these in the
device tree bindings.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/leds/common.yaml| 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentat
From: Thierry Reding
Convert the Texas Instruments LP855x backlight device tree bindings from
the free-form text format to json-schema.
Signed-off-by: Thierry Reding
---
.../bindings/leds/backlight/lp855x.txt| 72 -
.../bindings/leds/backlight/ti,lp8550.yaml| 151 +
17.12.2021 15:06, Dmitry Osipenko пишет:
> 17.12.2021 15:02, Thierry Reding пишет:
>> On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote:
>>> 17.12.2021 14:12, Mark Brown пишет:
On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
> On Sat, Dec 04, 2021 at 05:37:07P
On 17.12.21 15:52, Imre Deak wrote:
> On Fri, Dec 17, 2021 at 03:46:21PM +0100, Thorsten Leemhuis wrote:
>> added some CCs Geert added in his reply
>>
>> On 07.12.21 08:20, Thorsten Leemhuis wrote:
>>>
>>> [TLDR: adding this regression to regzbot; most of this mail is compiled
>>> from a few tem
Am Fr., 17. Dez. 2021 um 11:59 Uhr schrieb Lucas Stach :
>
> Currently we allow rediculous ammounts of kernel memory being allocated
> via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
> some reasonable limits in to fix this.
>
> The commandstream size is limited to 64KB, whi
Hi,
After a hiatus in 2021, the upcoming FOSDEM will have a graphics DevRoom
again. This time round on a sunday, the 6th of February 2022.
As usual, the focus of this DevRoom is:
* Graphics drivers: from display to media to 3d drivers, both in kernel
or userspace. Be it part of DRM, KMS, V4L,
If you could get me a copy of the vbios image from a problematic board,
that would be helpful. In the meantime, I've applied the patch.
Alex
On Thu, Dec 16, 2021 at 9:38 PM 周宗敏 wrote:
> Dear Alex:
>
>
> >Is the issue reproducible with the same board in bare metal on x86?Or
> does it only happ
The pull request you sent on Fri, 17 Dec 2021 15:45:54 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f549bf33e3824b3f4a719afaf0fd2e01a07acd6
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
On Fri, 17 Dec 2021 14:25:01 +0100, Maxime Ripard wrote:
> The lvds.yaml file so far was both defining the generic LVDS properties
> (such as data-mapping) that could be used for any LVDS sink, but also
> the panel-lvds binding.
>
> That last binding was to describe LVDS panels simple enough, and
On Fri, 17 Dec 2021 16:08:48 +0100, Guillaume Ranquet wrote:
> From: Markus Schneider-Pargmann
>
> This controller is present on several mediatek hardware. Currently
> mt8195 and mt8395 have this controller without a functional difference,
> so only one compatible field is added.
>
> The control
This patchset is based on earlier work by Boris[1] that allowed to have an
ordered workqueue at the driver level that will be used by the different
schedulers to queue their timeout work. On top of that I also serialized
any GPU reset we trigger from within amdgpu code to also go through the same
o
Do it for both single device and XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 9 +
drivers/gpu/drm/amd/amd
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/d
1 - 100 of 115 matches
Mail list logo
