Am 13.08.20 um 01:55 schrieb Jordan Crouse:
This is an RFC because I'm still trying to grok the correct behavior.
Consider a dma_fence_array created two two fence and signal_on_any is true.
A reference to dma_fence_array is taken for each waiting fence.
Ok, that sounds like you seem to mix a c
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #9 from Gordon (gor...@gordonite.tech) ---
nvm rebooted and the problem came back.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing li
Quoting Jordan Crouse (2020-08-13 00:55:44)
> This is an RFC because I'm still trying to grok the correct behavior.
>
> Consider a dma_fence_array created two two fence and signal_on_any is true.
> A reference to dma_fence_array is taken for each waiting fence.
>
> When the client calls dma_fence
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #8 from Gordon (gor...@gordonite.tech) ---
not getting any symptoms of the problem now.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel maili
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #7 from Gordon (gor...@gordonite.tech) ---
[ 18.764922] snd_hda_intel :0c:00.1: refused to change power state from
D3hot to D0
[ 18.869351] snd_hda_intel :0c:00.1: CORB reset timeout#2, CORBRP = 65535
[ 19.090949] snd_hda
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #6 from Gordon (gor...@gordonite.tech) ---
Created attachment 290871
--> https://bugzilla.kernel.org/attachment.cgi?id=290871&action=edit
this is the log from after my patch is applied
--
You are receiving this mail because:
You ar
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #5 from Gordon (gor...@gordonite.tech) ---
The problem: the GPU card / seems to make a difference here, some seem to
require a bigger delay? and some just work.
Would be nice to know why.
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #4 from Gordon (gor...@gordonite.tech) ---
Found a fix for the issue.
My card is a PowerColor Red Devil 5600 XT.
diff --git a/drivers/gpu/drm/amd/powerplay/smu_cmn.c
b/drivers/gpu/drm/amd/powerplay/smu_cmn.c
index 5c23c44c33bd..629
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add t
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/dr
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Implement dma-buf import
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #3 from Gordon (gor...@gordonite.tech) ---
The Diff from the log file - clearly showing the problem:
[ 51.925494] amdgpu: Msg issuing pre-check failed and SMU may be not in the
right state!
[ 54.442825] amdgpu: Msg issuing pre-che
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #2 from Gordon (gor...@gordonite.tech) ---
Created attachment 290869
--> https://bugzilla.kernel.org/attachment.cgi?id=290869&action=edit
added logfile for when single display is connected - notice no ERROR from
AMDGPU anymore!
--
https://bugzilla.kernel.org/show_bug.cgi?id=208893
--- Comment #1 from Gordon (gor...@gordonite.tech) ---
Created attachment 290867
--> https://bugzilla.kernel.org/attachment.cgi?id=290867&action=edit
added logfile for system has some AMD GPU errors in it, this is when both
displays are connecte
https://bugzilla.kernel.org/show_bug.cgi?id=208893
Bug ID: 208893
Summary: Navi (RX 5700 XT) system appears to hang with more
than one display connected
Product: Drivers
Version: 2.5
Kernel Version: 5.8.1, 5.7.15
Hardwa
Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit f87812284172a9809820d10143b573d833cd3f75:
drm/amdgpu: Fix bug where DPM is not enabled after hibernate and resume
(2020-08-07 17:52:15 -0400)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linu
Add the hook_plugged_cb op for the MSM DP driver to signal connect
and disconnect events to the hdmi-codec driver which in-turn shall
notify the audio subsystem to start a new or teardown an existing
session.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_audio.c | 25 +
Signal the hotplug disconnect event to the audio side in the
event handler so that they are notified earlier and have more
time to process the disconnect event.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
1 file changed, 10 insertions(+), 10 de
Store the dp_display in the platform driver data instead of the
dp_display_private.
This is required to allow other sub-modules to reuse the platform
driver data.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 +++--
1 file changed, 15 insertions(+
This series adds audio support for DP on MSM chipsets. It leverages
the hdmi-codec interface [1] to communicate between the Display Port
driver and the audio subsystem. These changes depend on the series [2]
which adds Display Port support to MSM chipsets.
[1] https://patchwork.kernel.org/patch/11
Introduce audio support for Display Port on MSM chipsets.
This change integrates DP audio sub-module with the main
Display Port platform driver.
In addition, this change leverages hdmi_codec_ops to expose
the operations to the audio driver.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/M
A new bus-width DT property has been introduced in the bindings to allow
overriding the bus width. Support it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8
The LCDIF in the i.MX8 SoCs has additional features compared to the
i.MX28. Replace the fsl,imx28-lcdif fallback compatible string with
fsl,imx6sx-lcdif to reflect that.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
neither the DT sources nor the driver support it anymore.
The compatible strings are messy, and DT sources use different kinds of
combination of documented and undocumented values. Keep it simple for
now, and update the examp
Rename the mxsfb.yaml binding schema to fsl,lcdif.yaml to match the
usual bindings naming scheme.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/display/{mxsfb.yaml => fsl,lcdif.yaml} | 2 +-
MAINTAINERS | 2 +-
2 files changed, 2
Hello,
This patch series adds support to the mxsfb driver for bus width
override. The need came from a hardware platform where a 18-bpp panel
had the R[5:0], G[5:0] and B[5:0] signals connected to LCD_DATA[7:2],
LCD_DATA[15:10] and LCD_DATA[23:18] instead of LCD_DATA[5:0],
LCD_DATA[11:6] and LCD_D
Additional compatible strings have been added in DT source for the
i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
Most of the upstream DT sources use the fsl,imx28-lcdif compatible
string, which mostly predates the realization that the LCDIF in the
i.MX6 and newer SoCs have ex
When the PCB routes the display data signals in an unconventional way,
the output bus width may differ from the bus width of the connected
panel or encoder. For instance, when a 18-bit RGB panel has its R[5:0],
G[5:0] and B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10]
and LCD_DATA[23:18
The LCDIF disp_axi clock is not mandatory in the DT binding and not
required by the driver. Remove it when it points to a dummy clock.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/imx6sl.dtsi | 5 ++---
arch/arm/boot/dts/imx6sll.dtsi | 5 ++---
arch/arm/boot/dts/imx6ul.dtsi | 5 ++---
The LCDIF in the i.MX6 SoCs has additional features compared to the
i.MX28. Replace the fsl,imx28-lcdif fallback compatible string with
fsl,imx6sx-lcdif to reflect that.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/imx6sl.dtsi | 2 +-
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
arch/arm/boo
From: Rob Clark
We need to set it to the most recent completed fence, not the most
recent submitted. Otherwise we have races where we think we can retire
submits that the GPU is not finished with, if the GPU doesn't manage to
overwrite the seqno before we look at it.
This can show up with hang
This is an RFC because I'm still trying to grok the correct behavior.
Consider a dma_fence_array created two two fence and signal_on_any is true.
A reference to dma_fence_array is taken for each waiting fence.
When the client calls dma_fence_wait() only one of the fences is signaled.
The client r
On Wed, Aug 12, 2020 at 4:32 PM Joe Perches wrote:
>
> On Wed, 2020-08-12 at 14:36 -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces
On Wed, Aug 12, 2020 at 3:34 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which shoul
On Wed, 2020-08-12 at 14:36 -0600, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel, set the bus
format to MEDIA_BUS_FMT_RGB666_1X18.
Fixes: 725c9d40f3fe ("drm/panel: Add support for OrtusTech COM43H4M85ULC panel")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(
Hi Rob.
On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
> keyword.
>
> Found
Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
new gp1xx temperature sensor") added support for reading finer-grain
temperatures, but continued to report temperatures in 1 degree Celsius
increments via nvkm_therm_temp_get().
Rather than altering nvkm_therm_temp_get() to r
Hi Marek.
On Sun, Aug 09, 2020 at 12:57:05PM +0200, Marek Vasut wrote:
> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
> from tc358764 driver and panel-raspberrypi-touchscreen. This driver is
> meant to replace the panel-raspberrypi-touchscreen too, as the bridge
> connecti
Hi Marek.
On Sun, Aug 09, 2020 at 12:57:04PM +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob H
The pull request you sent on Wed, 12 Aug 2020 14:53:17 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-08-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ea6ec774372740b024a6c27caac0d0af8960ea15
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Sun, 09 Aug 2020 12:57:04 +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Sam
On 2020-08-11 12:30, Stephen Boyd wrote:
Quoting Tanmay Shah (2020-08-10 19:15:53)
@@ -2440,6 +2447,71 @@ dsi_phy: dsi-phy@ae94400 {
status = "disabled";
};
+
+ msm_dp: displayport-controller@ae9 {
+
in case you all were wondering, it works on xorg-server git because of
this commit:
https://gitlab.freedesktop.org/xorg/xserver/-/commit/9b8999411033c9473cd68e92e4690a91aecf5b95
On Wed, Aug 12, 2020 at 8:25 PM James Jones wrote:
>
> On 8/12/20 10:40 AM, Alyssa Rosenzweig wrote:
> >> ...and in me
On 8/12/20 10:40 AM, Alyssa Rosenzweig wrote:
...and in merging my code with Alyssa's new panfrost format modifier
support, I see panfrost does the opposite of this and treats a format
modifier list of only INVALID as "don't care". I modeled the new nouveau
behavior on the Iris driver. Now I'm
On 12/08/2020 14:26, Tomi Valkeinen wrote:
> This patch implements WA for AM65xx erratum i2000, which causes YUV
> formats to show wrong colors.
>
> An earlier patch removed a partial WA:
>
> a8d9d7da1546349f18eb2d6b6b3a04bdeb38719d ("drm/tidss: remove AM65x PG1 YUV
> erratum code")
>
> The pat
On Wed, Aug 12, 2020 at 3:15 AM Anshuman Gupta wrote:
>
> On 2020-08-11 at 13:28:46 -0400, Sean Paul wrote:
> > On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta
> > wrote:
> > >
> >
> > \snip
> >
> > > > > +static int
> > > > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > > >
On 8/12/20 10:10 AM, Karol Herbst wrote:
On Wed, Aug 12, 2020 at 7:03 PM James Jones wrote:
On 8/12/20 5:37 AM, Ilia Mirkin wrote:
On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrot
On Wed, Aug 12, 2020 at 7:03 PM James Jones wrote:
>
> On 8/12/20 5:37 AM, Ilia Mirkin wrote:
> > On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
> >>
> >> On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
> >>>
> >>> On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
>
> On
On 8/12/20 5:37 AM, Ilia Mirkin wrote:
On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
Sorry for the slow reply here as well
On Sat, Aug 08, 2020 at 10:53:45AM +0800, Yongqiang Niu wrote:
> rdma fifo size may be different even in same SOC, add this
> property to the corresponding rdma
>
> Change-Id: I67635ec7f3f59cf4cbc7737285e5e28ff0ab71c9
> Signed-off-by: Yongqiang Niu
> ---
> .../devicetree/bindings/display/mediate
Hi Prabhakar,
Thank you for the patches.
On Wed, Aug 12, 2020 at 03:02:08PM +0100, Lad Prabhakar wrote:
> Hi All,
>
> This patch series adds support for DU, HDMI and LVDS to RZ/G2H SoC.
I have added patches 1/9, 2/9, 4/9, 5/9 and 7/9 to my tree. I expect
Geert to handle the rest.
> Lad Prabhak
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:17PM +0100, Lad Prabhakar wrote:
> Setup up the required clocks for the DU to be functional.
>
> Signed-off-by: Lad Prabhakar
> ---
> arch/arm64/boot/dts/renesas/r8a774e1-hihope-rzg2h.dts | 11 +++
> 1 file changed, 1
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:16PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Add the LVDS device node to R8A774E1 to SoC dtsi and connect it with
> the DU node.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prab
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:15PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> The LVDS encoder on RZ/G2H (R8A774E1) SoC is identical to R-Car Gen3 so
> just reuse the rcar_lvds_gen3_info structure to hookup R8A774E1 to LVDS
> encoder d
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:14PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Populate HDMI node properties in R8A774E1 SoC dtsi.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Laurent Pin
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:13PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Laurent Pinchart
> -
On Wed, Aug 12, 2020 at 07:17:59PM +0300, Laurent Pinchart wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wed, Aug 12, 2020 at 03:02:12PM +0100, Lad Prabhakar wrote:
> > From: Marian-Cristian Rotariu
> >
> > Document the RZ/G2H (R8A774E1) LVDS bindings.
> >
> > Signed-off-by: Maria
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:12PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Document the RZ/G2H (R8A774E1) LVDS bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
> ---
> .../devicetree/binding
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:11PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Populate the DU device node properties in R8A774E1 SoC dtsi.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: La
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:10PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Hookup RZ/G2H (R8A774E1) to DU driver. R8A774E1 has one RGB output,
> one LVDS output and one HDMI output.
>
> Signed-off-by: Marian-Cristian Rotariu
>
>
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:09PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Document the RZ/G2H (a.k.a. r8a774e1) SoC in the R-Car DU bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed
On Wed, Aug 12, 2020 at 5:20 PM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 5:05 PM Thierry Reding
> wrote:
> >
> > On Wed, Aug 12, 2020 at 12:43:17PM +0200, Karol Herbst wrote:
> > > On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> > > >
> > > > On Wed, Aug 12, 2020 at 2:19 AM James
On Wed, Aug 12, 2020 at 2:58 AM Linus Walleij wrote:
>
> Let's use a common.yaml include for the backlight like we do with
> the LEDs. The LEDs are inherently incompatible so their bindings
> cannot be reused for backlight.
>
> Cc: devicet...@vger.kernel.org
> Suggested-by: Sam Ravnborg
> Signed-
On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
> > On Tue, 11 Aug 2020, Daniel Vetter wrote:
> >
> > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > > > Hi Folks,
> > > > I know this thread eventually dr
Am 12.08.20 um 17:19 schrieb Steven Rostedt:
On Wed, 12 Aug 2020 16:36:36 +0200
Christian König wrote:
Am 12.08.20 um 16:17 schrieb Steven Rostedt:
On Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
Trace something useful instead of the pid of a kernel thread here.
Signed-off-
This patch implements WA for AM65xx erratum i2000, which causes YUV
formats to show wrong colors.
An earlier patch removed a partial WA:
a8d9d7da1546349f18eb2d6b6b3a04bdeb38719d ("drm/tidss: remove AM65x PG1 YUV
erratum code")
The patch explains the reasoning for removal. The change in plans ha
On Wed, Aug 12, 2020 at 5:05 PM Thierry Reding wrote:
>
> On Wed, Aug 12, 2020 at 12:43:17PM +0200, Karol Herbst wrote:
> > On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> > >
> > > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > > >
> > > > Sorry for the slow reply here as well.
On Wed, 12 Aug 2020 16:36:36 +0200
Christian König wrote:
> Am 12.08.20 um 16:17 schrieb Steven Rostedt:
> > On Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
> >> Trace something useful instead of the pid of a kernel thread here.
> >>
> >> Signed-off-by: Christian König
> >> --
On Wed, Aug 12, 2020 at 12:43:17PM +0200, Karol Herbst wrote:
> On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> >
> > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > >
> > > Sorry for the slow reply here as well. I've been in the process of
> > > rebasing and reworking the userspac
On Tue, Aug 11, 2020 at 04:36:57PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For production devices, the debugbus sections will typically be fused
> off and empty in the gpu device coredump. But since this may contain
> data like cache contents, don't capture it by default.
Reviewed-by: Jor
Hi Guido,
On 12/08/2020 11:39, Guido Günther wrote:
> Hi,
> On Thu, Aug 06, 2020 at 01:34:29PM +0200, Swapnil Jakhade wrote:
>> This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP
>> bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High
>> Definition Link, High
Am 12.08.20 um 16:17 schrieb Steven Rostedt:
On Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
Trace something useful instead of the pid of a kernel thread here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 1 +
1 file changed, 1 insertion(+)
On Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
> Trace something useful instead of the pid of a kernel thread here.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd
On Wed, Aug 12, 2020 at 08:31:54AM +0200, Greg KH wrote:
> On Tue, Aug 11, 2020 at 04:26:31PM -0400, Alyssa Rosenzweig wrote:
> > The AFBC decoder used in the Rockchip VOP assumes the use of the
> > YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
> > buffers, which covers the RGBA8
On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
>
> On Tue, 11 Aug 2020, Daniel Vetter wrote:
>
> > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > > Hi Folks,
> > > I know this thread eventually dropped off due to not identifying
> > > the underlying issue. It's s
Am 12.08.20 um 15:49 schrieb Daniel Vetter:
On Wed, Aug 12, 2020 at 3:42 PM Christian König
wrote:
Ping? Daniel, Dave any opinion on this?
Type patch, cc: tracing people, see what they say?
Adding Ingo and Steven then.
tbh I have no idea,
but they have been making unhappy noises about some
On Wed, Aug 12, 2020 at 10:25:25AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.08.20 um 10:50 schrieb dan...@ffwll.ch:
> > On Wed, Aug 05, 2020 at 12:54:28PM +0200, Thomas Zimmermann wrote:
> >> The ast HW cursor requires the primary plane and CRTC to display at
> >> a valid mode and format. Th
Hi,
On Wed, Aug 12, 2020 at 01:47:42PM +0300, Tomi Valkeinen wrote:
> Hi Guido,
>
> On 12/08/2020 11:39, Guido Günther wrote:
> > Hi,
> > On Thu, Aug 06, 2020 at 01:34:29PM +0200, Swapnil Jakhade wrote:
> >> This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP
> >> bridge. The Cade
On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> There are a few cases when the flags can change, for example DCC can be
> disabled due to a hw limitation in the 3d engine. Modifiers give the
> misleading impression that they help with that, but they don't. They don't
> really help wi
On Wed, Aug 12, 2020 at 3:42 PM Christian König
wrote:
>
> Ping? Daniel, Dave any opinion on this?
Type patch, cc: tracing people, see what they say? tbh I have no idea,
but they have been making unhappy noises about some of the tricks
we've played in the past in i915 tracepoints. So not everythi
Ping? Daniel, Dave any opinion on this?
Christian.
Am 07.08.20 um 15:36 schrieb Christian König:
Hi everybody,
in amdgpu we got the following issue which I'm seeking advise how to cleanly
handle it.
We have a bunch of trace points which are related to the VM subsystem and
executed in either
Hi Algea,
On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote:
> 在 2020/8/12 17:33, Laurent Pinchart 写道:
> > On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote:
> >> Introduce struct dw_hdmi_property_ops in plat_data to support
> >> vendor hdmi property.
> >>
> >> Implement hdmi vendor prop
drm-misc-fixes-2020-08-12:
drm-misc-fixes for v5.9-rc1:
- Add missing dma_fence_put() in virtio_gpu_execbuffer_ioctl().
- Fix memory leak in virtio_gpu_cleanup_object().
The following changes since commit b5ac98cbb8e5e30c34ebc837d1e5a3982d2b5f5c:
drm: Added orientation quirk for ASUS tablet mode
Hi Vinay,
On Wed, Aug 12, 2020 at 06:07:52PM +0530, Vinay Simha B N wrote:
> On Wed, Aug 12, 2020 at 3:24 PM Laurent Pinchart wrote:
> > On Wed, Aug 12, 2020 at 12:55:50PM +0530, Vinay Simha BN wrote:
> > > - bus formats read from drm_bridge_state.output_bus_cfg.format
> > > and .atomic_get_inpu
On Mon, 10 Aug 2020, Dave Airlie wrote:
> Like this stuff has been getting past me for years but I'm not happy
> about it anymore, I'm going to just be grumpy asshole going forward.
> If we introduced scheduler races in linux-next, I want to see reverts,
> and reverts only until we stopped introdu
On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
> >
> > On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> > >
> > > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > > >
> > > > Sorry for the slow reply here as well. I've b
On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> >
> > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > >
> > > Sorry for the slow reply here as well. I've been in the process of
> > > rebasing and reworking the userspace patc
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallbac
On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> >
> > Sorry for the slow reply here as well. I've been in the process of
> > rebasing and reworking the userspace patches. I'm not clear my changes
> > will address the Jetson Nano issu
On Wed, Aug 12, 2020 at 10:36:14AM +0200, Christian König wrote:
> Am 12.08.20 um 10:10 schrieb pet...@infradead.org:
> > On Tue, Aug 11, 2020 at 01:18:52PM +0200, Christian König wrote:
> > > From: Guchun Chen
> > >
> > > Otherwise, braces are needed when using it.
> > >
> > > Signed-off-by: Gu
On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
>
> Sorry for the slow reply here as well. I've been in the process of
> rebasing and reworking the userspace patches. I'm not clear my changes
> will address the Jetson Nano issue, but if you'd like to try them, the
> latest userspace changes a
Hi Algea,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on linus/master drm-exynos/exynos-drm-next v5.8
next-20200812]
[cannot apply to rockchip/for-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm/drm
Hi Vinay,
Thank you for the patch.
On Wed, Aug 12, 2020 at 12:55:50PM +0530, Vinay Simha BN wrote:
> - bus formats read from drm_bridge_state.output_bus_cfg.format
> and .atomic_get_input_bus_fmts() instead of connector
>
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> * Laurent Pinchart r
Hi Algea,
Thank you for the patch.
On Wed, Aug 12, 2020 at 04:34:07PM +0800, Algea Cao wrote:
> In some situations, connector should get some work done
> when plane is updating. Such as when change output color
> format, hdmi should send AVMUTE to make screen black before
> crtc updating color fo
Hi Algea,
Thank you for the patch.
On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote:
> Introduce struct dw_hdmi_property_ops in plat_data to support
> vendor hdmi property.
>
> Implement hdmi vendor properties color_depth_property and
> hdmi_output_property to config hdmi output color d
On 8/12/2020 1:09 PM, Rajendra Nayak wrote:
On 8/12/2020 1:05 PM, Amit Pundir wrote:
Hi Rajendra,
On Wed, 12 Aug 2020 at 11:18, Rajendra Nayak wrote:
On 8/12/2020 7:03 AM, John Stultz wrote:
On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote:
On Wed, Mar 20, 2019 at 2:49 AM Rajendra Na
1 - 100 of 134 matches
Mail list logo
