Hi Laurent,
On Thu, Jun 17, 2021 at 3:57 AM Laurent Pinchart
wrote:
> On Thu, Apr 29, 2021 at 06:47:06PM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 29, 2021 at 02:47:31PM +0200, Geert Uytterhoeven wrote:
> > > The "resets" property is not present on R-Car Gen1 SoCs.
> > > Supporting it would
Am 16.06.21 um 20:30 schrieb Jason Ekstrand:
On Tue, Jun 15, 2021 at 3:41 AM Christian König
wrote:
Hi Jason & Daniel,
maybe I should explain once more where the problem with this approach is
and why I think we need to get that fixed before we can do something
like this here.
To summarize wha
On 15.06.2021 13:15:43, Rob Herring wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final sche
Fix a potential NULL pointer exception when meson_drv_unbind()
attempts to operate on the driver_data priv which may be NULL.
Add a null pointer check on the priv struct to avoid the NULL
pointer dereference after calling dev_get_drvdata(), just like
the null pointer checks done on the struct priv
In function nvkm_ioctl_map(), the variable "type" could be
uninitialized if "nvkm_object_map()" returns error code,
however, it does not check the return value and directly
use the "type" in the if statement, which is potentially
unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/drm/nouveau/nvkm/cor
Am 16.06.21 um 21:19 schrieb Dan Carpenter:
On Wed, Jun 16, 2021 at 01:00:38PM +0200, Christian König wrote:
Am 16.06.21 um 11:36 schrieb Dan Carpenter:
On Wed, Jun 16, 2021 at 10:47:14AM +0200, Christian König wrote:
Am 16.06.21 um 10:37 schrieb Dan Carpenter:
On Wed, Jun 16, 2021 at 08:
Alex do want to review those so that we can close the ticket?
Thanks,
Christian.
Am 14.06.21 um 19:45 schrieb Christian König:
Unwrap the explicit fence if it is a dma_fence_chain and
sync to the first fence not matching the owner rules.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
From: ChunyouTang
The 'break' can cause 'Memory manager not clean during takedown'
It cannot use break to finish the circulation,it should use
continue to traverse the circulation.it should put every mapping
which is not NULL.
Signed-off-by: ChunyouTang
---
drivers/gpu/drm/panfrost/panfrost
On 03-06-21, 16:40, abhin...@codeaurora.org wrote:
> On 2021-06-02 04:01, Vinod Koul wrote:
> > On 27-05-21, 16:30, Rob Clark wrote:
> >
> > yeah that is always a very different world. although it might make sense
> > to use information in tables and try to deduce information about the
> > system
[Public]
Really sorry for the mistake that I made and any inconvenience it brought.
Thanks José and Lyude.
Regards,
Wayne
> From: Lyude Paul
> Sent: Thursday, June 17, 2021 03:47
> To: José Roberto de Souza; intel-...@lists.freedesktop.org
> Cc: dri-deve
On Wed, 16 Jun 2021 16:38:42 +0200
Maxime Ripard wrote:
> New KMS properties come with a bunch of requirements to avoid each
> driver from running their own, inconsistent, set of properties,
> eventually leading to issues like property conflicts, inconsistencies
> between drivers and semantics, e
On Wed, Jun 16, 2021 at 11:45:28AM +0100, Matthew Auld wrote:
> On Wed, 16 Jun 2021 at 10:04, Daniel Vetter wrote:
> >
> > Between
> >
> > commit ae30af84edb5b7cc95485922e43afd909a892e1b
> > Author: Maarten Lankhorst
> > Date: Tue Mar 23 16:50:00 2021 +0100
> >
> > drm/i915: Disable userptr
[AMD Official Use Only]
> From: Wentland, Harry
> Sent: Thursday, June 17, 2021 03:53
> To: Lin, Wayne; dri-devel@lists.freedesktop.org
> Cc: ly...@redhat.com; Kazlauskas, Nicholas; Zuo, Jerry; Pillai, Aurabindo;
> Maarten Lankhorst; Maxime Ripard; Thomas
On Thu, 17 Jun 2021 00:05:24 +0300
Laurent Pinchart wrote:
> On Tue, Jun 15, 2021 at 01:16:56PM +0300, Pekka Paalanen wrote:
> > On Tue, 15 Jun 2021 12:45:57 +0300 Laurent Pinchart wrote:
> > > On Tue, Jun 15, 2021 at 07:15:18AM +, Simon Ser wrote:
> > > > On Tuesday, June 15th, 2021 at 0
On Tue, 15 Jun 2021 at 21:15, Rob Herring wrote:
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the f
+ a bunch of recent committers to libdrm
Guys, anyone okay to push this patch? I can resend if required.
Regards,
Tvrtko
On 19/11/2020 13:58, Tvrtko Ursulin wrote:
On 19/11/2020 13:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-19 13:42:07)
On 18/11/2020 17:04, Chris Wilson wro
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/Christian-K-nig/dma-buf-fix-and-rework-dma_buf_poll/20210617-103036
base:c7d4c1fd91ab4a6d2620497921a9c6bf54650ab8
config: x86_64-
On Sat, 2021-06-12 at 17:17 +0200, Stefan Wahren wrote:
> Hi,
>
> while testing the mainline kernel (arm64, defconfig) on Raspberry Pi 3 B
> Plus with Raspberry Pi OS - 64 bit, sometimes X doesn't start into
> desktop properly (unexpected and unusable login screen instead of auto
> login or mouse
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/Christian-K-nig/dma-buf-fix-and-rework-dma_buf_poll/20210617-103036
base:c7d4c1fd91ab4a6d2620497921a9c6bf54650ab8
config: s390-
On 2021-06-15 at 13:36:00 +0200, Thomas Hellström wrote:
> To help avoid evicting already resident buffers from the batch we're
> processing, perform locking as a separate step.
>
Looks reasonable to me.
Reviewed-by: Ramalingam C
> Signed-off-by: Thomas Hellström
> ---
> .../gpu/drm/i915/gem/
On 6/17/21 11:56 AM, Ramalingam C wrote:
On 2021-06-15 at 13:36:00 +0200, Thomas Hellström wrote:
To help avoid evicting already resident buffers from the batch we're
processing, perform locking as a separate step.
Looks reasonable to me.
Reviewed-by: Ramalingam C
Thanks for reviewing!
Op 15-06-2021 om 13:36 schreef Thomas Hellström:
> To help avoid evicting already resident buffers from the batch we're
> processing, perform locking as a separate step.
>
> Signed-off-by: Thomas Hellström
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 ---
> 1 file ch
On Thu, 17 Jun 2021 at 10:36, nicolas saenz julienne wrote:
> Frankly I don't know if there is a better way. IIRC opensuse and downstream
> use
> DT overlays to cater for this limitation. It seems reasonable to bump the
> value. But it'll be in detriment of users that don't care much for graphica
Hi Pekka,
On Thu, Jun 17, 2021 at 10:27:01AM +0300, Pekka Paalanen wrote:
> On Thu, 17 Jun 2021 00:05:24 +0300 Laurent Pinchart wrote:
> > On Tue, Jun 15, 2021 at 01:16:56PM +0300, Pekka Paalanen wrote:
> > > On Tue, 15 Jun 2021 12:45:57 +0300 Laurent Pinchart wrote:
> > > > On Tue, Jun 15, 2021
The bridge chip "ANX7625" requires the packets on lanes to aligne at the end,
or ANX7625 will shift the screen.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm
Hi guys,
during the recent discussion about SLAB_TYPESAFE_BY_RCU, dma_fence_get_rcu and
dma_fence_get_rcu_safe we found that the RCU handling for dma_resv objects was
implemented multiple times.
Unfortunately a lot of those implementations get the rather complicated dance
with RCU and the sequ
A simpler version of the iterator to be used when the dma_resv object is
locked.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 38 ++
include/linux/dma-resv.h | 18 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 81 +++---
1 file changed, 32 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dr
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 44
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 862eb3
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 63 +++
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 54 +-
1 file changed, 7 insertions(+), 47 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_ge
This is probably a fix since we didn't even grabed a reference to the
fences.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index db53fe
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 49 ---
1 file changed, 4 insertions(+), 45 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drive
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 110 +
1 file changed, 37 insertions(+), 73 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dri
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 48 +++--
1 file changed, 12 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 05d0b3eb
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Signed-off-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 80dff29f2bc7..d86b0c
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 64 +-
1 file changed, 7 insertions(+), 57 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/drivers/gpu/drm/radeon/radeon_sync.c
index 9257b60144c4..14a4d81
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b8fa6e
Simplifying the code a bit.
Untested since I can't get the driver to compile on !ARM.
Signed-off-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/ms
If attach has not been called, unloading the driver can result in a null
pointer dereference in mipi_dsi_detach as ctx->dsi has not been assigned
yet.
Fixes: ceb515ba29ba6b ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and
SN65DSI84 driver")
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/bridge
On Mon, Jun 14, 2021 at 01:43:27PM +0300, Dan Carpenter wrote:
> If nvkm_object_init() fails then we should not call nvkm_object_fini()
> because it results in calling object->func->fini(object, suspend) twice.
> Once inside the nvkm_object_init() function and once inside the
> nvkm_object_fini() f
The drm_file pointer clears to zero during multi-user switching,
so it needs to call drm_new_set_master for master pointer from drm_file.
Signed-off-by: Qiang Ma
---
drivers/gpu/drm/drm_auth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/driver
On 6/17/21 1:19 PM, Jonathan Liu wrote:
If attach has not been called, unloading the driver can result in a null
pointer dereference in mipi_dsi_detach as ctx->dsi has not been assigned
yet.
Fixes: ceb515ba29ba6b ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84
driver")
Signed-off-by:
On Thu, 17 Jun 2021 13:29:48 +0300
Laurent Pinchart wrote:
> Hi Pekka,
>
> On Thu, Jun 17, 2021 at 10:27:01AM +0300, Pekka Paalanen wrote:
> > On Thu, 17 Jun 2021 00:05:24 +0300 Laurent Pinchart wrote:
> > > On Tue, Jun 15, 2021 at 01:16:56PM +0300, Pekka Paalanen wrote:
> > > > On Tue, 15 J
Hi Pekka,
On Thu, Jun 17, 2021 at 02:33:11PM +0300, Pekka Paalanen wrote:
> On Thu, 17 Jun 2021 13:29:48 +0300 Laurent Pinchart wrote:
> > On Thu, Jun 17, 2021 at 10:27:01AM +0300, Pekka Paalanen wrote:
> > > On Thu, 17 Jun 2021 00:05:24 +0300 Laurent Pinchart wrote:
> > > > On Tue, Jun 15, 2021
On Tue, Jun 15, 2021 at 2:15 PM Rob Herring wrote:
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the
This patch series reworks DPU's irq handling code by merging
dpu_core_irq into dpu_hw_intr, reworking/dropping irq-related helpers
and wrappers, etc.
Dependencies:
https://lore.kernel.org/linux-arm-msm/20210611170003.3539059-1-bjorn.anders...@linaro.org/
-
As dpu_core_irq was merged into dpu_hw_intr, merge data structures too,
removing the need for a separate data structure.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 51 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 5 ++
drivers/gpu/
With dpu_core_irq being the wrapper around dpu_hw_interrupts, there is
little sense in having them separate. Squash them together to remove
another layer of abstraction (hw_intr ops).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/d
We already clear the IRQ status register before processing IRQs, so do
not clear the register again. Especially do not clear the IRQ status
_after_ processing the IRQ as this way we can loose the event.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 17
Get rid of dpu_encoder_helper_register_irq/unregister_irq helpers, call
dpu_core_register/unregister_callback directly, without surrounding them
with helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 64 ---
.../gpu/drm/msm/disp/dpu1/dpu
Drop the wrapping structures and the enum used to index those structures
in dpu_kms. Instead of them use IRQ indices and callback functions
directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 47 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |
The struct dpu_irq_callbacks looks internal to IRQ handling code. Hide
it from the rest of the DPU driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 18 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_p
Remove extra dpu_irq_* wrappers from dpu_kms.c, merge them directly into
dpu_core_irq_* functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 12 -
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 9 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
Hi Jonathan,
Thank you for the patch.
On Thu, Jun 17, 2021 at 09:19:25PM +1000, Jonathan Liu wrote:
> If attach has not been called, unloading the driver can result in a null
> pointer dereference in mipi_dsi_detach as ctx->dsi has not been assigned
> yet.
Shouldn't this be done in a brige .deta
Hi,
On 17/06/2021 09:07, Jiajun Cao wrote:
> Fix a potential NULL pointer exception when meson_drv_unbind()
> attempts to operate on the driver_data priv which may be NULL.
> Add a null pointer check on the priv struct to avoid the NULL
> pointer dereference after calling dev_get_drvdata(), just l
On 6/16/21 1:50 AM, rajee...@codeaurora.org wrote:
On 03-06-2021 01:32, rajee...@codeaurora.org wrote:
On 02-06-2021 02:28, Rob Herring wrote:
On Mon, May 31, 2021 at 07:03:53PM +0530, Rajeev Nandan wrote:
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,dsi-phy-7nm
When woul
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
v2:
- rebased on DSI PHY reworks
- reworked getting cphy_mode in dsi_host.c
- documentation change in separate patch
v3:
- yaml bindings
- ch
These got lost when going from .txt to .yaml bindings, add them back.
Signed-off-by: Jonathan Marek
---
.../bindings/display/msm/dsi-phy-7nm.yaml | 66 +++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
di
Document a new phy-type property which will be used to determine whether
the phy should operate in D-PHY or C-PHY mode.
Signed-off-by: Jonathan Marek
Reviewed-by: Laurent Pinchart
---
.../devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 5 +
include/dt-bindings/phy/phy.h
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 2 +
drivers/gpu/drm/msm/dsi/dsi_h
v1:
AMD is building a system architecture for the Frontier supercomputer with a
coherent interconnect between CPUs and GPUs. This hardware architecture allows
the CPUs to coherently access GPU device memory. We have hardware in our labs
and we are working with our partner HPE on the BIOS, firmware
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
v2:
[AS]: rename dax_layout_is_idle_page func to dax_page_unused
Signed-off-by: Ral
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
The AMD architecture for the Frontier supercomputer will
have device memory which can be coherently accessed by
the CPU. The system BIOS advertises this memory as SPM
(special purpose memory) in the UEFI system address map.
The AMDGPU driver needs to be able to lookup this resource
in order to cla
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_GENERIC to create the device
page map region.
Sign
Generic device type memory on VRAM to RAM migration,
has similar access as System RAM from the CPU. This flag sets
the source from the sender. Which in Generic type case,
should be set as SYSTEM.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d8d79bb94be8..f5b247
Device generic type case added for migrate_vma_pages and
migrate_vma_check_page helpers.
Both, generic and private device types have the same
conditions to decide to migrate pages from/to device
memory.
Signed-off-by: Alex Sierra
---
mm/migrate.c | 8
1 file changed, 4 insertions(+), 4
Add MEMORY_DEVICE_GENERIC case to free_zone_device_page
callback.
Device generic type memory case is now able to free its
pages properly.
Signed-off-by: Alex Sierra
---
mm/memremap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index 614b
Hi Stefan,
On Sat, Jun 12, 2021 at 12:04:08PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 04.06.21 um 11:02 schrieb Maxime Ripard:
> > Hi Stefan,
> >
> > I would assume it's due to this:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/vc4/vc4_hdmi.c
> -Original Message-
> From: Intel-gfx On Behalf Of
> Thomas Hellström
> Sent: Tuesday, June 15, 2021 4:36 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Thomas Hellström ; Auld, Matthew
>
> Subject: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer objec
On 6/16/21 4:38 PM, Maxime Ripard wrote:
New KMS properties come with a bunch of requirements to avoid each
driver from running their own, inconsistent, set of properties,
eventually leading to issues like property conflicts, inconsistencies
between drivers and semantics, etc.
Let's document
On 6/17/2021 10:16 AM, Alex Sierra wrote:
v1:
AMD is building a system architecture for the Frontier supercomputer with a
coherent interconnect between CPUs and GPUs. This hardware architecture allows
the CPUs to coherently access GPU device memory. We have hardware in our labs
and we are worki
On Thu, Jun 17, 2021 at 10:16:58AM -0500, Alex Sierra wrote:
> From: Ralph Campbell
>
> There are several places where ZONE_DEVICE struct pages assume a reference
> count == 1 means the page is idle and free. Instead of open coding this,
> add a helper function to hide this detail.
>
> v2:
> [AS
On Thu, Jun 17, 2021 at 8:09 AM Jonathan Marek wrote:
>
> These got lost when going from .txt to .yaml bindings, add them back.
>
Fixes: 8fc939e72ff8 ("dt-bindings: msm: dsi: add yaml schemas for DSI
PHY bindings")
> Signed-off-by: Jonathan Marek
> ---
> .../bindings/display/msm/dsi-phy-7nm.ya
On Thu 17 Jun 01:24 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Wed, Jun 16, 2021 at 10:22:17PM -0500, Bjorn Andersson wrote:
> > > > +static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device
> > > > *pwm,
> > > > + const struct pwm_state *state)
>
Sorry I'm behind on mails ...
On Fri, Jun 11, 2021 at 12:50:29PM -0700, Matthew Brost wrote:
> On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > > Add entry for i915 new parallel submission uAPI plan.
> > >
> > >
On Mon, Jun 14, 2021 at 07:13:00PM +0200, Christian König wrote:
> As long as we can figure out who touched to a certain sync object last that
> would indeed work, yes.
Don't you need to know who will touch it next, i.e. who is holding up your
fence? Or maybe I'm just again totally confused.
-Dani
On Mon, Jun 14, 2021 at 09:25:44AM +0200, Christian König wrote:
> Am 11.06.21 um 17:18 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 12:09:19PM +0200, Christian König wrote:
> > > Am 11.06.21 um 11:07 schrieb Daniel Vetter:
> > > > On Thu, Jun 10, 2021 at 11:17:59AM +0200, Christian König wro
On Thu, Jun 17, 2021 at 09:41:35AM +0200, Christian König wrote:
>
>
> Am 16.06.21 um 21:19 schrieb Dan Carpenter:
> > On Wed, Jun 16, 2021 at 01:00:38PM +0200, Christian König wrote:
> > >
> > > Am 16.06.21 um 11:36 schrieb Dan Carpenter:
> > > > On Wed, Jun 16, 2021 at 10:47:14AM +0200, Christ
Hello Bjorn,
On Thu, Jun 17, 2021 at 11:38:26AM -0500, Bjorn Andersson wrote:
> On Thu 17 Jun 01:24 CDT 2021, Uwe Kleine-K?nig wrote:
> > On Wed, Jun 16, 2021 at 10:22:17PM -0500, Bjorn Andersson wrote:
> > > > > +static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device
> > > > > *pwm,
On Mon, Jun 14, 2021 at 07:15:44PM +0200, Christian König wrote:
> Am 11.06.21 um 16:55 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 04:53:11PM +0200, Christian König wrote:
> > >
> > > Am 11.06.21 um 16:47 schrieb Daniel Vetter:
> > > > On Fri, Jun 11, 2021 at 02:02:57PM +0200, Christian Kö
On Fri, Jun 11, 2021 at 04:40:42PM -0700, Matthew Brost wrote:
> Subject and patches say it all.
>
> v2: Address comments, patches have details of changes
> v3: Address comments, patches have details of changes
> v4: Address comments, patches have details of changes
>
> Signed-off-by: Matthew Bro
On Tue, Jun 15, 2021 at 10:36:44AM +0800, Desmond Cheong Zhi Xi wrote:
> While checking the master status of the DRM file in
> drm_is_current_master(), the device's master mutex should be
> held. Without the mutex, the pointer fpriv->master may be freed
> concurrently by another process calling drm
On Tue, Jun 15, 2021 at 10:36:45AM +0800, Desmond Cheong Zhi Xi wrote:
> This patch ensures that the device's master mutex is acquired before
> accessing pointers to struct drm_master that are subsequently
> dereferenced. Without the mutex, the struct drm_master may be freed
> concurrently by anoth
On Mon, Jun 14, 2021 at 10:09:59AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A little bit of documentation covering the topics of engine discovery,
> context engine maps and virtual engines. It is not very detailed but
> supposed to be a starting point of giving a brief high level o
On Wed, Jun 16, 2021 at 03:29:26PM +0100, Matthew Auld wrote:
> On Mon, 14 Jun 2021 at 10:22, Matthew Auld wrote:
> >
> > Purely for CI so we can get some pre-merge results for DG1. This is
> > especially useful for cross driver TTM changes where CI can hopefully
> > catch regressions. This is sim
On Mon, Jun 14, 2021 at 09:45:37PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> We are observing some user-space crashes (sigabort, segfaults etc.)
> under moderate memory pressure (pretty far from severe pressure) which
> have one thing in common - restrictive GFP mask in setup_scratch_page().
>
>
On Thu, Jun 17, 2021 at 09:44:25AM +0200, Christian König wrote:
> Alex do want to review those so that we can close the ticket?
Maybe I'm behind on mails, but 2nd patch still has the issues I think I'm
seeing ...
-Daniel
>
> Thanks,
> Christian.
>
> Am 14.06.21 um 19:45 schrieb Christian König
On Tue, Jun 15, 2021 at 01:21:17PM +0200, Christian König wrote:
> Daniel pointed me towards this function and there are multiple obvious
> problems
> in the implementation.
>
> First of all the retry loop is not working as intended. In general the retry
> makes only sense if you grab the referen
On Thu, Jun 17, 2021 at 06:46:48PM +0200, Daniel Vetter wrote:
> Sorry I'm behind on mails ...
>
Aren't we all.
> On Fri, Jun 11, 2021 at 12:50:29PM -0700, Matthew Brost wrote:
> > On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> > > On Wed, May 26, 2021 at 04:33:57PM -0700, Mat
On Tue, Jun 15, 2021 at 07:35:20PM +0800, Wan Jiabing wrote:
> Fix the following checkinclude.pl warning:
> drivers/gpu/drm/i915/gt/intel_region_lmem.c
> 8 #include "intel_region_lmem.h"
> 12 #include "intel_region_lmem.h"
>
> Signed-off-by: Wan Jiabing
Applied to drm-intel-gt-nex
Hi Maxime,
Am 17.06.21 um 17:25 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Sat, Jun 12, 2021 at 12:04:08PM +0200, Stefan Wahren wrote:
>> Hi Maxime,
>>
>> Am 04.06.21 um 11:02 schrieb Maxime Ripard:
>>> Hi Stefan,
>>>
>>> I would assume it's due to this:
>>> https://git.kernel.org/pub/scm/linux/ke
On Tue, Jun 15, 2021 at 07:17:13PM -0800, Yu Jiahua wrote:
> From: Jiahua Yu
>
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Signed-off-by: Jiahua Yu
Stuffed into drm-misc-next. The subject looked a bit strange, so I f
On Wed, Jun 16, 2021 at 02:01:58PM +0800, Jiapeng Chong wrote:
> Clean up the following includecheck warning:
>
> ./drivers/gpu/drm/i915/gt/intel_region_lmem.c: intel_region_lmem.h is
> included more than once.
>
> No functional change.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chon
Hi Nicolas,
Am 17.06.21 um 11:36 schrieb nicolas saenz julienne:
> On Sat, 2021-06-12 at 17:17 +0200, Stefan Wahren wrote:
>> Hi,
>>
>> while testing the mainline kernel (arm64, defconfig) on Raspberry Pi 3 B
>> Plus with Raspberry Pi OS - 64 bit, sometimes X doesn't start into
>> desktop properly
1 - 100 of 164 matches
Mail list logo
