Hi Joel,
That seems like a genuine bug. Could you file it at the i915 bug tracker
with all the requested information to make sure we can take a look at
it:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
Are you able to try different kernel versions to bisect which kernel
Hi, Maxime
Thank you for reply.
On 2021/06/21 18:24, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jun 21, 2021 at 09:10:19AM +0200, Thomas Zimmermann wrote:
>> Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
>>> Virtual DRM splits the overlay planes of a display controller into multiple
>>> virtual
Hi, Rob
Thank you for the error report and advice.
I will recheck DT binding.
Best regards
Tomohito Esaki
On 2021/06/22 2:40, Rob Herring wrote:
> On Mon, 21 Jun 2021 15:44:02 +0900, Tomohito Esaki wrote:
>> Add device tree bindings documentation for virtual DRM.
>>
>> Signed-off-by: Tomohito
Hi, Sam
Thank you for looking at the details.
I will fix it according to your comment.
Best regards
Tomohito Esaki
On 2021/06/22 0:55, Sam Ravnborg wrote:
> Hi Tomohito
>
> On Mon, Jun 21, 2021 at 03:44:00PM +0900, Tomohito Esaki wrote:
>> Virtual DRM splits the resources of an overlay plane
Hi, Enrico Weigelt
Thank you for reply.
On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote:
> On 21.06.21 08:27, Tomohito Esaki wrote:
>
> Hi,
>
>> Virtual DRM splits the overlay planes of a display controller into multiple
>> virtual devices to allow each plane to be accessed by each
Hi, Thomas
Thank you for reply.
On 2021/06/21 16:10, Thomas Zimmermann wrote:
> Hi
>
> Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
>> Virtual DRM splits the overlay planes of a display controller into
>> multiple
>> virtual devices to allow each plane to be accessed by each process.
>>
>> This
Hi all,
Today's linux-next merge of the devicetree tree got conflicts in:
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
Documentation/devicetree/bindings/media/renesas,drif.yaml
Documentation/devicetree/bindings/net/stm32-dwmac.yaml
between commits:
7169d082e7e6
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 exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Signed-off-by: Bjorn
The existing pxa driver and the upcoming addition of PWM support in the
TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
thereby a need for a of_xlate function with the period as its single
argument.
Introduce a common helper function in the core that can be used as
of_xlate
On Mon, Jun 21, 2021 at 2:25 AM Jagan Teki wrote:
>
> Add eLCDIF controller node for i.MX8MM.
>
> Cc: Rob Herring
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git
On Mon, Jun 21, 2021 at 2:25 AM Jagan Teki wrote:
>
> Add MIPI DSI pipeline for i.MX8MM.
>
> Video pipeline start from eLCDIF to MIPI DSI and respective
> Panel or Bridge on the backend side.
>
> Add support for it.
>
> Cc: Rob Herring
> Signed-off-by: Jagan Teki
> ---
>
Hi Steve,
I will send a new patch with suitable subject/commit message.
But I send a V3 or a new patch?
I met a bug about the GPU,I have no idea about how to fix it,
If you can give me some suggestion,it is perfect.
You can see such kernel log:
Jun 20 10:20:13 icube kernel: [
Hi Steve,
I make a mistake about the code branch,I will test it later,
thinks for your reply.
Chunyou
?? Mon, 21 Jun 2021 11:45:18 +0100
Steven Price :
> On 19/06/2021 04:09, Chunyou Tang wrote:
> > Hi Steve,
> > 1,
> > from
> >
On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
> Another thing I want to emphasize is that we are doing p2p only
> through the export/import of the FD. We do *not* allow the user to
> mmap the dma-buf as we do not support direct IO. So there is no access
> to these pages through the
On Tue, 22 Jun 2021 at 01:44, wrote:
>
> On 2021-05-15 06:12, Dmitry Baryshkov wrote:
> > Remove struct msm_dsi_dphy_timing field from the struct msm_dsi_phy.
> > There is no need to store them.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Remove struct msm_dsi_dphy_timing field from the struct msm_dsi_phy.
There is no need to store them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 18 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Instead of fetching shared timing through an extra function call, get
them directly from msm_dsi_phy_enable. This would allow removing phy
timings from the struct msm_dsi_phy in the next patch.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Use of_device_get_match-data() instead of of_match_node().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this
manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic place.
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
Can you please confirm if you have validated dual DSI with this change?
With that,
Reviewed-by: Abhinav Kumar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
On 2021-05-15 06:12, Dmitry Baryshkov wrote:
This patch series brings back several patches targeting assigning
dispcc
clock parents, that were removed from the massive dsi rework patchset
earlier.
Few notes:
- assign-clock-parents is a mandatory proprety according to the
current
dsi.txt
[+cc Joel (reporter)]
On Mon, Jun 21, 2021 at 04:50:14PM -0500, Bjorn Helgaas wrote:
> - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
>
> Date: Mon, 21 Jun 2021 02:50:09 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: bj...@helgaas.com
> Subject: [Bug 213519] New:
- Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
Date: Mon, 21 Jun 2021 02:50:09 +
From: bugzilla-dae...@bugzilla.kernel.org
To: bj...@helgaas.com
Subject: [Bug 213519] New: WARNING on system reboot in:
drivers/gpu/drm/i915/intel_runtime_pm.c:635
Hi Dave, Daniel,
Last minute fixes for 5.13.
The following changes since commit 13311e74253fe64329390df80bed3f07314ddd61:
Linux 5.13-rc7 (2021-06-20 15:03:15 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.13-2021-06-21
On Mon, Jun 21, 2021 at 01:17:11PM -0700, Guenter Roeck wrote:
> On Fri, Jun 18, 2021 at 12:57:35PM -0700, Yury Norov wrote:
> > A couple of kernel functions call for_each_*_bit_from() with start
> > bit equal to 0. Replace them with for_each_*_bit().
> >
> > No functional changes, but might
Hi Laurent,
On 23/03/2021 00:56, Laurent Pinchart wrote:
> When the device is unbound from the driver (the DU being a platform
> device, this occurs either when removing the DU module, or when
> unbinding the device manually through sysfs), the display may be active.
> Make sure it gets shut
Hi Laurent,
On 23/03/2021 00:56, Laurent Pinchart wrote:
> The reference to the drm_device that was acquired by
> devm_drm_dev_alloc() is released automatically by the devres
> infrastructure. It must not be released manually, as that causes a
> reference underflow..
>
Ouch. We need some tests
On Fri, Jun 18, 2021 at 12:57:35PM -0700, Yury Norov wrote:
> A couple of kernel functions call for_each_*_bit_from() with start
> bit equal to 0. Replace them with for_each_*_bit().
>
> No functional changes, but might improve on readability.
>
> Signed-off-by: Yury Norov
> ---
>
Hi Laurent,
On 23/03/2021 00:12, Laurent Pinchart wrote:
> When the system shuts down or warm reboots, the display may be active,
> with the hardware accessing system memory. Upon reboot, the DDR will not
> be accessible, which may cause issues.
Troublesome indeed.
> Implement the
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned.
Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.
Patch 2 deals
Hi Laurent,
> >
> > It is news to me that the atomic ops are the way to go - but then I have
> > been off-line for a while so no suprise or maybe I just missed it
> > before.
>
> They're not mandatory as such, but they give us access to the atomic
> state, which is sometimes required. Overall I
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #25 from Leandro Jacques (ls...@yahoo.com) ---
(In reply to Dominic Letz from comment #21)
Trying the same version linux firmware 20210315. Let's check how it goes
--
You may reply to this email to add a comment.
You are receiving
On Mon, Jun 21, 2021 at 9:27 PM Daniel Vetter wrote:
>
> On Mon, Jun 21, 2021 at 7:55 PM Jason Gunthorpe wrote:
> > On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> > > On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> > > >
> > > > On Mon, Jun 21, 2021 at 03:02:10PM +0200,
Hi Sam,
On Mon, Jun 21, 2021 at 08:49:53PM +0200, Sam Ravnborg wrote:
> On Mon, Jun 21, 2021 at 03:55:13PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series is based on top of "[PATCH] drm/bridge: ti-sn65dsi83:
> > Replace connector format patching with
Applied. Thanks!
Alex
On Mon, Jun 21, 2021 at 9:15 AM Christian König
wrote:
>
> Am 21.06.21 um 15:05 schrieb Bernard Zhao:
> > Function radeon_fence_driver_init always returns success,
> > the function type maybe coule be changed to void.
> > This patch first delete the check of the return
>
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #24 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297557
--> https://bugzilla.kernel.org/attachment.cgi?id=297557=edit
Firmware info
The downgrade to kernel 5.4.123 doesn't had any effect, I had the same bug. Now
Hi Laurent,
On Mon, Jun 21, 2021 at 03:55:13PM +0300, Laurent Pinchart wrote:
> Hello,
>
> This patch series is based on top of "[PATCH] drm/bridge: ti-sn65dsi83:
> Replace connector format patching with atomic_get_input_bus_fmts". It
> completes the transition to atomic operations in the
Hi Doug,
On Mon, Jun 21, 2021 at 08:34:51AM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Jun 20, 2021 at 3:01 AM Sam Ravnborg wrote:
> >
> > Hi Rajeev
> > On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
> > > Add Samsung 13.3" FHD eDP AMOLED panel.
> > >
> > > Signed-off-by:
Hi Rajeev,
On Mon, Jun 21, 2021 at 02:08:17PM +0530, rajee...@codeaurora.org wrote:
> Hi Sam,
>
> On 20-06-2021 15:01, Sam Ravnborg wrote:
> > Hi Rajeev
> >
> > On Sat, Jun 19, 2021 at 04:10:26PM +0530, Rajeev Nandan wrote:
> > > Some panels support backlight control over DP AUX channel using
>
Hi Stefan.
On Mon, Jun 21, 2021 at 05:09:28PM +0200, Stefan Riedmueller wrote:
> The AUO G104SN02 V2 is an LVDS display which supports 6 and 8 bpc PSWG.
> Add the corresponding connector type and 8 bpc as default bus_format.
>
> Signed-off-by: Stefan Riedmueller
> Reviewed-by: Laurent Pinchart
On Mon, Jun 21, 2021 at 7:55 PM Jason Gunthorpe wrote:
> On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> > On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> > >
> > > On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > > > On Mon, Jun 21, 2021 at 02:28:48PM +0200,
Hello everyone, my name is Shashank Singh. I hope this is the right
platform to reach out to the 'X.org' community. I was curious about the
X.org Endless Vacation of Code. Is this program still active?
> Also that feature was only introduced in t76x. So relying on that would
> sadly kill off support for t60x, t62x and t72x (albeit I'm not sure how
> 'supported' these are with Mesa anyway).
t60x and t62x are not supported, but t720 very much is (albeit GLES2
only, versus t760+ getting GLES3.1
On Fri, 18 Jun 2021, Christoph Hellwig wrote:
> On Fri, Jun 18, 2021 at 09:09:17AM -0500, Tom Lendacky wrote:
> > > swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
> > > and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
> > > swiotlb_init_with_tbl is also
Hi Jagan,
Thank you for the patch.
On Mon, Jun 21, 2021 at 12:54:16PM +0530, Jagan Teki wrote:
> Samsung SEC MIPI DSIM Bridge controller is MIPI DSI bridge
> available in NXP's i.MX8M Mini and Nano Processors.
>
> Add dt-bingings for it.
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc:
On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> >
> > On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > > On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote:
> >
> > > > Also I'm wondering which is the
On Mon, 21 Jun 2021 12:54:16 +0530, Jagan Teki wrote:
> Samsung SEC MIPI DSIM Bridge controller is MIPI DSI bridge
> available in NXP's i.MX8M Mini and Nano Processors.
>
> Add dt-bingings for it.
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Rob
On Mon, 21 Jun 2021 12:54:18 +0530, Jagan Teki wrote:
> Samsung SEC MIPI DSIM DPHY controller is part of registers
> available in SEC MIPI DSIM bridge for NXP's i.MX8M Mini and
> Nano Processors.
>
> Add dt-bingings for it.
>
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Rob Herring
>
On Mon, 21 Jun 2021 15:44:02 +0900, Tomohito Esaki wrote:
> Add device tree bindings documentation for virtual DRM.
>
> Signed-off-by: Tomohito Esaki
> ---
> .../devicetree/bindings/display/vdrm.yaml | 67 +++
> 1 file changed, 67 insertions(+)
> create mode 100644
Hi Laurent,
On Mon, Jun 21, 2021 at 7:44 PM Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> On Mon, Jun 21, 2021 at 07:41:07PM +0530, Jagan Teki wrote:
> > On Mon, Jun 21, 2021 at 6:26 PM Laurent Pinchart wrote:
> > > On Mon, Jun 21, 2021 at 12:49:14PM +0100, Dave Stevenson wrote:
> > > > On Sun, 20
>
> Perfect :-)
>
> Reviewed-by: Laurent Pinchart
>
Pulled into drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db8b7ca5b232083c82f627af7fe653d8074c5ca0
On 6/21/21 2:08 PM, Lucas Stach wrote:
Am Montag, dem 21.06.2021 um 00:47 +0200 schrieb Marek Vasut:
In case the DRAM is under high load, the MXSFB FIFO might underflow
and that causes visible artifacts. This could be triggered on i.MX8MM
using e.g. "$ memtester 128M" on a device with 1920x1080
On 6/21/21 2:14 PM, Lucas Stach wrote:
[...]
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 98d8ba0bae84..22cb749fc9bc 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -241,6 +241,9 @@ static void
On 6/21/21 2:10 PM, Lucas Stach wrote:
Am Montag, dem 21.06.2021 um 00:48 +0200 schrieb Marek Vasut:
The iMX8MM and iMX8MN do not support the overlay plane, so they
are MXSFB V4. Add the compatible strings to reflect this. Note
that iMX8MQ does support the overlay plane, so it is MXSFB V6.
Do
On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
>
> On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote:
>
> > > Also I'm wondering which is the other driver that we share buffers
> > > with. The gaudi stuff doesn't
Hi Maxime
On Mon, 21 Jun 2021 at 17:05, Maxime Ripard wrote:
>
> Hi Laurent,
>
> On Sun, Jun 20, 2021 at 04:44:33AM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > I'm testing this, and I'm afraid it causes an issue with all the
> > I2C-controlled bridges. I'm focussing on the newly merged
On Mon, Jun 21, 2021 at 05:53:46PM +0200, Christian König wrote:
> Am 21.06.21 um 17:17 schrieb Daniel Vetter:
> > Christian and me realized we have a pretty massive disconnect about
> > different interpretations of what dma_resv is used for by different
> > drivers. The discussion is much, much
On 21/06/2021 15:02, Boris Brezillon wrote:
> This should avoid uneccessary interrupt-context switches when the GPU
> is passed a lot of short jobs.
LGTM:
Reviewed-by: Steven Price
>
> v2:
> * New patch
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 54
On 21/06/2021 15:02, Boris Brezillon wrote:
> 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.
>
> v2:
> * Make sure non-faulty jobs get properly
Hi,
On Mon, Jun 21, 2021 at 01:48:33AM +0300, Laurent Pinchart wrote:
> Then, when running kmstest --flip, I get one warning per frame:
>
> [ 29.762089] [drm:vc4_dsi_runtime_resume] *ERROR* vc4_dsi_runtime_resume:
> [ 29.763200] [drm:vc4_dsi_runtime_resume] *ERROR* vc4_dsi_runtime_resume:
>
Hi Laurent,
On Sun, Jun 20, 2021 at 04:44:33AM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> I'm testing this, and I'm afraid it causes an issue with all the
> I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83
> driver at the moment, but other are affected the same way.
>
Hi Tomohito
> +
> +description:
> + This document defines device tree properties virtual DRM. The initial
> + position, size and z-position of the plane used in the virtual DRM is
> + specified.
> + The current limitation is that these settings are applied to all crtc.
This comment (I
On Mon, Jun 21, 2021 at 03:44:01PM +0900, Tomohito Esaki wrote:
> In order to use vDRM, it is necessary that the vDRM device is registered
> to du decice in the device tree.
> The "vdrms" key is added in du node and the vDRM device node is specified.
> For example:
> --
> & du {
> ...
Hi Tomohito
On Mon, Jun 21, 2021 at 03:44:00PM +0900, Tomohito Esaki wrote:
> Virtual DRM splits the resources of an overlay plane into multiple
> virtual devices to allow each plane to be accessed by each process.
>
> This makes it possible to overlay images output from multiple processes
> on
Am 21.06.21 um 17:17 schrieb Daniel Vetter:
Christian and me realized we have a pretty massive disconnect about
different interpretations of what dma_resv is used for by different
drivers. The discussion is much, much bigger than this change here,
but this is an important one:
Non-dynamic
On Mon, Jun 21, 2021 at 5:49 PM Christian König
wrote:
>
> Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> >> We actually need to wait for the moving fence after pinning
> >> the BO to make sure that the pin is completed.
> >>
>
Am 21.06.21 um 16:54 schrieb Daniel Vetter:
On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
We actually need to wait for the moving fence after pinning
the BO to make sure that the pin is completed.
Signed-off-by: Christian König
CC: sta...@kernel.org
---
On Mon, 21 Jun 2021 16:19:38 +0100
Steven Price wrote:
> On 21/06/2021 14:39, Boris Brezillon wrote:
> > Do the exception -> string translation using a table so we can add extra
> > fields if we need to. While at it add an error field to ease the
> > exception -> error conversion which we'll
On 21/06/2021 14:39, Boris Brezillon wrote:
> panfrost_reset() does not directly signal fences, but
> panfrost_scheduler_start() does, when calling drm_sched_start().
I have to admit to not fully understanding dma_fence_begin_signalling()
- but I thought the idea was that it should have a
[Public]
I've dropped it from my tree in that case.
From: Christian König
Sent: Monday, June 21, 2021 6:27 AM
To: Alex Deucher ; Kuehling, Felix
Cc: David Airlie ; Pan, Xinhui ;
kernel-janit...@vger.kernel.org ; Maling list
- DRI developers ; amd-gfx list
;
Hi,
On Sun, Jun 20, 2021 at 3:01 AM Sam Ravnborg wrote:
>
> Hi Rajeev
> On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
> > Add Samsung 13.3" FHD eDP AMOLED panel.
> >
> > Signed-off-by: Rajeev Nandan
> > Reviewed-by: Douglas Anderson
> > ---
> >
> > Changes in v4:
> > - New
> >
On 21/06/2021 14:39, 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/panfrost_job.c | 2 +-
> 1
On Mon, 21 Jun 2021 16:09:32 +0100
Steven Price wrote:
> On 21/06/2021 14:39, Boris Brezillon wrote:
> > If we don't do that, we have to wait for the job timeout to expire
> > before the fault jobs gets killed.
> >
> > Signed-off-by: Boris Brezillon
>
> Don't we need to do something here to
On 21/06/2021 14:39, Boris Brezillon wrote:
> 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.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 33
lied 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/Mikel-Rychliski/drm-radeon-Fix-NULL-dereference-when-u
On 21/06/2021 14:39, Boris Brezillon wrote:
> If we can recover from a fault without a reset there's no reason to
> issue one.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 9 ++
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
>
On 21/06/2021 14:39, Boris Brezillon wrote:
> Do the exception -> string translation using a table so we can add extra
> fields if we need to. While at it add an error field to ease the
> exception -> error conversion which we'll need if we want to set the
> fence error to something that reflects
Christian and me realized we have a pretty massive disconnect about
different interpretations of what dma_resv is used for by different
drivers. The discussion is much, much bigger than this change here,
but this is an important one:
Non-dynamic exporters must guarantee that the memory they
On 21/06/2021 14:39, Boris Brezillon wrote:
> 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
This one still haunts me... ;)
Reviewed-by: Steven Price
> ---
>
On 21/06/2021 14:39, Boris Brezillon wrote:
> 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
>
The connector_type for following two EDT displays is missing:
- EDT ETM0430G0DH6
- EDT ETM0700G0BDH6
Both are parallel displays thus add the corresponding connector_type.
Signed-off-by: Stefan Riedmueller
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 21/06/2021 14:39, Boris Brezillon wrote:
> If we don't do that, we have to wait for the job timeout to expire
> before the fault jobs gets killed.
>
> Signed-off-by: Boris Brezillon
Don't we need to do something here to allow recovery of the MMU context
in the future? panfrost_mmu_disable()
Add corresponding bus_format and bus_flags for the EDT ETM0430G0DH6
display.
Signed-off-by: Stefan Riedmueller
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index
The AUO G104SN02 V2 is an LVDS display which supports 6 and 8 bpc PSWG.
Add the corresponding connector type and 8 bpc as default bus_format.
Signed-off-by: Stefan Riedmueller
Reviewed-by: Laurent Pinchart
---
Hi,
I added the reviewed-by tag from Laurent Pinchart for the RESEND, hope
that is
On Mon, 21 Jun 2021 15:39:00 +0200
Boris Brezillon wrote:
> If we don't do that, we have to wait for the job timeout to expire
> before the fault jobs gets killed.
^ faulty
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 +-
> 1 file
Christian and me realized we have a pretty massive disconnect about
different interpretations of what dma_resv is used for by different
drivers. The discussion is much, much bigger than this change here,
but this is an important one:
Non-dynamic exporters must guarantee that the memory they
Hi Sam,
On Mon, 2021-06-21 at 16:17 +0200, Sam Ravnborg wrote:
> Hi Stefan,
>
> On Mon, Jun 21, 2021 at 08:22:10AM +, Stefan Riedmüller wrote:
> > Hi,
> >
> > another gentle ping.
> >
> > Also adding Laurent Pinchart to CC.
>
> Can I ask you to resend the whole lot. I have resurfaced
On Mon, Jun 21, 2021 at 03:03:28PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14
On Mon, Jun 21, 2021 at 03:03:27PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 16
On Mon, 21 Jun 2021 15:49:14 +0100
Steven Price wrote:
> On 21/06/2021 14:38, Boris Brezillon wrote:
> > 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
On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +++-
On 21/06/2021 15:49, Boris Brezillon wrote:
> On Mon, 21 Jun 2021 15:34:35 +0100
> Steven Price wrote:
>
>> On 21/06/2021 14:38, Boris Brezillon wrote:
>>> Exception types will be defined as an enum in panfrost_drm.h so userspace
>>> and use the same definitions if needed.
>>
>> s/and/can/ ?
On Mon, Jun 21, 2021 at 04:30:50PM +0200, Maarten Lankhorst wrote:
> Op 21-06-2021 om 11:33 schreef Matthew Auld:
> > On 18/06/2021 22:45, Daniel Vetter wrote:
> >> In
> >>
> >> commit ebc0808fa2da0548a78e715858024cb81cd732bc
> >> Author: Chris Wilson
> >> Date: Tue Oct 18 13:02:51 2016 +0100
>
On Mon, Jun 21, 2021 at 04:20:35PM +0200, Daniel Vetter wrote:
> Also unless we're actually doing this properly there's zero incentive for
> me to review the kernel code and check whether it follows the rules
> correctly, so you have excellent chances that you just break the rules.
> And
1 - 100 of 217 matches
Mail list logo
