Hi Ezequiel,
Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.
Is there any reason, you do not want to enabe H.264 on RK3399? I know
H.264 can b
Hi Ezequiel,
Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
From: Paul Kocialkowski
The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
drivers/stag
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and arm64 secondary MMU. To
do this, this serie
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it
From: David Stevens
Introduce new gfn_to_pfn_page functions that parallel existing
gfn_to_pfn functions. The new functions are identical except they take
an additional out parameter that is used to return the struct page if
the hva was resolved by gup. This allows callers to differentiate the
gup
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 43 -
arch/x86/kvm/mmu/mmu_internal.h | 3 ++-
arch/x86/kvm/mmu/paging_tmpl.h | 23
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/arm64/kvm/mmu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm6
From: David Stevens
Remove two warnings that require ref counts for pages to be non-zero, as
mapped pfns from follow_pfn may not have an initialized ref count.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 7 ---
virt/kvm/kvm_main.c| 2 +-
2 files changed, 1 insertion(+), 8
Op 24-06-2021 om 14:04 schreef Daniel Vetter:
> On Thu, Jun 24, 2021 at 1:29 PM Thomas Hellström
> wrote:
>> Reinstate the mmap ioctl for all current integrated platforms.
>> The intention was really to have it disabled for discrete graphics
>> where we enforce a single mmap mode.
>>
>> Fixes: 35c
On 25.06.21 09:36, David Stevens wrote:
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which
On Fri, Jun 25, 2021 at 9:48 AM Maarten Lankhorst
wrote:
>
> Op 24-06-2021 om 14:04 schreef Daniel Vetter:
> > On Thu, Jun 24, 2021 at 1:29 PM Thomas Hellström
> > wrote:
> >> Reinstate the mmap ioctl for all current integrated platforms.
> >> The intention was really to have it disabled for disc
On 25/06/21 09:58, Christian Borntraeger wrote:
On 25.06.21 09:36, David Stevens wrote:
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_t
On Thu, Jun 24, 2021 at 6:17 PM Laurent Pinchart
wrote:
>
> On Thu, Jun 24, 2021 at 06:02:36PM +0530, Jagan Teki wrote:
> > Hi Laurent,
> >
> > On Thu, Jun 24, 2021 at 5:48 PM Laurent Pinchart
> > wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Thu, Jun 24, 2021 at 05:42:43PM +0530, Jagan Teki wrote:
Remove references to struct drm_device.irq_enabled from modern
DRM drivers and core.
KMS drivers enable IRQs for their devices internally. They don't
have to keep track of the IRQ state via irq_enabled. For vblanking,
it's cleaner to test for vblanking support directly than to test
for enabled IRQ
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct radeon_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel V
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct amdgpu_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel V
Remove the check around drm_irq_uninstall(). The same test is
done by the function internally. The tested state in irq_enabled
is considered obsolete and should not be used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Tian Tao
Acked-by: Daniel Vetter
For KMS drivers, replace the IRQ check in VBLANK ioctls with a check for
vblank support. IRQs might be enabled wthout vblanking being supported.
This change also removes the DRM framework's only dependency on IRQ state
for non-legacy drivers. For legacy drivers with userspace modesetting,
the orig
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct drm_i915_private.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in armada.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/armada/armada_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in komeda.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4
1 file
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in malidp.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_drv.c | 4
1 file changed, 4 del
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in kirin.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
1 file changed, 2 deletions(-)
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in imx.
v3:
* move dcss changes into separate patch (Laurentiu)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Philipp Zabel
Acked-by: Daniel Vetter
---
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in exynos.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --
1 file changed, 10 deletions(-
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in dcss.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Laurentiu Palcu
Acked-by: Daniel Vetter
---
drivers/gpu/drm/imx/dcss/dcss-kms.c | 3 ---
1 file changed, 3
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in mediatek.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 --
1 file changed, 6 deletions(-)
di
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct omap_drm_device.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel V
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in nouveau.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ---
1 file changed, 3 deletions(-)
diff --
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in rockchip.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
1 file changed, 6 deletions(-
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in sti.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_compositor.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in rcar-du.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in stm.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/stm/ltdc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/g
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in sun4i.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/d
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vkms.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/vkms/vkms_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vc4.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/g
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't use it in tidss.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tidss/tidss_irq.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in tegra.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Thierry Reding
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 7 ---
1 file changed, 7 del
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vmxgfx. All usage of
the field within vmwgfx can safely be removed.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwg
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in xlnx.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in zte.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/zte/zx_drm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/
On Thu, 24 Jun 2021, Uwe Kleine-König wrote:
> Hi Lee,
>
> On Tue, Jun 22, 2021 at 02:12:57PM +0100, Lee Jones wrote:
> > On Mon, 21 Jun 2021, Uwe Kleine-König wrote:
> >
> > > The practical upside here is that this only needs a single API call to
> > > program the hardware which (depending on t
Remove all references to DRM's IRQ midlayer.
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1caa0 ("drm/i915/gt: Call
Am 23.06.21 um 13:26 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:10:14 +0200
> Werner Sembach wrote:
>
>> Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:57:53 +0200
>>> Werner Sembach wrote:
>>>
Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18
On 24.06.21 14:57, Nicholas Piggin wrote:
Excerpts from Paolo Bonzini's message of June 24, 2021 10:41 pm:
On 24/06/21 13:42, Nicholas Piggin wrote:
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM support
Hi,
On 24.06.21 21:26, Ezequiel Garcia wrote:
From: Paul Kocialkowski
The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/media/rockchip-vpu.yam
On Thu, 24 Jun 2021 at 14:19, Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> On Thu, Jun 24, 2021 at 05:42:43PM +0530, Jagan Teki wrote:
> > On Thu, Jun 24, 2021 at 8:18 AM Fabio Estevam wrote:
> > > On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart wrote:
> > >
> > > > Looking at the register set, it s
Hi Steve,
Thinks for your reply.
When I only set the pte |= ARM_LPAE_PTE_SH_NS;there have no "GPU
Fault",When I set the pte |= ARM_LPAE_PTE_SH_IS(or
ARM_LPAE_PTE_SH_OS);there have "GPU Fault".I don't know how the pte
effect this issue?
Can you give me some suggestions again?
Hi Krzysztof,
On Fri, Jun 25, 2021 at 2:51 PM Krzysztof Kozlowski
wrote:
>
> On Thu, 24 Jun 2021 at 14:19, Laurent Pinchart
> wrote:
> >
> > Hi Jagan,
> >
> > On Thu, Jun 24, 2021 at 05:42:43PM +0530, Jagan Teki wrote:
> > > On Thu, Jun 24, 2021 at 8:18 AM Fabio Estevam wrote:
> > > > On Wed, Ju
On 25/06/2021 12:08, Jagan Teki wrote:
> Hi Krzysztof,
>
> On Fri, Jun 25, 2021 at 2:51 PM Krzysztof Kozlowski
> wrote:
>>
>> On Thu, 24 Jun 2021 at 14:19, Laurent Pinchart
>> wrote:
>>>
>>> Hi Jagan,
>>>
>>> On Thu, Jun 24, 2021 at 05:42:43PM +0530, Jagan Teki wrote:
On Thu, Jun 24, 2021 a
For some specialised objects we might need something larger than the
regions min_page_size due to some hw restriction, and slightly more
hairy is needing something smaller with the guarantee that such objects
will never be inserted into any GTT, which is the case for the paging
structures.
This al
The min_page_size is only needed for pages inserted into the GTT, and
for our paging structures we only need at most 4K bytes, so simply
ignore the min_page_size restrictions here, otherwise we might see some
severe overallocation on some devices.
v2(Thomas): add some commentary
Signed-off-by: Ma
On 24/06/2021 19:31, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
Signed-off-by: Thomas H
On 25.06.2021 00:41, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 17:49, Matthew Brost wrote:
>>> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
On 24.06.2021 09:04, Matthew Brost wrote:
> Ad
On 24.06.2021 09:04, Matthew Brost wrote:
> Improve the error message when a unsolicited CT response is received by
> printing fence that couldn't be found, the last fence, and all requests
> with a response outstanding.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/inte
On 24.06.2021 17:41, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 03:49:55PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 09:04, Matthew Brost wrote:
>>> With the introduction of non-blocking CTBs more than one CTB can be in
>>> flight at a time. Increasing the size of the CTBs should
Add binding for the Innolux EJ030NA panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Paul Cercueil
---
.../display/panel/innolux,ej030na.yaml| 62 +++
1 file changed, 62 insertions(+)
create mo
From: Christophe Branchereau
Add support for the Innolux/Chimei EJ030NA 3.0"
320x480 TFT panel.
This panel can be found in the LDKs, RS97 V2.1 and RG300 (non IPS)
handheld gaming consoles.
While being 320x480, it is actually a horizontal 4:3
panel with non-square pixels in delta arrangement.
S
This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.
v2: rebase and also update set_domain
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Daniel Vetter
-
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX, so hopefully can also be safely rejected.
On Thu, Jun 24, 2021 at 03:19:48PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory
https://bugzilla.kernel.org/show_bug.cgi?id=213569
--- Comment #2 from Martin (martin...@gmx.com) ---
In my case it was watching a video that made the gpu reach 70°C
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
On 24.06.2021 09:04, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail) which could result in accesses across the PCIe bus,
> store shadow local copies and only read/
The simplefb and simpledrm drivers match against a "simple-framebuffer"
device, but for aarch64 this is only registered when using Device Trees
and there's a node with a "simple-framebuffer" compatible string.
There is no code to register a "simple-framebuffer" platform device when
using EFI inste
The x86 architecture has generic support to register a system framebuffer
platform device. It either registers a "simple-framebuffer" if the config
option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device.
But the code is generic enough to be reused by other architectures and can
be m
The register_gop_device() function registers an "efi-framebuffer" platform
device to match against the efifb driver, to have an early framebuffer for
EFI platforms.
But there is already support to do exactly the same by the Generic System
Framebuffers (sysfb) driver. This used to be only for X86 b
On 24.06.2021 09:04, Matthew Brost wrote:
> Add lrc descriptor context lookup array which can resolve the
> intel_context from the lrc descriptor index. In addition to lookup, it
> can determine in the lrc descriptor context is currently registered with
> the GuC by checking if an entry for a de
On 24.06.2021 09:04, Matthew Brost wrote:
> Implement GuC context operations which includes GuC specific operations
> alloc, pin, unpin, and destroy.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 5 +
> drivers/gpu/d
Hello,
This is a merge of [1] and [2] since the second series depends on
patches in the preparatory series.
The main change in this v3 is the addition of patch 1 and 9 simplifying
the reset synchronisation as suggested by Daniel.
Also addressed Steve's comments, and IGT tests are now passing rel
Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
reset. This leads to extra complexity when we need to synchronize timeout
works with the reset work. One solution to address that is to have an
ordered workqueue at the driver level that will be used by the different
schedulers
Now that we can pass our own workqueue to drm_sched_init(), we can use
an ordered workqueue on for both the scheduler timeout tdr and our own
reset work (which we use when the reset is not caused by a fault/timeout
on a specific job, like when we have AS_ACTIVE bit stuck). This
guarantees that the
If the process who submitted these jobs decided to close the FD before
the jobs are done it probably means it doesn't care about the result.
v3:
* Set fence error to ECANCELED when a TERMINATED exception is received
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 43
Expose a helper to trigger a GPU reset so we can easily trigger reset
operations outside the job timeout handler.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 8
drivers/gpu/drm/panfrost/panfrost_job.c| 4 +---
2 files ch
Exception types will be defined as an enum in panfrost_drm.h so userspace
and use the same definitions if needed.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/
Currently unused. We'll add it back if we need per-GPU definitions.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 2 +-
drivers/gpu/drm/panfrost/panfrost_gpu.c| 2 +-
drivers/gpu/d
Things are unlikely to resolve until we reset the GPU. Let's not wait
for other faults/timeout to happen to trigger this reset.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --
This is not yet needed because we let active jobs be killed during by
the reset and we don't really bother making sure they can be restarted.
But once we start adding soft-stop support, controlling when we deal
with the remaining interrrupts and making sure those are handled before
the reset is iss
This should avoid switching to interrupt context when the GPU is under
heavy use.
v3:
* Don't take the job_lock in panfrost_job_handle_irq()
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 53 ++---
1 file changed, 38 insertions(+), 15 deletions(
If we can recover from a fault without a reset there's no reason to
issue one.
v3:
* Drop the mention of Valhall requiring a reset on JOB_BUS_FAULT
* Set the fence error to -EINVAL instead of having per-exception
error codes
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost
Do the exception -> string translation using a table. This way we get
rid of those magic numbers and can easily add new fields if we need
to attach extra information to exception types.
v3:
* Drop the error field
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_device.c | 13
From: Steven Price
The hardware has a set of '_NEXT' registers that can hold a second job
while the first is executing. Make use of these registers to enqueue a
second job per slot.
v3:
* Fix the done/err job dequeuing logic to get a valid active state
* Only enable the second slot on GPUs suppo
Job headers contain an exception type field which might be read and
converted to a human readable string by tracing tools. Let's expose
the exception type as an enum so we share the same definition.
v3:
* Add missing values
Signed-off-by: Boris Brezillon
---
include/uapi/drm/panfrost_drm.h | 71
If the fence creation fail, we can return the error pointer directly.
The core will update the fence error accordingly.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
If we don't do that, we have to wait for the job timeout to expire
before the fault jobs gets killed.
v3:
* Make sure the AS is re-enabled when new jobs are submitted to the
context
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/
> Exception types will be defined as an enum in panfrost_drm.h so userspace
> and use the same definitions if needed.
s/and/can/, with that R-b
R-b
I'm not convinced. Right now most of our UABI is pleasantly
GPU-agnostic. With this suddenly there's divergence between Midgard and
Bifrost uABI. With that drawback in mind, could you explain the benefit?
On Fri, Jun 25, 2021 at 03:33:17PM +0200, Boris Brezillon wrote:
> Job headers contain an exc
Am Freitag, dem 25.06.2021 um 15:33 +0200 schrieb Boris Brezillon:
> If the process who submitted these jobs decided to close the FD before
> the jobs are done it probably means it doesn't care about the result.
>
> v3:
> * Set fence error to ECANCELED when a TERMINATED exception is received
>
>
> Currently unused. We'll add it back if we need per-GPU definitions.
We will, if not for Valhall v9, certainly for Valhall v10 with the CSF..
R-b
On Fri, Jun 25, 2021 at 03:33:14PM +0200, Boris Brezillon wrote:
> If the fence creation fail, we can return the error pointer directly.
> The core will update the fence error accordingly.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfr
R-b
A-b, but could you explain the context? Thanks
On Fri, Jun 25, 2021 at 03:33:20PM +0200, Boris Brezillon wrote:
> This should avoid switching to interrupt context when the GPU is under
> heavy use.
>
> v3:
> * Don't take the job_lock in panfrost_job_handle_irq()
>
> Signed-off-by: Boris Brezillo
Am 25.06.21 um 15:13 schrieb Javier Martinez Canillas:
The register_gop_device() function registers an "efi-framebuffer" platform
device to match against the efifb driver, to have an early framebuffer for
EFI platforms.
But there is already support to do exactly the same by the Generic System
On Fri, 25 Jun 2021 09:42:08 -0400
Alyssa Rosenzweig wrote:
> I'm not convinced. Right now most of our UABI is pleasantly
> GPU-agnostic. With this suddenly there's divergence between Midgard and
> Bifrost uABI.
Hm, I don't see why. I mean the exception types seem to be the same,
there are just
On Fri, 25 Jun 2021 09:47:59 -0400
Alyssa Rosenzweig wrote:
> A-b, but could you explain the context? Thanks
The rational behind this change is the complexity added to the
interrupt handler in patch 15. That means we might spend more time in
interrupt context after that patch and block other thi
On Fri, 25 Jun 2021 15:43:45 +0200
Lucas Stach wrote:
> Am Freitag, dem 25.06.2021 um 15:33 +0200 schrieb Boris Brezillon:
> > If the process who submitted these jobs decided to close the FD before
> > the jobs are done it probably means it doesn't care about the result.
> >
> > v3:
> > * Set fe
On 25/06/2021 14:33, Boris Brezillon wrote:
> Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
> reset. This leads to extra complexity when we need to synchronize timeout
> works with the reset work. One solution to address that is to have an
> ordered workqueue at the driver
On Fri, 25 Jun 2021 16:07:03 +0100
Steven Price wrote:
> On 25/06/2021 14:33, Boris Brezillon wrote:
> > Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
> > reset. This leads to extra complexity when we need to synchronize timeout
> > works with the reset work. One solution
On 25/06/2021 15:21, Boris Brezillon wrote:
> On Fri, 25 Jun 2021 09:42:08 -0400
> Alyssa Rosenzweig wrote:
>
>> I'm not convinced. Right now most of our UABI is pleasantly
>> GPU-agnostic. With this suddenly there's divergence between Midgard and
>> Bifrost uABI.
>
> Hm, I don't see why. I mean
On 25/06/2021 14:33, Boris Brezillon wrote:
> Do the exception -> string translation using a table. This way we get
> rid of those magic numbers and can easily add new fields if we need
> to attach extra information to exception types.
>
> v3:
> * Drop the error field
>
> Signed-off-by: Boris Bre
1 - 100 of 141 matches
Mail list logo
