[PATCHv8 1/8] iommu/io-pgtable-arm: Add support to use system cache
Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
the attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 10 --
include/linux/io-pgtable.h | 4
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..7c9ea9d7874a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
- IO_PGTABLE_QUIRK_ARM_TTBR1))
+ IO_PGTABLE_QUIRK_ARM_TTBR1 |
+ IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
return NULL;
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,10 +774,15 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+ goto out_free_data;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
- tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+ if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
+ tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+ else
+ tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
}
tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..a9a2c59fab37 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
*
* IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
* for use in the upper half of a split address space.
+*
+* IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the attributes set in TCR
for
+* the page table walker when using system cache.
*/
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
@@ -93,6 +96,7 @@ struct io_pgtable_cfg {
#define IO_PGTABLE_QUIRK_ARM_MTK_EXTBIT(3)
#define IO_PGTABLE_QUIRK_NON_STRICT BIT(4)
#define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5)
+ #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6)
unsigned long quirks;
unsigned long pgsize_bitmap;
unsigned intias;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 5/8] drm/msm/a6xx: Add support for using system cache(LLC)
From: Sharat Masetty
The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices upon
GPU power collapse and restore.
Some support from the IOMMU driver is also needed to make use
of the system cache to set the right TCR attributes. GPU then
has the ability to override a few cacheability parameters which
it does to override write-allocate to write-no-allocate as the
GPU hardware does not benefit much from it.
DOMAIN_ATTR_IO_PGTABLE_CFG is another domain level attribute used
by the IOMMU driver for pagetable configuration which will be used
to set a quirk initially to set the right attributes to cache the
hardware pagetables into the system cache.
Signed-off-by: Sharat Masetty
[saiprakash.ranjan: fix to set attr before device attach to iommu and rebase]
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 83 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 4 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 948f3656c20c..95c98c642876 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -8,7 +8,9 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include
#include
+#include
#define GPU_PAS_ID 13
@@ -1022,6 +1024,79 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
}
+static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
+{
+ return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
+{
+ return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+}
+
+static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_deactivate(a6xx_gpu->llc_slice);
+ llcc_slice_deactivate(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
+{
+ u32 cntl1_regval = 0;
+
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
+ u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+
+ gpu_scid &= 0x1f;
+ cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid <<
10) |
+ (gpu_scid << 15) | (gpu_scid << 20);
+ }
+
+ if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
+ u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ }
+
+ if (cntl1_regval) {
+ /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+ a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache lines on
+* a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ }
+}
+
+static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_putd(a6xx_gpu->llc_slice);
+ llcc_slice_putd(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_slices_init(struct platform_device *pdev,
+ struct a6xx_gpu *a6xx_gpu)
+{
+ a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
+ a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
+
+ if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+ a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
+}
+
static int a6xx_pm_resume(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1038,6 +1113,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
msm_gpu_resume_devfreq(gpu);
+ a6xx_llc_activate(a6xx_gpu);
+
return 0;
}
@@ -1048,6 +1125,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
trace_msm_gpu_suspend(0);
+ a6xx_llc_deactivate(a6xx_gpu);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
return a6xx_gmu_stop(a6xx_gpu);
@@ -1091,6 +1170,8 @@ static void a6xx_destroy(struct msm_gpu *gpu)
drm_gem_object_put(a6xx_gpu->shadow_bo);
}
+ a6xx_llc_slices_destroy(a6xx_gpu);
+
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_
[PATCH v4 7/7] ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808
Make some noise with mk808. Enable the hdmi_sound node and
add i2s0 as sound source for hdmi.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a-mk808.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
b/arch/arm/boot/dts/rk3066a-mk808.dts
index eed9e60cf..5fe74c097 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -116,6 +116,14 @@
};
};
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2s0 {
+ status = "okay";
+};
+
&mmc0 {
bus-width = <4>;
cap-mmc-highspeed;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/7] ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi
Add hdmi-sound node to rk3066a.dtsi, so that it
can be reused by boards with HDMI support.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 67fcb0dc9..f91ce3054 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -49,6 +49,22 @@
ports = <&vop0_out>, <&vop1_out>;
};
+ hdmi_sound: hdmi-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "HDMI";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <256>;
+ status = "disabled";
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0>;
+ };
+ };
+
sram: sram@1008 {
compatible = "mmio-sram";
reg = <0x1008 0x1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/7] dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi
'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property.
Add it to rockchip,rk3066-hdmi.yaml to document that the
rk3066 HDMI TX also can be used to transmit some audio.
Signed-off-by: Johan Jonker
---
.../devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
index 4110d003c..585a8d3b9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
+++
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -42,6 +42,9 @@ properties:
description:
This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
+ "#sound-dai-cells":
+const: 0
+
ports:
type: object
@@ -101,6 +104,7 @@ examples:
pinctrl-names = "default";
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
ports {
#address-cells = <1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
BUG: unable to handle kernel paging request in bitfill_aligned (2)
Hello, syzbot found the following issue on: HEAD commit:0062442e Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16584b8150 kernel config: https://syzkaller.appspot.com/x/.config?x=f9aa2432c01bcb1f dashboard link: https://syzkaller.appspot.com/bug?extid=a4edd73d589b0b7efbeb compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a4edd73d589b0b7ef...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: 88800100 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fc01067 P4D fc01067 PUD fc02067 PMD 810001e1 Oops: 0003 [#1] PREEMPT SMP KASAN CPU: 0 PID: 12457 Comm: syz-executor.5 Not tainted 5.10.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__writeq arch/x86/include/asm/io.h:98 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/cfbfillrect.c:70 [inline] RIP: 0010:bitfill_aligned+0x11d/0x200 drivers/video/fbdev/core/cfbfillrect.c:35 Code: 41 83 fc 07 76 5f 4c 89 ed e8 bf 28 8a fd 48 89 5d 00 48 89 5d 08 48 89 5d 10 48 89 5d 18 48 89 5d 20 48 89 5d 28 48 8d 45 38 <48> 89 5d 30 48 83 c5 40 48 89 18 41 83 ef 08 bf 07 00 00 00 44 89 RSP: 0018:c900082176d0 EFLAGS: 00010246 RAX: 88800108 RBX: RCX: c90013da2000 RDX: 0004 RSI: 83e60721 RDI: 0005 RBP: 888000d0 R08: 1380 R09: 0040 R10: 0007 R11: R12: 004e R13: 88800010 R14: R15: 0036 FS: () GS:8880b9e0(0063) knlGS:f5542b40 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 88800100 CR3: 1c7d6000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: cfb_fillrect+0x40b/0x7b0 drivers/video/fbdev/core/cfbfillrect.c:327 vga16fb_fillrect+0x683/0x1940 drivers/video/fbdev/vga16fb.c:951 bit_clear_margins+0x3f6/0x4b0 drivers/video/fbdev/core/bitblit.c:224 fbcon_clear_margins+0x1f1/0x280 drivers/video/fbdev/core/fbcon.c:1325 fbcon_switch+0xafe/0x16b0 drivers/video/fbdev/core/fbcon.c:2187 redraw_screen+0x2b9/0x790 drivers/tty/vt/vt.c:1021 vc_do_resize+0xed8/0x1150 drivers/tty/vt/vt.c:1326 vt_resize+0xa3/0xe0 drivers/tty/vt/vt.c:1367 tiocswinsz drivers/tty/tty_io.c:2278 [inline] tty_ioctl+0x11a2/0x1600 drivers/tty/tty_io.c:2576 tty_compat_ioctl+0x295/0x410 drivers/tty/tty_io.c:2818 __do_compat_sys_ioctl+0x1d3/0x230 fs/ioctl.c:842 do_syscall_32_irqs_on arch/x86/entry/common.c:78 [inline] __do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:137 do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:160 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7f48549 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:f55420cc EFLAGS: 0296 ORIG_RAX: 0036 RAX: ffda RBX: 0003 RCX: 5414 RDX: 2040 RSI: RDI: RBP: R08: R09: R10: R11: R12: R13: R14: R15: Modules linked in: CR2: 88800100 ---[ end trace 7c559c247d0f5502 ]--- RIP: 0010:__writeq arch/x86/include/asm/io.h:98 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/cfbfillrect.c:70 [inline] RIP: 0010:bitfill_aligned+0x11d/0x200 drivers/video/fbdev/core/cfbfillrect.c:35 Code: 41 83 fc 07 76 5f 4c 89 ed e8 bf 28 8a fd 48 89 5d 00 48 89 5d 08 48 89 5d 10 48 89 5d 18 48 89 5d 20 48 89 5d 28 48 8d 45 38 <48> 89 5d 30 48 83 c5 40 48 89 18 41 83 ef 08 bf 07 00 00 00 44 89 RSP: 0018:c900082176d0 EFLAGS: 00010246 RAX: 88800108 RBX: RCX: c90013da2000 RDX: 0004 RSI: 83e60721 RDI: 0005 RBP: 888000d0 R08: 1380 R09: 0040 R10: 0007 R11: R12: 004e R13: 88800010 R14: R15: 0036 FS: () GS:8880b9e0(0063) knlGS:f5542b40 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 88800100 CR3: 1c7d6000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https:
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
Hi CK,
On Tue, 17 Nov 2020 00:43:44 +0800
Chun-Kuang Hu wrote:
> Hi, Bilal:
>
> Bilal Wasim 於 2020年11月16日 週一
> 下午7:53寫道：
> >
> > Hi CK,
> >
> > On Mon, 16 Nov 2020 07:12:55 +0800
> > Chun-Kuang Hu wrote:
> >
> > > Hi, Bilal:
> > >
> > > Bilal Wasim 於 2020年11月16日 週一
> > > 上午3:25寫道：
> > > >
> > > > Hi CK,
> > > >
> > > > On Sun, 15 Nov 2020 08:53:24 +0800
> > > > Chun-Kuang Hu wrote:
> > > >
> > > > > Hi, Bilal:
> > > > >
> > > > > Please help to test this patch on your Chromebook elm, thanks.
> > > > >
> > > > > Regards,
> > > > > Chun-Kuang Hu
> > > >
> > > > Just tried this patch on the Chromebook Elm, and it doesn't
> > > > work. The HDMI screen remains black, though the rest of the
> > > > system keeps on operating normally.
> > >
> > > Could you print this information, so I could find out the
> > > solution for both small hbp and elm.
> > >
> > > vm->hfront_porch, vm->hback_porch, dsi_tmp_buf_bpp,
> > > data_phy_cycles_byte, and the final horizontal_frontporch_byte,
> > > horizontal_backporch_byte.
> >
> > Here are the values I got,
> >
> > [2.506400] [drm] vm->hfront_porch: 48
> > [2.506402] [drm] vm->hback_porch: 200
> > [2.506404] [drm] dsi_tmp_buf_bpp: 3
> > [2.506406] [drm] data_phy_cycles_byte: 180
> > [2.506408] [drm] horizontal_frontporch_byte: 110
> > [2.506409] [drm] horizontal_backporch_byte: 455
> >
> > Please let me know if I can help debug this in any other way.
> >
>
> How about this patch [1] ?
>
> [1]
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2536217/2
This patch works, though it doesn't apply cleanly on 5.9-rc3 (had to
manually patch the mtk_dsi.c file).
Here are the various variable values, if you're interested.
[2.453292] [drm] vm->hfront_porch: 48
[2.453293] [drm] vm->hback_porch: 200
[2.453295] [drm] dsi_tmp_buf_bpp: 3
[2.453296] [drm] data_phy_cycles_byte: 192
[2.453298] [drm] horizontal_frontporch_byte: 107
[2.453299] [drm] horizontal_backporch_byte: 436
Thanks,
Bilal
>
> > Thanks,
> > Bilal
> >
> > >
> > > Regards,
> > > Chun-Kuang.
> > >
> > > >
> > > > >
> > > > > Chun-Kuang Hu 於 2020年11月15日 週日
> > > > > 上午8:14寫道：
> > > > > >
> > > > > > From: CK Hu
> > > > > >
> > > > > > Using vm->hfront_porch + vm->hback_porch to calculate
> > > > > > horizontal_backporch_byte would make it negtive, so
> > > > > > use horizontal_backporch_byte itself to make it positive.
> > > > > >
> > > > > > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of
> > > > > > panel with small hfp or hbp")
> > > > > >
> > > > > > Signed-off-by: CK Hu
> > > > > > Signed-off-by: Chun-Kuang Hu
> > > > > > ---
> > > > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 53
> > > > > > ++ 1 file changed, 18
> > > > > > insertions(+), 35 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c index
> > > > > > 4a188a942c38..2a64fdaed9a7 100644 ---
> > > > > > a/drivers/gpu/drm/mediatek/mtk_dsi.c +++
> > > > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -444,7 +444,10 @@
> > > > > > static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> > > > > > u32 horizontal_sync_active_byte; u32
> > > > > > horizontal_backporch_byte; u32 horizontal_frontporch_byte;
> > > > > > + u32 horizontal_front_back_byte;
> > > > > > + u32 data_phy_cycles_byte;
> > > > > > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > > > > > + u32 delta;
> > > > > > struct mtk_phy_timing *timing = &dsi->phy_timing;
> > > > > >
> > > > > > struct videomode *vm = &dsi->vm;
> > > > > > @@ -474,42 +477,22 @@ static void
> > > > > > mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> > > > > > data_phy_cycles = timing->lpx + timing->da_hs_prepare
> > > > > > + timing->da_hs_zero + timing->da_hs_exit;
> > > > > >
> > > > > > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > > > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > > > > dsi_tmp_buf_bpp >
> > > > > > - data_phy_cycles * dsi->lanes + 18) {
> > > > > > - horizontal_frontporch_byte =
> > > > > > - vm->hfront_porch *
> > > > > > dsi_tmp_buf_bpp -
> > > > > > - (data_phy_cycles *
> > > > > > dsi->lanes + 18) *
> > > > > > - vm->hfront_porch /
> > > > > > - (vm->hfront_porch +
> > > > > > vm->hback_porch); -
> > > > > > - horizontal_backporch_byte =
> > > > > > - horizontal_backporch_byte -
> > > > > > - (data_phy_cycles *
> > > > > > dsi->lanes + 18) *
> > > > > > - vm->hback_porch /
> > > > > > - (vm->hfront_porch +
> > > > > > vm->hback_porch);
> > > > > > - } else {
> > > > > > -
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
On Tue, 17 Nov 2020 16:58:48 +0500
Bilal Wasim wrote:
> Hi CK,
>
> On Tue, 17 Nov 2020 00:43:44 +0800
> Chun-Kuang Hu wrote:
>
> > Hi, Bilal:
> >
> > Bilal Wasim 於 2020年11月16日 週一
> > 下午7:53寫道：
> > >
> > > Hi CK,
> > >
> > > On Mon, 16 Nov 2020 07:12:55 +0800
> > > Chun-Kuang Hu wrote:
> > >
> > > > Hi, Bilal:
> > > >
> > > > Bilal Wasim 於 2020年11月16日 週一
> > > > 上午3:25寫道：
> > > > >
> > > > > Hi CK,
> > > > >
> > > > > On Sun, 15 Nov 2020 08:53:24 +0800
> > > > > Chun-Kuang Hu wrote:
> > > > >
> > > > > > Hi, Bilal:
> > > > > >
> > > > > > Please help to test this patch on your Chromebook elm,
> > > > > > thanks.
> > > > > >
> > > > > > Regards,
> > > > > > Chun-Kuang Hu
> > > > >
> > > > > Just tried this patch on the Chromebook Elm, and it doesn't
> > > > > work. The HDMI screen remains black, though the rest of the
> > > > > system keeps on operating normally.
> > > >
> > > > Could you print this information, so I could find out the
> > > > solution for both small hbp and elm.
> > > >
> > > > vm->hfront_porch, vm->hback_porch, dsi_tmp_buf_bpp,
> > > > data_phy_cycles_byte, and the final horizontal_frontporch_byte,
> > > > horizontal_backporch_byte.
> > >
> > > Here are the values I got,
> > >
> > > [2.506400] [drm] vm->hfront_porch: 48
> > > [2.506402] [drm] vm->hback_porch: 200
> > > [2.506404] [drm] dsi_tmp_buf_bpp: 3
> > > [2.506406] [drm] data_phy_cycles_byte: 180
> > > [2.506408] [drm] horizontal_frontporch_byte: 110
> > > [2.506409] [drm] horizontal_backporch_byte: 455
> > >
> > > Please let me know if I can help debug this in any other way.
> > >
> >
> > How about this patch [1] ?
> >
> > [1]
> > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2536217/2
> >
>
> This patch works, though it doesn't apply cleanly on 5.9-rc3 (had to
> manually patch the mtk_dsi.c file).
>
Just to clarify: I tested with 5.10-rc3, not 5.9-rc3. Apologies for the
typo.
Thanks,
Bilal
> Here are the various variable values, if you're interested.
>
> [2.453292] [drm] vm->hfront_porch: 48
> [2.453293] [drm] vm->hback_porch: 200
> [2.453295] [drm] dsi_tmp_buf_bpp: 3
> [2.453296] [drm] data_phy_cycles_byte: 192
> [2.453298] [drm] horizontal_frontporch_byte: 107
> [2.453299] [drm] horizontal_backporch_byte: 436
>
> Thanks,
> Bilal
>
> >
> > > Thanks,
> > > Bilal
> > >
> > > >
> > > > Regards,
> > > > Chun-Kuang.
> > > >
> > > > >
> > > > > >
> > > > > > Chun-Kuang Hu 於 2020年11月15日
> > > > > > 週日上午8:14寫道：
> > > > > > >
> > > > > > > From: CK Hu
> > > > > > >
> > > > > > > Using vm->hfront_porch + vm->hback_porch to calculate
> > > > > > > horizontal_backporch_byte would make it negtive, so
> > > > > > > use horizontal_backporch_byte itself to make it positive.
> > > > > > >
> > > > > > > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of
> > > > > > > panel with small hfp or hbp")
> > > > > > >
> > > > > > > Signed-off-by: CK Hu
> > > > > > > Signed-off-by: Chun-Kuang Hu
> > > > > > > ---
> > > > > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 53
> > > > > > > ++ 1 file changed, 18
> > > > > > > insertions(+), 35 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c index
> > > > > > > 4a188a942c38..2a64fdaed9a7 100644 ---
> > > > > > > a/drivers/gpu/drm/mediatek/mtk_dsi.c +++
> > > > > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -444,7 +444,10 @@
> > > > > > > static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> > > > > > > u32 horizontal_sync_active_byte; u32
> > > > > > > horizontal_backporch_byte; u32 horizontal_frontporch_byte;
> > > > > > > + u32 horizontal_front_back_byte;
> > > > > > > + u32 data_phy_cycles_byte;
> > > > > > > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > > > > > > + u32 delta;
> > > > > > > struct mtk_phy_timing *timing = &dsi->phy_timing;
> > > > > > >
> > > > > > > struct videomode *vm = &dsi->vm;
> > > > > > > @@ -474,42 +477,22 @@ static void
> > > > > > > mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> > > > > > > data_phy_cycles = timing->lpx + timing->da_hs_prepare
> > > > > > > + timing->da_hs_zero + timing->da_hs_exit;
> > > > > > >
> > > > > > > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > > > > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > > > > > dsi_tmp_buf_bpp >
> > > > > > > - data_phy_cycles * dsi->lanes + 18) {
> > > > > > > - horizontal_frontporch_byte =
> > > > > > > - vm->hfront_porch *
> > > > > > > dsi_tmp_buf_bpp -
> > > > > > > - (data_phy_cycles *
> > > > > > > dsi->lanes + 18) *
> > > > > > > - vm->hfront_porch /
> > > > > > > - (vm->hfront_porch +
> > > > > > > vm->hbac
[PATCH] drm/msm/dpu: Remove chatty vbif debug print
I don't know what this debug print is for but it is super chatty,
throwing 8 lines of debug prints in the logs every time we update a
plane. It looks like it has no value. Let's nuke it so we can get
better logs.
Cc: Sean Paul
Cc: Abhinav Kumar
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
index 5e8c3f3e6625..5eb2b2ee09f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
@@ -245,9 +245,6 @@ void dpu_vbif_set_qos_remap(struct dpu_kms *dpu_kms,
forced_on = mdp->ops.setup_clk_force_ctrl(mdp, params->clk_ctrl, true);
for (i = 0; i < qos_tbl->npriority_lvl; i++) {
- DPU_DEBUG("vbif:%d xin:%d lvl:%d/%d\n",
- params->vbif_idx, params->xin_id, i,
- qos_tbl->priority_lvl[i]);
vbif->ops.set_qos_remap(vbif, params->xin_id, i,
qos_tbl->priority_lvl[i]);
}
--
Sent by a computer, using git, on the internet
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/tiny: Add driver for ili9341 with parallel bus
From: Mikhail Durnev
MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.
It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.
[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/tiny/Kconfig| 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9341_gpio.c | 290
3 files changed, 304 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
If M is selected the module will be called ili9341.
+config TINYDRM_ILI9341_GPIO
+ tristate "DRM support for ILI9341 display panels with parallel bus
interface over GPIO"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..de8a63b8
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+ mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+ mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+ mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+ mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+ mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+ /* Memory
[PATCH] amd/amdgpu: optimise CONFIG_X||CONFIG_X_MODULE to IS_ENABLED(X)
Optimise CONFIG_ || CONFIG__MODULE to IS_ENABLED().
This change also fix check_patch.pl warning:
WARNING: Prefer IS_ENABLED() to CONFIG_ ||
CONFIG__MODULE
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined
(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 165b02e267b0..f1980cd1f402 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -64,7 +64,7 @@ struct amdgpu_atif {
struct amdgpu_atif_notifications notifications;
struct amdgpu_atif_functions functions;
struct amdgpu_atif_notification_cfg notification_cfg;
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *bd;
#endif
struct amdgpu_dm_backlight_caps backlight_caps;
@@ -447,7 +447,7 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
if (req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) {
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
if (atif->bd) {
DRM_DEBUG_DRIVER("Changing brightness to %d\n",
req.backlight_level);
@@ -806,7 +806,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
}
adev->atif = atif;
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
if (atif->notifications.brightness_change) {
if (amdgpu_device_has_dc_support(adev)) {
#if defined(CONFIG_DRM_AMD_DC)
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 07/17] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
On 16-11-20, 00:29, Dmitry Osipenko wrote:
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect framework to the driver. This is a mandatory
> change which needs to be done in order to implement interconnect-based
> memory DVFS. Users of legacy device-trees will get a message telling that
> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 86 ---
> 1 file changed, 44 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 38cc0d014738..ed6d4469c8c7 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +#include
> +
> #include "governor.h"
>
> #define ACTMON_GLB_STATUS0x0
> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> + struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> - struct devfreq *devfreq = tegra->devfreq;
> struct dev_pm_opp *opp;
> - unsigned long rate;
> - int err;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> return PTR_ERR(opp);
> }
> - rate = dev_pm_opp_get_freq(opp);
> - dev_pm_opp_put(opp);
> -
> - err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
> - if (err)
> - return err;
> -
> - err = clk_set_rate(tegra->emc_clock, 0);
> - if (err)
> - goto restore_min_rate;
>
> - return 0;
> -
> -restore_min_rate:
> - clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
> + ret = dev_pm_opp_set_bw(dev, opp);
> + dev_pm_opp_put(opp);
>
> - return err;
> + return ret;
> }
>
> static int tegra_devfreq_get_dev_status(struct device *dev,
> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> stat->private_data = tegra;
>
> /* The below are to be used by the other governors */
> - stat->current_frequency = cur_freq;
> + stat->current_frequency = cur_freq * KHZ;
>
> actmon_dev = &tegra->devices[MCALL];
>
> @@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> target_freq = max(target_freq, dev->target_freq);
> }
>
> - *freq = target_freq;
> + /*
> + * tegra-devfreq driver operates with KHz units, while OPP table
> + * entries use Hz units. Hence we need to convert the units for the
> + * devfreq core.
> + */
> + *freq = target_freq * KHZ;
>
> return 0;
> }
> @@ -774,6 +767,7 @@ static struct devfreq_governor tegra_devfreq_governor = {
>
> static int tegra_devfreq_probe(struct platform_device *pdev)
> {
> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> struct tegra_devfreq_device *dev;
> struct tegra_devfreq *tegra;
> struct devfreq *devfreq;
> @@ -781,6 +775,13 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> long rate;
> int err;
>
> + /* legacy device-trees don't have OPP table and must be updated */
> + if (!device_property_present(&pdev->dev, "operating-points-v2")) {
> + dev_err(&pdev->dev,
> + "OPP table not found, please update your device
> tree\n");
> + return -ENODEV;
> + }
> +
You forgot to remove this ?
> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
> if (!tegra)
> return -ENOMEM;
> @@ -822,11 +823,25 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + tegra->opp_table = dev_pm_opp_set_supported_hw(&pdev->dev,
> +&hw_version, 1);
> + err = PTR_ERR_OR_ZERO(tegra->opp_table);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to set supported HW: %d\n", err);
> + return err;
> + }
> +
> + err = dev_pm_opp_of_add_table(&pdev->dev);
> + if (err) {
> + dev_err(&pd
Re: [Freedreno] [PATCH] drm/msm/dpu: Remove chatty vbif debug print
Quoting abhin...@codeaurora.org (2020-11-17 12:34:56)
> On 2020-11-17 09:26, Stephen Boyd wrote:
> > I don't know what this debug print is for but it is super chatty,
> > throwing 8 lines of debug prints in the logs every time we update a
> > plane. It looks like it has no value. Let's nuke it so we can get
> > better logs.
> >
> > Cc: Sean Paul
> > Cc: Abhinav Kumar
> > Signed-off-by: Stephen Boyd
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > index 5e8c3f3e6625..5eb2b2ee09f5 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > @@ -245,9 +245,6 @@ void dpu_vbif_set_qos_remap(struct dpu_kms
> > *dpu_kms,
> > forced_on = mdp->ops.setup_clk_force_ctrl(mdp, params->clk_ctrl,
> > true);
> >
> > for (i = 0; i < qos_tbl->npriority_lvl; i++) {
> > - DPU_DEBUG("vbif:%d xin:%d lvl:%d/%d\n",
> > - params->vbif_idx, params->xin_id, i,
> > - qos_tbl->priority_lvl[i]);
>
> Instead of getting rid of this print, we should optimize the caller of
> this.
Does the print tell us anything? Right now it prints 8 lines where it
feels like it could be trimmed down:
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:0/3
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:1/3
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:2/4
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:3/4
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:4/5
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:5/5
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:6/6
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:7/6
maybe one line that combines the index into values?
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 [3 3 4 4 5 5 6 6]
But again I have no idea if this print is really useful. Maybe we can
print it only if the value changes from what was already there?
Basically move the print into dpu_hw_set_qos_remap() and then skip out
early if nothing changed or print and modify the register.
> This is what
> we are doing in downstream. So we need to update the property only if we
> are switching from a RT client
> to non-RT client for the plane and vice-versa. So we should try to do
> the same thing here.
>
> is_rt = sde_crtc_is_rt_client(crtc, crtc->state);
> if (is_rt != psde->is_rt_pipe) {
> psde->is_rt_pipe = is_rt;
> pstate->dirty |= SDE_PLANE_DIRTY_QOS;
> }
>
>
> if (pstate->dirty & DPU_PLANE_DIRTY_QOS)
> _dpu_plane_set_qos_remap(plane);
>
Sounds great! Can you send the patch?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/mipi-dbi: Add support for Type B
From: Mikhail Durnev
Intel 8080 type (Type B) parallel bus over GPIO.
The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
It is enough to support only write operations to initialize displays
and output video data. The bus driver returns EOPNOTSUPP for all read
operations requested through a display driver.
Bit banging is used to transmit data over the parallel bus from host
to display. There are two numbers that contol timings: wr_up_delay
and wr_down_delay. They should be provided by the display driver.
The first number is related to the write control pulse duration, and
the second number is related to the write cycle duration that can
be found in the specification of the display.
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/drm_mipi_dbi.c | 116 -
include/drm/drm_mipi_dbi.h | 30 ++-
2 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd..4d2e108 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -61,7 +61,7 @@
*3. 8-bit with the Data/Command signal as a separate D/CX pin
*
* Currently mipi_dbi only supports Type C options 1 and 3 with
- * mipi_dbi_spi_init().
+ * mipi_dbi_spi_init() and Type B with mipi_dbi_gpio_init().
*/
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
@@ -1158,6 +1158,120 @@ EXPORT_SYMBOL(mipi_dbi_spi_transfer);
#endif /* CONFIG_SPI */
+/*
+ * This function implements data transfer only from host to display.
+ */
+static void mipi_dbi_gpio_transfer(struct mipi_dbi *dbi, u16 data)
+{
+ unsigned long ldata = data;
+
+ /*
+* Set W/R to low to start transfer.
+* Set DB bits with provided data when W/R is low.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 0);
+ gpiod_set_array_value_cansleep(dbi->db->ndescs, dbi->db->desc,
+ dbi->db->info, &ldata);
+
+ /*
+* The bus usually needs additional delay.
+*/
+ ndelay(dbi->wr_up_delay);
+
+ /*
+* Set W/R to high to indicate that DB lines are set.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 1);
+
+ /*
+* The connected display needs some time to read the data.
+*/
+ ndelay(dbi->wr_down_delay);
+}
+
+static int mipi_dbi_gpio_command(struct mipi_dbi *dbi, u8 *cmd,
+ u8 *par, size_t num)
+{
+ int i;
+
+ /*
+* Read commands are not currently supported.
+*/
+ if (mipi_dbi_command_is_read(dbi, *cmd))
+ return -EOPNOTSUPP;
+
+ MIPI_DBI_DEBUG_COMMAND(*cmd, par, num);
+
+ gpiod_set_value_cansleep(dbi->dc, 0);
+ mipi_dbi_gpio_transfer(dbi, (u16)*cmd);
+ gpiod_set_value_cansleep(dbi->dc, 1);
+
+ if (dbi->db->ndescs == 16 &&
+ (*cmd == MIPI_DCS_WRITE_MEMORY_START ||
+*cmd == MIPI_DCS_WRITE_MEMORY_CONTINUE)) {
+ /*
+* Only a couple of commands supports 16-bit transfer.
+*/
+ for (i = 0; i < num; i += 2) {
+ u16 data = *(u16 *)&par[i];
+
+ if (dbi->swap_bytes)
+ data = (data >> 8) | (data << 8);
+
+ mipi_dbi_gpio_transfer(dbi, data);
+ }
+ } else {
+ for (i = 0; i < num; i++) {
+ /*
+* Other commands ignore most significant bits.
+*/
+ mipi_dbi_gpio_transfer(dbi, (u16)par[i]);
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface implemented via
GPIO
+ * @dbi: MIPI DBI structure to initialize
+ * @dc: D/C gpio
+ * @wr: W/R gpio
+ * @db: DB gpios
+ * @wr_up_delay: Delay after setting DB and before changing W/R from low to
high
+ * @wr_down_delay: Delay after changing W/R from low to high
+ *
+ * This function sets &mipi_dbi->command, enables &mipi_dbi->read_commands for
the
+ * usual read commands. It should be followed by a call to mipi_dbi_dev_init()
or
+ * a driver-specific init.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_gpio_init(struct mipi_dbi *dbi, struct gpio_desc *dc,
+ struct gpio_desc *wr, struct gpio_descs *db,
+ unsigned long wr_up_delay, unsigned long wr_down_delay)
+{
+ dbi->spi = 0; /* Type B uses GPIO lines rather than SPI */
+
+ dbi->read_commands = mipi_dbi_dcs_read_commands;
+ dbi->command = mipi_dbi_gpio_command;
+
+ dbi->dc = dc;
+ dbi->
Re: [PATCH v9 01/17] memory: tegra30: Support interconnect framework
Hi Dmitry,
Thank you working on this!
On 15.11.20 23:29, Dmitry Osipenko wrote:
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS. MC driver now
supports tuning of memory arbitration latency, which needs to be done
for ISO memory clients, like a Display client for example.
Tested-by: Peter Geis
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/Kconfig | 1 +
drivers/memory/tegra/tegra30-emc.c | 349 +++--
drivers/memory/tegra/tegra30.c | 173 +-
3 files changed, 501 insertions(+), 22 deletions(-)
[..]> diff --git a/drivers/memory/tegra/tegra30.c
b/drivers/memory/tegra/tegra30.c
index d0314f29608d..ea849003014b 100644
--- a/drivers/memory/tegra/tegra30.c
+++ b/drivers/memory/tegra/tegra30.c
[..]
+
+static int tegra30_mc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct tegra_mc *mc = icc_provider_to_tegra_mc(src->provider);
+ const struct tegra_mc_client *client = &mc->soc->clients[src->id];
+ u64 peak_bandwidth = icc_units_to_bps(src->peak_bw);
+
+ /*
+* Skip pre-initialization that is done by icc_node_add(), which sets
+* bandwidth to maximum for all clients before drivers are loaded.
+*
+* This doesn't make sense for us because we don't have drivers for all
+* clients and it's okay to keep configuration left from bootloader
+* during boot, at least for today.
+*/
+ if (src == dst)
+ return 0;
Nit: The "proper" way to express this should be to implement the
.get_bw() callback to return zero as initial average/peak bandwidth.
I'm wondering if this will work here?
The rest looks good to me!
Thanks,
Georgi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 6/8] drm/msm/a6xx: Add support for using system cache on MMU500 based targets
From: Jordan Crouse
GPU targets with an MMU-500 attached have a slightly different process for
enabling system cache. Use the compatible string on the IOMMU phandle
to see if an MMU-500 is attached and modify the programming sequence
accordingly.
Signed-off-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 95c98c642876..3f8b92da8cba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1042,6 +1042,8 @@ static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
u32 cntl1_regval = 0;
if (IS_ERR(a6xx_gpu->llc_mmio))
@@ -1055,11 +1057,17 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
(gpu_scid << 15) | (gpu_scid << 20);
}
+ /*
+* For targets with a MMU500, activate the slice but don't program the
+* register. The XBL will take care of that.
+*/
if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
- u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+ if (!a6xx_gpu->have_mmu500) {
+ u32 gpuhtw_scid =
llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
- gpuhtw_scid &= 0x1f;
- cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25),
gpuhtw_scid);
+ }
}
if (cntl1_regval) {
@@ -1067,13 +1075,20 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
* Program the slice IDs for the various GPU blocks and GPU MMU
* pagetables
*/
- a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
-
- /*
-* Program cacheability overrides to not allocate cache lines on
-* a write miss
-*/
- a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ if (a6xx_gpu->have_mmu500)
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
+ cntl1_regval);
+ else {
+ a6xx_llc_write(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
0x03);
+ }
}
}
@@ -1086,10 +1101,21 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu
*a6xx_gpu)
static void a6xx_llc_slices_init(struct platform_device *pdev,
struct a6xx_gpu *a6xx_gpu)
{
+ struct device_node *phandle;
+
a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
+ /*
+* There is a different programming path for targets with an mmu500
+* attached, so detect if that is the case
+*/
+ phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+ a6xx_gpu->have_mmu500 = (phandle &&
+ of_device_is_compatible(phandle, "arm,mmu-500"));
+ of_node_put(phandle);
+
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 9e6079af679c..e793d329e77b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -32,6 +32,7 @@ struct a6xx_gpu {
void __iomem *llc_mmio;
void *llc_slice;
void *htw_llc_slice;
+ bool have_mmu500;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 7/8] iommu: arm-smmu-impl: Use table to list QCOM implementations
Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.
Signed-off-by: Sai Prakash Ranjan
Acked-by: Will Deacon
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 9 +
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 7fed89c9d18a..26e2734eb4d7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -214,14 +214,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
return nvidia_smmu_impl_init(smmu);
- if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
- of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
- return qcom_smmu_impl_init(smmu);
-
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
- return qcom_adreno_smmu_impl_init(smmu);
+ smmu = qcom_smmu_impl_init(smmu);
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = &mrvl_mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d0636c803a36..add1859b2899 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -318,12 +318,23 @@ static struct arm_smmu_device *qcom_smmu_create(struct
arm_smmu_device *smmu,
return &qsmmu->smmu;
}
+static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
+ { .compatible = "qcom,sc7180-smmu-500" },
+ { .compatible = "qcom,sdm845-smmu-500" },
+ { .compatible = "qcom,sm8150-smmu-500" },
+ { .compatible = "qcom,sm8250-smmu-500" },
+ { }
+};
+
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
{
- return qcom_smmu_create(smmu, &qcom_smmu_impl);
-}
+ const struct device_node *np = smmu->dev->of_node;
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu)
-{
- return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+ if (of_match_node(qcom_smmu_impl_of_match, np))
+ return qcom_smmu_create(smmu, &qcom_smmu_impl);
+
+ if (of_device_is_compatible(np, "qcom,adreno-smmu"))
+ return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+
+ return smmu;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index caae543ea077..7db81c7c7833 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -523,7 +523,6 @@ static inline void arm_smmu_writeq(struct arm_smmu_device
*smmu, int page,
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu);
void arm_smmu_write_context_bank(struct arm_smmu_device *smmu, int idx);
int arm_mmu500_reset(struct arm_smmu_device *smmu);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amd/amdgpu: use kmalloc_array to replace kmalloc with multiply
Fix check_patch.pl warning:
WARNING: Prefer kmalloc_array over kmalloc with multiply
+bps = kmalloc(align_space * sizeof((*data)->bps), GFP_KERNEL);
WARNING: Prefer kmalloc_array over kmalloc with multiply
+bps_bo = kmalloc(align_space * sizeof((*data)->bps_bo),
GFP_KERNEL);
kmalloc_array has multiply overflow check, which will be safer.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index d0aea5e39531..f2a0851c804f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -280,8 +280,8 @@ static int amdgpu_virt_init_ras_err_handler_data(struct
amdgpu_device *adev)
if (!*data)
return -ENOMEM;
- bps = kmalloc(align_space * sizeof((*data)->bps), GFP_KERNEL);
- bps_bo = kmalloc(align_space * sizeof((*data)->bps_bo), GFP_KERNEL);
+ bps = kmalloc_array(align_space, sizeof((*data)->bps), GFP_KERNEL);
+ bps_bo = kmalloc_array(align_space, sizeof((*data)->bps_bo),
GFP_KERNEL);
if (!bps || !bps_bo) {
kfree(bps);
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 3/8] iommu/arm-smmu: Move non-strict mode to use domain_attr_io_pgtbl_cfg
Now that we have a struct domain_attr_io_pgtbl_cfg with quirks,
use that for non_strict mode as well thereby removing the need
for more members of arm_smmu_domain in the future.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 7 ++-
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 7b05782738e2..5f066a1b7221 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
goto out_clear_smmu;
}
- if (smmu_domain->non_strict)
- pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-
if (smmu_domain->pgtbl_cfg.quirks)
pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
@@ -1527,7 +1524,7 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
*domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
- *(int *)data = smmu_domain->non_strict;
+ *(int *)data = smmu_domain->pgtbl_cfg.quirks;
return 0;
default:
return -ENODEV;
@@ -1583,7 +1580,7 @@ static int arm_smmu_domain_set_attr(struct iommu_domain
*domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
- smmu_domain->non_strict = *(int *)data;
+ smmu_domain->pgtbl_cfg.quirks |=
IO_PGTABLE_QUIRK_NON_STRICT;
break;
default:
ret = -ENODEV;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 18fbed376afb..caae543ea077 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -368,7 +368,6 @@ struct arm_smmu_domain {
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage stage;
- boolnon_strict;
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t cb_lock; /* Serialises ATS1* ops and
TLB syncs */
struct iommu_domain domain;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/7] Enable rk3066a HDMI sound
First fix some legacy things in clk-rk3188.c that was never updated, because probably nobody used rk3066a I2S before in the mainline kernel. Update the rk3066a HDMI documents with a #sound-dai-cells property. Include the code for sound in the HDMI driver. Add a simple-sound-card compatible node to rk3066a.dtsi, because I2S0 and HDMI TX are connected internally. And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. Johan Jonker (6): clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks clk: rockchip: fix i2s gate bits on rk3066 and rk3188 dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808 Zheng Yang (1): drm: rockchip: add sound support to rk3066 hdmi driver .../display/rockchip/rockchip,rk3066-hdmi.yaml | 4 + arch/arm/boot/dts/rk3066a-mk808.dts| 8 + arch/arm/boot/dts/rk3066a.dtsi | 17 ++ drivers/clk/rockchip/clk-rk3188.c | 35 +-- drivers/gpu/drm/rockchip/Kconfig | 2 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 272 - 6 files changed, 320 insertions(+), 18 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu/amdgpu_ids: fix kmalloc_array not uses number as first arg
Fix check_patch.pl warning: kmalloc_array uses number as first arg, sizeof is generally wrong. +fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); Signed-off-by: Bernard Zhao --- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index 6e9a9e5dbea0..f2bd4b0e06f6 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(id_mgr->num_ids, sizeof(void *), GFP_KERNEL); if (!fences) return -ENOMEM; -- 2.29.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 07/17] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
17.11.2020 13:07, Viresh Kumar пишет:
> On 16-11-20, 00:29, Dmitry Osipenko wrote:
>> This patch moves ACTMON driver away from generating OPP table by itself,
>> transitioning it to use the table which comes from device-tree. This
>> change breaks compatibility with older device-trees in order to bring
>> support for the interconnect framework to the driver. This is a mandatory
>> change which needs to be done in order to implement interconnect-based
>> memory DVFS. Users of legacy device-trees will get a message telling that
>> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
>> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>>
>> Tested-by: Peter Geis
>> Tested-by: Nicolas Chauvet
>> Acked-by: Chanwoo Choi
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/devfreq/tegra30-devfreq.c | 86 ---
>> 1 file changed, 44 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/devfreq/tegra30-devfreq.c
>> b/drivers/devfreq/tegra30-devfreq.c
>> index 38cc0d014738..ed6d4469c8c7 100644
>> --- a/drivers/devfreq/tegra30-devfreq.c
>> +++ b/drivers/devfreq/tegra30-devfreq.c
>> @@ -19,6 +19,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>> #include "governor.h"
>>
>> #define ACTMON_GLB_STATUS 0x0
>> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>>
>> struct tegra_devfreq {
>> struct devfreq *devfreq;
>> +struct opp_table*opp_table;
>>
>> struct reset_control*reset;
>> struct clk *clock;
>> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
>> *tegra)
>> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>> u32 flags)
>> {
>> -struct tegra_devfreq *tegra = dev_get_drvdata(dev);
>> -struct devfreq *devfreq = tegra->devfreq;
>> struct dev_pm_opp *opp;
>> -unsigned long rate;
>> -int err;
>> +int ret;
>>
>> opp = devfreq_recommended_opp(dev, freq, flags);
>> if (IS_ERR(opp)) {
>> dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
>> return PTR_ERR(opp);
>> }
>> -rate = dev_pm_opp_get_freq(opp);
>> -dev_pm_opp_put(opp);
>> -
>> -err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
>> -if (err)
>> -return err;
>> -
>> -err = clk_set_rate(tegra->emc_clock, 0);
>> -if (err)
>> -goto restore_min_rate;
>>
>> -return 0;
>> -
>> -restore_min_rate:
>> -clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
>> +ret = dev_pm_opp_set_bw(dev, opp);
>> +dev_pm_opp_put(opp);
>>
>> -return err;
>> +return ret;
>> }
>>
>> static int tegra_devfreq_get_dev_status(struct device *dev,
>> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
>> *dev,
>> stat->private_data = tegra;
>>
>> /* The below are to be used by the other governors */
>> -stat->current_frequency = cur_freq;
>> +stat->current_frequency = cur_freq * KHZ;
>>
>> actmon_dev = &tegra->devices[MCALL];
>>
>> @@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq
>> *devfreq,
>> target_freq = max(target_freq, dev->target_freq);
>> }
>>
>> -*freq = target_freq;
>> +/*
>> + * tegra-devfreq driver operates with KHz units, while OPP table
>> + * entries use Hz units. Hence we need to convert the units for the
>> + * devfreq core.
>> + */
>> +*freq = target_freq * KHZ;
>>
>> return 0;
>> }
>> @@ -774,6 +767,7 @@ static struct devfreq_governor tegra_devfreq_governor = {
>>
>> static int tegra_devfreq_probe(struct platform_device *pdev)
>> {
>> +u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
>> struct tegra_devfreq_device *dev;
>> struct tegra_devfreq *tegra;
>> struct devfreq *devfreq;
>> @@ -781,6 +775,13 @@ static int tegra_devfreq_probe(struct platform_device
>> *pdev)
>> long rate;
>> int err;
>>
>> +/* legacy device-trees don't have OPP table and must be updated */
>> +if (!device_property_present(&pdev->dev, "operating-points-v2")) {
>> +dev_err(&pdev->dev,
>> +"OPP table not found, please update your device
>> tree\n");
>> +return -ENODEV;
>> +}
>> +
>
> You forgot to remove this ?
Yes, good catch. I'm planning to replace this code with a common helper
sometime soon, so if there won't be another reasons to make a new
revision, then I'd prefer to keep it as-is for now.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
On 2020/11/18 1:47, Jernej Škrabec wrote:
> Dne ponedeljek, 16. november 2020 ob 02:09:29 CET je Xiongfeng Wang
> napisal(a):
>> Fix to return a negative error code from the error handling case instead
>> of 0 in function sun8i_dw_hdmi_bind().
>>
>> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
>> Reported-by: Hulk Robot
>> Signed-off-by: Xiongfeng Wang
>> Reviewed-by: Jernej Skrabec
>
> Applied to drm-misc-fixes, thanks!
>
> In future, please CC all people given by get_maintainer.pl script. In this
> case you missed Maxime Ripard and Chen-Yu Tsai.
Sure, thanks for reminding me.
Thanks,
Xiongfeng
>
> Best regards,
> Jernej
>
>
> .
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 0/8] System Cache support for GPU and required SMMU support
Some hardware variants contain a system cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices preallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver. Patch 7 and 8 are minor cleanups for arm-smmu impl. Changes in v8: * Introduce a generic domain attribute for pagetable config (Will) * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will) * Move non-strict mode to use new struct domain_attr_io_pgtbl_config (Will) Changes in v7: * Squash Jordan's patch to support MMU500 targets * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for adreno-smmu impl Changes in v6: * Move table to arm-smmu-qcom (Robin) Changes in v5: * Drop cleanup of blank lines since it was intentional (Robin) * Rebase again on top of msm-next-pgtables as it moves pretty fast Changes in v4: * Drop IOMMU_SYS_CACHE prot flag * Rebase on top of https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables Changes in v3: * Fix domain attribute setting to before iommu_attach_device() * Fix few code style and checkpatch warnings * Rebase on top of Jordan's latest split pagetables and per-instance pagetables support Changes in v2: * Addressed review comments and rebased on top of Jordan's split pagetables series Jordan Crouse (1): drm/msm/a6xx: Add support for using system cache on MMU500 based targets Sai Prakash Ranjan (5): iommu/io-pgtable-arm: Add support to use system cache iommu/arm-smmu: Add domain attribute for pagetable configuration iommu/arm-smmu: Move non-strict mode to use domain_attr_io_pgtbl_cfg iommu: arm-smmu-impl: Use table to list QCOM implementations iommu: arm-smmu-impl: Add a space before open parenthesis Sharat Masetty (2): drm/msm: rearrange the gpu_rmw() function drm/msm/a6xx: Add support for using system cache(LLC) drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 109 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 5 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 17 drivers/gpu/drm/msm/msm_drv.c | 8 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gpu.h | 5 +- drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 11 +-- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 +++- drivers/iommu/arm/arm-smmu/arm-smmu.c | 30 +- drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 +- drivers/iommu/io-pgtable-arm.c | 10 +- include/linux/io-pgtable.h | 8 ++ include/linux/iommu.h | 1 + 13 files changed, 203 insertions(+), 26 deletions(-) base-commit: a29bbb0861f487a5e144dc997a9f71a36c7a2404 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/mipi-dbi: Type B bus support, drm/tiny: MRB2801
From: Mikhail Durnev Hi All, This patch series is aiming at extending the mipi-dbi bus driver to support Intel 8080 type parallel bus (Type B) over GPIO and adding a new driver for ILI9341 display panels with 8- or 16-bit parallel interface. It was tested with the MRB2801 display module [1] that had a connector compatible with the ALIENTEK STM32 development board. The module was connected to Raspberry Pi 3 via GPIO pins. The parallel bus is implemented partially. It supports only write operations from the host to the display. Read operations would require switching GPIO mode between input and output back and forth. But this implementation is very simple, and GPIO mode can be set for all used pins to output once at initialization. The RD pin of the display has to always receive the logic high signal to make sure the data bus pins from the dislay side are always in the high impedance state. Otherwise the display module as well as the GPIO controller of the host can be damaged. To be on the safe side I recommend using protective resistors for all GPIO pins conneced to DB pins of the display. Resistors of 10 kOhms are just fine for RPi 3. The WR and DC pins may not work well with 10K resistors. Although there is no need to protect them, you can try using 1K resistors if you want. Bit banging is used to transmit data over the parallel bus from host to display. There are two numbers that contol timings. They should be defined in the device tree via the wr-up-down-delays property. The first number is related to the write control pulse duration, and the second number is related to the write cycle duration. For ILI9341, the write pulse cannot be shorter than 15 ns, and the write duration cannot be shorter than 66 ns. Delays of 10 and 51 ns respectively allow to meet the specifications on RPi 3. Faster machines may need values closer to 15 and 66. [1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801 Mikhail Durnev (3): drm/mipi-dbi: Add support for Type B drm/tiny: Add driver for ili9341 with parallel bus dt-bindings: panel: Add bindings for MRB2801 .../devicetree/bindings/display/ronbo,mrb2801.txt | 42 +++ drivers/gpu/drm/drm_mipi_dbi.c | 116 - drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9341_gpio.c| 290 + include/drm/drm_mipi_dbi.h | 30 ++- 6 files changed, 490 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/7] clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks
Add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks,
so that the parent COMPOSITE_FRACMUX and COMPOSITE_NOMUX
also update.
Signed-off-by: Johan Jonker
---
drivers/clk/rockchip/clk-rk3188.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3188.c
b/drivers/clk/rockchip/clk-rk3188.c
index 730020fcc..db8c58813 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -255,19 +255,19 @@ static struct rockchip_clk_branch common_spdif_fracmux
__initdata =
RK2928_CLKSEL_CON(5), 8, 2, MFLAGS);
static struct rockchip_clk_branch common_uart0_fracmux __initdata =
- MUX(SCLK_UART0, "sclk_uart0", mux_sclk_uart0_p, 0,
+ MUX(SCLK_UART0, "sclk_uart0", mux_sclk_uart0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(13), 8, 2, MFLAGS);
static struct rockchip_clk_branch common_uart1_fracmux __initdata =
- MUX(SCLK_UART1, "sclk_uart1", mux_sclk_uart1_p, 0,
+ MUX(SCLK_UART1, "sclk_uart1", mux_sclk_uart1_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(14), 8, 2, MFLAGS);
static struct rockchip_clk_branch common_uart2_fracmux __initdata =
- MUX(SCLK_UART2, "sclk_uart2", mux_sclk_uart2_p, 0,
+ MUX(SCLK_UART2, "sclk_uart2", mux_sclk_uart2_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(15), 8, 2, MFLAGS);
static struct rockchip_clk_branch common_uart3_fracmux __initdata =
- MUX(SCLK_UART3, "sclk_uart3", mux_sclk_uart3_p, 0,
+ MUX(SCLK_UART3, "sclk_uart3", mux_sclk_uart3_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(16), 8, 2, MFLAGS);
static struct rockchip_clk_branch common_clk_branches[] __initdata = {
@@ -408,28 +408,28 @@ static struct rockchip_clk_branch common_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "uart0_pre", "uart_src", 0,
RK2928_CLKSEL_CON(13), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 8, GFLAGS),
- COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_pre", 0,
+ COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(17), 0,
RK2928_CLKGATE_CON(1), 9, GFLAGS,
&common_uart0_fracmux),
COMPOSITE_NOMUX(0, "uart1_pre", "uart_src", 0,
RK2928_CLKSEL_CON(14), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 10, GFLAGS),
- COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_pre", 0,
+ COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(18), 0,
RK2928_CLKGATE_CON(1), 11, GFLAGS,
&common_uart1_fracmux),
COMPOSITE_NOMUX(0, "uart2_pre", "uart_src", 0,
RK2928_CLKSEL_CON(15), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 12, GFLAGS),
- COMPOSITE_FRACMUX(0, "uart2_frac", "uart2_pre", 0,
+ COMPOSITE_FRACMUX(0, "uart2_frac", "uart2_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(19), 0,
RK2928_CLKGATE_CON(1), 13, GFLAGS,
&common_uart2_fracmux),
COMPOSITE_NOMUX(0, "uart3_pre", "uart_src", 0,
RK2928_CLKSEL_CON(16), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 14, GFLAGS),
- COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_pre", 0,
+ COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(20), 0,
RK2928_CLKGATE_CON(1), 15, GFLAGS,
&common_uart3_fracmux),
@@ -543,15 +543,15 @@ static struct clk_div_table div_aclk_cpu_t[] = {
};
static struct rockchip_clk_branch rk3066a_i2s0_fracmux __initdata =
- MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, 0,
+ MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(2), 8, 2, MFLAGS);
static struct rockchip_clk_branch rk3066a_i2s1_fracmux __initdata =
- MUX(SCLK_I2S1, "sclk_i2s1", mux_sclk_i2s1_p, 0,
+ MUX(SCLK_I2S1, "sclk_i2s1", mux_sclk_i2s1_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(3), 8, 2, MFLAGS);
static struct rockchip_clk_branch rk3066a_i2s2_fracmux __initdata =
- MUX(SCLK_I2S2, "sclk_i2s2", mux_sclk_i2s2_p, 0,
+ MUX(SCLK_I2S2, "sclk_i2s2", mux_sclk_i2s2_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(4), 8, 2, MFLAGS);
static struct rockchip_clk_branch rk3066a_clk_branches[] __initdata = {
@@ -615,21 +615,21 @@ static struct rockchip_clk_branch rk3066a_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "i2s0_pre", "i2s_src", 0,
RK2928_CLKSEL_CON(2), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(0), 7, GFLAGS),
- COMPOSITE_FRACMUX(0, "i2s0_fra
[PATCH 3/3] dt-bindings: panel: Add bindings for MRB2801
From: Mikhail Durnev
Add binding for Ronbo MRB2801 display module.
This binding is for display panels using an Ilitek ILI9341 controller in
parallel mode.
Signed-off-by: Mikhail Durnev
---
.../devicetree/bindings/display/ronbo,mrb2801.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
diff --git a/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
new file mode 100644
index 000..db1a861e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
@@ -0,0 +1,42 @@
+MRB2801 display panel
+
+This binding is for display panels using an Ilitek ILI9341 controller in
+parallel mode.
+
+Required properties:
+- compatible: "ronbo,mrb2801"
+- dc-gpios:D/C pin
+- wr-gpios:W/R pin
+- db-gpios:8 or 16 DB pins
+- reset-gpios: Reset pin
+- wr-up-down-delays: Delays in ns for changing W/R from down to up and from
up to down
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ mrb2801{
+ compatible = "ronbo,mrb2801";
+ db-gpios = <&gpio 17 0>, /* DB0 */
+ <&gpio 18 0>, /* DB1 */
+ <&gpio 27 0>, /* DB2 */
+ <&gpio 22 0>, /* DB3 */
+ <&gpio 23 0>, /* DB4 */
+ <&gpio 24 0>, /* DB5 */
+ <&gpio 25 0>, /* DB6 */
+ <&gpio 4 0>, /* DB7 */
+ <&gpio 14 0>, /* DB8 */
+ <&gpio 15 0>, /* DB9 */
+ <&gpio 5 0>, /* DB10 */
+ <&gpio 6 0>, /* DB11 */
+ <&gpio 13 0>, /* DB12 */
+ <&gpio 19 0>, /* DB13 */
+ <&gpio 26 0>, /* DB14 */
+ <&gpio 12 0>; /* DB15 */
+ dc-gpios = <&gpio 16 0>; /* D/C */
+ wr-gpios = <&gpio 20 0>; /* W/R */
+ wr-up-down-delays = <10 51>;
+ reset-gpios = <&gpio 21 0>; /* RST */
+ backlight = <&backlight>;
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Dne ponedeljek, 16. november 2020 ob 02:09:29 CET je Xiongfeng Wang
napisal(a):
> Fix to return a negative error code from the error handling case instead
> of 0 in function sun8i_dw_hdmi_bind().
>
> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> Reviewed-by: Jernej Skrabec
Applied to drm-misc-fixes, thanks!
In future, please CC all people given by get_maintainer.pl script. In this
case you missed Maxime Ripard and Chen-Yu Tsai.
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm/dp: fix connect/disconnect handled at irq_hpd
Quoting Kuogee Hsieh (2020-11-17 10:40:15)
> Some usb type-c dongle use irq_hpd request to perform device connection
> and disconnection. This patch add handling of both connection and
> disconnection are based on the state of hpd_state and sink_count.
>
> Changes in V2:
> -- add dp_display_handle_port_ststus_changed()
> -- fix kernel test robot complaint
>
> Reported-by: kernel test robot
> Fixes: 26b8d66a399e ("drm/msm/dp: promote irq_hpd handle to handle link
> training correctly")
> Signed-off-by: Kuogee Hsieh
> ---
Tested-by: Stephen Boyd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 01/17] memory: tegra30: Support interconnect framework
17.11.2020 23:24, Georgi Djakov пишет:
> Hi Dmitry,
>
> Thank you working on this!
>
> On 15.11.20 23:29, Dmitry Osipenko wrote:
>> Now Internal and External memory controllers are memory interconnection
>> providers. This allows us to use interconnect API for tuning of memory
>> configuration. EMC driver now supports OPPs and DVFS. MC driver now
>> supports tuning of memory arbitration latency, which needs to be done
>> for ISO memory clients, like a Display client for example.
>>
>> Tested-by: Peter Geis
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/memory/tegra/Kconfig | 1 +
>> drivers/memory/tegra/tegra30-emc.c | 349 +++--
>> drivers/memory/tegra/tegra30.c | 173 +-
>> 3 files changed, 501 insertions(+), 22 deletions(-)
>>
> [..]> diff --git a/drivers/memory/tegra/tegra30.c
> b/drivers/memory/tegra/tegra30.c
>> index d0314f29608d..ea849003014b 100644
>> --- a/drivers/memory/tegra/tegra30.c
>> +++ b/drivers/memory/tegra/tegra30.c
> [..]
>> +
>> +static int tegra30_mc_icc_set(struct icc_node *src, struct icc_node
>> *dst)
>> +{
>> + struct tegra_mc *mc = icc_provider_to_tegra_mc(src->provider);
>> + const struct tegra_mc_client *client = &mc->soc->clients[src->id];
>> + u64 peak_bandwidth = icc_units_to_bps(src->peak_bw);
>> +
>> + /*
>> + * Skip pre-initialization that is done by icc_node_add(), which
>> sets
>> + * bandwidth to maximum for all clients before drivers are loaded.
>> + *
>> + * This doesn't make sense for us because we don't have drivers
>> for all
>> + * clients and it's okay to keep configuration left from bootloader
>> + * during boot, at least for today.
>> + */
>> + if (src == dst)
>> + return 0;
>
> Nit: The "proper" way to express this should be to implement the
> .get_bw() callback to return zero as initial average/peak bandwidth.
> I'm wondering if this will work here?
>
> The rest looks good to me!
Hello Georgi,
Returning zeros doesn't allow us to skip the initialization that is done
by provider->set(node, node) in icc_node_add(). It will reconfigure
memory latency in accordance to a zero memory bandwidth, which is wrong
to do.
It actually should be more preferred to preset bandwidth to a maximum
before all drivers are synced, but this should be done only once we will
wire up all drivers to use ICC framework. For now it's safer to keep the
default hardware configuration untouched.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 8/8] iommu: arm-smmu-impl: Add a space before open parenthesis
Fix the checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
Acked-by: Will Deacon
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 26e2734eb4d7..136872e77195 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -12,7 +12,7 @@
static int arm_smmu_gr0_ns(int offset)
{
- switch(offset) {
+ switch (offset) {
case ARM_SMMU_GR0_sCR0:
case ARM_SMMU_GR0_sACR:
case ARM_SMMU_GR0_sGFSR:
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 2/8] iommu/arm-smmu: Add domain attribute for pagetable configuration
Add iommu domain attribute for pagetable configuration which
initially will be used to set quirks like for system cache aka
last level cache to be used by client drivers like GPU to set
right attributes for caching the hardware pagetables into the
system cache and later can be extended to include other page
table configuration data.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 25 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
include/linux/io-pgtable.h| 4
include/linux/iommu.h | 1 +
4 files changed, 31 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0f28a8614da3..7b05782738e2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+ if (smmu_domain->pgtbl_cfg.quirks)
+ pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1511,6 +1514,12 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
*domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage ==
ARM_SMMU_DOMAIN_NESTED);
return 0;
+ case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+ struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
+ *pgtbl_cfg = smmu_domain->pgtbl_cfg;
+
+ return 0;
+ }
default:
return -ENODEV;
}
@@ -1551,6 +1560,22 @@ static int arm_smmu_domain_set_attr(struct iommu_domain
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+ case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+ struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
+
+ if (smmu_domain->smmu) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ if (!pgtbl_cfg) {
+ ret = -ENODEV;
+ goto out_unlock;
+ }
+
+ smmu_domain->pgtbl_cfg = *pgtbl_cfg;
+ break;
+ }
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 04288b6fc619..18fbed376afb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -364,6 +364,7 @@ enum arm_smmu_domain_stage {
struct arm_smmu_domain {
struct arm_smmu_device *smmu;
struct io_pgtable_ops *pgtbl_ops;
+ struct domain_attr_io_pgtbl_cfg pgtbl_cfg;
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage stage;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a9a2c59fab37..686b37d48743 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -212,6 +212,10 @@ struct io_pgtable {
#define io_pgtable_ops_to_pgtable(x) container_of((x), struct io_pgtable, ops)
+struct domain_attr_io_pgtbl_cfg {
+ unsigned long quirks;
+};
+
static inline void io_pgtable_tlb_flush_all(struct io_pgtable *iop)
{
iop->cfg.tlb->tlb_flush_all(iop->cookie);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..ffaa389ea128 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+ DOMAIN_ATTR_IO_PGTABLE_CFG,
DOMAIN_ATTR_MAX,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] drm: rockchip: add sound support to rk3066 hdmi driver
From: Zheng Yang
Add sound support to the rk3066 HDMI driver.
The I2S input of the HDMI TX allows transmission of
DVD-Audio and decoded Dolby Digital
to A/V Receivers and high-end displays.
The interface supports 2 to 8 channels audio up to 192 kHz.
The HDMI TX supports variable word length of
16bits to 32bits for I2S audio inputs.(This driver 24bit max)
There are three I2S input modes supported.(This driver HDMI_I2S only)
On RK3066/PX2 the HDMI TX audio source is connected to I2S_8CH.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/Kconfig | 2 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 272 -
2 files changed, 273 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 310aa1546..4c20445dc 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -11,6 +11,8 @@ config DRM_ROCKCHIP
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
+ select SND_SOC_HDMI_CODEC if ROCKCHIP_RK3066_HDMI && SND_SOC
+ select SND_SOC_ROCKCHIP_I2S if ROCKCHIP_RK3066_HDMI && SND_SOC
help
Choose this option if you have a Rockchip soc chipset.
This driver provides kernel mode setting and buffer
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1c546c3a8..31568658f 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
#include "rk3066_hdmi.h"
#include "rockchip_drm_drv.h"
@@ -20,9 +22,16 @@
#define DEFAULT_PLLA_RATE 3000
+struct audio_info {
+ int sample_rate;
+ int channels;
+ int sample_width;
+};
+
struct hdmi_data_info {
int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
bool sink_is_hdmi;
+ bool sink_has_audio;
unsigned int enc_out_format;
unsigned int colorimetry;
};
@@ -54,12 +63,19 @@ struct rk3066_hdmi {
unsigned int tmdsclk;
+ struct platform_device *audio_pdev;
+ bool audio_enable;
+
struct hdmi_data_info hdmi_data;
+ struct audio_info audio;
struct drm_display_mode previous_mode;
};
#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+static int
+rk3066_hdmi_config_audio(struct rk3066_hdmi *hdmi, struct audio_info *audio);
+
static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
{
return readl_relaxed(hdmi->regs + offset);
@@ -205,6 +221,20 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi,
HDMI_INFOFRAME_AVI, 0, 0, 0);
}
+static int rk3066_hdmi_config_aai(struct rk3066_hdmi *hdmi,
+ struct audio_info *audio)
+{
+ struct hdmi_audio_infoframe *faudio;
+ union hdmi_infoframe frame;
+ int rc;
+
+ rc = hdmi_audio_infoframe_init(&frame.audio);
+ faudio = (struct hdmi_audio_infoframe *)&frame;
+
+ return rk3066_hdmi_upload_frame(hdmi, rc, &frame,
+ HDMI_INFOFRAME_AAI, 0, 0, 0);
+}
+
static int rk3066_hdmi_config_video_timing(struct rk3066_hdmi *hdmi,
struct drm_display_mode *mode)
{
@@ -353,6 +383,7 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK,
HDMI_VIDEO_MODE_HDMI);
rk3066_hdmi_config_avi(hdmi, mode);
+ rk3066_hdmi_config_audio(hdmi, &hdmi->audio);
} else {
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK, 0);
}
@@ -369,9 +400,20 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
*/
rk3066_hdmi_i2c_init(hdmi);
- /* Unmute video output. */
+ /* Unmute video and audio output. */
hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
HDMI_VIDEO_AUDIO_DISABLE_MASK, HDMI_AUDIO_DISABLE);
+ if (hdmi->audio_enable) {
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2, HDMI_AUDIO_DISABLE, 0);
+ /* Reset audio capture logic. */
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK,
+ HDMI_AUDIO_CP_LOGIC_RESET);
+ usleep_range(900, 1000);
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK, 0);
+ }
+
return 0;
}
@@ -473,9 +515,13 @@ static int rk3066_hdmi_connector_get_modes(struct
drm_connector *connector)
edid = drm_get_edid(connector, hdmi->ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
+ hdmi->hdmi_data.sink_has_audio = drm_detect_
[PATCH v2] drm/msm/dp: fix connect/disconnect handled at irq_hpd
Some usb type-c dongle use irq_hpd request to perform device connection
and disconnection. This patch add handling of both connection and
disconnection are based on the state of hpd_state and sink_count.
Changes in V2:
-- add dp_display_handle_port_ststus_changed()
-- fix kernel test robot complaint
Reported-by: kernel test robot
Fixes: 26b8d66a399e ("drm/msm/dp: promote irq_hpd handle to handle link
training correctly")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 91 ++---
1 file changed, 54 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e9cb878..1a438d9 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -279,13 +279,25 @@ static void dp_display_send_hpd_event(struct msm_dp
*dp_display)
drm_helper_hpd_irq_event(connector->dev);
}
-static int dp_display_send_hpd_notification(struct dp_display_private *dp,
- bool hpd)
+
+static void dp_display_set_encoder_mode(struct dp_display_private *dp)
{
- static bool encoder_mode_set;
struct msm_drm_private *priv = dp->dp_display.drm_dev->dev_private;
struct msm_kms *kms = priv->kms;
+ static bool encoder_mode_set;
+
+ if (!encoder_mode_set && dp->dp_display.encoder &&
+ kms->funcs->set_encoder_mode) {
+ kms->funcs->set_encoder_mode(kms,
+ dp->dp_display.encoder, false);
+
+ encoder_mode_set = true;
+ }
+}
+static int dp_display_send_hpd_notification(struct dp_display_private *dp,
+ bool hpd)
+{
if ((hpd && dp->dp_display.is_connected) ||
(!hpd && !dp->dp_display.is_connected)) {
DRM_DEBUG_DP("HPD already %s\n", (hpd ? "on" : "off"));
@@ -298,15 +310,6 @@ static int dp_display_send_hpd_notification(struct
dp_display_private *dp,
dp->dp_display.is_connected = hpd;
- if (dp->dp_display.is_connected && dp->dp_display.encoder
- && !encoder_mode_set
- && kms->funcs->set_encoder_mode) {
- kms->funcs->set_encoder_mode(kms,
- dp->dp_display.encoder, false);
- DRM_DEBUG_DP("set_encoder_mode() Completed\n");
- encoder_mode_set = true;
- }
-
dp_display_send_hpd_event(&dp->dp_display);
return 0;
@@ -342,7 +345,6 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
dp_add_event(dp, EV_USER_NOTIFICATION, true, 0);
-
end:
return rc;
}
@@ -359,6 +361,8 @@ static void dp_display_host_init(struct dp_display_private
*dp)
if (dp->usbpd->orientation == ORIENTATION_CC2)
flip = true;
+ dp_display_set_encoder_mode(dp);
+
dp_power_init(dp->power, flip);
dp_ctrl_host_init(dp->ctrl, flip);
dp_aux_init(dp->aux);
@@ -442,24 +446,42 @@ static void dp_display_handle_video_request(struct
dp_display_private *dp)
}
}
-static int dp_display_handle_irq_hpd(struct dp_display_private *dp)
+static int dp_display_handle_port_ststus_changed(struct dp_display_private *dp)
{
- u32 sink_request;
-
- sink_request = dp->link->sink_request;
+ int rc = 0;
- if (sink_request & DS_PORT_STATUS_CHANGED) {
- if (dp_display_is_sink_count_zero(dp)) {
- DRM_DEBUG_DP("sink count is zero, nothing to do\n");
- return -ENOTCONN;
+ if (dp_display_is_sink_count_zero(dp)) {
+ DRM_DEBUG_DP("sink count is zero, nothing to do\n");
+ if (dp->hpd_state != ST_DISCONNECTED) {
+ dp->hpd_state = ST_DISCONNECT_PENDING;
+ dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
+ }
+ } else {
+ if (dp->hpd_state == ST_DISCONNECTED) {
+ dp->hpd_state = ST_CONNECT_PENDING;
+ rc = dp_display_process_hpd_high(dp);
+ if (rc)
+ dp->hpd_state = ST_DISCONNECTED;
}
+ }
+
+ return rc;
+}
+
+static int dp_display_handle_irq_hpd(struct dp_display_private *dp)
+{
+ u32 sink_request = dp->link->sink_request;
- return dp_display_process_hpd_high(dp);
+ if (dp->hpd_state == ST_DISCONNECTED) {
+ if (sink_request & DP_LINK_STATUS_UPDATED) {
+ DRM_ERROR("Disconnected, no DP_LINK_STATUS_UPDATED\n");
+ return -EINVAL;
+ }
}
dp_ctrl_handle_sink_request(dp->ctrl);
- if (dp->link->sink_request & DP_TEST_LINK_VIDEO_PATTERN)
+ if (sink_request & DP_TEST_LINK_VIDEO_PATTERN)
dp_dis
[PATCH v4 2/7] clk: rockchip: fix i2s gate bits on rk3066 and rk3188
The Rockchip PX2/RK3066 uses these bits in CRU_CLKGATE7_CON:
hclk_i2s_8ch_gate_en bit 4 (dtsi: i2s0)
hclk_i2s0_2ch_gate_en bit 2 (dtsi: i2s1)
hclk_i2s1_2ch_gate_en bit 3 (dtsi: i2s2)
The Rockchip PX3/RK3188 uses this bit in CRU_CLKGATE7_CON:
hclk_i2s_2ch_gate_en bit 2 (dtsi: i2s0)
The bits got somehow mixed up in the clk-rk3188.c file.
The labels in the dtsi files are not suppose to change.
The sclk and hclk names should match for
"trace_event=clk_disable,clk_enable",
so remove GATE HCLK_I2S0 from the common clock tree and
fix the bits in the rk3066 and rk3188 clock tree.
Signed-off-by: Johan Jonker
---
drivers/clk/rockchip/clk-rk3188.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3188.c
b/drivers/clk/rockchip/clk-rk3188.c
index db8c58813..0b76ad34d 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -449,7 +449,6 @@ static struct rockchip_clk_branch common_clk_branches[]
__initdata = {
/* hclk_cpu gates */
GATE(HCLK_ROM, "hclk_rom", "hclk_cpu", 0, RK2928_CLKGATE_CON(5), 6,
GFLAGS),
- GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2,
GFLAGS),
GATE(HCLK_SPDIF, "hclk_spdif", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 1,
GFLAGS),
GATE(0, "hclk_cpubus", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 8, GFLAGS),
/* hclk_ahb2apb is part of a clk branch */
@@ -634,8 +633,9 @@ static struct rockchip_clk_branch rk3066a_clk_branches[]
__initdata = {
RK2928_CLKGATE_CON(0), 12, GFLAGS,
&rk3066a_i2s2_fracmux),
- GATE(HCLK_I2S1, "hclk_i2s1", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 3,
GFLAGS),
- GATE(HCLK_I2S2, "hclk_i2s2", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 4,
GFLAGS),
+ GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 4,
GFLAGS),
+ GATE(HCLK_I2S1, "hclk_i2s1", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2,
GFLAGS),
+ GATE(HCLK_I2S2, "hclk_i2s2", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 3,
GFLAGS),
GATE(HCLK_CIF1, "hclk_cif1", "hclk_cpu", 0, RK2928_CLKGATE_CON(6), 6,
GFLAGS),
GATE(HCLK_HDMI, "hclk_hdmi", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 14,
GFLAGS),
@@ -728,6 +728,7 @@ static struct rockchip_clk_branch rk3188_clk_branches[]
__initdata = {
RK2928_CLKGATE_CON(0), 10, GFLAGS,
&rk3188_i2s0_fracmux),
+ GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2,
GFLAGS),
GATE(0, "hclk_imem0", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 14, GFLAGS),
GATE(0, "hclk_imem1", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 15, GFLAGS),
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Fri, 6 Nov 2020 at 12:46, Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > > dependencies that need to be picked back to v5.4 product kernel), and
> > > > due to some other things I'm in middle of debugging I didn't have time
> > > > yet to switch to v5.10-rc or look at what else needs to
> > > > cherry-picked..
> > > >
> > > > If you could, pushing a branch with this patch somewhere would be a
> > > > bit easier to work with (ie. fetch && cherry-pick is easier to deal
> > > > with than picking things from list)
> > >
> > > It has been in linux-next for a few days. Here is the HEAD to pick
> > > from. There are few patches there since rc1.
> > >
> > > commit 203e29749cc0 ("opp: Allocate the OPP table outside of
> > > opp_table_lock")
> > >
> >
> > sorry for the delay, with that cherry-picked, I'm getting a whole lot of:
>
> Ahh, sorry about that and thanks for reporting it. Here is the fix:
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index c718092757d9..6b7f0066942d 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -112,8 +112,6 @@ static struct opp_table *_find_table_of_opp_np(struct
> device_node *opp_np)
> struct opp_table *opp_table;
> struct device_node *opp_table_np;
>
> - lockdep_assert_held(&opp_table_lock);
> -
> opp_table_np = of_get_parent(opp_np);
> if (!opp_table_np)
> goto err;
> @@ -121,12 +119,15 @@ static struct opp_table *_find_table_of_opp_np(struct
> device_node *opp_np)
> /* It is safe to put the node now as all we need now is its address */
> of_node_put(opp_table_np);
>
> + mutex_lock(&opp_table_lock);
> list_for_each_entry(opp_table, &opp_tables, node) {
> if (opp_table_np == opp_table->np) {
> _get_opp_table_kref(opp_table);
> + mutex_unlock(&opp_table_lock);
> return opp_table;
> }
> }
> + mutex_unlock(&opp_table_lock);
>
> err:
> return ERR_PTR(-ENODEV);
Ping.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 4/8] drm/msm: rearrange the gpu_rmw() function
From: Sharat Masetty
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/msm_drv.c | 8
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_gpu.h | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..a1e22b974b77 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -180,6 +180,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+ u32 val = msm_readl(addr);
+
+ val &= ~mask;
+ msm_writel(val | or, addr);
+}
+
struct msm_vblank_work {
struct work_struct work;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..655b3b0424a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -478,6 +478,7 @@ void __iomem *msm_ioremap_quiet(struct platform_device
*pdev, const char *name,
const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
struct msm_gpu_submitqueue;
int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fdc1a76..b2b419277953 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -246,10 +246,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
{
- uint32_t val = gpu_read(gpu, reg);
-
- val &= ~mask;
- gpu_write(gpu, reg, val | or);
+ msm_rmw(gpu->mmio + (reg << 2), mask, or);
}
static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
Hi
Am 17.11.20 um 22:40 schrieb Daniel Vetter:
> It's probably full of bugs ready for exploiting by userspace. And
> there's not going to be any userspace for this without any of the drm
> legacy drivers enabled too. So just couple it together.
>
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Adam Jackson
> ---
> drivers/char/agp/Makefile | 6 +-
> drivers/char/agp/agp.h| 5 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
> index cb2497d157f6..90ed8c789e48 100644
> --- a/drivers/char/agp/Makefile
> +++ b/drivers/char/agp/Makefile
> @@ -1,7 +1,11 @@
> # SPDX-License-Identifier: GPL-2.0
> -agpgart-y := backend.o frontend.o generic.o isoch.o
> +agpgart-y := backend.o generic.o isoch.o
>
> +ifeq ($(CONFIG_DRM_LEGACY),y)
> agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
> +agpgart-y+= frontend.o
> +endif
> +
>
> obj-$(CONFIG_AGP)+= agpgart.o
> obj-$(CONFIG_AGP_ALI)+= ali-agp.o
> diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
> index 4eb1c772ded7..bb09d64cd51e 100644
> --- a/drivers/char/agp/agp.h
> +++ b/drivers/char/agp/agp.h
> @@ -186,8 +186,13 @@ int agp_add_bridge(struct agp_bridge_data *bridge);
> void agp_remove_bridge(struct agp_bridge_data *bridge);
>
> /* Frontend routines. */
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
> int agp_frontend_initialize(void);
> void agp_frontend_cleanup(void);
> +#else
> +static inline int agp_frontend_initialize(void) { return 0; }
> +static inline void agp_frontend_cleanup(void) {}
> +#endif
There's one non-legacy driver that uses these agp structures, which is
radeon. Does this change affect radeon?
Best regards
Thomas
>
> /* Generic routines. */
> void agp_generic_enable(struct agp_bridge_data *bridge, u32 mode);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/7] ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property,
so add them to the 'hdmi' node for 'rk3066a.dtsi'.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..67fcb0dc9 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -124,6 +124,7 @@
pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
status = "disabled";
ports {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 17-11-20, 09:02, Rob Clark wrote:
> With that on top of the previous patch,
Don't you still have this ? Which fixed the lockdep in the remove path.
https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
To make it clear you need these patches to fix the OPP stuff:
//From 5.10-rc3 (the one from the above link).
commit e0df59de670b ("opp: Reduce the size of critical section in
_opp_table_kref_release()")
//Below two from linux-next
commit ef43f01ac069 ("opp: Always add entries in dev_list with opp_table->lock
held")
commit 27c09484dd3d ("opp: Allocate the OPP table outside of opp_table_lock")
This matches the diff I gave you earlier.
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 07/17] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
On 17-11-20, 17:17, Dmitry Osipenko wrote:
> 17.11.2020 13:07, Viresh Kumar пишет:
> > On 16-11-20, 00:29, Dmitry Osipenko wrote:
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from device-tree. This
> >> change breaks compatibility with older device-trees in order to bring
> >> support for the interconnect framework to the driver. This is a mandatory
> >> change which needs to be done in order to implement interconnect-based
> >> memory DVFS. Users of legacy device-trees will get a message telling that
> >> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> >> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
> >>
> >> Tested-by: Peter Geis
> >> Tested-by: Nicolas Chauvet
> >> Acked-by: Chanwoo Choi
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/devfreq/tegra30-devfreq.c | 86 ---
> >> 1 file changed, 44 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/drivers/devfreq/tegra30-devfreq.c
> >> b/drivers/devfreq/tegra30-devfreq.c
> >> index 38cc0d014738..ed6d4469c8c7 100644
> >> --- a/drivers/devfreq/tegra30-devfreq.c
> >> +++ b/drivers/devfreq/tegra30-devfreq.c
> >> @@ -19,6 +19,8 @@
> >> #include
> >> #include
> >>
> >> +#include
> >> +
> >> #include "governor.h"
> >>
> >> #define ACTMON_GLB_STATUS 0x0
> >> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
> >>
> >> struct tegra_devfreq {
> >>struct devfreq *devfreq;
> >> + struct opp_table*opp_table;
> >>
> >>struct reset_control*reset;
> >>struct clk *clock;
> >> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> >> *tegra)
> >> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> >>u32 flags)
> >> {
> >> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> >> - struct devfreq *devfreq = tegra->devfreq;
> >>struct dev_pm_opp *opp;
> >> - unsigned long rate;
> >> - int err;
> >> + int ret;
> >>
> >>opp = devfreq_recommended_opp(dev, freq, flags);
> >>if (IS_ERR(opp)) {
> >>dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> >>return PTR_ERR(opp);
> >>}
> >> - rate = dev_pm_opp_get_freq(opp);
> >> - dev_pm_opp_put(opp);
> >> -
> >> - err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
> >> - if (err)
> >> - return err;
> >> -
> >> - err = clk_set_rate(tegra->emc_clock, 0);
> >> - if (err)
> >> - goto restore_min_rate;
> >>
> >> - return 0;
> >> -
> >> -restore_min_rate:
> >> - clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
> >> + ret = dev_pm_opp_set_bw(dev, opp);
> >> + dev_pm_opp_put(opp);
> >>
> >> - return err;
> >> + return ret;
> >> }
> >>
> >> static int tegra_devfreq_get_dev_status(struct device *dev,
> >> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> >> *dev,
> >>stat->private_data = tegra;
> >>
> >>/* The below are to be used by the other governors */
> >> - stat->current_frequency = cur_freq;
> >> + stat->current_frequency = cur_freq * KHZ;
> >>
> >>actmon_dev = &tegra->devices[MCALL];
> >>
> >> @@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq
> >> *devfreq,
> >>target_freq = max(target_freq, dev->target_freq);
> >>}
> >>
> >> - *freq = target_freq;
> >> + /*
> >> + * tegra-devfreq driver operates with KHz units, while OPP table
> >> + * entries use Hz units. Hence we need to convert the units for the
> >> + * devfreq core.
> >> + */
> >> + *freq = target_freq * KHZ;
> >>
> >>return 0;
> >> }
> >> @@ -774,6 +767,7 @@ static struct devfreq_governor tegra_devfreq_governor
> >> = {
> >>
> >> static int tegra_devfreq_probe(struct platform_device *pdev)
> >> {
> >> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> >>struct tegra_devfreq_device *dev;
> >>struct tegra_devfreq *tegra;
> >>struct devfreq *devfreq;
> >> @@ -781,6 +775,13 @@ static int tegra_devfreq_probe(struct platform_device
> >> *pdev)
> >>long rate;
> >>int err;
> >>
> >> + /* legacy device-trees don't have OPP table and must be updated */
> >> + if (!device_property_present(&pdev->dev, "operating-points-v2")) {
> >> + dev_err(&pdev->dev,
> >> + "OPP table not found, please update your device
> >> tree\n");
> >> + return -ENODEV;
> >> + }
> >> +
> >
> > You forgot to remove this ?
>
> Yes, good catch. I'm planning to replace this code with a common helper
> sometime soon, so if there won't be another reasons to make a new
> revision, then I'd prefer to keep it as-is for now.
You should just replace this patch only with a version of V9.1 and you
aren't really required to resend the whole series. And you should fix
it before it gets merged. This isn't
Re: [PATCH] drm/docs: Fix todo.rst
On Wednesday, November 18, 2020 8:36 AM, Daniel Vetter
wrote:
> I didnt' format the thing correctly :-(
>
> Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
> Reported-by: Stephen Rothwell s...@canb.auug.org.au
> Cc: Stephen Rothwell s...@canb.auug.org.au
> Signed-off-by: Daniel Vetter daniel.vet...@intel.com
Reviewed-by: Simon Ser
Note that a blank line is required before the first item and after the
last, but is optional between items.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Move fbdev setup to before output polling
Hi Am 17.11.20 um 16:52 schrieb Mark Jonas: > From: Leo Ruan > > The generic fbdev has to be setup before enabling output polling. > Otherwise the fbdev client is not ready to handle delayed events. > > Since f53705fd, the generic fbdev is setup after the output polling > init. During fbdev setup, when fbdev probes attached outputs and a > status changes from unknown to connected, the delayed event is > marked and the output_poll_work thread is scheduled without delay. > If output_poll_execute() is runs immediately, the delayed event > is handled without actually polling the output because the fbdev is not > registered yet. So the delayed event is lost. This leads to a dark > screen until a KMS application (or fbcon) sets the screen mode. > > This patch fixes the issue by moving the setup of generic fbdev before > initializing and enabling output polling. > > Signed-off-by: Leo Ruan > Signed-off-by: Mark Jonas > --- > drivers/gpu/drm/imx/imx-drm-core.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 9bf5ad6d18a2..2665040e11c7 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) > legacyfb_depth = 16; > } > > + /* > + * The generic fbdev has to be setup before enabling output polling. > + * Otherwise the fbdev client is not ready to handle delayed events. > + */ > + drm_fbdev_generic_setup(drm, legacyfb_depth); > + > drm_kms_helper_poll_init(drm); > > ret = drm_dev_register(drm, 0); > if (ret) > goto err_poll_fini; > > - drm_fbdev_generic_setup(drm, legacyfb_depth); > - This does not work well. fbdev is supposed to be another regular DRM client. It has to be enabled after registering the DRM device. I'd rather improve fbdev or the driver to handle this gracefully. Best regards Thomas > return 0; > > err_poll_fini: > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu/amdgpu_ids: fix kmalloc_array not uses number as first arg
Am 18.11.20 um 03:42 schrieb Bernard Zhao: Fix check_patch.pl warning: kmalloc_array uses number as first arg, sizeof is generally wrong. +fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); Signed-off-by: Bernard Zhao Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index 6e9a9e5dbea0..f2bd4b0e06f6 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(id_mgr->num_ids, sizeof(void *), GFP_KERNEL); if (!fences) return -ENOMEM; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amd/amdgpu: use kmalloc_array to replace kmalloc with multiply
Am 18.11.20 um 03:55 schrieb Bernard Zhao:
Fix check_patch.pl warning:
WARNING: Prefer kmalloc_array over kmalloc with multiply
+bps = kmalloc(align_space * sizeof((*data)->bps), GFP_KERNEL);
WARNING: Prefer kmalloc_array over kmalloc with multiply
+bps_bo = kmalloc(align_space * sizeof((*data)->bps_bo),
GFP_KERNEL);
kmalloc_array has multiply overflow check, which will be safer.
Signed-off-by: Bernard Zhao
Not userspace controllable values, but looks cleaner anyway.
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index d0aea5e39531..f2a0851c804f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -280,8 +280,8 @@ static int amdgpu_virt_init_ras_err_handler_data(struct
amdgpu_device *adev)
if (!*data)
return -ENOMEM;
- bps = kmalloc(align_space * sizeof((*data)->bps), GFP_KERNEL);
- bps_bo = kmalloc(align_space * sizeof((*data)->bps_bo), GFP_KERNEL);
+ bps = kmalloc_array(align_space, sizeof((*data)->bps), GFP_KERNEL);
+ bps_bo = kmalloc_array(align_space, sizeof((*data)->bps_bo),
GFP_KERNEL);
if (!bps || !bps_bo) {
kfree(bps);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amd/amdgpu: optimise CONFIG_X||CONFIG_X_MODULE to IS_ENABLED(X)
Am 18.11.20 um 04:43 schrieb Bernard Zhao:
Optimise CONFIG_ || CONFIG__MODULE to IS_ENABLED().
This change also fix check_patch.pl warning:
WARNING: Prefer IS_ENABLED() to CONFIG_ ||
CONFIG__MODULE
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined
(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
Signed-off-by: Bernard Zhao
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 165b02e267b0..f1980cd1f402 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -64,7 +64,7 @@ struct amdgpu_atif {
struct amdgpu_atif_notifications notifications;
struct amdgpu_atif_functions functions;
struct amdgpu_atif_notification_cfg notification_cfg;
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *bd;
#endif
struct amdgpu_dm_backlight_caps backlight_caps;
@@ -447,7 +447,7 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
if (req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) {
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
if (atif->bd) {
DRM_DEBUG_DRIVER("Changing brightness to %d\n",
req.backlight_level);
@@ -806,7 +806,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
}
adev->atif = atif;
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
if (atif->notifications.brightness_change) {
if (amdgpu_device_has_dc_support(adev)) {
#if defined(CONFIG_DRM_AMD_DC)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
Am 18.11.20 um 09:02 schrieb Thomas Zimmermann:
Hi
Am 17.11.20 um 22:40 schrieb Daniel Vetter:
It's probably full of bugs ready for exploiting by userspace. And
there's not going to be any userspace for this without any of the drm
legacy drivers enabled too. So just couple it together.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Adam Jackson
---
drivers/char/agp/Makefile | 6 +-
drivers/char/agp/agp.h| 5 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
index cb2497d157f6..90ed8c789e48 100644
--- a/drivers/char/agp/Makefile
+++ b/drivers/char/agp/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
-agpgart-y := backend.o frontend.o generic.o isoch.o
+agpgart-y := backend.o generic.o isoch.o
+ifeq ($(CONFIG_DRM_LEGACY),y)
agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
+agpgart-y += frontend.o
+endif
+
obj-$(CONFIG_AGP) += agpgart.o
obj-$(CONFIG_AGP_ALI) += ali-agp.o
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 4eb1c772ded7..bb09d64cd51e 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -186,8 +186,13 @@ int agp_add_bridge(struct agp_bridge_data *bridge);
void agp_remove_bridge(struct agp_bridge_data *bridge);
/* Frontend routines. */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
int agp_frontend_initialize(void);
void agp_frontend_cleanup(void);
+#else
+static inline int agp_frontend_initialize(void) { return 0; }
+static inline void agp_frontend_cleanup(void) {}
+#endif
There's one non-legacy driver that uses these agp structures, which is
radeon. Does this change affect radeon?
Nouveau uses AGP as well, but I'm not sure if both drivers use any of
this stuff.
Regards,
Christian.
Best regards
Thomas
/* Generic routines. */
void agp_generic_enable(struct agp_bridge_data *bridge, u32 mode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
This adds new panel type to the mantix driver as found on the Librem 5 and fixes a glitch in the init sequence (affecting both panels). The fix is at the start of the series to make backporting simpler. It also adds a patch to make st7703 use dev_err_probe(). changes from v1 - as per review comments by Linus Walleij - fix alphabetical ordering in Documentation/devicetree/bindings/vendor-prefixes.yaml https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ - add reviewed by to all except 5/6, thanks Guido Günther (6): drm/panel: st7703: Use dev_err_probe drm/panel: mantix: Tweak init sequence drm/panel: mantix: Allow to specify default mode for different panels drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co dt-bindings: vendor-prefixes: Add ys vendor prefix dt-binding: display: mantix: Add compatible for panel from YS .../display/panel/mantix,mlaf057we51-x.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 +++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/panel: mantix: Allow to specify default mode for different panels
This can be used to use different modes for differnt panels via OF
device match.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 624d17b96a69..b057857165b0 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,8 @@ struct mantix {
struct regulator *avdd;
struct regulator *avee;
struct regulator *vddi;
+
+ const struct drm_display_mode *default_mode;
};
static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
@@ -187,7 +190,7 @@ static int mantix_prepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode default_mode_mantix = {
.hdisplay= 720,
.hsync_start = 720 + 45,
.hsync_end = 720 + 45 + 14,
@@ -208,11 +211,11 @@ static int mantix_get_modes(struct drm_panel *panel,
struct mantix *ctx = panel_to_mantix(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, &default_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->default_mode);
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(&default_mode));
+ ctx->default_mode->hdisplay,
ctx->default_mode->vdisplay,
+ drm_mode_vrefresh(ctx->default_mode));
return -ENOMEM;
}
@@ -243,6 +246,7 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+ ctx->default_mode = of_device_get_match_data(dev);
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
@@ -293,8 +297,8 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
}
dev_info(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
-default_mode.hdisplay, default_mode.vdisplay,
-drm_mode_vrefresh(&default_mode),
+ctx->default_mode->hdisplay, ctx->default_mode->vdisplay,
+drm_mode_vrefresh(ctx->default_mode),
mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
return 0;
@@ -321,7 +325,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id mantix_of_match[] = {
- { .compatible = "mantix,mlaf057we51-x" },
+ { .compatible = "mantix,mlaf057we51-x", .data = &default_mode_mantix },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co
The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index b057857165b0..30f28ad4df6b 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -205,6 +205,21 @@ static const struct drm_display_mode default_mode_mantix =
{
.height_mm = 130,
};
+static const struct drm_display_mode default_mode_ys = {
+ .hdisplay= 720,
+ .hsync_start = 720 + 45,
+ .hsync_end = 720 + 45 + 14,
+ .htotal = 720 + 45 + 14 + 25,
+ .vdisplay= 1440,
+ .vsync_start = 1440 + 175,
+ .vsync_end = 1440 + 175 + 8,
+ .vtotal = 1440 + 175 + 8 + 50,
+ .clock = 85298,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .width_mm= 65,
+ .height_mm = 130,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -326,6 +341,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
static const struct of_device_id mantix_of_match[] = {
{ .compatible = "mantix,mlaf057we51-x", .data = &default_mode_mantix },
+ { .compatible = "ys,ys57pss36bh5gq", .data = &default_mode_ys },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/panel: st7703: Use dev_err_probe
Less code and easier probe deferral debugging.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b30510b1696a..a2c303e5732c 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -530,10 +530,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset gpio\n");
- return PTR_ERR(ctx->reset_gpio);
- }
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "Failed to
get reset gpio\n");
mipi_dsi_set_drvdata(dsi, ctx);
@@ -545,19 +543,13 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
dsi->lanes = ctx->desc->lanes;
ctx->vcc = devm_regulator_get(dev, "vcc");
- if (IS_ERR(ctx->vcc)) {
- ret = PTR_ERR(ctx->vcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request vcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->vcc), "Failed to request
vcc regulator\n");
+
ctx->iovcc = devm_regulator_get(dev, "iovcc");
- if (IS_ERR(ctx->iovcc)) {
- ret = PTR_ERR(ctx->iovcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request iovcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
+"Failed to request iovcc regulator\n");
drm_panel_init(&ctx->panel, dev, &st7703_drm_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/panel: mantix: Tweak init sequence
We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X
DSI panel")
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 0c5f22e95c2d..624d17b96a69 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -22,6 +22,7 @@
/* Manufacturer specific Commands send via DSI */
#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
#define MANTIX_CMD_INT_CANCEL 0x4C
+#define MANTIX_CMD_SPI_FINISH 0x90
struct mantix {
struct device *dev;
@@ -66,6 +67,10 @@ static int mantix_init_sequence(struct mantix *ctx)
dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
msleep(20);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00, 0x2F);
+ msleep(20);
+
dev_dbg(dev, "Panel init sequence done\n");
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] dt-binding: display: mantix: Add compatible for panel from YS
This panel from Shenzhen Yashi Changhua Intelligent Technology Co uses the same driver IC but a different LCD. Signed-off-by: Guido Günther Reviewed-by: Linus Walleij --- .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 51f423297ec8..9e78f2e60f99 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - mantix,mlaf057we51-x + - ys,ys57pss36bh5gq port: true reg: -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index e40ee369f808..fbcba08450c5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1222,6 +1222,8 @@ patternProperties: description: YSH & ATIL "^yones-toptech,.*": description: Yones Toptech Co., Ltd. + "^ys,.*": +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^ysoft,.*": description: Y Soft Corporation a.s. "^zealz,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Hi, On Tue, Nov 17, 2020 at 09:42:33PM +0100, Linus Walleij wrote: > On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote: > > > Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. > > > > Signed-off-by: Guido Günther > > --- > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > index e40ee369f808..d0f3abf2f12c 100644 > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > @@ -1220,6 +1220,8 @@ patternProperties: > > description: Shenzhen Yangliming Electronic Technology Co., Ltd. > >"^yna,.*": > > description: YSH & ATIL > > + "^ys,.*": > > +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. > >"^yones-toptech,.*": > > description: Yones Toptech Co., Ltd. > >"^ysoft,.*": > > I think this should be in alphabetical order of the compatible string, i.e. > under yones. Messed that up during rebase. Fixed in v2. Thanks for the review! -- Guido > > Yours, > Linus Walleij > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 42/42] include/drm/drm_atomic: Make use of 'new_crtc_state'
On Tue, 17 Nov 2020, Daniel Vetter wrote: > On Mon, Nov 16, 2020 at 05:41:12PM +, Lee Jones wrote: > > In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided > > as a container for state->crtcs[i].new_state, but is not utilised in > > some use-cases, so we fake-use it instead. > > > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/imx/ipuv3-plane.c: In function ‘ipu_planes_assign_pre’: > > drivers/gpu/drm/imx/ipuv3-plane.c:746:42: warning: variable ‘crtc_state’ > > set but not used [-Wunused-but-set-variable] > > > > Cc: Philipp Zabel > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Shawn Guo > > Cc: Sascha Hauer > > Cc: Pengutronix Kernel Team > > Cc: Fabio Estevam > > Cc: NXP Linux Team > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Ok I merged them all except: > - drm/amd and drm/imx, should be picked up already by respective > maintainers > - drm/msm, Rob promised to take care > > Thanks a lot for your patches. Perfect. Thank you for reviewing/merging them. > > --- > > include/drm/drm_atomic.h | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > > index dc5e0fbecc04e..54e051a957dfc 100644 > > --- a/include/drm/drm_atomic.h > > +++ b/include/drm/drm_atomic.h > > @@ -783,7 +783,8 @@ void drm_state_dump(struct drm_device *dev, struct > > drm_printer *p); > > (void)(crtc) /* Only to avoid > > unused-but-set-variable warning */, \ > > (old_crtc_state) = > > (__state)->crtcs[__i].old_state, \ > > (void)(old_crtc_state) /* Only to avoid > > unused-but-set-variable warning */, \ > > -(new_crtc_state) = > > (__state)->crtcs[__i].new_state, 1)) > > +(new_crtc_state) = > > (__state)->crtcs[__i].new_state, \ > > +(void)(new_crtc_state) /* Only to avoid > > unused-but-set-variable warning */, 1)) > > > > /** > > * for_each_old_crtc_in_state - iterate over all CRTCs in an atomic update > -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
On Wed, Nov 18, 2020 at 9:24 AM Christian König
wrote:
>
> Am 18.11.20 um 09:02 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 17.11.20 um 22:40 schrieb Daniel Vetter:
> >> It's probably full of bugs ready for exploiting by userspace. And
> >> there's not going to be any userspace for this without any of the drm
> >> legacy drivers enabled too. So just couple it together.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: David Airlie
> >> Cc: Adam Jackson
> >> ---
> >> drivers/char/agp/Makefile | 6 +-
> >> drivers/char/agp/agp.h| 5 +
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
> >> index cb2497d157f6..90ed8c789e48 100644
> >> --- a/drivers/char/agp/Makefile
> >> +++ b/drivers/char/agp/Makefile
> >> @@ -1,7 +1,11 @@
> >> # SPDX-License-Identifier: GPL-2.0
> >> -agpgart-y := backend.o frontend.o generic.o isoch.o
> >> +agpgart-y := backend.o generic.o isoch.o
> >>
> >> +ifeq ($(CONFIG_DRM_LEGACY),y)
> >> agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
> >> +agpgart-y += frontend.o
> >> +endif
> >> +
> >>
> >> obj-$(CONFIG_AGP) += agpgart.o
> >> obj-$(CONFIG_AGP_ALI) += ali-agp.o
> >> diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
> >> index 4eb1c772ded7..bb09d64cd51e 100644
> >> --- a/drivers/char/agp/agp.h
> >> +++ b/drivers/char/agp/agp.h
> >> @@ -186,8 +186,13 @@ int agp_add_bridge(struct agp_bridge_data *bridge);
> >> void agp_remove_bridge(struct agp_bridge_data *bridge);
> >>
> >> /* Frontend routines. */
> >> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
> >> int agp_frontend_initialize(void);
> >> void agp_frontend_cleanup(void);
> >> +#else
> >> +static inline int agp_frontend_initialize(void) { return 0; }
> >> +static inline void agp_frontend_cleanup(void) {}
> >> +#endif
> > There's one non-legacy driver that uses these agp structures, which is
> > radeon. Does this change affect radeon?
>
> Nouveau uses AGP as well, but I'm not sure if both drivers use any of
> this stuff.
frontend = /dev/agp chardev interface for userspace drivers. If you're
looking at kernel drivers, you're looking at the wrong thing, the
kernel-internal interface is in char/agp/backend.c and still enabled.
So no impact at all on any kernel code.
Now the impact this does have on kms drivers using agp is that there's
no longer a userspace ioctl interface to change the agp setup and
mappings and fight the kms driver (which assumes it's fully in control
of agp configuration).
-Daniel
>
> Regards,
> Christian.
>
> >
> > Best regards
> > Thomas
> >
> >>
> >> /* Generic routines. */
> >> void agp_generic_enable(struct agp_bridge_data *bridge, u32 mode);
> >>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Move fbdev setup to before output polling
On Wed, Nov 18, 2020 at 9:10 AM Thomas Zimmermann wrote: > > Hi > > Am 17.11.20 um 16:52 schrieb Mark Jonas: > > From: Leo Ruan > > > > The generic fbdev has to be setup before enabling output polling. > > Otherwise the fbdev client is not ready to handle delayed events. > > > > Since f53705fd, the generic fbdev is setup after the output polling > > init. During fbdev setup, when fbdev probes attached outputs and a > > status changes from unknown to connected, the delayed event is > > marked and the output_poll_work thread is scheduled without delay. > > If output_poll_execute() is runs immediately, the delayed event > > is handled without actually polling the output because the fbdev is not > > registered yet. So the delayed event is lost. This leads to a dark > > screen until a KMS application (or fbcon) sets the screen mode. > > > > This patch fixes the issue by moving the setup of generic fbdev before > > initializing and enabling output polling. > > > > Signed-off-by: Leo Ruan > > Signed-off-by: Mark Jonas > > --- > > drivers/gpu/drm/imx/imx-drm-core.c | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index 9bf5ad6d18a2..2665040e11c7 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) > > legacyfb_depth = 16; > > } > > > > + /* > > + * The generic fbdev has to be setup before enabling output polling. > > + * Otherwise the fbdev client is not ready to handle delayed events. > > + */ > > + drm_fbdev_generic_setup(drm, legacyfb_depth); > > + > > drm_kms_helper_poll_init(drm); > > > > ret = drm_dev_register(drm, 0); > > if (ret) > > goto err_poll_fini; > > > > - drm_fbdev_generic_setup(drm, legacyfb_depth); > > - > > This does not work well. fbdev is supposed to be another regular DRM > client. It has to be enabled after registering the DRM device. > > I'd rather improve fbdev or the driver to handle this gracefully. Yeah I'm not understanding the point here. Once fbcon is running, you have a screen. Any fbdev userspace client also should do a modeset first. And if they dont and it's expected uapi for fbdev chardev that the display boots up enabled, then we need to fix that in the fbdev helpers, not through clever reordering in drivers so that a side-effect causes a modeset. Note that this is a bit tricky since fbdev shouldn't take over the screen by default, so we'd need to delay this until first open of /dev/fb0. And we should probably also delay the hotplug handling until the first open. fbcon also fake-opens the fbdev file, so it's the same code path. -Daniel > > Best regards > Thomas > > > return 0; > > > > err_poll_fini: > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
Hi
Am 18.11.20 um 09:53 schrieb Daniel Vetter:
On Wed, Nov 18, 2020 at 9:24 AM Christian König
wrote:
Am 18.11.20 um 09:02 schrieb Thomas Zimmermann:
Hi
Am 17.11.20 um 22:40 schrieb Daniel Vetter:
It's probably full of bugs ready for exploiting by userspace. And
there's not going to be any userspace for this without any of the drm
legacy drivers enabled too. So just couple it together.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Adam Jackson
---
drivers/char/agp/Makefile | 6 +-
drivers/char/agp/agp.h| 5 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
index cb2497d157f6..90ed8c789e48 100644
--- a/drivers/char/agp/Makefile
+++ b/drivers/char/agp/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
-agpgart-y := backend.o frontend.o generic.o isoch.o
+agpgart-y := backend.o generic.o isoch.o
+ifeq ($(CONFIG_DRM_LEGACY),y)
agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
+agpgart-y += frontend.o
+endif
+
obj-$(CONFIG_AGP) += agpgart.o
obj-$(CONFIG_AGP_ALI) += ali-agp.o
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 4eb1c772ded7..bb09d64cd51e 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -186,8 +186,13 @@ int agp_add_bridge(struct agp_bridge_data *bridge);
void agp_remove_bridge(struct agp_bridge_data *bridge);
/* Frontend routines. */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
int agp_frontend_initialize(void);
void agp_frontend_cleanup(void);
+#else
+static inline int agp_frontend_initialize(void) { return 0; }
+static inline void agp_frontend_cleanup(void) {}
+#endif
There's one non-legacy driver that uses these agp structures, which is
radeon. Does this change affect radeon?
Nouveau uses AGP as well, but I'm not sure if both drivers use any of
this stuff.
frontend = /dev/agp chardev interface for userspace drivers. If you're
looking at kernel drivers, you're looking at the wrong thing, the
kernel-internal interface is in char/agp/backend.c and still enabled.
So no impact at all on any kernel code.
Now the impact this does have on kms drivers using agp is that there's
no longer a userspace ioctl interface to change the agp setup and
mappings and fight the kms driver (which assumes it's fully in control
of agp configuration).
Thanks for clarifying. I'm certainly not qualified, but still
Acked-by: Thomas Zimmermann
Best regards
Thomas
-Daniel
Regards,
Christian.
Best regards
Thomas
/* Generic routines. */
void agp_generic_enable(struct agp_bridge_data *bridge, u32 mode);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Move fbdev setup to before output polling
Hi Am 18.11.20 um 09:59 schrieb Daniel Vetter: On Wed, Nov 18, 2020 at 9:10 AM Thomas Zimmermann wrote: Hi Am 17.11.20 um 16:52 schrieb Mark Jonas: From: Leo Ruan The generic fbdev has to be setup before enabling output polling. Otherwise the fbdev client is not ready to handle delayed events. Since f53705fd, the generic fbdev is setup after the output polling init. During fbdev setup, when fbdev probes attached outputs and a status changes from unknown to connected, the delayed event is marked and the output_poll_work thread is scheduled without delay. If output_poll_execute() is runs immediately, the delayed event is handled without actually polling the output because the fbdev is not registered yet. So the delayed event is lost. This leads to a dark screen until a KMS application (or fbcon) sets the screen mode. This patch fixes the issue by moving the setup of generic fbdev before initializing and enabling output polling. Signed-off-by: Leo Ruan Signed-off-by: Mark Jonas --- drivers/gpu/drm/imx/imx-drm-core.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index 9bf5ad6d18a2..2665040e11c7 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) legacyfb_depth = 16; } + /* + * The generic fbdev has to be setup before enabling output polling. + * Otherwise the fbdev client is not ready to handle delayed events. + */ + drm_fbdev_generic_setup(drm, legacyfb_depth); + drm_kms_helper_poll_init(drm); ret = drm_dev_register(drm, 0); if (ret) goto err_poll_fini; - drm_fbdev_generic_setup(drm, legacyfb_depth); - This does not work well. fbdev is supposed to be another regular DRM client. It has to be enabled after registering the DRM device. I'd rather improve fbdev or the driver to handle this gracefully. Yeah I'm not understanding the point here. Once fbcon is running, you have a screen. Any fbdev userspace client also should do a modeset first. And if they dont and it's expected uapi for fbdev chardev that the display boots up enabled, then we need to fix that in the fbdev helpers, not through clever reordering in drivers so that a side-effect causes a modeset. Note that this is a bit tricky since fbdev shouldn't take over the screen by default, so we'd need to delay this until first open of /dev/fb0. And we should probably also delay the hotplug handling until the first open. fbcon also fake-opens the fbdev file, so it's the same code path. As far as I understand the commit message, the problem is that the display blanks out after registering the driver. And fbdev somewhat mitigates this by doing an early modeset. Users with fbdev disabled (most of them in embedded, I guess) would still run into the issue until userspace makes a modeset. Mark, if that's the case, an option might be to pick up the device settings instead of calling drm_mode_config_reset(). The driver would then continue to display whatever is on the screen. Best regards Thomas -Daniel Best regards Thomas return 0; err_poll_fini: -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
Hi Daniel,
Replying "early" (see below), as this was applied to
drm-misc/for-linux-next.
On Sat, Oct 31, 2020 at 3:17 PM Daniel Vetter wrote:
> On Sat, Oct 31, 2020 at 11:28 AM Geert Uytterhoeven
> wrote:
> > On Thu, 29 Oct 2020, Daniel Vetter wrote:
> > > So ever since syzbot discovered fbcon, we have solid proof that it's
> > > full of bugs. And often the solution is to just delete code and remove
> > > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> > >
> > > Now the problem is that most modern-ish drivers really only treat
> > > fbcon as an dumb kernel console until userspace takes over, and Oops
> > > printer for some emergencies. Looking at drm drivers and the basic
> > > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > > acceleration:
> > >
> > > - nouveau, seems to be enabled by default
> > > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > > y/xpanning
> > > - gma500, but that is getting deleted now for the GTT remapper trick,
> > > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > > flag, so unused (and could be deleted already I think).
> > >
> > > No other driver supportes accelerated fbcon. And fbcon is the only
> > > user of this accel code (it's not exposed as uapi through ioctls),
> > > which means we could garbage collect fairly enormous amounts of code
> > > if we kill this.
> >
> > "git grep FBINFO_HWACCEL_COPYAREA" shows me there are 32 more drivers
> > using acceleration under drivers/video/fbdev/.
> >
> > > Plus because syzbot only runs on virtual hardware, and none of the
> > > drivers for that have acceleration, we'd remove a huge gap in testing.
> > > And there's no other even remotely comprehensive testing aside from
> > > syzbot.
> >
> > That sounds like a great argument to remove all hardware drivers from
> > the kernel ;-)
>
> fbdev is unmaintained, has no one volunteering to put in the work (and
> there's huge amounts of work needed), and there's no test suite. No,
> fbtest.c doesn't can't, that's not even close. We're not going to
> delete everything in the kernel, but slowly sunsetting stuff that's
> just costing and not bringing in up is a good idea.
The fbcon acceleration code is indeed not tested by fbset, and it is
purely in-kernel acceleration for the console.
> > Seriously, how hard can it be to add "software-accelerated" acceleration
> > hooks to drivers/video/fbdev/vfb.c, to enable syzbot to exercise the
> > core acceleration code paths?
>
> Just this one is 5 combinations, which means I'd need to convince
> syzbot to test 5 different machine setups.
Why 5 combinations?
Enable vfb (which can be a module) and be done with it?
> Plus we're still lacking a test suite, and judging from how much time
> it took to get something basic going for kms, that's about 2 engineer
> years of effort that no one is even close to willing to spend.
Sure, writing test suites is hard, and takes time.
> > > This patch here just disables the acceleration code by always
> > > redrawing when scrolling. The plan is that once this has been merged
> > > for well over a year in released kernels, we can start to go around
> > > and delete a lot of code.
> >
> > Have you benchmarked the performance impact on traditional fbdev
> > drivers?
>
> There's still some acceleration if you have an image blit engine for
> redrawing the screen. But the complexity is contained in the old
> drivers that no one cares about.
>
> For anything I have access to the difference is 0.
Sure, you're doing DRM drivers ;-)
> Reality is that fbdev is just there nowadays for Oops printing and
> emergency usage, and it's plenty good enough for that. If there's
That's true for systems that are supported by a DRM driver.
> anyone who cares beyond that, they're most definitely not able to put
> in time for upstream work.
There exist actual products using out-of-tree fbdev drivers that never
got the chance of being merged upstream due to the moratorium on new
fbdev drivers.
BTW, I'm trying to convert an old fbdev driver to DRM, but don't have it
working yet. I had hoped to get something working before replying to
this email, so I could provide more detailed feedback.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
On Wed, Nov 18, 2020 at 12:20:11AM +, Michael Kelley wrote:
> From: Dexuan Cui Sent: Tuesday, November 17, 2020 4:03
> PM
> >
> > x86 Hyper-V used to essentially always overwrite the effective cache type
> > of guest memory accesses to WB. This was problematic in cases where there
> > is a physical device assigned to the VM, since that often requires that
> > the VM should have control over cache types. Thus, on newer Hyper-V since
> > 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
> > users start to complain that Linux VM's VRAM becomes very slow, and it
> > turns out that Linux VM should not map the VRAM uncacheable by ioremap().
> > Fix this slowness issue by using ioremap_cache().
> >
> > On ARM64, ioremap_cache() is also required as the host also maps the VRAM
> > cacheable, otherwise VM Connect can't display properly with ioremap() or
> > ioremap_wc().
> >
> > With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
> > it's no longer necessary to use the hacks we added to mitigate the
> > slowness, i.e. we no longer need to allocate physical memory and use
> > it to back up the VRAM in Generation-1 VM, and we also no longer need to
> > allocate physical memory to back up the framebuffer in a Generation-2 VM
> > and copy the framebuffer to the real VRAM. A further big change will
> > address these for v5.11.
> >
> > Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame
> > Buffer Driver")
> > Tested-by: Boqun Feng
> > Signed-off-by: Dexuan Cui
> Reviewed-by: Michael Kelley
>
Applied to hyperv-fixes. Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Move fbdev setup to before output polling
On Wed, Nov 18, 2020 at 10:47 AM Jonas Mark (BT-FIR/ENG1-Grb) wrote: > > Hi Thomas and Daniel, > > Thank you very much for your feedback. We appreciate it. > > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c > > >>> index 9bf5ad6d18a2..2665040e11c7 100644 > > >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c > > >>> +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > >>> @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) > > >>>legacyfb_depth = 16; > > >>>} > > >>> > > >>> + /* > > >>> + * The generic fbdev has to be setup before enabling output > > >>> polling. > > >>> + * Otherwise the fbdev client is not ready to handle delayed > > >>> events. > > >>> + */ > > >>> + drm_fbdev_generic_setup(drm, legacyfb_depth); > > >>> + > > >>>drm_kms_helper_poll_init(drm); > > >>> > > >>>ret = drm_dev_register(drm, 0); > > >>>if (ret) > > >>>goto err_poll_fini; > > >>> > > >>> - drm_fbdev_generic_setup(drm, legacyfb_depth); > > >>> - > > >> > > >> This does not work well. fbdev is supposed to be another regular DRM > > >> client. It has to be enabled after registering the DRM device. > > >> > > >> I'd rather improve fbdev or the driver to handle this gracefully. > > > > > > Yeah I'm not understanding the point here. Once fbcon is running, you > > > have a screen. Any fbdev userspace client also should do a modeset > > > first. And if they dont and it's expected uapi for fbdev chardev that > > > the display boots up enabled, then we need to fix that in the fbdev > > > helpers, not through clever reordering in drivers so that a > > > side-effect causes a modeset. > > > > > > Note that this is a bit tricky since fbdev shouldn't take over the > > > screen by default, so we'd need to delay this until first open of > > > /dev/fb0. And we should probably also delay the hotplug handling until > > > the first open. fbcon also fake-opens the fbdev file, so it's the same > > > code path. > > > > As far as I understand the commit message, the problem is that the display > > blanks out after registering the driver. And fbdev somewhat mitigates this > > by > > doing an early modeset. Users with fbdev disabled (most of them in > > embedded, I guess) would still run into the issue until userspace makes a > > modeset. > > > > Mark, if that's the case, an option might be to pick up the device settings > > instead of calling drm_mode_config_reset(). The driver would then continue > > to display whatever is on the screen. > > We are started using fbdev in our embedded application with Linux 3.10, later > updated to 4.14 and are now in the process of updating to 5.4. So far the uapi > appeared to us as if we could rely on an already enabled fbdev. That is, none > of our applications does a modeset. > > When switching to 5.4 we noticed that the fbdev uapi changed. That is, the > LCD is switched off until it is explicitly enabled. It could be enabled by > writing to /sys/class/graphics/fb0/blank. > > You are right, we are not using fbcon. fbcon will still enable the LCD but in > our > embedded domain we have it disabled because we must not show a console. > > Do we understand your proposal correctly to replace the call to > drm_mode_config_reset() in imx_drm_bind() [imx-drm-core.c] with picking up > the device settings instead? > > https://elixir.bootlin.com/linux/v5.10-rc4/source/drivers/gpu/drm/imx/imx-drm-core.c#L231 > > We are a little clueless right now: How do we pick up the device settings? Nope, not what I had in mind. Instead intercept the fb_ops->open call and in there if it's a userspace open (user parameter of the callback tells you that) and kms is not in use, then try to light up the display for the fbdev userspace to use. drm fbdev helpers already have that callback as drm_fbdev_fb_open(). I think you could try and just call drm_fbdev_client_hotplug directly, that should do the trick. Or maybe calling drm_fb_helper_dpms is the better option, not sure. fbmem.c seems to not store any blanking state at all, so this is probably all ill-defined. Important part is to do this only for the user fb_open case, since fbcon will do its own thing too. Plus I guess we need to document that this is the uapi we're having for fbdev clients, so ideally this should be cc'ed widely so we can get some acks from former fbdev maintainers. Also ideally we'd have an igt for this uapi to make sure it never breaks again. Something like: 1. open the kms driver for this, make sure display is completely off. 2. close kms file 3. open fbdev file 4. check (through opening kms side again) that the display has been enabled. See https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#validating-changes-with-igt for some details on our validation testing, there's already a very basic fbdev testcase there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___
Re: [PATCH 04/40] drm/amd/amdgpu/amdgpu_drv: Move 'amdgpu_info_ioctl()'s prototype to shared header
On Fri, 13 Nov 2020, Alex Deucher wrote:
> On Fri, Nov 13, 2020 at 8:49 AM Lee Jones wrote:
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:486:5: warning: no previous
> > prototype for ‘amdgpu_info_ioctl’ [-Wmissing-prototypes]
> > 486 | int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct
> > drm_file *filp)
> > | ^
> >
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Lee Jones
>
> Luben already sent a patch to fix this one. I'll be picking up that one.
FYI: Looks like this is still broken in today's -next.
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h | 31 +
> > 3 files changed, 33 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 1dfea15bbec36..afd357df0f886 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -43,7 +43,7 @@
> > #include "amdgpu_sched.h"
> >
> > #include "amdgpu_amdkfd.h"
> > -
> > +#include "amdgpu_kms.h"
> > #include "amdgpu_ras.h"
> >
> > /*
> > @@ -1521,8 +1521,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct
> > amdgpu_fpriv **fpriv)
> > return 0;
> > }
> >
> > -int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
> > *filp);
> > -
> > const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
> > DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl,
> > DRM_AUTH|DRM_RENDER_ALLOW),
> > DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl,
> > DRM_AUTH|DRM_RENDER_ALLOW),
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index 98721ae931841..54c4ee6d230d8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -41,6 +41,7 @@
> > #include "amdgpu_amdkfd.h"
> > #include "amdgpu_gem.h"
> > #include "amdgpu_display.h"
> > +#include "amdgpu_kms.h"
> > #include "amdgpu_ras.h"
> >
> > void amdgpu_unregister_gpu_instance(struct amdgpu_device *adev)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> > new file mode 100644
> > index 0..f3111aef76cae
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> > @@ -0,0 +1,31 @@
> > +/* amdgpu_kms.h -- Private header for radeon driver -*- linux-c -*-
> > + *
> > + * Copyright 2008 Advanced Micro Devices, Inc.
> > + * Copyright 2008 Red Hat Inc.
> > + * Copyright 2009 Jerome Glisse.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef __AMDGPU_KMS_H__
> > +#define __AMDGPU_KMS_H__
> > +
> > +int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
> > *filp);
> > +
> > +#endif /* __AMDGPU_KMS_H__ */
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/docs: Fix todo.rst
On Wed, Nov 18, 2020 at 08:04:46AM +, Simon Ser wrote:
> On Wednesday, November 18, 2020 8:36 AM, Daniel Vetter
> wrote:
>
> > I didnt' format the thing correctly :-(
> >
> > Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
> > Reported-by: Stephen Rothwell s...@canb.auug.org.au
> > Cc: Stephen Rothwell s...@canb.auug.org.au
> > Signed-off-by: Daniel Vetter daniel.vet...@intel.com
>
> Reviewed-by: Simon Ser
>
> Note that a blank line is required before the first item and after the
> last, but is optional between items.
Thanks for reviewing, patch applied.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
Am 18.11.20 um 10:02 schrieb Thomas Zimmermann:
Hi
Am 18.11.20 um 09:53 schrieb Daniel Vetter:
On Wed, Nov 18, 2020 at 9:24 AM Christian König
wrote:
Am 18.11.20 um 09:02 schrieb Thomas Zimmermann:
Hi
Am 17.11.20 um 22:40 schrieb Daniel Vetter:
It's probably full of bugs ready for exploiting by userspace. And
there's not going to be any userspace for this without any of the drm
legacy drivers enabled too. So just couple it together.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Adam Jackson
---
drivers/char/agp/Makefile | 6 +-
drivers/char/agp/agp.h | 5 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
index cb2497d157f6..90ed8c789e48 100644
--- a/drivers/char/agp/Makefile
+++ b/drivers/char/agp/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
-agpgart-y := backend.o frontend.o generic.o isoch.o
+agpgart-y := backend.o generic.o isoch.o
+ifeq ($(CONFIG_DRM_LEGACY),y)
agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
+agpgart-y += frontend.o
+endif
+
obj-$(CONFIG_AGP) += agpgart.o
obj-$(CONFIG_AGP_ALI) += ali-agp.o
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 4eb1c772ded7..bb09d64cd51e 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -186,8 +186,13 @@ int agp_add_bridge(struct agp_bridge_data
*bridge);
void agp_remove_bridge(struct agp_bridge_data *bridge);
/* Frontend routines. */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
int agp_frontend_initialize(void);
void agp_frontend_cleanup(void);
+#else
+static inline int agp_frontend_initialize(void) { return 0; }
+static inline void agp_frontend_cleanup(void) {}
+#endif
There's one non-legacy driver that uses these agp structures, which is
radeon. Does this change affect radeon?
Nouveau uses AGP as well, but I'm not sure if both drivers use any of
this stuff.
frontend = /dev/agp chardev interface for userspace drivers. If you're
looking at kernel drivers, you're looking at the wrong thing, the
kernel-internal interface is in char/agp/backend.c and still enabled.
So no impact at all on any kernel code.
Now the impact this does have on kms drivers using agp is that there's
no longer a userspace ioctl interface to change the agp setup and
mappings and fight the kms driver (which assumes it's fully in control
of agp configuration).
I was strongly assuming something like this, thanks for clarifying.
Thanks for clarifying. I'm certainly not qualified, but still
Acked-by: Thomas Zimmermann
Acked-by: Christian König as well.
Regards,
Christian.
Best regards
Thomas
-Daniel
Regards,
Christian.
Best regards
Thomas
/* Generic routines. */
void agp_generic_enable(struct agp_bridge_data *bridge, u32 mode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: document drm_mode_get_connector
Document how to perform a forced probe, and when should user-space do it.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm_mode.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5ad10ab2a577..09647b799f39 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -368,6 +368,19 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+/**
+ * struct drm_mode_get_connector - get connector metadata
+ *
+ * If the @count_modes field is set to zero, the kernel will perform a forced
+ * probe on the connector to refresh the connector status, modes and EDID.
+ * A forced-probe can be slow and the ioctl will block.
+ *
+ * User-space shouldn't need to force-probe connectors in general: the kernel
+ * will automatically take care of probing connectors that don't support
+ * hot-plug detection when appropriate. However, user-space may force-probe
+ * connectors on user request (e.g. clicking a "Scan connectors" button, or
+ * opening a UI to manage screens).
+ */
struct drm_mode_get_connector {
__u64 encoders_ptr;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] mm: mmap: fix fput in error path v2
Am 06.11.20 um 23:48 schrieb Andrew Morton: On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König" wrote: Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." adds a workaround for a bug in mmap_region. As the comment states ->mmap() callback can change vma->vm_file and so we might call fput() on the wrong file. Revert the workaround and proper fix this in mmap_region. Seems correct, best I can tell. Presumably all ->mmap() instances will correctly fput() to original file* if they're rewriting vma->vm_file. Yes, exactly. Patch #2 provides a helper to make sure that everybody gets the get_file()/fput() correctly while updating vma->vm_file. Can I add your acked-by to the patches and push them upstream through drm-misc-next? Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
Am 18.11.20 um 08:39 schrieb Daniel Vetter:
On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
wrote:
On 11/17/20 2:49 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
On 11/17/20 1:52 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6932d75..5d6d3d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return ret;
}
+static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
+{
+int i;
+
+for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+struct amdgpu_ring *ring = adev->rings[i];
+
+if (!ring || !ring->sched.thread)
+continue;
+
+cancel_delayed_work_sync(&ring->sched.work_tdr);
+}
+}
I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel
This function iterates across all the schedulers per amdgpu device and accesses
amdgpu specific structures , drm/scheduler deals with single scheduler at most
so looks to me like this is the right place for this function
I guess we could keep track of all schedulers somewhere in a list in
struct drm_device and wrap this up. That was kinda the idea.
Minimally I think a tiny wrapper with docs for the
cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
observe to make sure there's no race.
Will do
I'm not exactly sure there's no
guarantee here we won't get a new tdr work launched right afterwards at
least, so this looks a bit like a hack.
Note that for any TDR work happening post amdgpu_cancel_all_tdr
amdgpu_job_timedout->drm_dev_is_unplugged
will return true and so it will return early. To make it water proof tight
against race
i can switch from drm_dev_is_unplugged to drm_dev_enter/exit
Hm that's confusing. You do a work_cancel_sync, so that at least looks
like "tdr work must not run after this point"
If you only rely on drm_dev_enter/exit check with the tdr work, then
there's no need to cancel anything.
Agree, synchronize_srcu from drm_dev_unplug should play the role
of 'flushing' any earlier (in progress) tdr work which is
using drm_dev_enter/exit pair. Any later arising tdr will terminate early when
drm_dev_enter
returns false.
Nope, anything you put into the work itself cannot close this race.
It's the schedule_work that matters here. Or I'm missing something ...
I thought that the tdr work you're cancelling here is launched by
drm/scheduler code, not by the amd callback?
Yes that is correct. Canceling the work item is not the right approach
at all, nor is adding dev_enter/exit pair in the recovery handler.
What we need to do here is to stop the scheduler thread and then wait
for any timeout handling to have finished.
Otherwise it can scheduler a new timeout just after we have canceled
this one.
Regards,
Christian.
-Daniel
Will update.
Andrey
For race free cancel_work_sync you need:
1. make sure whatever is calling schedule_work is guaranteed to no longer
call schedule_work.
2. call cancel_work_sync
Anything else is cargo-culted work cleanup:
- 1. without 2. means if a work got scheduled right before it'll still be
a problem.
- 2. without 1. means a schedule_work right after makes you calling
cancel_work_sync pointless.
So either both or nothing.
-Daniel
Andrey
-Daniel
Andrey
+
static void
amdgpu_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+struct amdgpu_device *adev = dev->dev_private;
drm_dev_unplug(dev);
+amdgpu_cancel_all_tdr(adev);
ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
amdgpu_driver_unload_kms(dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 4720718..87ff0c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,6 +28,8 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
+#include
+
static void amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
@@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
m
RE: [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
From: Dexuan Cui Sent: Tuesday, November 17, 2020 4:03 PM
>
> x86 Hyper-V used to essentially always overwrite the effective cache type
> of guest memory accesses to WB. This was problematic in cases where there
> is a physical device assigned to the VM, since that often requires that
> the VM should have control over cache types. Thus, on newer Hyper-V since
> 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
> users start to complain that Linux VM's VRAM becomes very slow, and it
> turns out that Linux VM should not map the VRAM uncacheable by ioremap().
> Fix this slowness issue by using ioremap_cache().
>
> On ARM64, ioremap_cache() is also required as the host also maps the VRAM
> cacheable, otherwise VM Connect can't display properly with ioremap() or
> ioremap_wc().
>
> With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
> it's no longer necessary to use the hacks we added to mitigate the
> slowness, i.e. we no longer need to allocate physical memory and use
> it to back up the VRAM in Generation-1 VM, and we also no longer need to
> allocate physical memory to back up the framebuffer in a Generation-2 VM
> and copy the framebuffer to the real VRAM. A further big change will
> address these for v5.11.
>
> Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer
> Driver")
> Tested-by: Boqun Feng
> Signed-off-by: Dexuan Cui
> ---
>
> Hi Wei Liu, can you please pick this up into the hyperv/linux.git tree's
> hyperv-fixes branch? I really hope this patch can be in v5.10 since it
> fixes a longstanding issue: https://github.com/LIS/lis-next/issues/655
>
> drivers/video/fbdev/hyperv_fb.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 5bc86f481a78..c8b0ae676809 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1093,7 +1093,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info
> *info)
> goto err1;
> }
>
> - fb_virt = ioremap(par->mem->start, screen_fb_size);
> + /*
> + * Map the VRAM cacheable for performance. This is also required for
> + * VM Connect to display properly for ARM64 Linux VM, as the host also
> + * maps the VRAM cacheable.
> + */
> + fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
> if (!fb_virt)
> goto err2;
>
> --
> 2.19.1
Reviewed-by: Michael Kelley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
On ARM64, ioremap_cache() is also required as the host also maps the VRAM
cacheable, otherwise VM Connect can't display properly with ioremap() or
ioremap_wc().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer
Driver")
Tested-by: Boqun Feng
Signed-off-by: Dexuan Cui
---
Hi Wei Liu, can you please pick this up into the hyperv/linux.git tree's
hyperv-fixes branch? I really hope this patch can be in v5.10 since it
fixes a longstanding issue: https://github.com/LIS/lis-next/issues/655
drivers/video/fbdev/hyperv_fb.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 5bc86f481a78..c8b0ae676809 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1093,7 +1093,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
goto err1;
}
- fb_virt = ioremap(par->mem->start, screen_fb_size);
+ /*
+* Map the VRAM cacheable for performance. This is also required for
+* VM Connect to display properly for ARM64 Linux VM, as the host also
+* maps the VRAM cacheable.
+*/
+ fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
if (!fb_virt)
goto err2;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: make up to 90% of system memory available
Am 17.11.20 um 17:38 schrieb Michel Dänzer: On 2020-11-17 3:06 p.m., Christian König wrote: Increase the ammount of system memory drivers can use to about 90% of the total available. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index a958135cb3fe..0a93df93dba4 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) * the available system memory. */ num_pages = (u64)si.totalram * si.mem_unit; - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; /* But for DMA32 we limit ourself to only use 2GiB maximum. */ num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit; This should update the comment added in patch 1. Yeah indeed, I've tested this with 70, 75, 80, 85 and finally 90 and it looks like I've forgot to update the comment after a while. Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave and Daniel, here's this week's PR for drm-misc-next. It's fairly large, but most of the patches fix kernel build warnings. The rest is the usual mixture of cleanups and small fixes. The panel code gained support for new devices. Best regards Thomas drm-misc-next-2020-11-18: drm-misc-next for 5.11: UAPI Changes: * media: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA format Cross-subsystem Changes: * console: Remove unused functions; Store characters-per-font in font- descriptor structure instead of hard-coding * DT: Add vendor prefix for ShenZhen Asia Better Technology Ltd. (ABT) Core Changes: * Fix build warnings * Update debug logging to new interfaces, plus fixes * Add error messages for ioctls; * Fix kernel docs * doc: Fix kernel docs * fbcon: Remove accelerated scrolling * selftests: Fix build warnings * ttm: Fix missing NULL check in new page pool; Fix build warnings * video: Fix kernel docs Driver Changes: * armada: Fix build warnings * atmel-hlcdc: Fix build warnings * exynos: Fix build warnings * gma500: Remove 2d framebuffer acceleration * lima: Fix build warnings; Cleanups * mediatek: Fix build warnings * meson: Module removal fixes; Fix build warnings * nouveau: Fix build warnings * omap: Fix return values * panel: Fix build warnings; Add support and DT bindings for OnePlus 6/T; Add support and DT bindings for ABT Y030XX067A * panel/s6e63m0: Add/improve SPi reading/writing; Support 3WIRE protocol; Set connector display info; Add more comments * panfrost: Move GPU reset into separate worker, avoid race conditions * pl111: Fix build warnings * qxl: Cleanup fbcon acceleration * rockchip: Fix build warnings * savage: Fix build warnings * sti: Fix build warnings * udl: Fix missing error code in udl_handle_damage() * v3d: Fix build warnings * vc4: Fix build warnings * via: Fix build warnings * virtio: Make dma-buf ops static The following changes since commit 05481f072787e96d08cc304cda0c10e0d02cdadc: drm/kmb: fix spelling mistakes in drm_info and drm_dbg messages (2020-11-11 22:00:05 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-11-18 for you to fetch changes up to fa388231fec99b60346319d56495ae531b666275: drm/docs: Fix todo.rst (2020-11-18 11:51:58 +0100) drm-misc-next for 5.11: UAPI Changes: * media: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA format Cross-subsystem Changes: * console: Remove unused functions; Store characters-per-font in font- descriptor structure instead of hard-coding * DT: Add vendor prefix for ShenZhen Asia Better Technology Ltd. (ABT) Core Changes: * Fix build warnings * Update debug logging to new interfaces, plus fixes * Add error messages for ioctls; * Fix kernel docs * doc: Fix kernel docs * fbcon: Remove accelerated scrolling * selftests: Fix build warnings * ttm: Fix missing NULL check in new page pool; Fix build warnings * video: Fix kernel docs Driver Changes: * armada: Fix build warnings * atmel-hlcdc: Fix build warnings * exynos: Fix build warnings * gma500: Remove 2d framebuffer acceleration * lima: Fix build warnings; Cleanups * mediatek: Fix build warnings * meson: Module removal fixes; Fix build warnings * nouveau: Fix build warnings * omap: Fix return values * panel: Fix build warnings; Add support and DT bindings for OnePlus 6/T; Add support and DT bindings for ABT Y030XX067A * panel/s6e63m0: Add/improve SPi reading/writing; Support 3WIRE protocol; Set connector display info; Add more comments * panfrost: Move GPU reset into separate worker, avoid race conditions * pl111: Fix build warnings * qxl: Cleanup fbcon acceleration * rockchip: Fix build warnings * savage: Fix build warnings * sti: Fix build warnings * udl: Fix missing error code in udl_handle_damage() * v3d: Fix build warnings * vc4: Fix build warnings * via: Fix build warnings * virtio: Make dma-buf ops static Boris Brezillon (1): drm/panfrost: Move the GPU reset bits outside the timeout handler Caleb Connolly (2): dt-bindings: panel-simple-dsi: add samsung panels for OnePlus 6/T drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devices Christian König (1): drm/ttm: fix missing NULL check in the new page pool Dan Carpenter (1): drm/udl: Fix missing error code in udl_handle_damage() Daniel Vetter (4): fbcon: Disable accelerated scrolling fbcon: Drop EXPORT_SYMBOL drm/qxl: Remove fbcon acceleration leftovers drm/docs: Fix todo.rst Lee Jones (44): drm/atmel-hlcdc/atmel_hlcdc_crtc: Apply correct formatting to struct docs drm/atmel-hlcdc/atmel_hlcdc_plane: Staticise local function 'atmel_hlcdc_plane_setup_scaler()' drm/atmel-hlcdc/atmel_hlcdc_plane: Fix documentation formatting and add missing description drm/savage/sava
[PATCH] drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence
Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
added an intel_dsi_msleep() helper which skips sleeping if the
MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
and it moved a bunch of msleep-s over to this new helper.
This was based on my reading of the big comment around line 730 which
starts with "Panel enable/disable sequences from the VBT spec.",
where the "v3 video mode seq" column does not have any wait t# entries.
Given that this code has been used on a lot of different devices without
issues until now, it seems that my interpretation of the spec here is
mostly correct.
But now I have encountered one device, an Acer Aspire Switch 10 E
SW3-016, where the panel will not light up unless we do actually honor the
panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
What seems to set this model apart is that it is lacking a
MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
delay usually happens.
Fix the panel not lighting up on this model by using an unconditional
msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
no MIPI_SEQ_DEASSERT_RESET sequence.
Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 194c239ab6b1..ef673277b36d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -816,10 +816,14 @@ static void intel_dsi_pre_enable(struct
intel_atomic_state *state,
intel_dsi_prepare(encoder, pipe_config);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
- intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
- /* Deassert reset */
- intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+ if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
+ intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
+ /* Deassert reset */
+ intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+ } else {
+ msleep(intel_dsi->panel_on_delay);
+ }
if (IS_GEMINILAKE(dev_priv)) {
glk_cold_boot = glk_dsi_enable_io(encoder);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/ttm/drivers: remove unecessary ttm_module.h include
Am 17.11.20 um 18:46 schrieb Daniel Vetter: On Tue, Nov 17, 2020 at 05:33:35PM +0100, Christian König wrote: ttm_module.h deals with internals of TTM and should never be include outside of it. Signed-off-by: Christian König Maybe also move it to drivers/gpu/drm/ttm/ttm_internal.h. We're using the _interal.h suffix in a few other places for module internal functions already. Perhaps in a follow-up? I've thought I already moved the header into drivers/gpu/drm/ttm/, but it somehow got mangled into patch #2. Going to fix that and resend. Anyway this here is Acked-by: Daniel Vetter For this one or the whole series? Please note that #2 removes the TTM sysfs files. I think that nobody every used those, but who knows? Regards, Christian. (I didn't bother compile testing it on everything, just to make that clear). -Daniel --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/qxl/qxl_ttm.c | 1 - drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_ttm.c | 1 - drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 - drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 - drivers/gpu/drm/ttm/ttm_range_manager.c | 1 - drivers/gpu/drm/vmwgfx/ttm_object.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 - include/drm/ttm/ttm_bo_driver.h | 1 - 16 files changed, 16 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 183b09d71b64..6e042b4ed13d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -55,7 +55,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index c438d290a6db..967859c6be3c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -46,7 +46,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 8e90b3e47bbe..700fa0979d14 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -54,7 +54,6 @@ #include #include #include -#include #include diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h index 8bd0f916dfbc..83b54f0dad61 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -46,7 +46,6 @@ #include #include #include -#include #include #include "qxl_dev.h" diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index 128c38c8a837..0cc661df2258 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c +++ b/drivers/gpu/drm/qxl/qxl_ttm.c @@ -31,7 +31,6 @@ #include #include #include -#include #include #include "qxl_drv.h" diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 28cb8ced91b9..428c561a4e2c 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -75,7 +75,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 0ca381b95d3d..2259d3811a45 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -46,7 +46,6 @@ #include #include #include -#include #include #include "radeon_reg.h" diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 03c86628e4ac..8f9fa4188897 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -32,7 +32,6 @@ #define pr_fmt(fmt) "[TTM] " fmt -#include #include #include #include diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 2944fa0af493..144a4940b6b6 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -31,7 +31,6 @@ #define pr_fmt(fmt) "[TTM] " fmt -#include #include #include #include diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c index ea77919569a2..4c0c756c9124 100644 --- a/drivers/gpu/drm/ttm/ttm_range_manager.c +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c @@ -29,7 +29,6 @@ * Authors: Thomas Hellstrom */ -#include #include #include #include diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c b/drivers/gpu/drm/vmwgfx/ttm_object.c index 16077785ad47..0fe869d0fad1 100644 --- a/drivers/gpu/drm/vmwgfx/ttm_obj
Re: [PATCH 1/3] drm/mipi-dbi: Add support for Type B
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on robh/for-next drm-intel/for-linux-next
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.10-rc4
next-20201118]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201118-153901
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
09162bc32c880a791c6c0668ce0745cf7958f576
config: alpha-randconfig-s032-20201118 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-107-gaf3512a6-dirty
#
https://github.com/0day-ci/linux/commit/f75093067b26ff68b2de896f317a03a10d8bc7ff
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201118-153901
git checkout f75093067b26ff68b2de896f317a03a10d8bc7ff
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/gpu/drm/drm_mipi_dbi.c:1255:20: sparse: sparse: Using plain integer
>> as NULL pointer
vim +1255 drivers/gpu/drm/drm_mipi_dbi.c
1234
1235 /**
1236 * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface
implemented via GPIO
1237 * @dbi: MIPI DBI structure to initialize
1238 * @dc: D/C gpio
1239 * @wr: W/R gpio
1240 * @db: DB gpios
1241 * @wr_up_delay: Delay after setting DB and before changing W/R from
low to high
1242 * @wr_down_delay: Delay after changing W/R from low to high
1243 *
1244 * This function sets &mipi_dbi->command, enables
&mipi_dbi->read_commands for the
1245 * usual read commands. It should be followed by a call to
mipi_dbi_dev_init() or
1246 * a driver-specific init.
1247 *
1248 * Returns:
1249 * Zero on success, negative error code on failure.
1250 */
1251 int mipi_dbi_gpio_init(struct mipi_dbi *dbi, struct gpio_desc *dc,
1252struct gpio_desc *wr, struct gpio_descs *db,
1253unsigned long wr_up_delay, unsigned long
wr_down_delay)
1254 {
> 1255 dbi->spi = 0; /* Type B uses GPIO lines rather than SPI */
1256
1257 dbi->read_commands = mipi_dbi_dcs_read_commands;
1258 dbi->command = mipi_dbi_gpio_command;
1259
1260 dbi->dc = dc;
1261 dbi->wr = wr;
1262 dbi->db = db;
1263 dbi->wr_up_delay = wr_up_delay;
1264 dbi->wr_down_delay = wr_down_delay;
1265
1266 if (mipi_dbi_machine_little_endian())
1267 dbi->swap_bytes = true;
1268
1269 mutex_init(&dbi->cmdlock);
1270
1271 return 0;
1272 }
1273 EXPORT_SYMBOL(mipi_dbi_gpio_init);
1274
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: make up to 90% of system memory available
Am 17.11.20 um 18:19 schrieb Daniel Vetter: On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wrote: Increase the ammount of system memory drivers can use to about 90% of the total available. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index a958135cb3fe..0a93df93dba4 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) * the available system memory. */ num_pages = (u64)si.totalram * si.mem_unit; - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; I don't think this is the design we want. As long as it was set at "half of system memory" it was clear that a) it's a hack b) precision didn't matter. Yeah, I'm also wondering what to do here exactly. In generally I would completely nuke that limit if possible. But if you go to the limit and still want to keep the "we make sure there's no OOM", then precision starts to matter: - memory hotplug and hotunplug is a thing - userspace can mlock, and it's configureable - drivers can pin_user_pages for IO and random other stuff. Some of it is accounted as some subsystem specific mlock (like rdma does iirc), some is just yolo or short term enough (like) - none of what we do here takes into considerations any interactions with core mm tracking (like cgroups or numa or anything like that) OOM is perfectly fine with me, we should just not run into an OOM killer situation because we call shmem_read_mapping_page_gfp() in the shrinker callback. Any idea how we could guarantee that? If we want to drop the "half of system ram" limit (and yes that makes sense) I think the right design is: - we give up on the "no OOM" guarantee. - This means if you want real isolation of tasks, we need cgroups, and we need to integrate ttm cgroups with system memory cgroups somehow. Unlike randomly picked hardcoded limits this should work a lot more reliably and be a lot more useful in practical use in the field. - This also means that drivers start to fail in interesting ways. I think locking headaches are covered with all the lockdep annotations I've pushed, plus some of the things I still have in-flight (I have a might_alloc() annotations somewhere). That leaves validation of error paths for when allocations fail. Ime a very effective way we used in i915 is (ab)using EINTR restarting, which per drmIoctl uapi spec is requried. We could put a debug mode into ttm_tt which randomly fails with -EINTR to make sure it's all working correctly (plus anything else that allocates memory), and unlike real out-of-memory injection piglit and any other cts will complete without failure. Which gives us an excellent metric for "does it work". Actualy OOM, even injected one, tends to make stuff blow up in a way that's very hard to track and make sure you've got good coverage, since all your usual tests die pretty quickly. - ttm_tt needs to play fair with every other system memory user. We need to register a shrinker for each ttm_tt (so usually one per device I guess), which walks the lru (in shrink_count) and uses dma_resv_trylock for actual shrinking. We probably want to move it to SYSTEM first for that shrinker to pick up, so that there's some global fairness across all ttm_tt. I already have patches for this. What's still missing is teaching the OOM killer which task is using the memory since memory referenced through the file descriptors are currently not accounted towards any process resources. - for GFP_DMA32 that means zone aware shrinkers. We've never used those, because thus far i915 didn't have any big need for low memory, so we haven't used this in practice. But it's supposed to be a thing. I think we can mostly forget about GFP_DMA32, this should only be used for AGP and other ancient hardware. Christian. It's a bit more code than the oneliner above, but I also think it's a lot more solid. Plus it would resolve the last big issue where i915 gem is fairly fundamentally different compared to ttm. For that question I think once Maarten's locking rework for i915 has landed and all the other ttm rework from you and Dave is in, we've resolved them all. /* But for DMA32 we limit ourself to only use 2GiB maximum. */ num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
AW: [PATCH] drm: imx: Move fbdev setup to before output polling
Hi Thomas and Daniel, Thank you very much for your feedback. We appreciate it. > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > >>> b/drivers/gpu/drm/imx/imx-drm-core.c > >>> index 9bf5ad6d18a2..2665040e11c7 100644 > >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c > >>> +++ b/drivers/gpu/drm/imx/imx-drm-core.c > >>> @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) > >>>legacyfb_depth = 16; > >>>} > >>> > >>> + /* > >>> + * The generic fbdev has to be setup before enabling output polling. > >>> + * Otherwise the fbdev client is not ready to handle delayed events. > >>> + */ > >>> + drm_fbdev_generic_setup(drm, legacyfb_depth); > >>> + > >>>drm_kms_helper_poll_init(drm); > >>> > >>>ret = drm_dev_register(drm, 0); > >>>if (ret) > >>>goto err_poll_fini; > >>> > >>> - drm_fbdev_generic_setup(drm, legacyfb_depth); > >>> - > >> > >> This does not work well. fbdev is supposed to be another regular DRM > >> client. It has to be enabled after registering the DRM device. > >> > >> I'd rather improve fbdev or the driver to handle this gracefully. > > > > Yeah I'm not understanding the point here. Once fbcon is running, you > > have a screen. Any fbdev userspace client also should do a modeset > > first. And if they dont and it's expected uapi for fbdev chardev that > > the display boots up enabled, then we need to fix that in the fbdev > > helpers, not through clever reordering in drivers so that a > > side-effect causes a modeset. > > > > Note that this is a bit tricky since fbdev shouldn't take over the > > screen by default, so we'd need to delay this until first open of > > /dev/fb0. And we should probably also delay the hotplug handling until > > the first open. fbcon also fake-opens the fbdev file, so it's the same > > code path. > > As far as I understand the commit message, the problem is that the display > blanks out after registering the driver. And fbdev somewhat mitigates this by > doing an early modeset. Users with fbdev disabled (most of them in > embedded, I guess) would still run into the issue until userspace makes a > modeset. > > Mark, if that's the case, an option might be to pick up the device settings > instead of calling drm_mode_config_reset(). The driver would then continue > to display whatever is on the screen. We are started using fbdev in our embedded application with Linux 3.10, later updated to 4.14 and are now in the process of updating to 5.4. So far the uapi appeared to us as if we could rely on an already enabled fbdev. That is, none of our applications does a modeset. When switching to 5.4 we noticed that the fbdev uapi changed. That is, the LCD is switched off until it is explicitly enabled. It could be enabled by writing to /sys/class/graphics/fb0/blank. You are right, we are not using fbcon. fbcon will still enable the LCD but in our embedded domain we have it disabled because we must not show a console. Do we understand your proposal correctly to replace the call to drm_mode_config_reset() in imx_drm_bind() [imx-drm-core.c] with picking up the device settings instead? https://elixir.bootlin.com/linux/v5.10-rc4/source/drivers/gpu/drm/imx/imx-drm-core.c#L231 We are a little clueless right now: How do we pick up the device settings? Greetings, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/selftests/test-drm_dp_mst_helper: fix memory leak allocated to 'out'
From: Colin Ian King
Currently when txmsg fails to allocate then there is a leak on 'out'. Fix
this by setting result to false and exiting via the clean up exit path.
Note since txmsg is NULL at this point, the kfree of txmsg is a no-op.
Addresses-Coverity: ("Resource leak")
Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move
'sideband_msg_req_encode_decode' onto the heap")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
index 6b4759ed6bfd..dbac073ed385 100644
--- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
+++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
@@ -131,8 +131,10 @@ sideband_msg_req_encode_decode(struct
drm_dp_sideband_msg_req_body *in)
return false;
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
- if (!txmsg)
- return false;
+ if (!txmsg) {
+ result = false;
+ goto out;
+ }
drm_dp_encode_sideband_req(in, txmsg);
ret = drm_dp_decode_sideband_req(txmsg, out);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/selftests/test-drm_dp_mst_helper: fix memory leak allocated to 'out'
On Wed, 18 Nov 2020, Colin King wrote:
> From: Colin Ian King
>
> Currently when txmsg fails to allocate then there is a leak on 'out'. Fix
> this by setting result to false and exiting via the clean up exit path.
> Note since txmsg is NULL at this point, the kfree of txmsg is a no-op.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move
> 'sideband_msg_req_encode_decode' onto the heap")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
This is fixed in my local branch.
Looks like the wrong version of the patch was sent/applied.
Either way, thanks for the fix Colin.
Reviewed-by: Lee Jones
> diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> index 6b4759ed6bfd..dbac073ed385 100644
> --- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> @@ -131,8 +131,10 @@ sideband_msg_req_encode_decode(struct
> drm_dp_sideband_msg_req_body *in)
> return false;
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> - if (!txmsg)
> - return false;
> + if (!txmsg) {
> + result = false;
> + goto out;
> + }
>
> drm_dp_encode_sideband_req(in, txmsg);
> ret = drm_dp_decode_sideband_req(txmsg, out);
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/ttm: add multihop infrastrucutre (v2)
Am 10.11.20 um 18:11 schrieb Daniel Vetter:
On Tue, Nov 10, 2020 at 4:48 PM Ville Syrjälä
wrote:
On Tue, Nov 10, 2020 at 03:24:32PM +1000, Dave Airlie wrote:
On Tue, 10 Nov 2020 at 07:27, Ville Syrjälä
wrote:
On Mon, Nov 09, 2020 at 09:48:04PM +0100, Christian König wrote:
Am 09.11.20 um 17:43 schrieb Ville Syrjälä:
On Mon, Nov 09, 2020 at 05:20:17PM +0100, Christian König wrote:
Am 09.11.20 um 17:18 schrieb Ville Syrjälä:
On Mon, Nov 09, 2020 at 04:57:29PM +0100, Christian König wrote:
Am 09.11.20 um 16:16 schrieb Ville Syrjälä:
On Wed, Nov 11, 2020 at 06:13:02PM +0100, Christian König wrote:
Am 09.11.20 um 01:54 schrieb Dave Airlie:
@@ -1432,15 +1479,18 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->mem.mem_type != TTM_PL_SYSTEM) {
struct ttm_operation_ctx ctx = { false, false };
struct ttm_resource evict_mem;
+ struct ttm_place hop = {};
Please always use memset() if you want to zero initialize something in
the kernel, we had enough trouble with that.
What trouble is that? I've not heard of anything, and we use
={} quite extensively in drm land.
={} initializes only named fields, not padding.
Has that actually happened?
YES! Numerous times!
You wouldn't happen to have links/etc. to the discussion?
I'd like to check them out.
Uff, that was years ago. Just google for something like "mesa memset
hash", there was recently (~ the last year) another discussion because
somebody ran into exactly that problem once more.
Found this:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F2071&data=04%7C01%7Cchristian.koenig%40amd.com%7C66be3d367f2b401b2e2808d8859ba4ee%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637406250838085232%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X2z5zxsBvhXQvmd2oJzuN2YzDMGZnYUff6qxuJL%2BjLE%3D&reserved=0
which does suprise me a bit. Though I suspect ={} might
behave differently since the compiler might treat it
more like a memset().
It doesn't there's a bit of info out there on what happens, it really
only matters for structs we are passing to userspace, but it's
unlikely to matter here,
but I've changed this to memset in my local tree, because why not.
Structs passed to userspace should really have no implicit padding.
One of those how to botch your ioctl things...
The main problems with memset() are:
- it's ugly
- people often get the sizeof wrong
I guess the latter could be alleviated with a cpp macro that
does the sizeof correctly for you.
Yeah imo not using = {} and instead insisting on memset is really bad
w/a for not padding your api structs properly. memset is only one
place where this goes horribly wrong.
I'm not a fan of memset either, but there are more problems than just
the padding in the UAPI.
I've seen at least the following in the wild:
1. UAPI information leak.
2. Hash and fingerprinting functions returning unstable results even
when all meaningful members of a structure are initialized.
3. Valgrind/KASAN/Coverity randomly pointing this out as problem.
4. There is the discussion if ={} (not ISO C conform) or ={0] or even
={{0}} should be used.
My preference would be to just teach compilers that not initializing
padding in the kernel is a undesired behavior which should be avoided.
Regards
Christian.
I think for the gallium state tracker hasing issue memset is probably
ok ot use for these specifically, with a big comment explaining why.
And some code assurance that the memset is the same length you're
passing to the crc function and all that. But anywhere were it's more
(like anything related to api, which the gallium CSO hashing isnt) you
really want to have no implicit holes at all.
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/imx: depend on COMMON_CLK to fix compile tests
Hi Krzysztof, On Tue, 2020-11-17 at 19:24 +0100, Krzysztof Kozlowski wrote: > The iMX DRM LVDS driver uses Common Clock Framework thus it cannot be > built on platforms without it (e.g. compile test on MIPS with RALINK and > SOC_RT305X): > > /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in function > `imx_ldb_encoder_disable': > imx-ldb.c:(.text+0x400): undefined reference to `clk_set_parent' > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Put depends in DRM_IMX_LDB option only. > --- > drivers/gpu/drm/imx/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 6231048aa5aa..73fe2bc5633c 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -28,6 +28,7 @@ config DRM_IMX_TVE > config DRM_IMX_LDB > tristate "Support for LVDS displays" > depends on DRM_IMX && MFD_SYSCON > + depends on COMMON_CLK > select DRM_PANEL > help > Choose this to enable the internal LVDS Display Bridge (LDB) Thank you, applied to imx-drm/next. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document drm_mode_get_connector
On Wed, Nov 18, 2020 at 11:52 AM Simon Ser wrote:
>
> Document how to perform a forced probe, and when should user-space do it.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> ---
> include/uapi/drm/drm_mode.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ad10ab2a577..09647b799f39 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -368,6 +368,19 @@ enum drm_mode_subconnector {
> #define DRM_MODE_CONNECTOR_WRITEBACK 18
> #define DRM_MODE_CONNECTOR_SPI 19
>
> +/**
> + * struct drm_mode_get_connector - get connector metadata
> + *
> + * If the @count_modes field is set to zero, the kernel will perform a forced
> + * probe on the connector to refresh the connector status, modes and EDID.
> + * A forced-probe can be slow and the ioctl will block.
> + *
> + * User-space shouldn't need to force-probe connectors in general: the kernel
> + * will automatically take care of probing connectors that don't support
> + * hot-plug detection when appropriate. However, user-space may force-probe
> + * connectors on user request (e.g. clicking a "Scan connectors" button, or
> + * opening a UI to manage screens).
> + */
I think this causes warnings, because now we have kerneldoc for this,
but not for all the members. Also the member-specific stuff should be
documented as inline comment, see
https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#in-line-member-documentation-comments
I also noticed that this file has a ton of wrong kerneldoc comments,
but they seem to not cause warnings (anything starting with /** is
fishy).
Can I volunteer you for a bit more here?
Thanks, Daniel
> struct drm_mode_get_connector {
>
> __u64 encoders_ptr;
> --
> 2.29.2
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document drm_mode_get_connector
On Wednesday, November 18, 2020 4:03 PM, Daniel Vetter wrote: > I think this causes warnings, because now we have kerneldoc for this, > but not for all the members. Also the member-specific stuff should be > documented as inline comment, see > > https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#in-line-member-documentation-comments Hm, right, will make sure the patch doesn't trigger warnings. I still think the force-probe stuff shouldn't be documented in in-line comments, because I'd never look at the in-line count_modes comment to know whether the ioctl probes or not. Adding short in-line comments sounds fine though. > I also noticed that this file has a ton of wrong kerneldoc comments, > but they seem to not cause warnings (anything starting with /** is > fishy). > > Can I volunteer you for a bit more here? Yeah, I've noticed this as well. Will have a look! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: use min_t to replace min
Hi Bernard, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.10-rc4 next-20201118] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Bernard-Zhao/drm-vmwgfx-use-min_t-to-replace-min/20201118-191834 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 0fa8ee0d9ab95c9350b8b84574824d9a384a9f7d config: i386-randconfig-a012-20201118 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/7de055295e38f294671f936d65719c02195251ca git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Bernard-Zhao/drm-vmwgfx-use-min_t-to-replace-min/20201118-191834 git checkout 7de055295e38f294671f936d65719c02195251ca # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c: In function 'vmw_gmr2_bind': include/linux/minmax.h:110:46: error: expected expression before ')' token 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ include/linux/minmax.h:18:21: note: in definition of macro '__typecheck' 18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^ include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp' 42 | __builtin_choose_expr(__safe_cmp(x, y), \ |^~ include/linux/minmax.h:110:27: note: in expansion of macro '__careful_cmp' 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c:75:22: note: in expansion of macro 'min_t' 75 | unsigned long nr = min_t((unsigned long), num_pages, VMW_PPN_PER_REMAP); | ^ include/linux/minmax.h:110:46: error: expected expression before ')' token 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ include/linux/minmax.h:26:48: note: in definition of macro '__is_constexpr' 26 | (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) |^ include/linux/minmax.h:32:25: note: in expansion of macro '__no_side_effects' 32 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^ include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp' 42 | __builtin_choose_expr(__safe_cmp(x, y), \ |^~ include/linux/minmax.h:110:27: note: in expansion of macro '__careful_cmp' 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c:75:22: note: in expansion of macro 'min_t' 75 | unsigned long nr = min_t((unsigned long), num_pages, VMW_PPN_PER_REMAP); | ^ include/linux/minmax.h:110:57: error: expected expression before ')' token 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ include/linux/minmax.h:26:48: note: in definition of macro '__is_constexpr' 26 | (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) |^ include/linux/minmax.h:32:25: note: in expansion of macro '__no_side_effects' 32 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^ include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp' 42 | __builtin_choose_expr(__safe_cmp(x, y), \ |^~ include/linux/minmax.h:110:27: note: in expansion of macro '__careful_cmp' 110 | #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) | ^ drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c:75:22: note: in expansion of macro 'min_t' 75 | unsigned long nr = min_t((unsigned long), num_pages, VMW_PPN_PER_REMAP); | ^ include/linux/minmax.h:110:46: err
Re: [PATCH] drm: document drm_mode_get_connector
On Wed, Nov 18, 2020 at 4:09 PM Simon Ser wrote: > > On Wednesday, November 18, 2020 4:03 PM, Daniel Vetter > wrote: > > > I think this causes warnings, because now we have kerneldoc for this, > > but not for all the members. Also the member-specific stuff should be > > documented as inline comment, see > > > > https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#in-line-member-documentation-comments > > Hm, right, will make sure the patch doesn't trigger warnings. > > I still think the force-probe stuff shouldn't be documented in in-line > comments, because I'd never look at the in-line count_modes comment to know > whether the ioctl probes or not. Adding short in-line comments sounds fine > though. Hm yeah, maybe give it a sub-title then like "Probe Modes" with the two options. I think the detail that a small array/count (either 0 or 1 depending whether you want force probing) should be documented in the inline comment though. I think the inline comment for connection should also link to the drm_connector_status enum. Maybe also have that link in the "Probe Modes" section with an explanation that a forced probe can get rid of some the unknown ones. I also kinda wonder where we should up recommendations for autoconfiguration. > > > I also noticed that this file has a ton of wrong kerneldoc comments, > > but they seem to not cause warnings (anything starting with /** is > > fishy). > > > > Can I volunteer you for a bit more here? > > Yeah, I've noticed this as well. Will have a look! Thanks! -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On 2020-11-18 07:01, Christian König wrote:
> Am 18.11.20 um 08:39 schrieb Daniel Vetter:
>> On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
>> wrote:
>>>
>>> On 11/17/20 2:49 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
> On 11/17/20 1:52 PM, Daniel Vetter wrote:
>> On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
>>> On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> No point to try recovery if device is gone, just messes up things.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6932d75..5d6d3d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev
> *pdev,
> return ret;
> }
> +static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
> +{
> +int i;
> +
> +for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> +struct amdgpu_ring *ring = adev->rings[i];
> +
> +if (!ring || !ring->sched.thread)
> +continue;
> +
> +cancel_delayed_work_sync(&ring->sched.work_tdr);
> +}
> +}
I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or
your
split in one of the earlier patches not done quite right.
-Daniel
>>> This function iterates across all the schedulers per amdgpu device and
>>> accesses
>>> amdgpu specific structures , drm/scheduler deals with single scheduler
>>> at most
>>> so looks to me like this is the right place for this function
>> I guess we could keep track of all schedulers somewhere in a list in
>> struct drm_device and wrap this up. That was kinda the idea.
>>
>> Minimally I think a tiny wrapper with docs for the
>> cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
>> observe to make sure there's no race.
> Will do
>
>
>> I'm not exactly sure there's no
>> guarantee here we won't get a new tdr work launched right afterwards at
>> least, so this looks a bit like a hack.
> Note that for any TDR work happening post amdgpu_cancel_all_tdr
> amdgpu_job_timedout->drm_dev_is_unplugged
> will return true and so it will return early. To make it water proof tight
> against race
> i can switch from drm_dev_is_unplugged to drm_dev_enter/exit
Hm that's confusing. You do a work_cancel_sync, so that at least looks
like "tdr work must not run after this point"
If you only rely on drm_dev_enter/exit check with the tdr work, then
there's no need to cancel anything.
>>>
>>> Agree, synchronize_srcu from drm_dev_unplug should play the role
>>> of 'flushing' any earlier (in progress) tdr work which is
>>> using drm_dev_enter/exit pair. Any later arising tdr will terminate early
>>> when
>>> drm_dev_enter
>>> returns false.
>> Nope, anything you put into the work itself cannot close this race.
>> It's the schedule_work that matters here. Or I'm missing something ...
>> I thought that the tdr work you're cancelling here is launched by
>> drm/scheduler code, not by the amd callback?
>
> Yes that is correct. Canceling the work item is not the right approach
> at all, nor is adding dev_enter/exit pair in the recovery handler.
>
> What we need to do here is to stop the scheduler thread and then wait
> for any timeout handling to have finished.
>
> Otherwise it can scheduler a new timeout just after we have canceled
> this one.
Yep, that's exactly what I said in my email above.
Regards,
Luben
>
> Regards,
> Christian.
>
>> -Daniel
>>
>>> Will update.
>>>
>>> Andrey
>>>
>>>
For race free cancel_work_sync you need:
1. make sure whatever is calling schedule_work is guaranteed to no longer
call schedule_work.
2. call cancel_work_sync
Anything else is cargo-culted work cleanup:
- 1. without 2. means if a work got scheduled right before it'll still be
a problem.
- 2. without 1. means a schedule_work right after makes you calling
cancel_work_sync pointless.
So either both or nothing.
-Daniel
> Andrey
>
>
>> -Daniel
>>
>>> Andrey
>>>
>>>
> +
> stati
Re: [Freedreno] [PATCH] drm/msm/dpu: Remove chatty vbif debug print
On Tue, Nov 17, 2020 at 2:53 PM Stephen Boyd wrote:
>
> Quoting abhin...@codeaurora.org (2020-11-17 12:34:56)
> > On 2020-11-17 09:26, Stephen Boyd wrote:
> > > I don't know what this debug print is for but it is super chatty,
> > > throwing 8 lines of debug prints in the logs every time we update a
> > > plane. It looks like it has no value. Let's nuke it so we can get
> > > better logs.
> > >
> > > Cc: Sean Paul
> > > Cc: Abhinav Kumar
> > > Signed-off-by: Stephen Boyd
> >
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > > index 5e8c3f3e6625..5eb2b2ee09f5 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > > @@ -245,9 +245,6 @@ void dpu_vbif_set_qos_remap(struct dpu_kms
> > > *dpu_kms,
> > > forced_on = mdp->ops.setup_clk_force_ctrl(mdp, params->clk_ctrl,
> > > true);
> > >
> > > for (i = 0; i < qos_tbl->npriority_lvl; i++) {
> > > - DPU_DEBUG("vbif:%d xin:%d lvl:%d/%d\n",
> > > - params->vbif_idx, params->xin_id, i,
> > > - qos_tbl->priority_lvl[i]);
> >
> > Instead of getting rid of this print, we should optimize the caller of
> > this.
>
> Does the print tell us anything? Right now it prints 8 lines where it
> feels like it could be trimmed down:
>
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:0/3
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:1/3
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:2/4
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:3/4
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:4/5
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:5/5
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:6/6
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:7/6
>
> maybe one line that combines the index into values?
>
>[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 [3 3 4 4 5 5 6 6]
>
or possibly convert to a tracepoint (so it doesn't spam the drm_trace buffer)
BR,
-R
> But again I have no idea if this print is really useful. Maybe we can
> print it only if the value changes from what was already there?
> Basically move the print into dpu_hw_set_qos_remap() and then skip out
> early if nothing changed or print and modify the register.
>
> > This is what
> > we are doing in downstream. So we need to update the property only if we
> > are switching from a RT client
> > to non-RT client for the plane and vice-versa. So we should try to do
> > the same thing here.
> >
> > is_rt = sde_crtc_is_rt_client(crtc, crtc->state);
> > if (is_rt != psde->is_rt_pipe) {
> > psde->is_rt_pipe = is_rt;
> > pstate->dirty |= SDE_PLANE_DIRTY_QOS;
> > }
> >
> >
> > if (pstate->dirty & DPU_PLANE_DIRTY_QOS)
> > _dpu_plane_set_qos_remap(plane);
> >
>
> Sounds great! Can you send the patch?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char/agp: Disable frontend without CONFIG_DRM_LEGACY
On Tue, Nov 17, 2020 at 4:40 PM Daniel Vetter wrote: > > It's probably full of bugs ready for exploiting by userspace. And > there's not going to be any userspace for this without any of the drm > legacy drivers enabled too. So just couple it together. Not quite true. The only UMS driver using this is i810, which needs it even with DRI disabled. I have difficulty caring though. In related news, since i810 is only ever attached to 32-bit x86 we could disable the frontend unconditionally on amd64 (and everything else tbh). Acked-by: Adam Jackson - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On 11/18/20 7:01 AM, Christian König wrote:
Am 18.11.20 um 08:39 schrieb Daniel Vetter:
On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
wrote:
On 11/17/20 2:49 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
On 11/17/20 1:52 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6932d75..5d6d3d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return ret;
}
+static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
+{
+ int i;
+
+ for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+ struct amdgpu_ring *ring = adev->rings[i];
+
+ if (!ring || !ring->sched.thread)
+ continue;
+
+ cancel_delayed_work_sync(&ring->sched.work_tdr);
+ }
+}
I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel
This function iterates across all the schedulers per amdgpu device and
accesses
amdgpu specific structures , drm/scheduler deals with single scheduler
at most
so looks to me like this is the right place for this function
I guess we could keep track of all schedulers somewhere in a list in
struct drm_device and wrap this up. That was kinda the idea.
Minimally I think a tiny wrapper with docs for the
cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
observe to make sure there's no race.
Will do
I'm not exactly sure there's no
guarantee here we won't get a new tdr work launched right afterwards at
least, so this looks a bit like a hack.
Note that for any TDR work happening post amdgpu_cancel_all_tdr
amdgpu_job_timedout->drm_dev_is_unplugged
will return true and so it will return early. To make it water proof tight
against race
i can switch from drm_dev_is_unplugged to drm_dev_enter/exit
Hm that's confusing. You do a work_cancel_sync, so that at least looks
like "tdr work must not run after this point"
If you only rely on drm_dev_enter/exit check with the tdr work, then
there's no need to cancel anything.
Agree, synchronize_srcu from drm_dev_unplug should play the role
of 'flushing' any earlier (in progress) tdr work which is
using drm_dev_enter/exit pair. Any later arising tdr will terminate early when
drm_dev_enter
returns false.
Nope, anything you put into the work itself cannot close this race.
It's the schedule_work that matters here. Or I'm missing something ...
I thought that the tdr work you're cancelling here is launched by
drm/scheduler code, not by the amd callback?
My bad, you are right, I am supposed to put drm_dev_enter.exit pair into
drm_sched_job_timedout
Yes that is correct. Canceling the work item is not the right approach at all,
nor is adding dev_enter/exit pair in the recovery handler.
Without adding the dev_enter/exit guarding pair in the recovery handler you are
ending up with GPU reset starting while
the device is already unplugged, this leads to multiple errors and general mess.
What we need to do here is to stop the scheduler thread and then wait for any
timeout handling to have finished.
Otherwise it can scheduler a new timeout just after we have canceled this one.
Regards,
Christian.
Schedulers are stopped from amdgpu_driver_unload_kms which indeed happens after
drm_dev_unplug
so yes, there is still a chance for new work being scheduler and timeout armed
after but, once i fix the code
to place drm_dev_enter/exit pair into drm_sched_job_timeout I don't see why that
not a good solution ?
Any tdr work started after drm_dev_unplug finished will simply abort on entry to
drm_sched_job_timedout
because drm_dev_enter will be false and the function will return without
rearming the timeout timer and
so will have no impact.
The only issue i see here now is of possible use after free if some late tdr
work will try to execute after
drm device already gone, for this we probably should add
cancel_delayed_work_sync(sched.work_tdr)
to drm_sched_fini after sched->thread is stopped there.
Andrey
-Daniel
Will update.
Andrey
For race free cancel_work_sync you need:
1. make sure whatever is calling schedule_work is guaranteed to no longer
call schedule_work.
2. call cancel_work_sync
Anything else is cargo-culte
[PATCH] intel: Do not assert on unknown chips in drm_intel_decode_context_alloc
From: Tvrtko Ursulin
There is this long standing nit of igt/tools/intel_error_decode asserting
when you feed it an error state from a GPU the local libdrm does not know
of.
To fix this I need a tweak in drm_intel_decode_context_alloc to make it
not assert but just return NULL (which seems an already possible return
value).
Signed-off-by: Tvrtko Ursulin
---
intel/intel_decode.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index e0a516644314..be6f77984d65 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3815,32 +3815,35 @@ drm_public struct drm_intel_decode *
drm_intel_decode_context_alloc(uint32_t devid)
{
struct drm_intel_decode *ctx;
+ int gen = 0;
- ctx = calloc(1, sizeof(struct drm_intel_decode));
- if (!ctx)
- return NULL;
-
- ctx->devid = devid;
- ctx->out = stdout;
-
- if (intel_get_genx(devid, &ctx->gen))
+ if (intel_get_genx(devid, &gen))
;
else if (IS_GEN8(devid))
- ctx->gen = 8;
+ gen = 8;
else if (IS_GEN7(devid))
- ctx->gen = 7;
+ gen = 7;
else if (IS_GEN6(devid))
- ctx->gen = 6;
+ gen = 6;
else if (IS_GEN5(devid))
- ctx->gen = 5;
+ gen = 5;
else if (IS_GEN4(devid))
- ctx->gen = 4;
+ gen = 4;
else if (IS_9XX(devid))
- ctx->gen = 3;
- else {
- assert(IS_GEN2(devid));
- ctx->gen = 2;
- }
+ gen = 3;
+ else if (IS_GEN2(devid))
+ gen = 2;
+
+ if (!gen)
+ return NULL;
+
+ ctx = calloc(1, sizeof(struct drm_intel_decode));
+ if (!ctx)
+ return NULL;
+
+ ctx->devid = devid;
+ ctx->gen = gen;
+ ctx->out = stdout;
return ctx;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar wrote:
>
> On 17-11-20, 09:02, Rob Clark wrote:
> > With that on top of the previous patch,
>
> Don't you still have this ? Which fixed the lockdep in the remove path.
>
> https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
>
> To make it clear you need these patches to fix the OPP stuff:
>
> //From 5.10-rc3 (the one from the above link).
> commit e0df59de670b ("opp: Reduce the size of critical section in
> _opp_table_kref_release()")
>
> //Below two from linux-next
> commit ef43f01ac069 ("opp: Always add entries in dev_list with
> opp_table->lock held")
> commit 27c09484dd3d ("opp: Allocate the OPP table outside of opp_table_lock")
>
> This matches the diff I gave you earlier.
>
no, I did not have all three, only "opp: Allocate the OPP table
outside of opp_table_lock" plus the fixup. But with all three:
[ 27.072188] ==
[ 27.078542] WARNING: possible circular locking dependency detected
[ 27.084897] 5.10.0-rc2+ #1 Not tainted
[ 27.088750] --
[ 27.095103] chrome/1897 is trying to acquire lock:
[ 27.100031] ffdb14e4aa88 (opp_table_lock){+.+.}-{3:3}, at:
_find_opp_table+0x38/0x78
[ 27.108379]
[ 27.108379] but task is already holding lock:
[ 27.114373] ff8e2c8f91b0
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
submit_lock_objects+0x70/0x1ec
[ 27.124212]
[ 27.124212] which lock already depends on the new lock.
[ 27.124212]
[ 27.132604]
[ 27.132604] the existing dependency chain (in reverse order) is:
[ 27.140290]
[ 27.140290] -> #4 (reservation_ww_class_mutex){+.+.}-{3:3}:
[ 27.147544]lock_acquire+0x23c/0x30c
[ 27.151848]__mutex_lock_common+0xdc/0xbc4
[ 27.156685]ww_mutex_lock_interruptible+0x84/0xec
[ 27.162142]msm_gem_fault+0x30/0x138
[ 27.166443]__do_fault+0x44/0x184
[ 27.170479]handle_mm_fault+0x754/0xc50
[ 27.175053]do_page_fault+0x230/0x354
[ 27.179444]do_translation_fault+0x40/0x54
[ 27.184277]do_mem_abort+0x44/0xac
[ 27.188402]el0_sync_compat_handler+0x15c/0x190
[ 27.193680]el0_sync_compat+0x144/0x180
[ 27.198244]
[ 27.198244] -> #3 (&mm->mmap_lock){}-{3:3}:
[ 27.204435]lock_acquire+0x23c/0x30c
[ 27.208738]__might_fault+0x60/0x80
[ 27.212951]compat_filldir+0x118/0x4d0
[ 27.217434]dcache_readdir+0x74/0x1e0
[ 27.221825]iterate_dir+0xd4/0x198
[ 27.225947]__arm64_compat_sys_getdents+0x6c/0x168
[ 27.231495]el0_svc_common+0xa4/0x174
[ 27.235886]do_el0_svc_compat+0x20/0x30
[ 27.240461]el0_sync_compat_handler+0x124/0x190
[ 27.245746]el0_sync_compat+0x144/0x180
[ 27.250310]
[ 27.250310] -> #2 (&sb->s_type->i_mutex_key#2){}-{3:3}:
[ 27.257569]lock_acquire+0x23c/0x30c
[ 27.261877]down_write+0x80/0x1dc
[ 27.265912]simple_recursive_removal+0x48/0x238
[ 27.271193]debugfs_remove+0x5c/0x78
[ 27.275502]opp_debug_remove_one+0x18/0x20
[ 27.280343]_opp_kref_release+0x40/0x74
[ 27.284917]dev_pm_opp_put_unlocked+0x44/0x64
[ 27.290015]_opp_remove_all_static+0x5c/0x90
[ 27.295029]dev_pm_opp_remove_table+0x70/0x90
[ 27.300129]dev_pm_opp_of_remove_table+0x14/0x1c
[ 27.305504]msm_dsi_host_destroy+0xd8/0x108
[ 27.310434]dsi_destroy+0x40/0x58
[ 27.314469]dsi_bind+0x8c/0x16c
[ 27.318329]component_bind_all+0xf4/0x20c
[ 27.323081]msm_drm_init+0x180/0x588
[ 27.327382]msm_drm_bind+0x1c/0x24
[ 27.331503]try_to_bring_up_master+0x160/0x1a8
[ 27.336696]component_master_add_with_match+0xc4/0x108
[ 27.342597]msm_pdev_probe+0x214/0x2a4
[ 27.347076]platform_drv_probe+0x94/0xb4
[ 27.351739]really_probe+0x138/0x348
[ 27.356041]driver_probe_device+0x80/0xb8
[ 27.360788]device_driver_attach+0x50/0x70
[ 27.365621]__driver_attach+0xb4/0xc8
[ 27.370012]bus_for_each_dev+0x80/0xc8
[ 27.374495]driver_attach+0x28/0x30
[ 27.378712]bus_add_driver+0x100/0x1d4
[ 27.383188]driver_register+0x68/0xfc
[ 27.387579]__platform_driver_register+0x48/0x50
[ 27.392957]msm_drm_register+0x64/0x68
[ 27.397434]do_one_initcall+0x1ac/0x3e4
[ 27.402011]do_initcall_level+0xa0/0xb8
[ 27.406583]do_initcalls+0x58/0x94
[ 27.410704]do_basic_setup+0x28/0x30
[ 27.415008]kernel_init_freeable+0x190/0x1d0
[ 27.420024]kernel_init+0x18/0x10c
[ 27.424146]ret_from_fork+0x10/0x18
[ 27.428362]
[ 27.428362] -> #1 (&opp_table->lock){+.+.}-{3:3}:
[ 27.434725]lock_acquire+0x23c/0x30c
[ 27.439028]__mutex_lock_common+0xdc/0xbc4
[ 27.443862]mutex_lock_nested+0x50/0x58
[
Re: [PATCH] intel: Do not assert on unknown chips in drm_intel_decode_context_alloc
Quoting Tvrtko Ursulin (2020-11-18 16:36:01) > From: Tvrtko Ursulin > > There is this long standing nit of igt/tools/intel_error_decode asserting > when you feed it an error state from a GPU the local libdrm does not know > of. > > To fix this I need a tweak in drm_intel_decode_context_alloc to make it > not assert but just return NULL (which seems an already possible return > value). > > Signed-off-by: Tvrtko Ursulin Good riddance, Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 5.10-rc4
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote: > > I've got the 'splat' below during boot. > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > User space is Ubuntu 20.04. > > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. > I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus > [ 20.809891] WARNING: CPU: 0 PID: 973 at > drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 > [drm_vram_helper] > [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac > scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm > joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid > sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy > async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath > linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt > fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper > crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca > i2c_ismt i2c_algo_bit > [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 > 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b > 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 > [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 > [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: > c032d600 > [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: > 8b468f9acc00 > [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: > 8b46864ce288 > [ 20.952769] R10: R11: 0001 R12: > 8b468f47a000 > [ 20.959915] R13: R14: R15: > 8b468ad2bf00 > [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() > knlGS: > [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 > [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: > 001006f0 > [ 20.988047] Call Trace: > [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > [ 21.083167] do_syscall_64+0x38/0x90 > [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 21.091813] RIP: 0033:0x7f5b3cf1350b > [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 > c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 > [ 21.114154] RSP: 002b:7ffef1966588 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 21.121730] RAX: ffda RBX: 7ffef19665c0 RCX: > 7f5b3cf1350b > [ 21.128870] RDX: 7ffef19665c0 RSI: c02464bb RDI: > 0009 > [ 21.136013] RBP: c02464bb R08: 0040 R09: > 0004 > [ 21.143157] R10: 0002 R11: 0246 R12: > 561ec9d10060 > [ 21.150295] R13: 0009 R14: 561eca2cc9a0 R15: > 0040
Re: Linux 5.10-rc4
Hi
Am 18.11.20 um 19:10 schrieb Linus Torvalds:
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
I've got the 'splat' below during boot.
This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
User space is Ubuntu 20.04.
Additionally the X display has all the colours and alignment slightly
messed up.
5.9.0 was ok.
I'm just guessing the two issues are related.
Sounds likely. But it would be lovely if you could bisect when
exactly the problem(s) started to both verify that, and just to
pinpoint the exact change..
I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast:
Program display mode in CRTC's atomic_enable" which looks relevant in
that it's right in that call-chain.
Did some initialization perhaps get overlooked?
And Dave and Daniel and the drm list cc'd as well..
Full splat left quoted below for new people and list.
Linus
[ 20.809891] WARNING: CPU: 0 PID: 973 at
drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40
[drm_vram_helper]
That line is at [1], which comes from
46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4")
But the patch was merged in 5.9-rc1, so it's probably something else.
We've had a lot of TTM-related changes recently, so my best guess is
that it's something in TTM with BO initialization.
From some grepping, it looks like we have to call ttm_bo_mem_space() to
fill mm_node (i.e., the pointer that causes the warning). But I cannot
find where vram helpers do this. Maybe that's a good starting point.
I'm adding the TTM devs to cc.
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.10-rc4#n284
[ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac
scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm
joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs
blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear
ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper
crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca
i2c_ismt i2c_algo_bit
[ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78
[ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015
[ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
[ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87
80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d
c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06
[ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246
[ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: c032d600
[ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: 8b468f9acc00
[ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: 8b46864ce288
[ 20.952769] R10: R11: 0001 R12: 8b468f47a000
[ 20.959915] R13: R14: R15: 8b468ad2bf00
[ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0()
knlGS:
[ 20.975149] CS: 0010 DS: ES: CR0: 80050033
[ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: 001006f0
[ 20.988047] Call Trace:
[ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast]
[ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast]
[ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper]
[ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper]
[ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper]
[ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper]
[ 21.026269] drm_atomic_commit+0x4a/0x50 [drm]
[ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper]
[ 21.037384] __setplane_atomic+0xcc/0x110 [drm]
[ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm]
[ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm]
[ 21.052287] ? alloc_set_pte+0x10d/0x6d0
[ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm]
[ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm]
[ 21.070455] drm_ioctl+0x241/0x3f0 [drm]
[ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[ 21.079401] __x64_sys_ioctl+0x91/0xc0
[ 21.083167] do_syscall_64+0x38/0x90
[ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 21.091813] RIP: 0033:0x7f5b3cf1350b
[ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff
ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05
Re: [Freedreno] [PATCH] drm/msm/dpu: Remove chatty vbif debug print
Hi Stephen
On 2020-11-18 07:49, Rob Clark wrote:
On Tue, Nov 17, 2020 at 2:53 PM Stephen Boyd
wrote:
Quoting abhin...@codeaurora.org (2020-11-17 12:34:56)
> On 2020-11-17 09:26, Stephen Boyd wrote:
> > I don't know what this debug print is for but it is super chatty,
> > throwing 8 lines of debug prints in the logs every time we update a
> > plane. It looks like it has no value. Let's nuke it so we can get
> > better logs.
> >
> > Cc: Sean Paul
> > Cc: Abhinav Kumar
> > Signed-off-by: Stephen Boyd
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > index 5e8c3f3e6625..5eb2b2ee09f5 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
> > @@ -245,9 +245,6 @@ void dpu_vbif_set_qos_remap(struct dpu_kms
> > *dpu_kms,
> > forced_on = mdp->ops.setup_clk_force_ctrl(mdp, params->clk_ctrl,
> > true);
> >
> > for (i = 0; i < qos_tbl->npriority_lvl; i++) {
> > - DPU_DEBUG("vbif:%d xin:%d lvl:%d/%d\n",
> > - params->vbif_idx, params->xin_id, i,
> > - qos_tbl->priority_lvl[i]);
>
> Instead of getting rid of this print, we should optimize the caller of
> this.
Does the print tell us anything? Right now it prints 8 lines where it
feels like it could be trimmed down:
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:0/3
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:1/3
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:2/4
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:3/4
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:4/5
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:5/5
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:6/6
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 lvl:7/6
maybe one line that combines the index into values?
[drm:dpu_vbif_set_qos_remap] vbif:0 xin:0 [3 3 4 4 5 5 6 6]
or possibly convert to a tracepoint (so it doesn't spam the drm_trace
buffer)
BR,
-R
But again I have no idea if this print is really useful. Maybe we can
print it only if the value changes from what was already there?
Basically move the print into dpu_hw_set_qos_remap() and then skip out
early if nothing changed or print and modify the register.
> This is what
> we are doing in downstream. So we need to update the property only if we
> are switching from a RT client
> to non-RT client for the plane and vice-versa. So we should try to do
> the same thing here.
>
> is_rt = sde_crtc_is_rt_client(crtc, crtc->state);
> if (is_rt != psde->is_rt_pipe) {
> psde->is_rt_pipe = is_rt;
> pstate->dirty |= SDE_PLANE_DIRTY_QOS;
> }
>
>
> if (pstate->dirty & DPU_PLANE_DIRTY_QOS)
> _dpu_plane_set_qos_remap(plane);
>
Sounds great! Can you send the patch?
Will finalize approach and send the patch in a day or two.
Thanks
Abhinav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 1/2] dma-fence: allow signaling drivers to set fence timestamp
On Wed, Nov 18, 2020 at 9:28 PM wrote:
>
> On 2020-11-12 10:27, Veera Sundaram Sankaran wrote:
> > Some drivers have hardware capability to get the precise timestamp of
> > certain events based on which the fences are triggered. This allows it
> > to set accurate timestamp factoring out any software and IRQ latencies.
> > Move the timestamp parameter out of union in dma_fence struct to allow
> > signaling drivers to set it. If the parameter is not set, ktime_get is
> > used to set the current time to fence timestamp during
> > dma_fence_signal.
> >
>
> @Sumit Semwal / @Gustavo Padovan,
> Can you please help in reviewing this change as it falls in dma-fence
> files.
Please answer my question on the 2nd patch. This is new uabi
behaviour, we have a bunch of requirements for this kind of work:
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Thanks, Daniel
> Thanks,
> Veera
>
> > Signed-off-by: Veera Sundaram Sankaran
> > ---
> > drivers/dma-buf/dma-fence.c | 18 ++
> > include/linux/dma-fence.h | 15 +++
> > 2 files changed, 13 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 43624b4..7cef49a 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -4,6 +4,7 @@
> > *
> > * Copyright (C) 2012 Canonical Ltd
> > * Copyright (C) 2012 Texas Instruments
> > + * Copyright (c) 2020 The Linux Foundation. All rights reserved.
> > *
> > * Authors:
> > * Rob Clark
> > @@ -329,7 +330,6 @@ void __dma_fence_might_wait(void)
> > int dma_fence_signal_locked(struct dma_fence *fence)
> > {
> > struct dma_fence_cb *cur, *tmp;
> > - struct list_head cb_list;
> >
> > lockdep_assert_held(fence->lock);
> >
> > @@ -337,16 +337,18 @@ int dma_fence_signal_locked(struct dma_fence
> > *fence)
> > &fence->flags)))
> > return -EINVAL;
> >
> > - /* Stash the cb_list before replacing it with the timestamp */
> > - list_replace(&fence->cb_list, &cb_list);
> > -
> > - fence->timestamp = ktime_get();
> > + /* set current time, if not set by signaling driver */
> > + if (!fence->timestamp)
> > + fence->timestamp = ktime_get();
> > set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
> > trace_dma_fence_signaled(fence);
> >
> > - list_for_each_entry_safe(cur, tmp, &cb_list, node) {
> > - INIT_LIST_HEAD(&cur->node);
> > - cur->func(fence, cur);
> > + if (!list_empty(&fence->cb_list)) {
> > + list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> > + INIT_LIST_HEAD(&cur->node);
> > + cur->func(fence, cur);
> > + }
> > + INIT_LIST_HEAD(&fence->cb_list);
> > }
> >
> > return 0;
> > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> > index 09e23ad..a9eebaf 100644
> > --- a/include/linux/dma-fence.h
> > +++ b/include/linux/dma-fence.h
> > @@ -4,6 +4,7 @@
> > *
> > * Copyright (C) 2012 Canonical Ltd
> > * Copyright (C) 2012 Texas Instruments
> > + * Copyright (c) 2020 The Linux Foundation. All rights reserved.
> > *
> > * Authors:
> > * Rob Clark
> > @@ -70,26 +71,16 @@ struct dma_fence {
> >* release the fence it is unused. No one should be adding to the
> >* cb_list that they don't themselves hold a reference for.
> >*
> > - * The lifetime of the timestamp is similarly tied to both the
> > - * rcu freelist and the cb_list. The timestamp is only set upon
> > - * signaling while simultaneously notifying the cb_list. Ergo, we
> > - * only use either the cb_list of timestamp. Upon destruction,
> > - * neither are accessible, and so we can use the rcu. This means
> > - * that the cb_list is *only* valid until the signal bit is set,
> > - * and to read either you *must* hold a reference to the fence,
> > - * and not just the rcu_read_lock.
> > - *
> >* Listed in chronological order.
> >*/
> > union {
> > struct list_head cb_list;
> > - /* @cb_list replaced by @timestamp on dma_fence_signal() */
> > - ktime_t timestamp;
> > - /* @timestamp replaced by @rcu on dma_fence_release() */
> > + /* @cb_list replaced by @rcu on dma_fence_release() */
> > struct rcu_head rcu;
> > };
> > u64 context;
> > u64 seqno;
> > + ktime_t timestamp;
> > unsigned long flags;
> > struct kref refcount;
> > int error;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on next-20201117] [cannot apply to linus/master v5.10-rc4 v5.10-rc3 v5.10-rc2 v5.10-rc4] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit/20201117-220814 base:7c8ca8129ee9724cb1527895fe6dec942ef07f19 config: arm-allyesconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/78c57dc48dc2612e7a6a9d265622f3f459a92c56 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit/20201117-220814 git checkout 78c57dc48dc2612e7a6a9d265622f3f459a92c56 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arm-linux-gnueabi-ld: drivers/gpu/drm/ttm/ttm_bo.o: in function `ttm_bo_device_init': (.text+0x1bb0): undefined reference to `__aeabi_uldivmod' >> arm-linux-gnueabi-ld: (.text+0x1c1c): undefined reference to >> `__aeabi_uldivmod' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: make up to 90% of system memory available
On Wed, Nov 18, 2020 at 02:35:24PM +0100, Christian König wrote: > Am 17.11.20 um 18:19 schrieb Daniel Vetter: > > On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wrote: > > > Increase the ammount of system memory drivers can use to about 90% of > > > the total available. > > > > > > Signed-off-by: Christian König > > > --- > > > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > > > index a958135cb3fe..0a93df93dba4 100644 > > > --- a/drivers/gpu/drm/ttm/ttm_bo.c > > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > > > @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) > > >* the available system memory. > > >*/ > > > num_pages = (u64)si.totalram * si.mem_unit; > > > - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; > > > + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; > > I don't think this is the design we want. As long as it was set at "half > > of system memory" it was clear that a) it's a hack b) precision didn't > > matter. > > Yeah, I'm also wondering what to do here exactly. In generally I would > completely nuke that limit if possible. > > > But if you go to the limit and still want to keep the "we make sure > > there's no OOM", then precision starts to matter: > > - memory hotplug and hotunplug is a thing > > - userspace can mlock, and it's configureable > > - drivers can pin_user_pages for IO and random other stuff. Some of it is > >accounted as some subsystem specific mlock (like rdma does iirc), some > >is just yolo or short term enough (like) > > - none of what we do here takes into considerations any interactions with > >core mm tracking (like cgroups or numa or anything like that) > > OOM is perfectly fine with me, we should just not run into an OOM killer > situation because we call shmem_read_mapping_page_gfp() in the shrinker > callback. > > Any idea how we could guarantee that? Uh ... I just realized I missed something between how ttm works and how i915 works. With i915 directly using shmem, all we do in the shrinker is unpin the shmem pages. With ttm we have the page pool in the middle. And it's needed for dma coherent and other things. This is rather fundamental. btw I don't think you'll get OOM, you get lockdep splat because you're recusring on fs_reclaim fake lock. We should probably put a might_alloc() into shmem_read_mapping_page_gfp(). > > If we want to drop the "half of system ram" limit (and yes that makes > > sense) I think the right design is: > > > > - we give up on the "no OOM" guarantee. > > > > - This means if you want real isolation of tasks, we need cgroups, and we > >need to integrate ttm cgroups with system memory cgroups somehow. Unlike > >randomly picked hardcoded limits this should work a lot more reliably > >and be a lot more useful in practical use in the field. > > > > - This also means that drivers start to fail in interesting ways. I think > >locking headaches are covered with all the lockdep annotations I've > >pushed, plus some of the things I still have in-flight (I have a > >might_alloc() annotations somewhere). That leaves validation of error > >paths for when allocations fail. Ime a very effective way we used in > >i915 is (ab)using EINTR restarting, which per drmIoctl uapi spec is > >requried. We could put a debug mode into ttm_tt which randomly fails > >with -EINTR to make sure it's all working correctly (plus anything else > >that allocates memory), and unlike real out-of-memory injection piglit > >and any other cts will complete without failure. Which gives us an > >excellent metric for "does it work". Actualy OOM, even injected one, > >tends to make stuff blow up in a way that's very hard to track and make > >sure you've got good coverage, since all your usual tests die pretty > >quickly. > > > > - ttm_tt needs to play fair with every other system memory user. We need > >to register a shrinker for each ttm_tt (so usually one per device I > >guess), which walks the lru (in shrink_count) and uses dma_resv_trylock > >for actual shrinking. We probably want to move it to SYSTEM first for > >that shrinker to pick up, so that there's some global fairness across > >all ttm_tt. > > I already have patches for this. > > What's still missing is teaching the OOM killer which task is using the > memory since memory referenced through the file descriptors are currently > not accounted towards any process resources. Yeah I don't think we've fixed that problem for i915 either. It loves to kill randome other stuff. In igt we solve this by marking any igt testcase as "pls kill this first". Well "solve". > > - for GFP_DMA32 that means zone aware shrinkers. We've never used those, > >because thus far i915 didn't have any big need for low memory, so we > >haven't used this in p
Re: [PATCH 1/9] dt-binding: soc: xilinx: ai-engine: Add AI engine binding
On Wed, 18 Nov 2020 00:06:12 -0800, Wendy Liang wrote: > Xilinx AI engine array can be partitioned statically for different > applications. In the device tree, there will be device node for the AI > engine device, and device nodes for the statically configured AI engine > partitions. Each of the statically configured partition has a partition > ID in the system. > > Signed-off-by: Wendy Liang > --- > .../bindings/soc/xilinx/xlnx,ai-engine.yaml| 119 > + > 1 file changed, 119 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml:10:2: [warning] wrong indentation: expected 2 but found 1 (indentation) dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml: 'additionalProperties' is a required property /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml: ignoring, error in schema: warning: no schema found in file: ./Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml See https://patchwork.ozlabs.org/patch/1402008 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
