[PATCH] drm: re-add deleted doc for drm_gem_open_ioctl
Add back the removed documentation for drm_gem_open_ioctl. This patch is submitted in response to [1]. [1] https://lore.kernel.org/linux-arm-msm/20200728085244.GY6419@phenom.ffwll.local/ Signed-off-by: Steve Cohen --- drivers/gpu/drm/drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ee2058a..fe94122 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -871,6 +871,9 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, * @file_priv: drm file-private structure * * Open an object using the global name, returning a handle and the size. + * + * This handle (of course) holds a reference to the object, so the object + * will not go away until the handle is deleted. */ int drm_gem_open_ioctl(struct drm_device *dev, void *data, -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vt: Handle recursion in vc_do_resize().
syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
based on outdated old_{rows,row_size} values, for resize_screen() can
recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
old_{rows,row_size} values which were read before calling resize_screen().
Minimal fix might be to read vc->vc_{rows,size_row} after resize_screen().
A different fix might be to forbid recursive vc_do_resize() request.
I can't tell which fix is the better.
But since I guess that new_cols == vc->vc_cols && new_rows == vc->vc_rows
check could become true after returning from resize_screen(), and I assume
that not calling clear_selection() when resize_screen() will return error
is harmless, let's redo the check by moving resize_screen() earlier.
[1]
https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 42d8c67..952a067 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1217,7 +1217,24 @@ static int vc_do_resize(struct tty_struct *tty, struct
vc_data *vc,
if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
return 0;
+ if (new_screen_size > KMALLOC_MAX_SIZE || !new_screen_size)
+ return -EINVAL;
+ /*
+* Since fbcon_resize() from resize_screen() can recurse into
+* this function via fb_set_var(), handle recursion now.
+*/
+ err = resize_screen(vc, new_cols, new_rows, user);
+ if (err)
+ return err;
+ /* Reload values in case recursion changed vc->vc_{cols,rows}. */
+ new_cols = (cols ? cols : vc->vc_cols);
+ new_rows = (lines ? lines : vc->vc_rows);
+ new_row_size = new_cols << 1;
+ new_screen_size = new_row_size * new_rows;
+
+ if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
+ return 0;
if (new_screen_size > KMALLOC_MAX_SIZE || !new_screen_size)
return -EINVAL;
newscreen = kzalloc(new_screen_size, GFP_USER);
@@ -1238,13 +1255,6 @@ static int vc_do_resize(struct tty_struct *tty, struct
vc_data *vc,
old_rows = vc->vc_rows;
old_row_size = vc->vc_size_row;
- err = resize_screen(vc, new_cols, new_rows, user);
- if (err) {
- kfree(newscreen);
- vc_uniscr_free(new_uniscr);
- return err;
- }
-
vc->vc_rows = new_rows;
vc->vc_cols = new_cols;
vc->vc_size_row = new_row_size;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Fix soft lockup.
A soft deadlock occurs when call hrtimer_cancel in softirq context: a) The main frequency of the machine is very slow b) output->period_ns is very small, even only 1 ns The problem can be solved in the following way: Setting a hrtimer exit flag in the vkms_disable_vblank function and checking the flag in the vkms_vblank_simulate function. If the flag is set, the hrtimer is not added to hrtimer queue again,the hrtimer_cancel function can exit quickly without deadlock. watchdog: BUG: soft lockup - CPU#2 stuck for 134s! [syz-executor.2:18027] Modules linked in: CPU: 2 PID: 18027 Comm: syz-executor.2 Tainted: GW 5.8.0-rc2-csan #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 RIP: 0010:csd_lock_wait kernel/smp.c:108 [inline] RIP: 0010:smp_call_function_many_cond+0x40c/0x470 kernel/smp.c:555 RSP: 0018:c900028d3a88 EFLAGS: 0297 RAX: 0002 RBX: 888237cacc80 RCX: 813240fc RDX: 0001 RSI: RDI: 0005 RBP: 0001 R08: 8881f497d000 R09: R10: R11: 0100 R12: 888237cf6fc0 R13: 0003 R14: 888237cacc88 R15: 0001 FS: 7fa6314a9700() GS:888237c8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00513c80 CR3: 0001e3df3002 CR4: 000626e0 Call Trace: smp_call_function_many kernel/smp.c:577 [inline] smp_call_function+0x40/0x80 kernel/smp.c:599 on_each_cpu+0x2a/0xc0 kernel/smp.c:717 __purge_vmap_area_lazy+0x7c/0xbc0 mm/vmalloc.c:1367 _vm_unmap_aliases.part.0+0x126/0x180 mm/vmalloc.c:1800 _vm_unmap_aliases mm/vmalloc.c:1769 [inline] vm_unmap_aliases+0x2f/0x40 mm/vmalloc.c:1823 change_page_attr_set_clr+0x10a/0x4a0 arch/x86/mm/pat/set_memory.c:1732 change_page_attr_clear arch/x86/mm/pat/set_memory.c:1789 [inline] set_memory_ro+0x2b/0x40 arch/x86/mm/pat/set_memory.c:1935 bpf_jit_binary_lock_ro include/linux/filter.h:815 [inline] bpf_int_jit_compile+0x54f/0x663 arch/x86/net/bpf_jit_comp.c:1929 bpf_prog_select_runtime+0x1cc/0x2c0 kernel/bpf/core.c:1807 bpf_migrate_filter net/core/filter.c:1264 [inline] bpf_prepare_filter net/core/filter.c:1312 [inline] bpf_prepare_filter+0x518/0x620 net/core/filter.c:1278 __get_filter+0x107/0x160 net/core/filter.c:1481 sk_attach_filter+0x19/0xa0 net/core/filter.c:1496 sock_setsockopt+0x1208/0x1230 net/core/sock.c:1080 __sys_setsockopt+0x248/0x270 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2143 [inline] __se_sys_setsockopt net/socket.c:2140 [inline] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2140 do_syscall_64+0x48/0xb0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sending NMI from CPU 2 to CPUs 0-1,3-5: NMI backtrace for cpu 4 skipped: idling at native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:60 NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:60 NMI backtrace for cpu 1 NMI backtrace for cpu 3 CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW 5.8.0-rc2-csan #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline] RIP: 0010:preempt_count_sub+0xa/0x90 kernel/sched/core.c:3874 RSP: 0018:c912cdd0 EFLAGS: 0046 RAX: 0001 RBX: 88822ecb8fb0 RCX: RDX: RSI: 0086 RDI: 0001 RBP: 888237d5edc0 R08: 888236ddc000 R09: R10: R11: R12: R13: 0086 R14: 888237d5edc0 R15: 85bc6d60 FS: () GS:888237cc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f35cc47adb8 CR3: 05a23006 CR4: 000626e0 Call Trace: __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:161 [inline] _raw_spin_unlock_irqrestore+0x2f/0x50 kernel/locking/spinlock.c:191 unlock_hrtimer_base kernel/time/hrtimer.c:898 [inline] hrtimer_try_to_cancel kernel/time/hrtimer.c:1171 [inline] hrtimer_try_to_cancel+0xbd/0x1b0 kernel/time/hrtimer.c:1151 hrtimer_cancel+0x13/0x40 kernel/time/hrtimer.c:1278 __disable_vblank drivers/gpu/drm/drm_vblank.c:429 [inline] drm_vblank_disable_and_save+0x122/0x140 drivers/gpu/drm/drm_vblank.c:470 vblank_disable_fn+0x96/0xa0 drivers/gpu/drm/drm_vblank.c:487 call_timer_fn+0x3a/0x230 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x2b8/0x840 kernel/time/timer.c:1786 __do_softirq+0x118/0x344 kernel/softirq.c:292 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_
[PATCH 3/3] drm/panel: simple: Add Chefree CH101OLHLWH-002 panel
Add support for the Chefree CH101OLHLWH-002 10.1" (1280x800)
color TFT LCD panel, connected over LVDS.
Timings are taken from the datasheet version P0.5.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
drivers/gpu/drm/panel/panel-simple.c | 33
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 298e3a26d9ee..a8e1f6306923 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1414,6 +1414,36 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
},
};
+static const struct display_timing chefree_ch101olhlwh_002_timing = {
+ .pixelclock = { 6890, 7110, 7340 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 65, 80, 95 },
+ .hback_porch = { 64, 79, 94 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 7, 11, 14 },
+ .vback_porch = { 7, 11, 14 },
+ .vsync_len = { 1, 1, 1 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc chefree_ch101olhlwh_002 = {
+ .timings = &chefree_ch101olhlwh_002_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 135,
+ },
+ .delay = {
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -3845,6 +3875,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "cdtech,s070wv95-ct16",
.data = &cdtech_s070wv95_ct16,
+ }, {
+ .compatible = "chefree,ch101olhlwh-002",
+ .data = &chefree_ch101olhlwh_002,
}, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
PROBLEM: 5.8-rc7 no video output with nouveau on NV36 (regression)
Hi, After installing Linux 5.8-rc7 I seem to get no video output on my NV36 card once the nouveau module is loaded. The display (connected to the digital output) simply reports "No Signal". I bisected to the following commit, and reverting this commit on top of 5.8-rc7 appears to correct the issue. fa4f4c213f5f7807360c41f2501a3031a9940f3a is the first bad commit commit fa4f4c213f5f7807360c41f2501a3031a9940f3a Author: James Jones Date: Mon Feb 10 15:15:55 2020 -0800 drm/nouveau/kms: Support NVIDIA format modifiers Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind. The specified format modifier is validated against the list of modifiers supported by the target display hardware. v2: Used Tesla family instead of NV50 chipset compare v4: Do not cache kind, tile_mode in nouveau_framebuffer v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones Signed-off-by: Ben Skeggs drivers/gpu/drm/nouveau/dispnv50/wndw.c | 20 --- drivers/gpu/drm/nouveau/nouveau_display.c | 89 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 4 ++ 3 files changed, 104 insertions(+), 9 deletions(-) The dmesg output from loading the driver is identical except several lines are missing in the non-working case, which I have marked with "XXX" below: [ 168.222926] PCI Interrupt Link [LNKE] enabled at IRQ 16 [ 168.223199] nouveau :01:00.0: vgaarb: deactivate vga console [ 168.224379] Console: switching to colour dummy device 80x25 [ 168.224612] nouveau :01:00.0: NVIDIA NV36 (436200a1) [ 168.324779] nouveau :01:00.0: bios: version 04.36.20.21.00 [ 168.325646] agpgart-amd64 :00:00.0: AGP 3.0 bridge [ 168.325657] agpgart: modprobe tried to set rate=x12. Setting to AGP3 x8 mode. [ 168.325662] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode [ 168.325679] nouveau :01:00.0: putting AGP V3 device into 8x mode [ 168.325908] agpgart-amd64 :00:00.0: AGP 3.0 bridge [ 168.325914] agpgart: modprobe tried to set rate=x12. Setting to AGP3 x8 mode. [ 168.325918] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode [ 168.325933] nouveau :01:00.0: putting AGP V3 device into 8x mode [ 168.325990] nouveau :01:00.0: tmr: unknown input clock freq [ 168.326732] nouveau :01:00.0: fb: 256 MiB DDR1 [ 168.328174] [TTM] Zone kernel: Available graphics memory: 1022540 KiB [ 168.328175] [TTM] Initializing pool allocator [ 168.328181] [TTM] Initializing DMA pool allocator [ 168.328200] nouveau :01:00.0: DRM: VRAM: 255 MiB [ 168.328201] nouveau :01:00.0: DRM: GART: 128 MiB [ 168.328204] nouveau :01:00.0: DRM: BMP version 5.40 [ 168.328208] nouveau :01:00.0: DRM: DCB version 2.2 [ 168.328210] nouveau :01:00.0: DRM: DCB outp 00: 01000300 9c40 [ 168.328214] nouveau :01:00.0: DRM: DCB outp 01: 02010310 9c40 [ 168.328215] nouveau :01:00.0: DRM: DCB outp 02: 04000302 [ 168.328217] nouveau :01:00.0: DRM: DCB outp 03: 02020321 0303 [ 168.328495] nouveau :01:00.0: DRM: Loading NV17 power sequencing microcode [ 168.329691] nouveau :01:00.0: DRM: MM: using M2MF for buffer copies [ 168.330258] nouveau :01:00.0: DRM: Saving VGA fonts [ 168.389460] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 168.391250] nouveau :01:00.0: DRM: Setting dpms mode 3 on TV encoder (output 3) XXX [ 168.487647] nouveau :01:00.0: DRM: allocated 1920x1080 fb: 0x9000, bo ff426de1 XXX [ 168.491835] fbcon: nouveaudrmfb (fb0) is primary device XXX [ 168.608512] nouveau :01:00.0: DRM: 0xE4FB: Parsing digital output script table XXX [ 168.662451] Console: switching to colour frame buffer device 240x67 XXX [ 168.755987] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer device [ 168.763736] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 Let me know if you need any more info. Cheers, Nick ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Small cleanups to ingenic-drm driver
Le mer. 29 juil. 2020 à 0:00, dan...@ffwll.ch a écrit : On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote: Hi Paul. On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote: > Here are a few cleanups to the ingenic-drm driver. > - some error paths were missing and have been added; > - the mode validation has been moved to the .mode_valid helper callback. > > Cheers, > -Paul > > Paul Cercueil (2): > drm/ingenic: Handle errors of drm_atomic_get_plane_state > drm/ingenic: Validate mode in a .mode_valid callback Both looks fine, you can add my: Reviewed-by: Sam Ravnborg I assume you will apply the patches. Maybe wait for Daniel to take a look, he had some feedback on where to add checks. I assume this is covered by the second patch. Yeah changelog for new versions would be great, but aside from that bickering patch 2 lgtm now. This patchset is V1, I'm fixing issues you saw in the ingenic-drm driver when reviewing a different patchset. Thanks for the review, I'll apply now. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
> While looking into adding atomic-pwm support to the pwm-crc driver I
> noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
> there is a clock-divider which divides this with a value between 1-128,
> and there are 256 duty-cycle steps.
>
> The pwm-crc code before this commit assumed that a clock-divider
> setting of 1 means that the PWM output is running at 6 MHZ, if that
> is true, where do these 256 duty-cycle steps come from?
>
> This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
> seems unlikely for a PMIC which is using a silicon process optimized for
> power-switching transistors. It is way more likely that there is an 8
> bit counter for the duty cycle which acts as an extra fixed divider
> wrt the PWM output frequency.
>
> The main user of the pwm-crc driver is the i915 GPU driver which uses it
> for backlight control. Lets compare the PWM register values set by the
> video-BIOS (the GOP), assuming the extra fixed divider is present versus
> the PWM frequency specified in the Video-BIOS-Tables:
>
> Device: PWM Hz set by BIOS PWM Hz specified in VBT
> Asus T100TA 200 200
> Asus T100HA 200 200
> Lenovo Miix 2 8 23437 2
> Toshiba WT8-A 23437 2
>
> So as we can see if we assume the extra division by 256 then the register
> values set by the GOP are an exact match for the VBT values, where as
> otherwise the values would be of by a factor of 256.
>
> This commit fixes the period / duty_cycle calculations to take the
> extra division by 256 into account.
So, base clock is 6MHz, then 7 bit divisor. That's what original values
were for. On top of that there is 8-bit duty cycle control ("divide by 256"
whatever it means) with the output range 23.437kHz..183Hz.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
> ---
> drivers/pwm/pwm-crc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> index 272eeb071147..c056eb9b858c 100644
> --- a/drivers/pwm/pwm-crc.c
> +++ b/drivers/pwm/pwm-crc.c
> @@ -21,8 +21,8 @@
>
> #define PWM_MAX_LEVEL0xFF
>
> -#define PWM_BASE_CLK 600 /* 6 MHz */
> -#define PWM_MAX_PERIOD_NS21333/* 46.875KHz */
> +#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
> +#define PWM_MAX_PERIOD_NS5461333 /* 183 Hz */
>
> /**
> * struct crystalcove_pwm - Crystal Cove PWM controller
> @@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct
> pwm_device *pwm,
>
> /* changing the clk divisor, need to disable fisrt */
> crc_pwm_disable(c, pwm);
> - clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
> + clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
>
> regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
> clk_div | PWM_OUTPUT_ENABLE);
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PROBLEM: 5.8-rc7 no video output with nouveau on NV36 (regression)
On 2020-07-29, Dave Airlie wrote: > On Wed, 29 Jul 2020 at 15:05, Nick Bowler wrote: >> >> Hi, >> >> After installing Linux 5.8-rc7 I seem to get no video output on my >> NV36 card once the nouveau module is loaded. The display (connected >> to the digital output) simply reports "No Signal". >> >> I bisected to the following commit, and reverting this commit on >> top of 5.8-rc7 appears to correct the issue. > > Can you test the drm fixes pull I just sent to Linus > > https://patchwork.freedesktop.org/patch/381225/ Yes, pulling this seems to fix things. Thanks, Nick ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Compiler leaves a 4-byte hole near the end of `dev_info`, causing
amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
when `size` is greater than 356.
In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
unfortunately does not initialize that 4-byte hole. Fix it by using
memset() instead.
Cc: sta...@vger.kernel.org
Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Suggested-by: Dan Carpenter
Signed-off-by: Peilin Ye
---
$ pahole -C "drm_amdgpu_info_device" drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
struct drm_amdgpu_info_device {
__u32 device_id;/* 0 4 */
__u32 chip_rev; /* 4 4 */
__u32 external_rev; /* 8 4 */
__u32 pci_rev; /*12 4 */
__u32 family; /*16 4 */
__u32 num_shader_engines; /*20 4 */
__u32 num_shader_arrays_per_engine; /*24 4
*/
__u32 gpu_counter_freq; /*28 4 */
__u64 max_engine_clock; /*32 8 */
__u64 max_memory_clock; /*40 8 */
__u32 cu_active_number; /*48 4 */
__u32 cu_ao_mask; /*52 4 */
__u32 cu_bitmap[4][4]; /*5664 */
/* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
__u32 enabled_rb_pipes_mask; /* 120 4 */
__u32 num_rb_pipes; /* 124 4 */
/* --- cacheline 2 boundary (128 bytes) --- */
__u32 num_hw_gfx_contexts; /* 128 4 */
__u32 _pad; /* 132 4 */
__u64 ids_flags;/* 136 8 */
__u64 virtual_address_offset; /* 144 8 */
__u64 virtual_address_max; /* 152 8 */
__u32 virtual_address_alignment; /* 160 4 */
__u32 pte_fragment_size;/* 164 4 */
__u32 gart_page_size; /* 168 4 */
__u32 ce_ram_size; /* 172 4 */
__u32 vram_type;/* 176 4 */
__u32 vram_bit_width; /* 180 4 */
__u32 vce_harvest_config; /* 184 4 */
__u32 gc_double_offchip_lds_buf; /* 188 4 */
/* --- cacheline 3 boundary (192 bytes) --- */
__u64 prim_buf_gpu_addr;/* 192 8 */
__u64 pos_buf_gpu_addr; /* 200 8 */
__u64 cntl_sb_buf_gpu_addr; /* 208 8 */
__u64 param_buf_gpu_addr; /* 216 8 */
__u32 prim_buf_size;/* 224 4 */
__u32 pos_buf_size; /* 228 4 */
__u32 cntl_sb_buf_size; /* 232 4 */
__u32 param_buf_size; /* 236 4 */
__u32 wave_front_size; /* 240 4 */
__u32 num_shader_visible_vgprs; /* 244 4 */
__u32 num_cu_per_sh;/* 248 4 */
__u32 num_tcc_blocks; /* 252 4 */
/* --- cacheline 4 boundary (256 bytes) --- */
__u32 gs_vgt_table_depth; /* 256 4 */
__u32 gs_prim_buffer_depth; /* 260 4 */
__u32 max_gs_waves_per_vgt; /* 264 4 */
__u32 _pad1;/* 268 4 */
__u32 cu_ao_bitmap[4][4]; /* 27264 */
/* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */
__u64 high_va_offset; /* 336 8 */
__u64 high_va_max; /* 344 8 */
__u32 pa_sc_tile_steering_override; /* 352 4
*/
/* XXX 4 bytes hole, try to pack */
__u64 tcc_disabled_mask;/* 360 8 */
/* size: 368, cachelines: 6, members: 49 */
/* sum members: 364, holes: 1, sum holes: 4 */
/* last cacheline: 48 bytes */
};
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
[PATCH 2/3] dt-bindings: Add DT bindings for Chefree CH101OLHLWH-002
Add DT bindings for Chefree CH101OLHLWH-002 10.1" 1280x800 LCD. This panel is connected via LVDS. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 5a0af2b80aba..47247ace86ac 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -87,6 +87,8 @@ properties: - cdtech,s070swv29hg-dc44 # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel - cdtech,s070wv95-ct16 +# Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel + - chefree,ch101olhlwh-002 # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel - chunghwa,claa070wp03xg # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: Add vendor prefix for Chefree
The Chefree Technology Corp. is an LCD panel manufacturer. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- 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 5b1343a8d198..7204e069d498 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -197,6 +197,8 @@ patternProperties: description: Ceva, Inc. "^checkpoint,.*": description: Check Point Software Technologies Ltd. + "^chefree,.*": +description: Chefree Technology Corp. "^chipidea,.*": description: Chipidea, Inc "^chipone,.*": -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jul 27 (drivers/gpu/drm/xlnx/zynqmp-dpsub)
On 7/28/20 3:32 PM, Laurent Pinchart wrote: > Hi Randy, > > (adding a few people to the CC list to discuss the proposed solution > below) > > Thanks for the report. > > On Mon, Jul 27, 2020 at 05:49:41PM -0700, Randy Dunlap wrote: >> On 7/27/20 6:23 AM, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20200724: >> >> on x86_64: >> >> WARNING: unmet direct dependencies detected for DMA_ENGINE >> Depends on [n]: DMADEVICES [=n] >> Selected by [m]: >> - DRM_ZYNQMP_DPSUB [=m] && HAS_IOMEM [=y] && (ARCH_ZYNQMP || COMPILE_TEST >> [=y]) && COMMON_CLK [=y] && DRM [=m] && OF [=y] >> >> and about 45 "undefined reference" build errors (here's a sample): >> >> ld: drivers/misc/mic/scif/scif_dma.o: in function >> `scif_sync_dma.constprop.11': >> scif_dma.c:(.text+0x672): undefined reference to `dma_sync_wait' >> ld: drivers/spi/spi-bcm2835.o: in function `bcm2835_dma_release.isra.9': >> spi-bcm2835.c:(.text+0xb34): undefined reference to `dma_release_channel' >> ld: spi-bcm2835.c:(.text+0xc17): undefined reference to `dma_release_channel' >> ld: drivers/spi/spi-bcm2835.o: in function `bcm2835_dma_init': >> spi-bcm2835.c:(.text+0xd3c): undefined reference to `dma_request_chan' >> ld: spi-bcm2835.c:(.text+0xd8b): undefined reference to `dma_request_chan' >> ld: spi-bcm2835.c:(.text+0xf8a): undefined reference to `dma_get_slave_caps' >> ld: spi-bcm2835.c:(.text+0x11d0): undefined reference to `dma_get_slave_caps' >> ld: drivers/spi/spi-ep93xx.o: in function `ep93xx_spi_release_dma': >> spi-ep93xx.c:(.text+0x1fc): undefined reference to `dma_release_channel' >> ld: spi-ep93xx.c:(.text+0x220): undefined reference to `dma_release_channel' >> ERROR: modpost: "dma_release_channel" [drivers/gpu/drm/xlnx/zynqmp-dpsub.ko] >> undefined! >> >> >> >> I tried adding >> depends on DMADEVICES >> to DRM_ZYNQMP_DPSUB >> >> but that just gets into messy/ugly Kconfig >> error: recursive dependency detected! > > drivers/i2c/Kconfig:8:error: recursive dependency detected! > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on > DRM_KMS_HELPER > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by > DRM_ZYNQMP_DPSUB > drivers/gpu/drm/xlnx/Kconfig:1: symbol DRM_ZYNQMP_DPSUB depends on DMA_ENGINE > drivers/dma/Kconfig:44: symbol DMA_ENGINE depends on DMADEVICES > drivers/dma/Kconfig:6: symbol DMADEVICES is selected by SND_SOC_SH4_SIU > sound/soc/sh/Kconfig:30:symbol SND_SOC_SH4_SIU is selected by > SND_SIU_MIGOR > sound/soc/sh/Kconfig:60:symbol SND_SIU_MIGOR depends on I2C > For a resolution refer to Documentation/kbuild/kconfig-language.rst > subsection "Kconfig recursive dependency limitations" > >> BTW, adding >> select DMADEVICES >> is not a good solution. We try very hard not to enable entire >> subsystems with one driver "select". (No doubt you can find a >> few examples that do just that, but it is strongly discouraged.) > > If this isn't allowed, then we need to fix this where used, as that's > what seems to cause the recursive dependency. Would the following > patches be acceptable in your opinion ? If so I'll submit them proper. Yes, they look like they do the right thing and I tested them. Acked-by: Randy Dunlap Thanks for doing this. > commit 410e29afd54fd23ee94cd1842b51b7a9e2f96cd8 > Author: Laurent Pinchart > Date: Wed Jul 29 01:19:40 2020 +0300 > > treewide: kconfig: Replace 'select' DMAENGINES 'with depends on' > > Enabling a whole subsystem from a single driver 'select' is frowned > upon and won't be accepted in new drivers, that need to use 'depends on' > instead. Existing selection of DMAENGINES will then cause circular > dependencies. Replace them with a dependency. > > Signed-off-by: Laurent Pinchart > > diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig > index e4c422d806be..b9f8514909bf 100644 > --- a/drivers/rapidio/Kconfig > +++ b/drivers/rapidio/Kconfig > @@ -37,7 +37,7 @@ config RAPIDIO_ENABLE_RX_TX_PORTS > config RAPIDIO_DMA_ENGINE > bool "DMA Engine support for RapidIO" > depends on RAPIDIO > - select DMADEVICES > + depends on DMADEVICES > select DMA_ENGINE > help > Say Y here if you want to use DMA Engine frameork for RapidIO data > diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig > index dc20f0f7080a..ef8a29b9f641 100644 > --- a/sound/soc/sh/Kconfig > +++ b/sound/soc/sh/Kconfig > @@ -30,8 +30,8 @@ config SND_SOC_SH4_FSI > config SND_SOC_SH4_SIU > tristate > depends on ARCH_SHMOBILE && HAVE_CLK > + depends on DMADEVICES > select DMA_ENGINE > - select DMADEVICES > select SH_DMAE > select FW_LOADER > > commit 3e68c8fc7a2f3f7992c7fa8b30108d3831c7fb3b > Author: Laurent Pinchart > Date: W
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #107 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) --- Everyone seeing this, it’d be great, if you tested [PATCH] drm/amd/display: Clear dm_state for fast updates and reported any noticeable performance regressions. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
On Wed, 29 Jul 2020 at 16:21, Dave Airlie wrote: > > On Fri, 24 Jul 2020 at 16:43, Thomas Zimmermann wrote: > > > > > > > > Am 23.07.20 um 17:17 schrieb Christian König: > > > Instead of repeating that in each driver. > > > > > > Signed-off-by: Christian König > > > > Reviewed-by: Thomas Zimmermann > > I'm not sure what happened but the patchwork copies of this series are > mangled badly, I expect AMD email with the crappy headers or something > got in there somewhere. > > Can we get them in drm-misc-next at some point so I can cleanly look at them. Oh it looks like they are there already, I'm not sure why I'm having trouble applying the next set. will dig a bit more. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
On Fri, 24 Jul 2020 at 16:43, Thomas Zimmermann wrote: > > > > Am 23.07.20 um 17:17 schrieb Christian König: > > Instead of repeating that in each driver. > > > > Signed-off-by: Christian König > > Reviewed-by: Thomas Zimmermann I'm not sure what happened but the patchwork copies of this series are mangled badly, I expect AMD email with the crappy headers or something got in there somewhere. Can we get them in drm-misc-next at some point so I can cleanly look at them. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/ttm] Memory corruption problem when ttm_tt_init() fails.
On Wed, 15 Jul 2020 at 17:00, Tetsuo Handa wrote: > > On 2020/07/14 18:13, Gu Jinxiang wrote: > > I've encountered [BUG: unable to handle kernel NULL pointer dereference at] > > which has call stack like your pattern2. > > And before this happended, I got a lot of memory allocation failure > > warnings. > > And my kernel is 3.10.0-327.62.1.el7.x86_64. > > > > Since, you mentioned it may be a bug of drm/tmm. So, I checked drm/ttm for > > possible patch to fix this problem, but found nothing. > > Could you please tell me is there any progress of this problem that you > > detected. > > I'm not aware of any progress on https://patchwork.kernel.org/patch/5681611/ . Just found this email, I've hopefully fix this issue in my drm-next tree with https://patchwork.freedesktop.org/patch/380782/ Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst: Add ddc i2c device links for DP MST connectors
As of commit d8bd15b37d32 ("drm/dp_mst: Fix the DDC I2C device
registration of an MST port"), DP MST DDC I2C devices are consistently
parented to the underlying DRM device, making it challenging to
associate the ddc i2c device with its connector from userspace.
Given the need for further refactoring before the i2c devices can be
parented to their connectors, in the meantime follow the pattern of
commit e1a29c6c5955 ("drm: Add ddc link in sysfs created by
drm_connector"), creating sysfs ddc links to the associated i2c device
for MST DP connectors.
If the connector is created and registered before the i2c device, create
the link when registering the i2c device; otherwise, create the link
during late connector registration.
Signed-off-by: Sam McNally
---
drivers/gpu/drm/drm_dp_mst_topology.c | 29 +--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1ac874e4e7a1..73a2299c2faa 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2161,11 +2161,23 @@ static void build_mst_prop_path(const struct
drm_dp_mst_branch *mstb,
int drm_dp_mst_connector_late_register(struct drm_connector *connector,
struct drm_dp_mst_port *port)
{
+ int ret;
DRM_DEBUG_KMS("registering %s remote bus for %s\n",
port->aux.name, connector->kdev->kobj.name);
port->aux.dev = connector->kdev;
- return drm_dp_aux_register_devnode(&port->aux);
+ ret = drm_dp_aux_register_devnode(&port->aux);
+ if (ret)
+ return ret;
+
+ if (port->pdt != DP_PEER_DEVICE_NONE &&
+ drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
+ ret = sysfs_create_link(&port->connector->kdev->kobj,
+ &port->aux.ddc.dev.kobj, "ddc");
+ if (ret)
+ drm_dp_aux_unregister_devnode(&port->aux);
+ }
+ return ret;
}
EXPORT_SYMBOL(drm_dp_mst_connector_late_register);
@@ -5490,6 +5502,7 @@ static int drm_dp_mst_register_i2c_bus(struct
drm_dp_mst_port *port)
{
struct drm_dp_aux *aux = &port->aux;
struct device *parent_dev = port->mgr->dev->dev;
+ int ret;
aux->ddc.algo = &drm_dp_mst_i2c_algo;
aux->ddc.algo_data = aux;
@@ -5504,7 +5517,17 @@ static int drm_dp_mst_register_i2c_bus(struct
drm_dp_mst_port *port)
strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(parent_dev),
sizeof(aux->ddc.name));
- return i2c_add_adapter(&aux->ddc);
+ ret = i2c_add_adapter(&aux->ddc);
+ if (ret)
+ return ret;
+
+ if (port->connector && port->connector->kdev) {
+ ret = sysfs_create_link(&port->connector->kdev->kobj,
+ &port->aux.ddc.dev.kobj, "ddc");
+ if (ret)
+ i2c_del_adapter(&port->aux.ddc);
+ }
+ return ret;
}
/**
@@ -5513,6 +5536,8 @@ static int drm_dp_mst_register_i2c_bus(struct
drm_dp_mst_port *port)
*/
static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port)
{
+ if (port->connector && port->connector->kdev)
+ sysfs_remove_link(&port->connector->kdev->kobj, "ddc");
i2c_del_adapter(&port->aux.ddc);
}
--
2.28.0.rc0.142.g3c755180ce-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
On Wed, 29 Jul 2020 at 06:33, Ruhl, Michael J
wrote:
> >-Original Message-
> >From: Ben Skeggs
> >Sent: Tuesday, July 28, 2020 4:16 PM
> >To: Ruhl, Michael J
> >Cc: Dave Airlie ; dri-devel@lists.freedesktop.org;
> >bske...@redhat.com
> >Subject: Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
> >
> >On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J
> >wrote:
> >>
> >> >-Original Message-
> >> >From: dri-devel On Behalf Of
> >> >Dave Airlie
> >> >Sent: Monday, July 27, 2020 11:26 PM
> >> >To: dri-devel@lists.freedesktop.org
> >> >Cc: bske...@redhat.com
> >> >Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
> >> >
> >> >From: Dave Airlie
> >> >
> >> >Instead of rolling driver copies of them.
> >> >
> >> >v2: cleanup return handling (Ben)
> >> >Signed-off-by: Dave Airlie
> >> >---
> >> > drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++--
> >> > 1 file changed, 2 insertions(+), 36 deletions(-)
> >> >
> >> >diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >> >b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >> >index 7806278dce57..6ef5085c9a91 100644
> >> >--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >> >+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >> >@@ -1231,8 +1231,6 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
> >> >struct ttm_operation_ctx *ctx)
> >> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
> >> > struct nouveau_drm *drm;
> >> > struct device *dev;
> >> >- unsigned i;
> >> >- int r;
> >> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> >> >
> >> > if (ttm->state != tt_unpopulated)
> >> >@@ -1260,31 +1258,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
> >> >struct ttm_operation_ctx *ctx)
> >> > return ttm_dma_populate((void *)ttm, dev, ctx);
> >> > }
> >> > #endif
> >> >-
> >> >- r = ttm_pool_populate(ttm, ctx);
> >> >- if (r) {
> >> >- return r;
> >> >- }
> >> >-
> >> >- for (i = 0; i < ttm->num_pages; i++) {
> >> >- dma_addr_t addr;
> >> >-
> >> >- addr = dma_map_page(dev, ttm->pages[i], 0, PAGE_SIZE,
> >> >- DMA_BIDIRECTIONAL);
> >> >-
> >> >- if (dma_mapping_error(dev, addr)) {
> >> >- while (i--) {
> >> >- dma_unmap_page(dev, ttm_dma-
> >> >>dma_address[i],
> >> >- PAGE_SIZE,
> >> >DMA_BIDIRECTIONAL);
> >> >- ttm_dma->dma_address[i] = 0;
> >> >- }
> >> >- ttm_pool_unpopulate(ttm);
> >> >- return -EFAULT;
> >> >- }
> >> >-
> >> >- ttm_dma->dma_address[i] = addr;
> >> >- }
> >> >- return 0;
> >> >+ return ttm_populate_and_map_pages(dev, ttm_dma, ctx);
> >>
> >> This is not a completely straight code replacement.
> >>
> >> ttm_populate_and_map_pages() also has code to deal with pages that are
> >> contiguous (consolidates them).
> >>
> >> Is it possible that the nouveau HW can't handle a contiguous buffer
> larger
> >> than PAG_SIZE?
> >I think it's fine. The function appears to consolidate the pages for
> >the dma_map_page() call, but otherwise leave dma_address[] in
> >PAGE_SIZE chunks, I don't believe anything else in the driver will
> >care.
>
> Ahh.. I misread it. This is limiting the calls to dma_map_page().
> Instead
> of calling it for each page, just do it for the first one...
>
> Thanks for setting me straight. 😊
>
> Reviewed-by: Michael J. Ruhl
>
Thanks for the review! I've got the patch in my tree.
Ben.
>
> Mike
>
>
> >Ben.
> >
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >> > }
> >> >
> >> > static void
> >> >@@ -1293,7 +1267,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> >> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
> >> > struct nouveau_drm *drm;
> >> > struct device *dev;
> >> >- unsigned i;
> >> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> >> >
> >> > if (slave)
> >> >@@ -1316,14 +1289,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt
> >*ttm)
> >> > }
> >> > #endif
> >> >
> >> >- for (i = 0; i < ttm->num_pages; i++) {
> >> >- if (ttm_dma->dma_address[i]) {
> >> >- dma_unmap_page(dev, ttm_dma->dma_address[i],
> >> >PAGE_SIZE,
> >> >- DMA_BIDIRECTIONAL);
> >> >- }
> >> >- }
> >> >-
> >> >- ttm_pool_unpopulate(ttm);
> >> >+ ttm_unmap_and_unpopulate_pages(dev, ttm_dma);
> >> > }
> >> >
> >> > void
> >> >--
> >> >2.26.2
> >> >
> >> >___
> >> >dri-devel mailing list
> >> >dri-devel@lists.freedesktop.org
> >> >https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/li
[RFC][PATCH 2/2] dma-heap: Add a system-uncached heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we have no such flag, and by default the
current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
This does have a few "ugly" bits that were required to get
the buffer properly flushed out initially which I'd like to
improve. So feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/Kconfig| 10 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_uncached_heap.c | 392 +++
3 files changed, 403 insertions(+)
create mode 100644 drivers/dma-buf/heaps/system_uncached_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..420b0ed0a512 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -5,6 +5,16 @@ config DMABUF_HEAPS_SYSTEM
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+config DMABUF_HEAPS_SYSTEM_UNCACHED
+ bool "DMA-BUF Uncached System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the uncached system dmabuf heap. This
+ heap is backed by pages from the buddy allocator, but pages are setup
+ for write combining. This avoids cache management overhead, and can
+ be faster if pages are mostly untouched by the cpu. If in doubt,
+ say Y.
+
config DMABUF_HEAPS_CMA
bool "DMA-BUF CMA Heap"
depends on DMABUF_HEAPS && DMA_CMA
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..085685ec478f 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM_UNCACHED) += system_uncached_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/system_uncached_heap.c
b/drivers/dma-buf/heaps/system_uncached_heap.c
new file mode 100644
index ..d23908038376
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_uncached_heap.c
@@ -0,0 +1,392 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Uncached System DMA-Heap exporter
+ *
+ * Copyright (C) 2020 Linaro Ltd.
+ *
+ * Based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct uncached_heap {
+ struct dma_heap *heap;
+};
+
+struct uncached_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ memcpy(new_sg, sg, sizeof(*sg));
+ new_sg->dma_address = 0;
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int dma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct uncached_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+
[RFC][PATCH 1/2] dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(&heap_list_lock);
list_add(&heap->list, &heap_list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PROBLEM: 5.8-rc7 no video output with nouveau on NV36 (regression)
On Wed, 29 Jul 2020 at 15:05, Nick Bowler wrote: > > Hi, > > After installing Linux 5.8-rc7 I seem to get no video output on my > NV36 card once the nouveau module is loaded. The display (connected > to the digital output) simply reports "No Signal". > > I bisected to the following commit, and reverting this commit on > top of 5.8-rc7 appears to correct the issue. Can you test the drm fixes pull I just sent to Linus https://patchwork.freedesktop.org/patch/381225/ Otherwise we are awaiting a fix from James for one other issue, should be here today/tomorrow. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.8-rc8
Hi Linus, I'm sending this out a bit early, just to give you a chance to reject it or help decide on an rc8. The nouveau fixes missed the last pull by a few hours, and we had a few arm driver/panel/bridge fixes come in. This is possibly a bit more than I'm comfortable sending at this stage, but I've looked at each patch, the core + nouveau patches fix regressions, and the arm related ones are all around screens turning on and working, and are mostly trivial patches, the line count is mostly in comments. If you feel this is too much I'm happy to respin with the core/drm_fb_helper and nouveau fixes. we have one outstanding nouveau regression fix, that I'll follow this up with in the next day or so once Ben and James get it reviewed. Dave. This is possibly a bit drm-fixes-2020-07-29: drm fixes for 5.8-rc8 core: - fix possible use-after-free drm_fb_helper: - regression fix to use memcpy_io on bochs' sparc64 nouveau: - format modifiers fixes - HDA regression fix - turing modesetting race fix of: - fix a double free dbi: - fix SPI Type 1 transfer mcde: - fix screen stability crash panel: - panel: fix display noise on auo,kd101n80-45na - panel: delay HPD checks for boe_nv133fhm_n61 bridge: - bridge: drop connector check in nwl-dsi bridge - bridge: set proper bridge type for adv7511 The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-29 for you to fetch changes up to a4a2739beb8933a19281bca077fdb852598803ed: Merge tag 'drm-misc-fixes-2020-07-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-07-29 12:46:58 +1000) drm fixes for 5.8-rc8 core: - fix possible use-after-free drm_fb_helper: - regression fix to use memcpy_io on bochs' sparc64 nouveau: - format modifiers fixes - HDA regression fix - turing modesetting race fix of: - fix a double free dbi: - fix SPI Type 1 transfer mcde: - fix screen stability crash panel: - panel: fix display noise on auo,kd101n80-45na - panel: delay HPD checks for boe_nv133fhm_n61 bridge: - bridge: drop connector check in nwl-dsi bridge - bridge: set proper bridge type for adv7511 Ben Skeggs (5): drm/nouveau/disp/gm200-: fix regression from HDA SOR selection changes drm/nouveau/kms/gf100: use correct format modifiers drm/nouveau/kms/tu102: wait for core update to complete when assigning windows drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure Biju Das (1): drm: of: Fix double-free bug Dave Airlie (2): Merge branch 'linux-5.8' of git://github.com/skeggsb/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-07-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Douglas Anderson (1): drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms Guido Günther (1): drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check. Jitao Shi (1): drm/panel: Fix auo, kd101n80-45na horizontal noise on edges of panel Laurentiu Palcu (1): drm/bridge/adv7511: set the bridge type properly Linus Walleij (1): drm/mcde: Fix stability issue Paul Cercueil (1): drm/dbi: Fix SPI Type 1 (9-bit) transfer Sam Ravnborg (1): drm/drm_fb_helper: fix fbdev with sparc64 Steve Cohen (1): drm: hold gem reference until object is no longer accessed drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 1 + drivers/gpu/drm/bridge/nwl-dsi.c| 5 - drivers/gpu/drm/drm_fb_helper.c | 6 - drivers/gpu/drm/drm_gem.c | 10 - drivers/gpu/drm/drm_mipi_dbi.c | 2 +- drivers/gpu/drm/drm_of.c| 4 +--- drivers/gpu/drm/mcde/mcde_display.c | 11 ++--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 30 + drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 ++--- drivers/gpu/drm/panel/panel-simple.c| 16 - include/drm/drm_mode_config.h | 12 ++ 14 files changed, 76 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers
On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote:
>
> On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
> >
> > On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> > >>
> > >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> > >> family of modifiers to handle broken userspace
> > >> Xorg modesetting and Mesa drivers. Existing Mesa
> > >> drivers are still aware of only these older
> > >> format modifiers which do not differentiate
> > >> between different variations of the block linear
> > >> layout. When the format modifier support flag was
> > >> flipped in the nouveau kernel driver, the X.org
> > >> modesetting driver began attempting to use its
> > >> format modifier-enabled framebuffer path. Because
> > >> the set of format modifiers advertised by the
> > >> kernel prior to this change do not intersect with
> > >> the set of format modifiers advertised by Mesa,
> > >> allocating GBM buffers using format modifiers
> > >> fails and the modesetting driver falls back to
> > >> non-modifier allocation. However, it still later
> > >> queries the modifier of the GBM buffer when
> > >> creating its DRM-KMS framebuffer object, receives
> > >> the old-format modifier from Mesa, and attempts
> > >> to create a framebuffer with it. Since the kernel
> > >> is still not aware of these formats, this fails.
> > >>
> > >> Userspace should not be attempting to query format
> > >> modifiers of GBM buffers allocated with a non-
> > >> format-modifier-aware allocation path, but to
> > >> avoid breaking existing userspace behavior, this
> > >> change accepts the old-style format modifiers when
> > >> creating framebuffers and applying them to planes
> > >> by translating them to the equivalent new-style
> > >> modifier. To accomplish this, some layout
> > >> parameters must be assumed to match properties of
> > >> the device targeted by the relevant ioctls. To
> > >> avoid perpetuating misuse of the old-style
> > >> modifiers, this change does not advertise support
> > >> for them. Doing so would imply compatibility
> > >> between devices with incompatible memory layouts.
> > >>
> > >> Tested with Xorg 1.20 modesetting driver,
> > >> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
> > >> gnome & KDE wayland desktops from Ubuntu 18.04,
> > >> and sway 1.5
> > >>
> > >> Reported-by: Kirill A. Shutemov
> > >> Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
> > >> Link: https://lkml.org/lkml/2020/6/30/1251
> > >> Signed-off-by: James Jones
> > >> ---
> > >> drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
> > >> 1 file changed, 24 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> > >> b/drivers/gpu/drm/nouveau/nouveau_display.c
> > >> index 496c4621cc78..31543086254b 100644
> > >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > >> @@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
> > >> uint32_t *tile_mode,
> > >> uint8_t *kind)
> > >> {
> > >> + struct nouveau_display *disp = nouveau_display(drm->dev);
> > >> BUG_ON(!tile_mode || !kind);
> > >>
> > >> + if ((modifier & (0xffull << 12)) == 0ull) {
> > >> + /* Legacy modifier. Translate to this device's 'kind.'
> > >> */
> > >> + modifier |= disp->format_modifiers[0] & (0xffull << 12);
> > >> + }
> > > I believe this should be moved into the != MOD_LINEAR case.
> >
> > Yes, of course, thanks. I need to re-evaluate my testing yet again to
> > make sure I hit that case too. Preparing a v3...
>
> Going to need something here in the next day, two max.
>
> Linus may wait for another week, but it's not guaranteed.
I tested a whole bunch of GPUs before sending nouveau's -next tree,
and with the change I suggested to this patch + the other stuff I sent
through -fixes already, things seemed to be in OK shape.
Ben.
>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers
On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
>
> On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> >>
> >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> >> family of modifiers to handle broken userspace
> >> Xorg modesetting and Mesa drivers. Existing Mesa
> >> drivers are still aware of only these older
> >> format modifiers which do not differentiate
> >> between different variations of the block linear
> >> layout. When the format modifier support flag was
> >> flipped in the nouveau kernel driver, the X.org
> >> modesetting driver began attempting to use its
> >> format modifier-enabled framebuffer path. Because
> >> the set of format modifiers advertised by the
> >> kernel prior to this change do not intersect with
> >> the set of format modifiers advertised by Mesa,
> >> allocating GBM buffers using format modifiers
> >> fails and the modesetting driver falls back to
> >> non-modifier allocation. However, it still later
> >> queries the modifier of the GBM buffer when
> >> creating its DRM-KMS framebuffer object, receives
> >> the old-format modifier from Mesa, and attempts
> >> to create a framebuffer with it. Since the kernel
> >> is still not aware of these formats, this fails.
> >>
> >> Userspace should not be attempting to query format
> >> modifiers of GBM buffers allocated with a non-
> >> format-modifier-aware allocation path, but to
> >> avoid breaking existing userspace behavior, this
> >> change accepts the old-style format modifiers when
> >> creating framebuffers and applying them to planes
> >> by translating them to the equivalent new-style
> >> modifier. To accomplish this, some layout
> >> parameters must be assumed to match properties of
> >> the device targeted by the relevant ioctls. To
> >> avoid perpetuating misuse of the old-style
> >> modifiers, this change does not advertise support
> >> for them. Doing so would imply compatibility
> >> between devices with incompatible memory layouts.
> >>
> >> Tested with Xorg 1.20 modesetting driver,
> >> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
> >> gnome & KDE wayland desktops from Ubuntu 18.04,
> >> and sway 1.5
> >>
> >> Reported-by: Kirill A. Shutemov
> >> Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
> >> Link: https://lkml.org/lkml/2020/6/30/1251
> >> Signed-off-by: James Jones
> >> ---
> >> drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
> >> 1 file changed, 24 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> index 496c4621cc78..31543086254b 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> @@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
> >> uint32_t *tile_mode,
> >> uint8_t *kind)
> >> {
> >> + struct nouveau_display *disp = nouveau_display(drm->dev);
> >> BUG_ON(!tile_mode || !kind);
> >>
> >> + if ((modifier & (0xffull << 12)) == 0ull) {
> >> + /* Legacy modifier. Translate to this device's 'kind.' */
> >> + modifier |= disp->format_modifiers[0] & (0xffull << 12);
> >> + }
> > I believe this should be moved into the != MOD_LINEAR case.
>
> Yes, of course, thanks. I need to re-evaluate my testing yet again to
> make sure I hit that case too. Preparing a v3...
Going to need something here in the next day, two max.
Linus may wait for another week, but it's not guaranteed.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #106 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Duncan from comment #101) > (In reply to Nicholas Kazlauskas from comment #95) > > Created attachment 290583 [details] > > 0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch > > Just booted to 5.8-rc7 with this patched in locally (and the g320+ reverts > /not/ patched in). So testing, but noting again that the bug can take a > couple days to trigger on my hardware This doesn't seem to trigger the bug at all for me, tho there's the expected slowdown/judder from force-syncing all CRTCs as detailed in my last couple comments. But with the more serious side effects mnrzk is seeing with it, it's clearly not useful as an even temporary mainline candidate. I'll be testing mnrzk's patch now. Hopefully it'll be good enough for the quickly approaching 5.8, tho dev consensus seems to be that a deeper rework is needed longer-term. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/sun4i: backend: Support alpha property on lowest plane
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on soc/for-next xlnx/master linus/master v5.8-rc7
next-20200728]
[cannot apply to mripard/sunxi/for-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/Maxime-Ripard/drm-sun4i-backend-Support-alpha-property-on-lowest-plane/20200729-033432
base: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
sunxi/for-next
config: arm-defconfig (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
# 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 >>):
drivers/gpu/drm/sun4i/sun4i_backend.c: In function
'sun4i_backend_atomic_check':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:592:57: error: expected statement
>> before ')' token
592 | (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE)))
| ^
vim +592 drivers/gpu/drm/sun4i/sun4i_backend.c
dd63250c55bf26 Maxime Ripard 2018-01-22 484
96180dde23b799 Maxime Ripard 2018-01-22 485 static int
sun4i_backend_atomic_check(struct sunxi_engine *engine,
96180dde23b799 Maxime Ripard 2018-01-22 486
struct drm_crtc_state *crtc_state)
96180dde23b799 Maxime Ripard 2018-01-22 487 {
8f1f25534fff09 Maxime Ripard 2018-02-16 488struct drm_plane_state
*plane_states[SUN4I_BACKEND_NUM_LAYERS] = { 0 };
dcf496a6a60873 Paul Kocialkowski 2018-07-19 489struct sun4i_backend
*backend = engine_to_sun4i_backend(engine);
96180dde23b799 Maxime Ripard 2018-01-22 490struct drm_atomic_state
*state = crtc_state->state;
96180dde23b799 Maxime Ripard 2018-01-22 491struct drm_device *drm
= state->dev;
96180dde23b799 Maxime Ripard 2018-01-22 492struct drm_plane *plane;
65f7fa3a3fcbdb Maxime Ripard 2017-06-26 493unsigned int num_planes
= 0;
65f7fa3a3fcbdb Maxime Ripard 2017-06-26 494unsigned int
num_alpha_planes = 0;
96180dde23b799 Maxime Ripard 2018-01-22 495unsigned int
num_frontend_planes = 0;
dcf496a6a60873 Paul Kocialkowski 2018-07-19 496unsigned int
num_alpha_planes_max = 1;
32463556a634f3 Maxime Ripard 2018-03-01 497unsigned int
num_yuv_planes = 0;
8f1f25534fff09 Maxime Ripard 2018-02-16 498unsigned int
current_pipe = 0;
8f1f25534fff09 Maxime Ripard 2018-02-16 499unsigned int i;
96180dde23b799 Maxime Ripard 2018-01-22 500
96180dde23b799 Maxime Ripard 2018-01-22 501
DRM_DEBUG_DRIVER("Starting checking our planes\n");
96180dde23b799 Maxime Ripard 2018-01-22 502
96180dde23b799 Maxime Ripard 2018-01-22 503if
(!crtc_state->planes_changed)
96180dde23b799 Maxime Ripard 2018-01-22 504return 0;
96180dde23b799 Maxime Ripard 2018-01-22 505
96180dde23b799 Maxime Ripard 2018-01-22 506
drm_for_each_plane_mask(plane, drm, crtc_state->plane_mask) {
96180dde23b799 Maxime Ripard 2018-01-22 507struct
drm_plane_state *plane_state =
96180dde23b799 Maxime Ripard 2018-01-22 508
drm_atomic_get_plane_state(state, plane);
96180dde23b799 Maxime Ripard 2018-01-22 509struct
sun4i_layer_state *layer_state =
96180dde23b799 Maxime Ripard 2018-01-22 510
state_to_sun4i_layer_state(plane_state);
65f7fa3a3fcbdb Maxime Ripard 2017-06-26 511struct
drm_framebuffer *fb = plane_state->fb;
65f7fa3a3fcbdb Maxime Ripard 2017-06-26 512struct
drm_format_name_buf format_name;
96180dde23b799 Maxime Ripard 2018-01-22 513
ab6985108a53d5 Paul Kocialkowski 2018-11-23 514if
(!sun4i_backend_plane_is_supported(plane_state,
ab6985108a53d5 Paul Kocialkowski 2018-11-23 515
&layer_state->uses_frontend))
ab6985108a53d5 Paul Kocialkowski 2018-11-23 516return
-EINVAL;
ab6985108a53d5 Paul Kocialkowski 2018-11-23 517
ab6985108a53d5 Paul Kocialkowski 2018-11-23 518if
(layer_state->uses_frontend) {
96180dde23b799 Maxime Ripard 2018-01-22 519
DRM_DEBUG_DRIVER
Re: [PATCH -next] drm: xlnx: Fix typo in parameter description
Hello,
On Tue, Jul 28, 2020 at 03:35:43PM -0700, Laurent Pinchart wrote:
> On Wed, Jul 29, 2020 at 12:02:05AM +0200, dan...@ffwll.ch wrote:
> > Hi Hyun Kwon,
> >
> > Are you all sorted with drm-misc commit rights so you can push the 3
> > (maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
>
> Thanks Daniel for bringing this up.
>
> Hyun, would that work for you ?
>
Should I commit small fixups directly to,
https://cgit.freedesktop.org/drm/drm-misc/log/?h=drm-misc-next-fixes?
I received the account for drm-misc a couple years ago, and was able to access
back then. But now someting has changed, and I can't access at the moment. I'll
need some time to fix my setup. Maybe some help would be appreciated to speed
up. I may ping you offline if you don't mind.
Thanks,
-hyun
> > On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> > > Fix typo in parameter description.
> > >
> > > Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP
> > > DisplayPort Subsystem")
> > > Reported-by: Hulk Robot
> > > Signed-off-by: Wei Yongjun
> > > ---
> > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > > index 821f7a71e182..3d53638ab15e 100644
> > > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > > @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value
> > > in msec (default: 50)");
> > > */
> > > static uint zynqmp_dp_power_on_delay_ms = 4;
> > > module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> > > 0444);
> > > -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default:
> > > 4)");
> > > +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> > > 4)");
> > >
> > > /* Link configuration registers */
> > > #define ZYNQMP_DP_LINK_BW_SET0x0
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm/nouveau: don't call tt destroy callback on alloc failure.
On Tue, 28 Jul 2020 at 17:49, Christian König wrote: > > Am 28.07.20 um 06:17 schrieb Dave Airlie: > > From: Dave Airlie > > > > This is confusing, and from my reading of all the drivers only > > nouveau got this right. > > > > Just make the API act under driver control of it's own allocation > > failing, and don't call destroy, if the page table fails to > > create there is nothing to cleanup here. > > > > (I'm willing to believe I've missed something here, so please > > review deeply). > > > > Signed-off-by: Dave Airlie > > That looks right to me as well, Reviewed-by: Christian König > Landed this in drm-next as well. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: drop unusued function declaration
On Tue, 28 Jul 2020 at 17:49, Christian König wrote: > > Am 28.07.20 um 06:51 schrieb Dave Airlie: > > From: Dave Airlie > > > > This was removed in > > f5a9a9383f279de9da63296cb623a6418a66196b drm/ttm: remove > > TTM_MEMTYPE_FLAG_CMA > > > > but the the declaration was left dangling. > > > > Signed-off-by: Dave Airlie > > Reviewed-by: Christian König I've just pushed this, the unbind and swapout all to drm-next. Though we should probably in future just have you merge them via misc. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ttm: ttm_bo_swapout_all doesn't use it's argument.
> On Jul 27, 2020, at 11:42 PM, Dave Airlie wrote: > > From: Dave Airlie > > Just drop the argument from this. > > This does ask the question if this is the function vmwgfx > should be using or should it be doing an evict all like > the other drivers. Yea, it really should. This code is really old. Over the next year we’ll spend some time making our driver a little less special so that we can make those symbols private again (we’ll have to reevaulate whether we still need the private ttm_lock code, because ideally we’d bring all of that inline with the other drivers). For the patch: Reviewed-by: Zack Rusin z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Tue, Jul 28, 2020 at 11:05 AM Rob Herring wrote:
>
> On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan
> wrote:
> >
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code. These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
> >
> > Signed-off-by: Jim Quinlan
> > ---
>
> [...]
>
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 8eea3f6e29a4..4b718d199efe 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct
> > device_node *np, int index,
> > }
> > EXPORT_SYMBOL(of_io_request_and_map);
> >
> > +#ifdef CONFIG_HAS_DMA
> > /**
> > - * of_dma_get_range - Get DMA range info
> > + * of_dma_get_range - Get DMA range info and put it into a map array
> > * @np:device node to get DMA range info
> > - * @dma_addr: pointer to store initial DMA address of DMA range
> > - * @paddr: pointer to store initial CPU address of DMA range
> > - * @size: pointer to store size of DMA range
> > + * @map: dma range structure to return
> > *
> > * Look in bottom up direction for the first "dma-ranges" property
> > - * and parse it.
> > - * dma-ranges format:
> > + * and parse it. Put the information into a DMA offset map array.
> > + *
> > + * dma-ranges format:
> > * DMA addr (dma_addr) : naddr cells
> > * CPU addr (phys_addr_t) : pna cells
> > * size: nsize cells
> > *
> > - * It returns -ENODEV if "dma-ranges" property was not found
> > - * for this device in DT.
> > + * It returns -ENODEV if "dma-ranges" property was not found for this
> > + * device in the DT.
> > */
> > -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr,
> > u64 *size)
> > +int of_dma_get_range(struct device_node *np, const struct bus_dma_region
> > **map)
> > {
> > struct device_node *node = of_node_get(np);
> > const __be32 *ranges = NULL;
> > - int len;
> > - int ret = 0;
> > bool found_dma_ranges = false;
> > struct of_range_parser parser;
> > struct of_range range;
> > - u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> > + struct bus_dma_region *r;
> > + int len, num_ranges = 0;
> > + int ret;
> >
> > while (node) {
> > ranges = of_get_property(node, "dma-ranges", &len);
> > @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64
> > *dma_addr, u64 *paddr, u64 *siz
> > }
> >
> > of_dma_range_parser_init(&parser, node);
> > + for_each_of_range(&parser, &range)
> > + num_ranges++;
> > +
> > + of_dma_range_parser_init(&parser, node);
> > +
> > + ret = -ENOMEM;
> > + r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> > + if (!r)
> > + goto out;
>
> AFAICT, you have the error cases covered, but you are leaking memory
> if the device is removed.
Hi Rob,
I started using devm_kcalloc() but at least two reviewers convinced me
to just use kcalloc(). In addition, when I was using devm_kcalloc()
it was awkward because 'dev' is not available to this function.
It comes down to whether unbind/binding the device N times is actually
a reasonable usage. As for my experience I've seen two cases: (1) my
overnight "bind/unbind the PCIe RC driver" script, and we have a
customer who does an unbind/bind as a hail mary to bring back life to
their dead EP device. If the latter case happens repeatedly, there
are bigger problems.
>
>
> [...]
>b
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> > b/drivers/remoteproc/remoteproc_core.c
> > index 9f04c30c4aaf..49242dd6176e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> > struct fw_rsc_vdev *rsc,
> > /* Initialise vdev subdevice */
> > snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> > rvdev->dev.parent = &rproc->dev;
> > - rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> > + rvdev->
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Hi Christoph,
On Tue, Jul 28, 2020 at 8:33 AM Christoph Hellwig wrote:
>
> A few tiny nitpicks:
>
> The subject should have the dma-mapping prefix, this doesn't
> really touch the device core.
>
> > - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> > + rc = of_dma_get_range(np, &map);
> > + rc = PTR_ERR_OR_ZERO(map);
>
> I don't think you need the PTR_ERR_OR_ZERO line here, of_dma_get_range
> returns the error.
Yes, that link needs to be deleted.
>
> > +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> > + dma_addr_t dma_start, u64 size)hh
> > +{
> > + struct bus_dma_region *map;
> > + u64 offset = (u64)cpu_start - (u64)dma_start;
> > +
> > + if (!dev)
> > + return -ENODEV;
>
> I don't think we need the NULL protection here, all DMA API calls
> expect a device.
Yes, your review-patch removed it but left the comment about the
function returning -ENODEV. So I wasn't sure to leave it in or not.
>
> > + if (!offset)
> > + return 0;
> > +
> > + /*
> > + * See if a map already exists and we already encompass the new range:
> > + */
> > + if (dev->dma_range_map) {
> > + if (dma_range_overlaps(dev, cpu_start, dma_start, size,
> > offset))
> > + return 0;
> > + dev_err(dev, "attempt to add conflicting DMA range to
> > existing map\n");
> > + return -EINVAL;
> > + }
>
> And here why do we need the overlap check at all? I'd be tempted to
> always return an error for this case.
I believe the overlap check was your suggestion or at least in your
review-patch? I'm fine with just returning an error.
>
> What is the plan to merge this? Do you want all this to go into one
> tree, or get as many bits into the applicable trees for 5.9 and then
> finish up for 5.10? If the former I can apply it to the dma-mapping
> tree and just fix up the nitpicks.
Whatever you think is best -- I would be quite happy if you could
accept at least the "dma_range_map" commit. Of course I'd be most
happy if the entire patchset were accepted, but perhaps you can just
apply the "dma_range_map" commit, and I will continue to bang away at
getting the N-1 PCIe-related commits ack'd and accepted.
Thanks much!
Jim Quinlan
Broadcom STB
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm: xln: fix spelling mistake "failes" -> "failed"
Hi Colin,
Thank you for the patch.
On Fri, Jul 24, 2020 at 12:12:58PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_dbg messages. Fix it.
There is a spelling mistake in the commit message, s/xln/xlnx/ ;-)
> Signed-off-by: Colin Ian King
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..0e1c818746eb 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -1308,7 +1308,7 @@ zynqmp_dp_connector_detect(struct drm_connector
> *connector, bool force)
> ret = drm_dp_dpcd_read(&dp->aux, 0x0, dp->dpcd,
> sizeof(dp->dpcd));
> if (ret < 0) {
> - dev_dbg(dp->dev, "DPCD read failes");
> + dev_dbg(dp->dev, "DPCD read failed");
> goto disconnected;
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm: xlnx: Fix typo in parameter description
On Wed, Jul 29, 2020 at 12:02:05AM +0200, dan...@ffwll.ch wrote:
> Hi Hyun Kwon,
>
> Are you all sorted with drm-misc commit rights so you can push the 3
> (maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Thanks Daniel for bringing this up.
Hyun, would that work for you ?
> On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> > Fix typo in parameter description.
> >
> > Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP
> > DisplayPort Subsystem")
> > Reported-by: Hulk Robot
> > Signed-off-by: Wei Yongjun
> > ---
> > drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > index 821f7a71e182..3d53638ab15e 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in
> > msec (default: 50)");
> > */
> > static uint zynqmp_dp_power_on_delay_ms = 4;
> > module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> > 0444);
> > -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> > +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> > 4)");
> >
> > /* Link configuration registers */
> > #define ZYNQMP_DP_LINK_BW_SET 0x0
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm: xlnx: Fix typo in parameter description
Hi Wei,
Thank you for the patch.
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..3d53638ab15e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in
> msec (default: 50)");
> */
> static uint zynqmp_dp_power_on_delay_ms = 4;
> module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> 0444);
> -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> 4)");
>
> /* Link configuration registers */
> #define ZYNQMP_DP_LINK_BW_SET0x0
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jul 27 (drivers/gpu/drm/xlnx/zynqmp-dpsub)
Hi Randy, (adding a few people to the CC list to discuss the proposed solution below) Thanks for the report. On Mon, Jul 27, 2020 at 05:49:41PM -0700, Randy Dunlap wrote: > On 7/27/20 6:23 AM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20200724: > > on x86_64: > > WARNING: unmet direct dependencies detected for DMA_ENGINE > Depends on [n]: DMADEVICES [=n] > Selected by [m]: > - DRM_ZYNQMP_DPSUB [=m] && HAS_IOMEM [=y] && (ARCH_ZYNQMP || COMPILE_TEST > [=y]) && COMMON_CLK [=y] && DRM [=m] && OF [=y] > > and about 45 "undefined reference" build errors (here's a sample): > > ld: drivers/misc/mic/scif/scif_dma.o: in function > `scif_sync_dma.constprop.11': > scif_dma.c:(.text+0x672): undefined reference to `dma_sync_wait' > ld: drivers/spi/spi-bcm2835.o: in function `bcm2835_dma_release.isra.9': > spi-bcm2835.c:(.text+0xb34): undefined reference to `dma_release_channel' > ld: spi-bcm2835.c:(.text+0xc17): undefined reference to `dma_release_channel' > ld: drivers/spi/spi-bcm2835.o: in function `bcm2835_dma_init': > spi-bcm2835.c:(.text+0xd3c): undefined reference to `dma_request_chan' > ld: spi-bcm2835.c:(.text+0xd8b): undefined reference to `dma_request_chan' > ld: spi-bcm2835.c:(.text+0xf8a): undefined reference to `dma_get_slave_caps' > ld: spi-bcm2835.c:(.text+0x11d0): undefined reference to `dma_get_slave_caps' > ld: drivers/spi/spi-ep93xx.o: in function `ep93xx_spi_release_dma': > spi-ep93xx.c:(.text+0x1fc): undefined reference to `dma_release_channel' > ld: spi-ep93xx.c:(.text+0x220): undefined reference to `dma_release_channel' > ERROR: modpost: "dma_release_channel" [drivers/gpu/drm/xlnx/zynqmp-dpsub.ko] > undefined! > > > > I tried adding > depends on DMADEVICES > to DRM_ZYNQMP_DPSUB > > but that just gets into messy/ugly Kconfig > error: recursive dependency detected! drivers/i2c/Kconfig:8:error: recursive dependency detected! drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_ZYNQMP_DPSUB drivers/gpu/drm/xlnx/Kconfig:1: symbol DRM_ZYNQMP_DPSUB depends on DMA_ENGINE drivers/dma/Kconfig:44: symbol DMA_ENGINE depends on DMADEVICES drivers/dma/Kconfig:6: symbol DMADEVICES is selected by SND_SOC_SH4_SIU sound/soc/sh/Kconfig:30:symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR sound/soc/sh/Kconfig:60:symbol SND_SIU_MIGOR depends on I2C For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" > BTW, adding > select DMADEVICES > is not a good solution. We try very hard not to enable entire > subsystems with one driver "select". (No doubt you can find a > few examples that do just that, but it is strongly discouraged.) If this isn't allowed, then we need to fix this where used, as that's what seems to cause the recursive dependency. Would the following patches be acceptable in your opinion ? If so I'll submit them proper. commit 410e29afd54fd23ee94cd1842b51b7a9e2f96cd8 Author: Laurent Pinchart Date: Wed Jul 29 01:19:40 2020 +0300 treewide: kconfig: Replace 'select' DMAENGINES 'with depends on' Enabling a whole subsystem from a single driver 'select' is frowned upon and won't be accepted in new drivers, that need to use 'depends on' instead. Existing selection of DMAENGINES will then cause circular dependencies. Replace them with a dependency. Signed-off-by: Laurent Pinchart diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig index e4c422d806be..b9f8514909bf 100644 --- a/drivers/rapidio/Kconfig +++ b/drivers/rapidio/Kconfig @@ -37,7 +37,7 @@ config RAPIDIO_ENABLE_RX_TX_PORTS config RAPIDIO_DMA_ENGINE bool "DMA Engine support for RapidIO" depends on RAPIDIO - select DMADEVICES + depends on DMADEVICES select DMA_ENGINE help Say Y here if you want to use DMA Engine frameork for RapidIO data diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig index dc20f0f7080a..ef8a29b9f641 100644 --- a/sound/soc/sh/Kconfig +++ b/sound/soc/sh/Kconfig @@ -30,8 +30,8 @@ config SND_SOC_SH4_FSI config SND_SOC_SH4_SIU tristate depends on ARCH_SHMOBILE && HAVE_CLK + depends on DMADEVICES select DMA_ENGINE - select DMADEVICES select SH_DMAE select FW_LOADER commit 3e68c8fc7a2f3f7992c7fa8b30108d3831c7fb3b Author: Laurent Pinchart Date: Wed Jul 29 01:23:32 2020 +0300 drm: xlnx: dpsub: Fix DMADEVICES Kconfig dependency The dpsub driver uses the DMA engine API, and thus selects DMA_ENGINE to provide that API. DMA_ENGINE depends on DMADEVICES, which can be deselected by the user, creating a possibly unmet indirect dependen
Re: [PATCH -next] drm: xlnx: Fix typo in parameter description
Hi Hyun Kwon,
Are you all sorted with drm-misc commit rights so you can push the 3
(maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Cheers, Daniel
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..3d53638ab15e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in
> msec (default: 50)");
> */
> static uint zynqmp_dp_power_on_delay_ms = 4;
> module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> 0444);
> -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> 4)");
>
> /* Link configuration registers */
> #define ZYNQMP_DP_LINK_BW_SET0x0
>
>
>
--
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 0/2] Small cleanups to ingenic-drm driver
On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote: > Hi Paul. > > On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote: > > Here are a few cleanups to the ingenic-drm driver. > > - some error paths were missing and have been added; > > - the mode validation has been moved to the .mode_valid helper callback. > > > > Cheers, > > -Paul > > > > Paul Cercueil (2): > > drm/ingenic: Handle errors of drm_atomic_get_plane_state > > drm/ingenic: Validate mode in a .mode_valid callback > > Both looks fine, you can add my: > Reviewed-by: Sam Ravnborg > > I assume you will apply the patches. > Maybe wait for Daniel to take a look, he had some feedback on where > to add checks. I assume this is covered by the second patch. Yeah changelog for new versions would be great, but aside from that bickering patch 2 lgtm now. Cheers, Daniel > > Sam > > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +++ > > 1 file changed, 27 insertions(+), 14 deletions(-) > > > > -- > > 2.27.0 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Tue, Jul 28, 2020 at 01:07:13PM -0400, Kazlauskas, Nicholas wrote: > On 2020-07-28 5:22 a.m., Paul Menzel wrote: > > Dear Linux folks, > > > > > > Am 25.07.20 um 07:20 schrieb Mazin Rezk: > > > On Saturday, July 25, 2020 12:59 AM, Duncan wrote: > > > > > > > On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: > > > > > > > > > > Am 24.07.20 um 19:33 schrieb Kees Cook: > > > > > > > > > > > > > There was a fix to disable the async path for this driver that > > > > > > > worked around the bug too, yes? That seems like a safer and more > > > > > > > focused change that doesn't revert the SLUB defense for all > > > > > > > users, and would actually provide a complete, I think, workaround > > > > > > > > > > That said, I haven't seen the async disabling patch. If you could > > > > > link to it, I'd be glad to test it out and perhaps we can use that > > > > > instead. > > > > > > > > I'm confused. Not to put words in Kees' mouth; /I/ am confused (which > > > > admittedly could well be just because I make no claims to be a > > > > coder and am simply reading the bug and thread, but I'd appreciate some > > > > "unconfusing" anyway). > > > > > > > > My interpretation of the "async disabling" reference was that it was to > > > > comment #30 on the bug: > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 > > > > > > > > > > > > ... which (if I'm not confused on this point too) appears to be yours. > > > > There it was stated... > > > > > > > > I've also found that this bug exclusively occurs when commit_work is on > > > > the workqueue. After forcing drm_atomic_helper_commit to run all of the > > > > commits without adding to the workqueue and running the OS, the issue > > > > seems to have disappeared. > > > > > > > > > > > > Would not forcing all commits to run directly, without placing them on > > > > the workqueue, be "async disabling"? That's what I /thought/ he was > > > > referencing. > > > > > > Oh, I thought he was referring to a different patch. Kees, could I get > > > your confirmation on this? > > > > > > The change I made actually affected all of the DRM code, although > > > this could > > > easily be changed to be specific to amdgpu. (By forcing blocking on > > > amdgpu_dm's non-blocking commit code) > > > > > > That said, I'd still need to test further because I only did test it > > > for a > > > couple of hours then. Although it should work in theory. > > > > > > > OTOH your base/context swap idea sounds like a possibly "less > > > > disturbance" workaround, if it works, and given the point in the > > > > commit cycle... (But if it's out Sunday it's likely too late to test > > > > and get it in now anyway; if it's another week, tho...) > > > > > > The base/context swap idea should make the use-after-free behave how it > > > did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a > > > "less disturbance" workaround and more of a "no disturbance" workaround. > > > > Sorry for bothering, but is there now a solution, besides reverting the > > commits, to avoid freezes/crashes *without* performance regressions? > > > > > > Kind regards, > > > > Paul > > Mazin's "drm/amd/display: Clear dm_state for fast updates" change > accomplishes this, at least as a temporary hack. Yeah I gets it's horrible, but better than nothing. Reverting the old amdgpu change to a private state object is probably a lot more invasive. > I've started work on a more large scale fix that we could get in in after. Does that include a fix for the "stuff needed by irq handler"? Either way pls cc dri-devel, I think this is something worth of a bit wider discussion. Feels like unsolved homework from the entire "make DC integrate into linux" saga ... -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] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Tue, Jul 28, 2020 at 04:16:34PM +, Sidong Yang wrote: > On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote: > > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote: > > > > > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote: > > > > > > > > > No, this very first warning continues (only once) :( > > > > > From here (drm_crtc_vblank_on): > > > > > if (atomic_read(&vblank->refcount) != 0 || > > > > > drm_vblank_offdelay == 0) > > > > > drm_WARN_ON(dev, drm_vblank_enable(dev, pipe)); > > > > > > > > Sorry, not sure when this warning is triggered. > > > > > > Again, I just had to look at the trace: > > > [ 52.299388] drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > > > [ 52.299389] drm_reset_vblank_timestamp+0x5b/0xd0 [drm] > > > [ 52.299389] drm_crtc_vblank_on.cold+0x37/0x103 [drm] > > > [ 52.299390] drm_atomic_helper_commit_modeset_enable > > > > Yeah I think vkms can't generate a reasonable timestamp when the > > hrtimer is off. I thought the warning comes from a different > > callchain, but seems to be a general problem. > > > > I guess in the vkms timestamp function we should check whether the > > timer is running, and if it's not running, then we just grab the > > current time and done. > > I tried some test about this scenario that commit_tail calls in sequence > disable > - enable - commit. > In a first test. there was a warning and found out that it raised from > vkms_get_vblank_timestamp() the code checking vblank_hrtimer's expire time > and > vblank_time. In first run, vblank_time and hrtimer's expire time was both > zero. > because vblank wasn't happened yet. this warning wasn't happend since second > run > that vblank time was set from first run. > > I don't know it's good way to solve the problem. Is there no problem in other > drm modules? Generally real hw drivers always have working clocks, not like the fake ones we have here :-) The idea behind the timestamp callback is that when vblank interrupts aren't enabled, the timestamp will help us keep track of how many vblanks have happened. So I think (but might be wrong) correct fix for this issue would be to check whether vblanks are enabled, and if not, simply pass back the current system time. That's a lie, but much better than whatever value was set last time around the hrtimer fired- e.g. similar problem can happen later on when the vblank interrupt was off for a very long time. -Daniel > > -Sidong > > > -Daniel > > > > > > > > > > > > > > > > > But I'm still wondering why after step 3 we don't get -EINVAL from > > > > > > vblank_get() - after vblank_off() vblank->enabled should be false > > > > > > again, getting us back to the same state as after 1. Is that not > > > > > > happening? > > > > > > > > > > Yes (sorry if it got confused), we got -EINVAL after setp 3: > > > > > > > > > > In step 3, at the end of the 2nd running, we have: > > > > > atomic_disable > > > > > --> vblank_off [!vblank->inmodeset + refcount going 0->1 + > > > > > inmodeset=1] > > > > > and then in next vblank_get: -EINVAL (!vblank->enabled + refcount > > > > > ends 1) > > > > > as in the first step. > > > > > > > > > > Melissa > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > -Sidong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > crtc->state->event = NULL; > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > 2.27.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Daniel Vetter > > > > > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Daniel Vetter > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Daniel Vetter > > > > > > Software Engineer, Intel Corporation > > > > > > http://blog.ffwll.ch > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- 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 RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang wrote: > > From: Kevin Tang > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > RFC v6: > - Access registers via readl/writel > - Checking for unsupported KMS properties (format, rotation, blend_mode, > etc) on plane_check ops > - Remove always true checks for dpu core ops > > Cc: Orson Zhai > Cc: Chunyan Zhang > Signed-off-by: Kevin Tang Quickly scrolled through this, and the entire thing very much leaves a midlayer heavy aftertaste. Do we really need stuff like struct dpu_layer and struct dpu_core_ops? They only seem to complicate the code base, and seem to have no real reason. The indirection with first computing register values into a sprd_plane/crtc structure, and then writing it into hardware is also a bit much - I recommend to only do that if you have to compute values in _check to validate them, so that the computation doesn't have to be repeated in the commit phase functions. Also, the layer and pending_flips stuff in sprd_dpu don't work with atomic, that races. You have to put all that stuff into state objects, or if it's some data shared with interrupt handlers (doesn't seem to be the case here), it needs its own locking, and any data you need in the interrupt handler must be copied over. Also no devm_kzalloc for anything containined a drm_* structure, that's the wrong lifetime. So yeah high level review is that I think this driver would benefit a lot from a pile of demidlayer. Cheers, Daniel > --- > drivers/gpu/drm/sprd/Makefile | 5 +- > drivers/gpu/drm/sprd/dpu/Makefile | 3 + > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503 > drivers/gpu/drm/sprd/sprd_dpu.c | 646 > > drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++ > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > 7 files changed, 1346 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile > create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > index 86d95d9..88ab32a 100644 > --- a/drivers/gpu/drm/sprd/Makefile > +++ b/drivers/gpu/drm/sprd/Makefile > @@ -2,4 +2,7 @@ > > subdir-ccflags-y += -I$(srctree)/$(src) > > -obj-y := sprd_drm.o > +obj-y := sprd_drm.o \ > + sprd_dpu.o > + > +obj-y += dpu/ > diff --git a/drivers/gpu/drm/sprd/dpu/Makefile > b/drivers/gpu/drm/sprd/dpu/Makefile > new file mode 100644 > index 000..40278b6 > --- /dev/null > +++ b/drivers/gpu/drm/sprd/dpu/Makefile > @@ -0,0 +1,3 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +obj-y += dpu_r2p0.o > diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > new file mode 100644 > index 000..4b9521d > --- /dev/null > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > @@ -0,0 +1,503 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Unisoc Inc. > + */ > + > +#include > +#include > +#include > +#include > + > +#include "sprd_dpu.h" > + > +/* DPU registers size, 4 Bytes(32 Bits) */ > +#define DPU_REG_SIZE 0x04 > + > +/* Layer registers offset */ > +#define DPU_LAY_REG_OFFSET 0x0C > + > +#define DPU_LAY_REG(reg, index) \ > + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE) > + > +#define DPU_REG_RD(reg) readl_relaxed(reg) > + > +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg) > + > +#define DPU_REG_SET(reg, mask) \ > + writel_relaxed(readl_relaxed(reg) | mask, reg) > + > +#define DPU_REG_CLR(reg, mask) \ > + writel_relaxed(readl_relaxed(reg) & ~mask, reg) > + > +/* Global control registers */ > +#define REG_DPU_CTRL 0x04 > +#define REG_DPU_CFG0 0x08 > +#define REG_DPU_CFG1 0x0C > +#define REG_DPU_CFG2 0x10 > +#define REG_PANEL_SIZE 0x20 > +#define REG_BLEND_SIZE 0x24 > +#define REG_BG_COLOR 0x2C > + > +/* Layer0 control registers */ > +#define REG_LAY_BASE_ADDR0 0x30 > +#define REG_LAY_BASE_ADDR1 0x34 > +#define REG_LAY_BASE_ADDR2 0x38 > +#define REG_LAY_CTRL 0x40 > +#define REG_LAY_SIZE 0x44 > +#define REG_LAY_PITCH 0x48 > +#define REG_LAY_POS0x4C > +#define REG_LAY_ALPHA 0x50 > +#define REG_LAY_PALLETE0x58 > +#define REG_LAY_CROP_START 0x5C > + > +/* Interrupt control registers */ > +#define REG_DPU_INT_EN 0x1E0 > +#define REG_DPU_INT_CLR0x1E4 > +#define REG_DPU_INT_STS0x1E8 > + > +/* DPI control registers */ > +#define REG_DPI_CTRL 0x1F0 > +#define REG_DPI_H_TIMING 0x1F4 > +#define REG_DPI_V_TIMING 0x1F8 > + > +/* MMU control registers */ > +#define REG_MMU_EN 0x800 > +#define REG_MMU_VPN_RANGE
[PATCH 2/2] drm/mcde: Fix display data flow control
Revamp the way that the flow of data to the display is
defined.
I realized that the hardware supports something like
5 different modes of flow: oneshot, command with TE IRQ,
command with BTA (bus turn around) and TE IRQ, video
with TE IRQ and video without TE IRQ instead synchronizing
to the output of the MCDE DSI formatter.
Like before the selection of the type of flow is done
frome the DSI driver when we attach it to the MCDE and we
get to know what the display wants.
The new video mode synchronization method from the MCDE DSI
formatter is used on some upstream devices such as Golden
presumably because the TE IRQ is not working on the display.
It will likely need some (new) special flag to be passed
from the display to indicate this mode of operation
once we make use of it.
The only real semantic change is that we stop sending
a TE request before every command when sending data to
a display in command mode: this should only be explicitly
requested when using BTA, according to the vendor driver.
This has been tested and works fine with the command mode
displays I have. (All that are supported upstream.)
Reported-by: Stephan Gerhold
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_display.c | 107 +---
drivers/gpu/drm/mcde/mcde_drm.h | 26 ++-
drivers/gpu/drm/mcde/mcde_drv.c | 3 -
drivers/gpu/drm/mcde/mcde_dsi.c | 18 -
4 files changed, 104 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index a99cc3fd5ef4..897d29e318d3 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -89,7 +89,7 @@ void mcde_display_irq(struct mcde *mcde)
* the update function is called, then we disable the
* flow on the channel once we get the TE IRQ.
*/
- if (mcde->oneshot_mode) {
+ if (mcde->flow_mode == MCDE_COMMAND_ONESHOT_FLOW) {
spin_lock(&mcde->flow_lock);
if (--mcde->flow_active == 0) {
dev_dbg(mcde->dev, "TE0 IRQ\n");
@@ -524,19 +524,41 @@ static void mcde_configure_channel(struct mcde *mcde,
enum mcde_channel ch,
}
/* Set up channel 0 sync (based on chnl_update_registers()) */
- if (mcde->video_mode || mcde->te_sync)
+ switch (mcde->flow_mode) {
+ case MCDE_COMMAND_ONESHOT_FLOW:
+ /* Oneshot is achieved with software sync */
+ val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SOFTWARE
+ << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
+ break;
+ case MCDE_COMMAND_TE_FLOW:
val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE
<< MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
- else
- val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SOFTWARE
+ val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0
+ << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
+ break;
+ case MCDE_COMMAND_BTA_TE_FLOW:
+ val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE
<< MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
-
- if (mcde->te_sync)
val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0
<< MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
- else
+ break;
+ case MCDE_VIDEO_TE_FLOW:
+ val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE
+ << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
+ val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0
+ << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
+ break;
+ case MCDE_VIDEO_FORMATTER_FLOW:
+ val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE
+ << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_FORMATTER
<< MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
+ break;
+ default:
+ dev_err(mcde->dev, "unknown flow mode %d\n",
+ mcde->flow_mode);
+ break;
+ }
writel(val, mcde->regs + sync);
@@ -946,7 +968,11 @@ static void mcde_display_enable(struct
drm_simple_display_pipe *pipe,
mcde_configure_dsi_formatter(mcde, MCDE_DSI_FORMATTER_0,
formatter_frame, pkt_size);
- if (mcde->te_sync) {
+ switch (mcde->flow_mode) {
+ case MCDE_COMMAND_TE_FLOW:
+ case MCDE_COMMAND_BTA_TE_FLOW:
+ case MCDE_VIDEO_TE_FLOW:
+ /* We are using TE in some comination */
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
val = MCDE_VSCRC_VSPOL;
else
@@ -956,16 +982,22 @@ static void mcde_display_enable(struct
drm_simple_display_pipe *pipe,
val = readl(mcde->regs + MCDE_CRC);
v
[PATCH 1/2] drm/mcde: Rename flow function
The function mcde_display_send_one_frame() has a historical
name that stems from being implemented when the driver
only supported single frame updates.
Rename it mcde_start_flow() so that it reflects the current
usage.
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 1d8ea8830a17..a99cc3fd5ef4 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -994,7 +994,7 @@ static void mcde_display_disable(struct
drm_simple_display_pipe *pipe)
dev_info(drm->dev, "MCDE display is disabled\n");
}
-static void mcde_display_send_one_frame(struct mcde *mcde)
+static void mcde_start_flow(struct mcde *mcde)
{
/* Request a TE ACK */
if (mcde->te_sync)
@@ -1092,7 +1092,7 @@ static void mcde_display_update(struct
drm_simple_display_pipe *pipe,
* is not active yet.
*/
if (mcde->flow_active == 0)
- mcde_display_send_one_frame(mcde);
+ mcde_start_flow(mcde);
}
dev_info_once(mcde->dev, "sent first display update\n");
} else {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 0/6] Add Unisoc's drm kms module
Hi Kevin. Thanks for submitting this set of drivers. To better review the pataches can you please give some kind of high level overview. An ascii block diagram that identifies all the relevant blocks and how they relate would be great. This makes it easier to verify if the right modelling is used. Sam On Tue, Jul 28, 2020 at 06:07:53PM +0800, Kevin Tang wrote: > From: Kevin Tang > > ChangeList: > v1: > 1. only upstream modeset and atomic at first commit. > 2. remove some unused code; > 3. use alpha and blend_mode properties; > 3. add yaml support; > 4. remove auto-adaptive panel driver; > 5. bugfix > > v2: > 1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder > 2. remove gem drivers, use generic CMA handlers > 3. remove redundant "module_init", all the sub modules loading by KMS > > v3: > 1. multi crtc&encoder design have problem, so rollback to v1 > > v4: > 1. update to gcc-linaro-7.5.0 > 2. update to Linux 5.6-rc3 > 3. remove pm_runtime support > 4. add COMPILE_TEST, remove unused kconfig > 5. "drm_dev_put" on drm_unbind > 6. fix some naming convention issue > 7. remove semaphore lock for crtc flip > 8. remove static variables > > v5: > 1. optimize encoder and connector code implementation > 2. use "platform_get_irq" and "platform_get_resource" > 3. drop useless function return type, drop unless debug log > 4. custom properties should be separate, so drop it > 5. use DRM_XXX replase pr_xxx > 6. drop dsi&dphy hal callback ops > 7. drop unless callback ops checking > 8. add comments for sprd dpu structure > > v6: > 1. Access registers via readl/writel > 2. Checking for unsupported KMS properties (format, rotation, blend_mode, > etc) on plane_check ops > 3. Remove always true checks for dpu core ops > > Kevin Tang (6): > dt-bindings: display: add Unisoc's drm master bindings > drm/sprd: add Unisoc's drm kms master > dt-bindings: display: add Unisoc's dpu bindings > drm/sprd: add Unisoc's drm display controller driver > dt-bindings: display: add Unisoc's mipi dsi&dphy bindings > drm/sprd: add Unisoc's drm mipi dsi&dphy driver > > .../devicetree/bindings/display/sprd/dphy.yaml | 75 + > .../devicetree/bindings/display/sprd/dpu.yaml | 82 ++ > .../devicetree/bindings/display/sprd/drm.yaml | 36 + > .../devicetree/bindings/display/sprd/dsi.yaml | 98 ++ > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/sprd/Kconfig | 12 + > drivers/gpu/drm/sprd/Makefile | 13 + > drivers/gpu/drm/sprd/disp_lib.c| 57 + > drivers/gpu/drm/sprd/disp_lib.h| 16 + > drivers/gpu/drm/sprd/dphy/Makefile |7 + > drivers/gpu/drm/sprd/dphy/pll/Makefile |3 + > drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c | 473 +++ > drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c | 201 +++ > drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h | 22 + > drivers/gpu/drm/sprd/dpu/Makefile |3 + > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c| 503 +++ > drivers/gpu/drm/sprd/dsi/Makefile |8 + > drivers/gpu/drm/sprd/dsi/core/Makefile |4 + > drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c | 964 + > drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h | 1477 > > drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.c | 328 + > drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h | 32 + > drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c| 590 > drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h| 26 + > drivers/gpu/drm/sprd/sprd_dphy.c | 209 +++ > drivers/gpu/drm/sprd/sprd_dphy.h | 50 + > drivers/gpu/drm/sprd/sprd_dpu.c| 668 + > drivers/gpu/drm/sprd/sprd_dpu.h| 190 +++ > drivers/gpu/drm/sprd/sprd_drm.c| 227 +++ > drivers/gpu/drm/sprd/sprd_drm.h| 18 + > drivers/gpu/drm/sprd/sprd_dsi.c| 571 > drivers/gpu/drm/sprd/sprd_dsi.h| 108 ++ > 33 files changed, 7074 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/sprd/dphy.yaml > create mode 100644 Documentation/devicetree/bindings/display/sprd/dpu.yaml > create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml > create mode 100644 Documentation/devicetree/bindings/display/sprd/dsi.yaml > create mode 100644 drivers/gpu/drm/sprd/Kconfig > create mode 100644 drivers/gpu/drm/sprd/Makefile > create mode 100644 drivers/gpu/drm/sprd/disp_lib.c > create mode 100644 drivers/gpu/drm/sprd/disp_lib.h > create mode 100644 drivers/gpu/drm/sprd/dphy/Makefile > create mode 100644 drivers/gpu/drm/sprd/dphy/pll/Makefile > create mode 100644 drivers/gp
Re: [PATCH RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi Kevin. Some feedback in the following. I lost track of thing for the atomic modesettting stuff and I hope other will review that. Sam On Tue, Jul 28, 2020 at 06:07:57PM +0800, Kevin Tang wrote: > From: Kevin Tang > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > RFC v6: > - Access registers via readl/writel > - Checking for unsupported KMS properties (format, rotation, blend_mode, > etc) on plane_check ops > - Remove always true checks for dpu core ops > > Cc: Orson Zhai > Cc: Chunyan Zhang > Signed-off-by: Kevin Tang > --- > drivers/gpu/drm/sprd/Makefile | 5 +- > drivers/gpu/drm/sprd/dpu/Makefile | 3 + > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503 > drivers/gpu/drm/sprd/sprd_dpu.c | 646 > > drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++ > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > 7 files changed, 1346 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile > create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > index 86d95d9..88ab32a 100644 > --- a/drivers/gpu/drm/sprd/Makefile > +++ b/drivers/gpu/drm/sprd/Makefile > @@ -2,4 +2,7 @@ > > subdir-ccflags-y += -I$(srctree)/$(src) Not needed - drop. > > -obj-y := sprd_drm.o > +obj-y := sprd_drm.o \ > + sprd_dpu.o > + > +obj-y += dpu/ Until there are several DPU's there is no need for a separate directory. Make it simpler by keeping it all in drm/sprd/* > diff --git a/drivers/gpu/drm/sprd/dpu/Makefile > b/drivers/gpu/drm/sprd/dpu/Makefile > new file mode 100644 > index 000..40278b6 > --- /dev/null > +++ b/drivers/gpu/drm/sprd/dpu/Makefile > @@ -0,0 +1,3 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +obj-y += dpu_r2p0.o > diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > new file mode 100644 > index 000..4b9521d > --- /dev/null > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > @@ -0,0 +1,503 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Unisoc Inc. > + */ > + > +#include > +#include > +#include > +#include > + > +#include "sprd_dpu.h" > + > +/* DPU registers size, 4 Bytes(32 Bits) */ > +#define DPU_REG_SIZE 0x04 > + > +/* Layer registers offset */ > +#define DPU_LAY_REG_OFFSET 0x0C > + > +#define DPU_LAY_REG(reg, index) \ > + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE) Use a static inline to get better typecheck. > +#define DPU_REG_RD(reg) readl_relaxed(reg) > + > +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg) > + > +#define DPU_REG_SET(reg, mask) \ > + writel_relaxed(readl_relaxed(reg) | mask, reg) > + > +#define DPU_REG_CLR(reg, mask) \ > + writel_relaxed(readl_relaxed(reg) & ~mask, reg) I am no fan of macros used like this. Maybe use static inlines and add struct dpu_context * as first argument. Then adding base can be hidden away. I had a hard time convincing myself that _relaxed was the right variants. If I get it correct we may see writes re-ordered with the _relaxed variants wich would be no good when dealign with interrupts. But I may miss somethign here. > + > +/* Global control registers */ > +#define REG_DPU_CTRL 0x04 > +#define REG_DPU_CFG0 0x08 > +#define REG_DPU_CFG1 0x0C > +#define REG_DPU_CFG2 0x10 > +#define REG_PANEL_SIZE 0x20 > +#define REG_BLEND_SIZE 0x24 > +#define REG_BG_COLOR 0x2C > + > +/* Layer0 control registers */ > +#define REG_LAY_BASE_ADDR0 0x30 > +#define REG_LAY_BASE_ADDR1 0x34 > +#define REG_LAY_BASE_ADDR2 0x38 > +#define REG_LAY_CTRL 0x40 > +#define REG_LAY_SIZE 0x44 > +#define REG_LAY_PITCH0x48 > +#define REG_LAY_POS 0x4C > +#define REG_LAY_ALPHA0x50 > +#define REG_LAY_PALLETE 0x58 > +#define REG_LAY_CROP_START 0x5C > + > +/* Interrupt control registers */ > +#define REG_DPU_INT_EN 0x1E0 > +#define REG_DPU_INT_CLR 0x1E4 > +#define REG_DPU_INT_STS 0x1E8 > + > +/* DPI control registers */ > +#define REG_DPI_CTRL 0x1F0 > +#define REG_DPI_H_TIMING 0x1F4 > +#define REG_DPI_V_TIMING 0x1F8 > + > +/* MMU control registers */ > +#define REG_MMU_EN 0x800 > +#define REG_MMU_VPN_RANGE0x80C > +#define REG_MMU_VAOR_ADDR_RD 0x818 > +#define REG_MMU_VAOR_ADDR_WR 0x81C > +#define REG_MMU_INV_ADDR_RD 0x820 > +#define REG_MMU_INV_ADDR_WR 0x824 > +#define REG_MMU_PPN1 0x83C > +#define REG_MMU_RANGE1 0x840 > +#define REG_MMU_PPN2 0x844 > +#define REG_MMU_RANGE2
Re: [PATCH RFC v6 3/6] dt-bindings: display: add Unisoc's dpu bindings
Hi Kevin.
On Tue, Jul 28, 2020 at 06:07:56PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> which transfers the image data from a video memory buffer to an internal
> LCD interface.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> .../devicetree/bindings/display/sprd/dpu.yaml | 82
> ++
Could we name it after the compatible "sharkl3-dpu.yaml"?
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sprd/dpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/sprd/dpu.yaml
> b/Documentation/devicetree/bindings/display/sprd/dpu.yaml
> new file mode 100644
> index 000..54ba9b6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sprd/dpu.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: GPL-2.0
Can this be: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/dpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc SoC Display Processor Unit (DPU)
> +
> +maintainers:
> + - Mark Rutland
> +
> +description: |
> + DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> + which transfers the image data from a video memory buffer to an internal
> + LCD interface.
> +
> +properties:
> + compatible:
> +const: sprd,sharkl3-dpu
> +
> + reg:
> +maxItems: 1
> +description:
> + Physical base address and length of the DPU registers set
> +
> + interrupts:
> +maxItems: 1
> +description:
> + The interrupt signal from DPU
> +
> + clocks:
> +minItems: 2
> +
> + clock-names:
> +items:
> + - const: clk_src_128m
> + - const: clk_src_384m
> +
> + power-domains:
> +description: A phandle to DPU power domain node.
maxItems: 1
> +
> + iommus:
> +description: A phandle to DPU iommu node.
maxItems: 1
> +
> + port:
> +type: object
> +description:
> + A port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + That port should be the output endpoint, usually output to
> + the associated DSI.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +dpu: dpu@0x6300 {
> + compatible = "sprd,sharkl3-dpu";
> + reg = <0x0 0x6300 0x0 0x1000>;
> + interrupts = ;
> + clock-names = "clk_src_128m",
> + "clk_src_384m";
> +
> + clocks = <&pll CLK_TWPLL_128M>,
> +<&pll CLK_TWPLL_384M>;
> +
> + dpu_port: port {
> + dpu_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + };
> + };
> +};
Be consistent in indent. Now it is a mix of 6 and 8 spaces.
(My preference is 4 spaces, but 2,4,6,8 are all OK)
End the file with and end statement like this:
...
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master
Hi Kevin.
Nice split of the driver.
Some feedback in the following.
Most to bring the driver up-to-date with what have happened since
we saw it last time.
Keeping up with the changes in drm is not always easy.
Sam
On Tue, Jul 28, 2020 at 06:07:55PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm kms driver, this driver provides support for the
> application framework in Android, Yocto and more.
>
> Application framework can access Unisoc's display internel
> peripherals through libdrm or libkms, it's test ok by modetest
> (DRM/KMS test tool) and Android HWComposer.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/sprd/Kconfig| 12 +++
> drivers/gpu/drm/sprd/Makefile | 5 +
> drivers/gpu/drm/sprd/sprd_drm.c | 226
>
> drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
> 6 files changed, 262 insertions(+)
> create mode 100644 drivers/gpu/drm/sprd/Kconfig
> create mode 100644 drivers/gpu/drm/sprd/Makefile
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c4fd57d..7fe7ab91 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -386,6 +386,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
>
> source "drivers/gpu/drm/tidss/Kconfig"
>
> +source "drivers/gpu/drm/sprd/Kconfig"
> +
> # Keep legacy drivers last
>
> menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c0e5a7..ee2ccd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -123,3 +123,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
> obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> obj-$(CONFIG_DRM_MCDE) += mcde/
> obj-$(CONFIG_DRM_TIDSS) += tidss/
> +obj-$(CONFIG_DRM_SPRD) += sprd/
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 000..b189a54
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs Platform"
> + depends on ARCH_SPRD || COMPILE_TEST
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DSI
> + help
> + Choose this option if you have a Unisoc chipsets.
> + If M is selected the module will be called sprd-drm.
> +
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> new file mode 100644
> index 000..86d95d9
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +subdir-ccflags-y += -I$(srctree)/$(src)
subdir-ccflags-y is not needed - drop it.
> +
> +obj-y := sprd_drm.o
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
> new file mode 100644
> index 000..4706185
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> @@ -0,0 +1,226 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sprd_drm.h"
> +
> +#define DRIVER_NAME "sprd"
> +#define DRIVER_DESC "Spreadtrum SoCs' DRM Driver"
> +#define DRIVER_DATE "20200201"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper
> = {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
> +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> + .fb_create = drm_gem_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static void sprd_drm_mode_config_init(struct drm_device *drm)
> +{
> + drm_mode_config_init(drm);
The documentation of this functions says:
FIXME: This function is deprecated and drivers should be converted over to
drmm_mode_config_init().
> +
> + drm->mode_config.min_width = 0;
> + drm->mode_config.min_height = 0;
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + drm->mode_config.allow_fb_modifiers = true;
> +
> + drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
> + drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
> +}
> +
> +DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
> +
> +static struct drm_driver sprd_drm_drv = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .fops = &sprd_drm_fops,
> +
> + /* GEM Operations */
> + DRM_GEM_CMA_VMAP_DRIVER_OPS,
>
RE: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>-Original Message-
>From: Ben Skeggs
>Sent: Tuesday, July 28, 2020 4:16 PM
>To: Ruhl, Michael J
>Cc: Dave Airlie ; dri-devel@lists.freedesktop.org;
>bske...@redhat.com
>Subject: Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J
>wrote:
>>
>> >-Original Message-
>> >From: dri-devel On Behalf Of
>> >Dave Airlie
>> >Sent: Monday, July 27, 2020 11:26 PM
>> >To: dri-devel@lists.freedesktop.org
>> >Cc: bske...@redhat.com
>> >Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>> >
>> >From: Dave Airlie
>> >
>> >Instead of rolling driver copies of them.
>> >
>> >v2: cleanup return handling (Ben)
>> >Signed-off-by: Dave Airlie
>> >---
>> > drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++--
>> > 1 file changed, 2 insertions(+), 36 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >index 7806278dce57..6ef5085c9a91 100644
>> >--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >@@ -1231,8 +1231,6 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>> >struct ttm_operation_ctx *ctx)
>> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
>> > struct nouveau_drm *drm;
>> > struct device *dev;
>> >- unsigned i;
>> >- int r;
>> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>> >
>> > if (ttm->state != tt_unpopulated)
>> >@@ -1260,31 +1258,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>> >struct ttm_operation_ctx *ctx)
>> > return ttm_dma_populate((void *)ttm, dev, ctx);
>> > }
>> > #endif
>> >-
>> >- r = ttm_pool_populate(ttm, ctx);
>> >- if (r) {
>> >- return r;
>> >- }
>> >-
>> >- for (i = 0; i < ttm->num_pages; i++) {
>> >- dma_addr_t addr;
>> >-
>> >- addr = dma_map_page(dev, ttm->pages[i], 0, PAGE_SIZE,
>> >- DMA_BIDIRECTIONAL);
>> >-
>> >- if (dma_mapping_error(dev, addr)) {
>> >- while (i--) {
>> >- dma_unmap_page(dev, ttm_dma-
>> >>dma_address[i],
>> >- PAGE_SIZE,
>> >DMA_BIDIRECTIONAL);
>> >- ttm_dma->dma_address[i] = 0;
>> >- }
>> >- ttm_pool_unpopulate(ttm);
>> >- return -EFAULT;
>> >- }
>> >-
>> >- ttm_dma->dma_address[i] = addr;
>> >- }
>> >- return 0;
>> >+ return ttm_populate_and_map_pages(dev, ttm_dma, ctx);
>>
>> This is not a completely straight code replacement.
>>
>> ttm_populate_and_map_pages() also has code to deal with pages that are
>> contiguous (consolidates them).
>>
>> Is it possible that the nouveau HW can't handle a contiguous buffer larger
>> than PAG_SIZE?
>I think it's fine. The function appears to consolidate the pages for
>the dma_map_page() call, but otherwise leave dma_address[] in
>PAGE_SIZE chunks, I don't believe anything else in the driver will
>care.
Ahh.. I misread it. This is limiting the calls to dma_map_page(). Instead
of calling it for each page, just do it for the first one...
Thanks for setting me straight. 😊
Reviewed-by: Michael J. Ruhl
Mike
>Ben.
>
>>
>> Thanks,
>>
>> Mike
>>
>> > }
>> >
>> > static void
>> >@@ -1293,7 +1267,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
>> > struct nouveau_drm *drm;
>> > struct device *dev;
>> >- unsigned i;
>> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>> >
>> > if (slave)
>> >@@ -1316,14 +1289,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt
>*ttm)
>> > }
>> > #endif
>> >
>> >- for (i = 0; i < ttm->num_pages; i++) {
>> >- if (ttm_dma->dma_address[i]) {
>> >- dma_unmap_page(dev, ttm_dma->dma_address[i],
>> >PAGE_SIZE,
>> >- DMA_BIDIRECTIONAL);
>> >- }
>> >- }
>> >-
>> >- ttm_pool_unpopulate(ttm);
>> >+ ttm_unmap_and_unpopulate_pages(dev, ttm_dma);
>> > }
>> >
>> > void
>> >--
>> >2.26.2
>> >
>> >___
>> >dri-devel mailing list
>> >dri-devel@lists.freedesktop.org
>> >https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings
Hi Kevin
On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> .../devicetree/bindings/display/sprd/drm.yaml | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml
> b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> new file mode 100644
> index 000..b5792c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
drm seems like a sub-optimal name.
How about usign the compatible name "display-subsystem" as it is a bit
more specific (but not good).
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: GPL-2.0
Any chance this can be (GPL-2.0-only OR BSD-2-Clause).
I noticed that for example clock/sprd,sc9863a-clk.yaml uses this license
so I hope this is OK.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc DRM master device
> +
> +maintainers:
> + - Mark Rutland
> +
> +description: |
> + The Unisoc DRM master device is a virtual device needed to list all
> + DPU devices or other display interface nodes that comprise the
> + graphics subsystem.
> +
> +properties:
> + compatible:
> +const: sprd,display-subsystem
> +
> + ports:
> +description:
> + Should contain a list of phandles pointing to display interface port
> + of DPU devices.
Add type - like this:
$ref: /schemas/types.yaml#/definitions/phandle-array
See for example display/rockchip/rockchip-drm.yaml
Any specific reason why this is not a ports node like used by many other
display bindings?
In other words - I think this is too simple.
> +
> +required:
> + - compatible
> + - ports
> +
Add:
additionalProperties: false
so we catch if other properties sneak in.
> +examples:
> + - |
> +display-subsystem {
> +compatible = "sprd,display-subsystem";
> +ports = <&dpu_out>;
> +};
> +
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Small cleanups to ingenic-drm driver
Hi Paul. On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote: > Here are a few cleanups to the ingenic-drm driver. > - some error paths were missing and have been added; > - the mode validation has been moved to the .mode_valid helper callback. > > Cheers, > -Paul > > Paul Cercueil (2): > drm/ingenic: Handle errors of drm_atomic_get_plane_state > drm/ingenic: Validate mode in a .mode_valid callback Both looks fine, you can add my: Reviewed-by: Sam Ravnborg I assume you will apply the patches. Maybe wait for Daniel to take a look, he had some feedback on where to add checks. I assume this is covered by the second patch. Sam > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +++ > 1 file changed, 27 insertions(+), 14 deletions(-) > > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J wrote:
>
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Dave Airlie
> >Sent: Monday, July 27, 2020 11:26 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: bske...@redhat.com
> >Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
> >
> >From: Dave Airlie
> >
> >Instead of rolling driver copies of them.
> >
> >v2: cleanup return handling (Ben)
> >Signed-off-by: Dave Airlie
> >---
> > drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++--
> > 1 file changed, 2 insertions(+), 36 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >index 7806278dce57..6ef5085c9a91 100644
> >--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >@@ -1231,8 +1231,6 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
> >struct ttm_operation_ctx *ctx)
> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
> > struct nouveau_drm *drm;
> > struct device *dev;
> >- unsigned i;
> >- int r;
> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> >
> > if (ttm->state != tt_unpopulated)
> >@@ -1260,31 +1258,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
> >struct ttm_operation_ctx *ctx)
> > return ttm_dma_populate((void *)ttm, dev, ctx);
> > }
> > #endif
> >-
> >- r = ttm_pool_populate(ttm, ctx);
> >- if (r) {
> >- return r;
> >- }
> >-
> >- for (i = 0; i < ttm->num_pages; i++) {
> >- dma_addr_t addr;
> >-
> >- addr = dma_map_page(dev, ttm->pages[i], 0, PAGE_SIZE,
> >- DMA_BIDIRECTIONAL);
> >-
> >- if (dma_mapping_error(dev, addr)) {
> >- while (i--) {
> >- dma_unmap_page(dev, ttm_dma-
> >>dma_address[i],
> >- PAGE_SIZE,
> >DMA_BIDIRECTIONAL);
> >- ttm_dma->dma_address[i] = 0;
> >- }
> >- ttm_pool_unpopulate(ttm);
> >- return -EFAULT;
> >- }
> >-
> >- ttm_dma->dma_address[i] = addr;
> >- }
> >- return 0;
> >+ return ttm_populate_and_map_pages(dev, ttm_dma, ctx);
>
> This is not a completely straight code replacement.
>
> ttm_populate_and_map_pages() also has code to deal with pages that are
> contiguous (consolidates them).
>
> Is it possible that the nouveau HW can't handle a contiguous buffer larger
> than PAG_SIZE?
I think it's fine. The function appears to consolidate the pages for
the dma_map_page() call, but otherwise leave dma_address[] in
PAGE_SIZE chunks, I don't believe anything else in the driver will
care.
Ben.
>
> Thanks,
>
> Mike
>
> > }
> >
> > static void
> >@@ -1293,7 +1267,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
> > struct nouveau_drm *drm;
> > struct device *dev;
> >- unsigned i;
> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> >
> > if (slave)
> >@@ -1316,14 +1289,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> > }
> > #endif
> >
> >- for (i = 0; i < ttm->num_pages; i++) {
> >- if (ttm_dma->dma_address[i]) {
> >- dma_unmap_page(dev, ttm_dma->dma_address[i],
> >PAGE_SIZE,
> >- DMA_BIDIRECTIONAL);
> >- }
> >- }
> >-
> >- ttm_pool_unpopulate(ttm);
> >+ ttm_unmap_and_unpopulate_pages(dev, ttm_dma);
> > }
> >
> > void
> >--
> >2.26.2
> >
> >___
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
Hi,
On 7/28/20 9:36 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clock-divider
setting of 1 means that the PWM output is running at 6 MHZ, if that
is true, where do these 256 duty-cycle steps come from?
This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
seems unlikely for a PMIC which is using a silicon process optimized for
power-switching transistors. It is way more likely that there is an 8
bit counter for the duty cycle which acts as an extra fixed divider
wrt the PWM output frequency.
The main user of the pwm-crc driver is the i915 GPU driver which uses it
for backlight control. Lets compare the PWM register values set by the
video-BIOS (the GOP), assuming the extra fixed divider is present versus
the PWM frequency specified in the Video-BIOS-Tables:
Device: PWM Hz set by BIOS PWM Hz specified in VBT
Asus T100TA 200 200
Asus T100HA 200 200
Lenovo Miix 2 8 23437 2
Toshiba WT8-A 23437 2
So as we can see if we assume the extra division by 256 then the register
values set by the GOP are an exact match for the VBT values, where as
otherwise the values would be of by a factor of 256.
This commit fixes the period / duty_cycle calculations to take the
extra division by 256 into account.
So, base clock is 6MHz, then 7 bit divisor. That's what original values
were for. On top of that there is 8-bit duty cycle control ("divide by 256"
whatever it means) with the output range 23.437kHz..183Hz.
Right, so that range matches with a clock div of 1*256 (6 MHz/256 = 23437.5KHz)
to 128*256 (6 MHz/(128*256) = 183.1Hz) IOW this patch is correct.
Before this patch the code assumed a clkdiv of 1-128 (*), which leads to a
very different output frequency range.
Regards,
Hans
*) 0-127 really, that is fixed in a followup patch
Signed-off-by: Hans de Goede
---
Changes in v3:
- Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
---
drivers/pwm/pwm-crc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 272eeb071147..c056eb9b858c 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -21,8 +21,8 @@
#define PWM_MAX_LEVEL 0xFF
-#define PWM_BASE_CLK 600 /* 6 MHz */
-#define PWM_MAX_PERIOD_NS 21333/* 46.875KHz */
+#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
+#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
/**
* struct crystalcove_pwm - Crystal Cove PWM controller
@@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct
pwm_device *pwm,
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
- clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
+ clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
Hi,
On 7/28/20 8:57 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.
...
-static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
- const struct pwm_state *state)
+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state, bool from_resume)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret = 0;
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
- pm_runtime_get_sync(chip->dev);
+ if (!from_resume)
+ pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
- if (ret)
+ if (ret && !from_resume)
pm_runtime_put(chip->dev);
} else {
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
- pm_runtime_put(chip->dev);
+
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
}
return ret;
}
Maybe I'm too picky, but I would go even further and split apply to two versions
static int pwm_lpss_apply_on_resume(struct pwm_chip *chip, struct pwm_device
*pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
if (state->enabled)
return pwm_lpss_prepare_enable(lpwm, pwm, state,
!pwm_is_enabled(pwm));
if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
return 0;
}
and another one for !from_resume.
It is a bit picky :) But that is actually not a bad idea, although I would write
it like this for more symmetry with the normal (not on_resume) apply version,
while at it I also renamed the function:
/*
* This is a mirror of pwm_lpss_apply() without pm_runtime reference handling
* for restoring the PWM state on resume.
*/
static int pwm_lpss_restore_state(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret = 0;
if (state->enabled)
ret = pwm_lpss_prepare_enable(lpwm, pwm, state,
!pwm_is_enabled(pwm));
else if (pwm_is_enabled(pwm))
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
return ret;
}
Would that work for you?
+static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ return __pwm_lpss_apply(chip, pwm, state, false);
+}
...
+ ret = __pwm_lpss_apply(&l
Re: [PATCH v5 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper
Hi,
On 7/28/20 8:45 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.
While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.
Reviewed-by: Andy Shevchenko
But see below.
Suggested-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 45 --
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index da9bc3d10104..8a136ba2a583 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct pwm_device
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
}
+static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
+ struct pwm_device *pwm,
+ const struct pwm_state *state,
+ bool enable)
+{
+ int ret;
+
+ ret = pwm_lpss_is_updating(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+ ret = pwm_lpss_wait_for_update(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+ return 0;
+}
+
static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
- int ret;
+ int ret = 0;
We can avoid this change...
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
- ret = pwm_lpss_is_updating(pwm);
- if (ret) {
- pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
- ret = pwm_lpss_wait_for_update(pwm);
- if (ret) {
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+ if (ret)
pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
} else {
- ret = pwm_lpss_is_updating(pwm);
- if (ret)
- return ret;
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- return pwm_lpss_wait_for_update(pwm);
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
...by simple return directly from here. But I admit I haven't seen the next
patch yet.
True, but I'm not a big fan of earlier returns except for errors.
Regards,
Hans
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
pm_runtime_put(chip->dev);
}
- return 0;
+ return ret;
}
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
On Tue, Jul 28, 2020 at 06:12:46PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 27/07/2020 10:13, Roger Pau Monne wrote:
> > > > To be used in order to create foreign mappings. This is based on the
> > > > ZONE_DEVICE facility which is used by persistent memory devices in
> > > > order to create struct pages and kernel virtual mappings for the IOMEM
> > > > areas of such devices. Note that on kernels without support for
> > > > ZONE_DEVICE Xen will fallback to use ballooned pages in order to
> > > > create foreign mappings.
> > > >
> > > > The newly added helpers use the same parameters as the existing
> > > > {alloc/free}_xenballooned_pages functions, which allows for in-place
> > > > replacement of the callers. Once a memory region has been added to be
> > > > used as scratch mapping space it will no longer be released, and pages
> > > > returned are kept in a linked list. This allows to have a buffer of
> > > > pages and prevents resorting to frequent additions and removals of
> > > > regions.
> > > >
> > > > If enabled (because ZONE_DEVICE is supported) the usage of the new
> > > > functionality untangles Xen balloon and RAM hotplug from the usage of
> > > > unpopulated physical memory ranges to map foreign pages, which is the
> > > > correct thing to do in order to avoid mappings of foreign pages depend
> > > > on memory hotplug.
> > > I think this is going to break Dom0 on Arm if the kernel has been built
> > > with
> > > hotplug. This is because you may end up to re-use region that will be used
> > > for the 1:1 mapping of a foreign map.
> > >
> > > Note that I don't know whether hotplug has been tested on Xen on Arm yet.
> > > So
> > > it might be possible to be already broken.
> > >
> > > Meanwhile, my suggestion would be to make the use of hotplug in the
> > > balloon
> > > code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
> >
> > Right, this feature (allocation of unpopulated memory separated from
> > the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I
> > think could be used on Arm.
> >
> > IMO the right solution seems to be to subtract the physical memory
> > regions that can be used for the identity mappings of foreign pages
> > (all RAM on the system AFAICT) from iomem_resource, as that would make
> > this and the memory hotplug done in the balloon driver safe?
>
> Dom0 doesn't know the regions used for the identity mappings as this is only
> managed by Xen. So there is nothing you can really do here.
OK, I will add the guards to prevent this being built on Arm.
> But don't you have the same issue on x86 with "magic pages"?
Those are marked as reserved on the memory map, and hence I would
expect them to never end up in iomem_resource.
Thanks, Roger.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 1/3] dt-bindings: Add vendor prefix for Powertip
The Powertip Tech. Corp. is an LCD panel manufacturer. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Eric Anholt Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- V2: No change --- 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 f3d847832fdc..5b1343a8d198 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -830,6 +830,8 @@ patternProperties: description: Poslab Technology Co., Ltd. "^pov,.*": description: Point of View International B.V. + "^powertip,.*": +description: Powertip Tech. Corp. "^powervr,.*": description: PowerVR (deprecated, use img) "^primux,.*": -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle are made.
>
> This problem has been masked so far because the main consumer
> (the i915 driver) was always making duty-cycle changes on resume.
> With the conversion of the i915 driver to the atomic PWM API the
> driver now only disables/enables the PWM on suspend/resume leaving
> the output-freq and duty as is, triggering this problem.
>
> The LPSS PWM controller has a mechanism where the ctrl register value
> and the actual base-unit and on-time-div values used are latched. When
> software sets the SW_UPDATE bit then at the end of the current PWM cycle,
> the new values from the ctrl-register will be latched into the actual
> registers, and the SW_UPDATE bit will be cleared.
>
> The problem is that before this commit our suspend/resume handling
> consisted of simply saving the PWM ctrl register on suspend and
> restoring it on resume, without setting the PWM_SW_UPDATE bit.
> When the controller has lost its state over a suspend/resume and thus
> has been reset to the defaults, just restoring the register is not
> enough. We must also set the SW_UPDATE bit to tell the controller to
> latch the restored values into the actual registers.
>
> Fixing this problem is not as simple as just or-ing in the value which
> is being restored with SW_UPDATE. If the PWM was enabled before we must
> write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
> We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
> model we must do this either before or after the setting of PWM_ENABLE.
>
> All the necessary logic for doing this is already present inside
> pwm_lpss_apply(), so instead of duplicating this inside the resume
> handler, this commit makes the resume handler use pwm_lpss_apply() to
> restore the settings when necessary. This fixes the output-freq and
> duty-cycle being reset to their defaults on resume.
...
> -static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> - const struct pwm_state *state)
> +static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state, bool from_resume)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> int ret = 0;
>
> if (state->enabled) {
> if (!pwm_is_enabled(pwm)) {
> - pm_runtime_get_sync(chip->dev);
> + if (!from_resume)
> + pm_runtime_get_sync(chip->dev);
> +
> ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
> - if (ret)
> + if (ret && !from_resume)
> pm_runtime_put(chip->dev);
> } else {
> ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
> }
> } else if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> - pm_runtime_put(chip->dev);
> +
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> }
>
> return ret;
> }
Maybe I'm too picky, but I would go even further and split apply to two versions
static int pwm_lpss_apply_on_resume(struct pwm_chip *chip, struct pwm_device
*pwm,
const struct pwm_state *state)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
>
> if (state->enabled)
> return pwm_lpss_prepare_enable(lpwm, pwm, state,
> !pwm_is_enabled(pwm));
> if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> return 0;
> }
and another one for !from_resume.
> +static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + return __pwm_lpss_apply(chip, pwm, state, false);
> +}
...
> + ret = __pwm_lpss_apply(&lpwm->chip, pwm, &saved_state, true);
> + if (ret)
> + dev_err(dev, "Error restoring state on resume\n");
I'm wondering if it's a real error why we do not bail out?
Otherwise dev_warn() ?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/sun4i: backend: Disable alpha on the lowest plane on the A20
Unlike we previously thought, the per-pixel alpha is just as broken on the
A20 as it is on the A10. Remove the quirk that says we can use it.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
alpha support")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 6d0f0526515f..24574bef28f9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -994,7 +994,6 @@ static const struct sun4i_backend_quirks
sun6i_backend_quirks = {
static const struct sun4i_backend_quirks sun7i_backend_quirks = {
.needs_output_muxing = true,
- .supports_lowest_plane_alpha = true,
};
static const struct sun4i_backend_quirks sun8i_a33_backend_quirks = {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/sun4i: backend: Support alpha property on lowest plane
Unlike what we previously thought, only the per-pixel alpha is broken on
the lowest plane and the per-plane alpha isn't. Remove the check on the
alpha property being set on the lowest plane to reject a mode.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
alpha support")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 072ea113e6be..6d0f0526515f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -589,7 +589,6 @@ static int sun4i_backend_atomic_check(struct sunxi_engine
*engine,
/* We can't have an alpha plane at the lowest position */
if (!backend->quirks->supports_lowest_plane_alpha &&
- (plane_states[0]->fb->format->has_alpha ||
(plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE)))
return -EINVAL;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-kernel-mentees] [PATCH v2] drm/bufs: Prevent kernel-infoleak in copy_one_buf()
On Tue, Jul 28, 2020 at 12:35:17PM +, David Laight wrote:
> From: Peilin Ye
> > Sent: 28 July 2020 12:52
> > Currently `struct drm_buf_desc` is defined as follows:
> >
> > struct drm_buf_desc {
> > int count;
> > int size;
> > int low_mark;
> > int high_mark;
> > enum {
> > _DRM_PAGE_ALIGN = 0x01,
> > _DRM_AGP_BUFFER = 0x02,
> > _DRM_SG_BUFFER = 0x04,
> > _DRM_FB_BUFFER = 0x08,
> > _DRM_PCI_BUFFER_RO = 0x10
> > } flags;
> > unsigned long agp_start;
> > };
> >
> > copy_one_buf() is potentially copying uninitialized kernel stack memory
> > to userspace, since the compiler may leave such "holes" (around `.flags`
> > and `.agp_start` fields) in this statically allocated structure. Prevent
> > it by initializing `v` with memset().
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
> > Suggested-by: Dan Carpenter
> > Acked-by: Arnd Bergmann
> > Signed-off-by: Peilin Ye
> > ---
> > Change in v2:
> > - Improve commit description. (Suggested by Arnd Bergmann
> > )
> >
> > drivers/gpu/drm/drm_bufs.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> > index a0735fbc144b..f99cd4a3f951 100644
> > --- a/drivers/gpu/drm/drm_bufs.c
> > +++ b/drivers/gpu/drm/drm_bufs.c
> > @@ -1349,10 +1349,14 @@ static int copy_one_buf(void *data, int count,
> > struct drm_buf_entry *from)
> > {
> > struct drm_buf_info *request = data;
> > struct drm_buf_desc __user *to = &request->list[count];
> > - struct drm_buf_desc v = {.count = from->buf_count,
> > -.size = from->buf_size,
> > -.low_mark = from->low_mark,
> > -.high_mark = from->high_mark};
> > + struct drm_buf_desc v;
> > +
> > + memset(&v, 0, sizeof(v));
> > +
> > + v.count = from->buf_count;
> > + v.size = from->buf_size;
> > + v.low_mark = from->low_mark;
> > + v.high_mark = from->high_mark;
> >
> > if (copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags)))
> > return -EFAULT;
>
> The memset() isn't needed.
> The copy_to_user() stops after the 4 'int' values so no 'random'
> kernel stack can get copied.
You are right, I overlooked that. Thank you for pointing this out!
Peilin Ye
> Quite why it is 'right' to leave the remaining part of each
> userspace structure unchanged is another matter.
>
> David.
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/mediatek: dpi/dsi: change the getting possible_crtc way
From: Jitao Shi
[Detail]
dpi/dsi get the possible_crtc by
mtk_drm_find_possible_crtc_by_comp(*drm_dev, ddp_comp)
Test: build pass and boot to logo
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..e43977015843 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -608,7 +608,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
/* Currently DPI0 is fixed to be driven by OVL1 */
- dpi->encoder.possible_crtcs = BIT(1);
+ dpi->encoder.possible_crtcs =
+ mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->ddp_comp);
ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
if (ret) {
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 270bf22c98fe..c31d9c12d4a9 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -892,7 +892,8 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
* Currently display data paths are statically assigned to a crtc each.
* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
*/
- dsi->encoder.possible_crtcs = 1;
+ dsi->encoder.possible_crtcs =
+ mtk_drm_find_possible_crtc_by_comp(drm, dsi->ddp_comp);
/* If there's a bridge, attach to it and let it create the connector */
if (dsi->bridge) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-kernel-mentees] [PATCH] drm/bufs: Prevent kernel-infoleak in copy_one_buf()
On Tue, Jul 28, 2020 at 10:11:09AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 28, 2020 at 3:45 AM Peilin Ye wrote:
> >
> > copy_one_buf() is copying uninitialized stack memory to userspace due to
> > the compiler not initializing holes in statically allocated structures.
> > Fix it by initializing `v` with memset().
>
> I would add 'potentially' somewhere in that description: it is architecture
> dependent whether there are holes in this structure as 'enum' types
> and 'long' are both dependent on the ABI, and even if there is a hole,
> it is undefined behavior whether the hold gets initialized.
I see. I will fix that up. Thank you for the advice!
Peilin Ye
> Other than that, the patch looks good.
>
> > Cc: sta...@vger.kernel.org
> > Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
> > Suggested-by: Dan Carpenter
> > Signed-off-by: Peilin Ye
>
> Acked-by: Arnd Bergmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/mediatek: config component output by device node port
From: Bibby Hsieh
We can select output component by decive node port.
Main path default output component is DSI.
External path default output component is DPI.
without this Patch i get this warning:
WARNING: CPU: 3 PID: 70 at drivers/gpu/drm/drm_mode_config.c:621
drm_mode_config_validate+0x1d8/0x258
Signed-off-by: Bibby Hsieh
added small fixes for warnings
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 46 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 +--
2 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6bd369434d9d..ce7abf2743d9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp.h"
@@ -61,7 +68,7 @@ static const struct drm_mode_config_funcs
mtk_drm_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
+static enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_COLOR0,
@@ -69,12 +76,12 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
DDP_COMPONENT_DSI0,
};
-static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
+static enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_DPI0,
};
-static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
+static enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL0,
@@ -84,7 +91,7 @@ static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
DDP_COMPONENT_PWM0,
};
-static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
+static enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_AAL1,
@@ -100,7 +107,7 @@ static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
DDP_COMPONENT_PWM2,
};
-static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
+static enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL0,
@@ -111,7 +118,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_PWM0,
};
-static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
+static enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_GAMMA,
@@ -459,6 +466,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(phandle->parent, node) {
+ struct device_node *port, *ep, *remote;
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -522,6 +530,32 @@ static int mtk_drm_probe(struct platform_device *pdev)
private->ddp_comp[comp_id] = comp;
}
+
+ if (comp_type != MTK_DSI && comp_type != MTK_DPI) {
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ continue;
+ ep = of_get_child_by_name(port, "endpoint");
+ of_node_put(port);
+ if (!ep)
+ continue;
+ remote = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ if (!remote)
+ continue;
+ of_id = of_match_node(mtk_ddp_comp_dt_ids, remote);
+ if (!of_id)
+ continue;
+ comp_type = (enum mtk_ddp_comp_type)of_id->data;
+ for (i = 0; i < private->data->main_len - 1; i++)
+ if (private->data->main_path[i] == comp_id)
+ private->data->main_path[i + 1] =
+ mtk_ddp_comp_get_id(node, comp_type);
+ for (i = 0; i < private->data->ext_len - 1; i++)
+ if (private->data->ext_path[i] == comp_id)
+ private->data->ext_path[i + 1] =
+ mtk_ddp_comp_get_id(node, comp_type);
+ }
}
if (!private->mutex_node) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index b5be63e53176..7fcaab648bf1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/g
[PATCH 2/2] drm/ingenic: Validate mode in a .mode_valid callback
Validate modes in the drm_crtc_helper_funcs.mode_valid() callback, which
is designed for this purpose, instead of doing it in
drm_crtc_helper_funcs.atomic_check().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +--
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 64eabab3ef69..5dab9c3d0a52 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -199,21 +199,8 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
struct drm_plane_state *f1_state, *f0_state, *ipu_state = NULL;
- long rate;
-
- if (!drm_atomic_crtc_needs_modeset(state))
- return 0;
-
- if (state->mode.hdisplay > priv->soc_info->max_width ||
- state->mode.vdisplay > priv->soc_info->max_height)
- return -EINVAL;
- rate = clk_round_rate(priv->pix_clk,
- state->adjusted_mode.clock * 1000);
- if (rate < 0)
- return rate;
-
- if (priv->soc_info->has_osd) {
+ if (drm_atomic_crtc_needs_modeset(state) && priv->soc_info->has_osd) {
f1_state = drm_atomic_get_plane_state(state->state, &priv->f1);
if (IS_ERR(f1_state))
return PTR_ERR(f1_state);
@@ -242,6 +229,24 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
return 0;
}
+static enum drm_mode_status
+ingenic_drm_crtc_mode_valid(struct drm_crtc *crtc, const struct
drm_display_mode *mode)
+{
+ struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ long rate;
+
+ if (mode->hdisplay > priv->soc_info->max_width)
+ return MODE_BAD_HVALUE;
+ if (mode->vdisplay > priv->soc_info->max_height)
+ return MODE_BAD_VVALUE;
+
+ rate = clk_round_rate(priv->pix_clk, mode->clock * 1000);
+ if (rate < 0)
+ return MODE_CLOCK_RANGE;
+
+ return MODE_OK;
+}
+
static void ingenic_drm_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *oldstate)
{
@@ -655,6 +660,7 @@ static const struct drm_crtc_helper_funcs
ingenic_drm_crtc_helper_funcs = {
.atomic_begin = ingenic_drm_crtc_atomic_begin,
.atomic_flush = ingenic_drm_crtc_atomic_flush,
.atomic_check = ingenic_drm_crtc_atomic_check,
+ .mode_valid = ingenic_drm_crtc_mode_valid,
};
static const struct drm_encoder_helper_funcs ingenic_drm_encoder_helper_funcs
= {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
Hi Roger,
On 28/07/2020 17:59, Roger Pau Monné wrote:
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
I think this is going to break Dom0 on Arm if the kernel has been built with
hotplug. This is because you may end up to re-use region that will be used
for the 1:1 mapping of a foreign map.
Note that I don't know whether hotplug has been tested on Xen on Arm yet. So
it might be possible to be already broken.
Meanwhile, my suggestion would be to make the use of hotplug in the balloon
code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
Right, this feature (allocation of unpopulated memory separated from
the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I
think could be used on Arm.
IMO the right solution seems to be to subtract the physical memory
regions that can be used for the identity mappings of foreign pages
(all RAM on the system AFAICT) from iomem_resource, as that would make
this and the memory hotplug done in the balloon driver safe?
Dom0 doesn't know the regions used for the identity mappings as this is
only managed by Xen. So there is nothing you can really do here.
But don't you have the same issue on x86 with "magic pages"?
Cheers,
--
Julien Grall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/mediatek: fix boot up for 720 and 480 but 1080
From: chunhui dai
- disable tmds on phy on mt2701
- support other resolutions like 1280x1024
without this Patch i see flickering on my TFT (1280x1024),
so i guess clock is wrong.
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 5223498502c4..edadb7a700f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -184,6 +184,9 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy_provider);
}
+ if (hdmi_phy->conf->pll_default_off)
+ hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy);
+
return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
hdmi_phy->pll);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 2d8b3182470d..f472fdeb63dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -22,6 +22,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
unsigned long flags;
+ bool pll_default_off;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index d3cc4022e988..6fbedacfc1e8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -239,6 +239,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
.flags = CLK_SET_RATE_GATE,
+ .pll_default_off = true,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] drm/panel: simple: Add DT bindings for Powertip PH800480T013
Add support for Powertip PH800480T013 800x480 parallel LCD, this
one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
V2: Add bus_flags and connector_type
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cb6550d37e85..298e3a26d9ee 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3000,6 +3000,31 @@ static const struct panel_desc pda_91_00156_a0 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode powertip_ph800480t013_idf02_mode = {
+ .clock = 24750,
+ .hdisplay = 800,
+ .hsync_start = 800 + 54,
+ .hsync_end = 800 + 54 + 2,
+ .htotal = 800 + 54 + 2 + 44,
+ .vdisplay = 480,
+ .vsync_start = 480 + 49,
+ .vsync_end = 480 + 49 + 2,
+ .vtotal = 480 + 49 + 2 + 22,
+};
+
+static const struct panel_desc powertip_ph800480t013_idf02 = {
+ .modes = &powertip_ph800480t013_idf02_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
@@ -4012,6 +4037,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "pda,91-00156-a0",
.data = &pda_91_00156_a0,
+ }, {
+ .compatible = "powertip,ph800480t013-idf02",
+ .data = &powertip_ph800480t013_idf02,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
On Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote:
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> >> Hi,
> >>
> >> On 27/07/2020 10:13, Roger Pau Monne wrote:
> >>> To be used in order to create foreign mappings. This is based on the
> >>> ZONE_DEVICE facility which is used by persistent memory devices in
> >>> order to create struct pages and kernel virtual mappings for the IOMEM
> >>> areas of such devices. Note that on kernels without support for
> >>> ZONE_DEVICE Xen will fallback to use ballooned pages in order to
> >>> create foreign mappings.
> >>>
> >>> The newly added helpers use the same parameters as the existing
> >>> {alloc/free}_xenballooned_pages functions, which allows for in-place
> >>> replacement of the callers. Once a memory region has been added to be
> >>> used as scratch mapping space it will no longer be released, and pages
> >>> returned are kept in a linked list. This allows to have a buffer of
> >>> pages and prevents resorting to frequent additions and removals of
> >>> regions.
> >>>
> >>> If enabled (because ZONE_DEVICE is supported) the usage of the new
> >>> functionality untangles Xen balloon and RAM hotplug from the usage of
> >>> unpopulated physical memory ranges to map foreign pages, which is the
> >>> correct thing to do in order to avoid mappings of foreign pages depend
> >>> on memory hotplug.
> >> I think this is going to break Dom0 on Arm if the kernel has been built
> >> with
> >> hotplug. This is because you may end up to re-use region that will be used
> >> for the 1:1 mapping of a foreign map.
> >>
> >> Note that I don't know whether hotplug has been tested on Xen on Arm yet.
> >> So
> >> it might be possible to be already broken.
> >>
> >> Meanwhile, my suggestion would be to make the use of hotplug in the balloon
> >> code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
> > Right, this feature (allocation of unpopulated memory separated from
> > the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I
> > think could be used on Arm.
> >
> > IMO the right solution seems to be to subtract the physical memory
> > regions that can be used for the identity mappings of foreign pages
> > (all RAM on the system AFAICT) from iomem_resource, as that would make
> > this and the memory hotplug done in the balloon driver safe?
>
> The right solution is a mechanism for translated guests to query Xen to
> find regions of guest physical address space which are unused, and can
> be safely be used for foreign/grant/other mappings.
>
> Please don't waste any more time applying more duct tape to a broken
> system, and instead spend the time organising some proper foundations.
The piece added here (using ZONE_DEVICE) will be relevant when Xen can
provide the space to map foreign pages, it's just that right now it
relies on iomem_resource instead of a Xen specific resource map that
should be provided by the hypervisor. It should indeed be fixed, but
right now this patch should allow a PVH dom0 to work slightly better.
When Xen provides such areas Linux just needs to populate a custom Xen
resource with them and use it instead of iomem_resurce.
The Arm stuff I'm certainly not familiar with, and can't provide much
insight on that. If it's best to just disable it and continue to rely
on ballooned out pages that's fine.
Roger.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
I think this is going to break Dom0 on Arm if the kernel has been built
with hotplug. This is because you may end up to re-use region that will
be used for the 1:1 mapping of a foreign map.
Note that I don't know whether hotplug has been tested on Xen on Arm
yet. So it might be possible to be already broken.
Meanwhile, my suggestion would be to make the use of hotplug in the
balloon code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
Cheers,
--
Julien Grall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm: Add get_possible_crtc API for dpi, dsi
From: Stu Hsieh
Test: build pass and run ok
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 57c88de9a329..a5f2ff6bea93 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+
#include "mtk_drm_drv.h"
#include "mtk_drm_plane.h"
#include "mtk_drm_ddp_comp.h"
@@ -412,6 +414,22 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
};
+static bool mtk_drm_find_comp_in_ddp(struct mtk_ddp_comp ddp_comp,
+const enum mtk_ddp_comp_id *path,
+unsigned int path_len)
+{
+ unsigned int i;
+
+ if (path == NULL)
+ return false;
+
+ for (i = 0U; i < path_len; i++)
+ if (ddp_comp.id == path[i])
+ return true;
+
+ return false;
+}
+
int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type)
{
@@ -427,6 +445,30 @@ int mtk_ddp_comp_get_id(struct device_node *node,
return -EINVAL;
}
+unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
+ struct mtk_ddp_comp ddp_comp)
+{
+ struct mtk_drm_private *private = drm->dev_private;
+ unsigned int ret;
+
+ if (mtk_drm_find_comp_in_ddp(ddp_comp, private->data->main_path,
+ private->data->main_len) == true) {
+ ret = BIT(0);
+ } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
+ private->data->ext_path,
+ private->data->ext_len) == true) {
+ ret = BIT(1);
+ } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
+ private->data->third_path,
+ private->data->third_len) == true) {
+ ret = BIT(2);
+ } else {
+ DRM_INFO("Failed to find comp in ddp table\n");
+ ret = 0;
+ }
+ return ret;
+}
+
int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
const struct mtk_ddp_comp_funcs *funcs)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index debe36395fe7..1d9e00b69462 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -202,6 +202,8 @@ static inline void mtk_ddp_ctm_set(struct mtk_ddp_comp
*comp,
int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type);
+unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
+ struct mtk_ddp_comp ddp_comp);
int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
const struct mtk_ddp_comp_funcs *funcs);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Linux-kernel-mentees] [PATCH v2] drm/bufs: Prevent kernel-infoleak in copy_one_buf()
From: Peilin Ye
> Sent: 28 July 2020 12:52
> Currently `struct drm_buf_desc` is defined as follows:
>
> struct drm_buf_desc {
> int count;
> int size;
> int low_mark;
> int high_mark;
> enum {
> _DRM_PAGE_ALIGN = 0x01,
> _DRM_AGP_BUFFER = 0x02,
> _DRM_SG_BUFFER = 0x04,
> _DRM_FB_BUFFER = 0x08,
> _DRM_PCI_BUFFER_RO = 0x10
> } flags;
> unsigned long agp_start;
> };
>
> copy_one_buf() is potentially copying uninitialized kernel stack memory
> to userspace, since the compiler may leave such "holes" (around `.flags`
> and `.agp_start` fields) in this statically allocated structure. Prevent
> it by initializing `v` with memset().
>
> Cc: sta...@vger.kernel.org
> Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
> Suggested-by: Dan Carpenter
> Acked-by: Arnd Bergmann
> Signed-off-by: Peilin Ye
> ---
> Change in v2:
> - Improve commit description. (Suggested by Arnd Bergmann
> )
>
> drivers/gpu/drm/drm_bufs.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index a0735fbc144b..f99cd4a3f951 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -1349,10 +1349,14 @@ static int copy_one_buf(void *data, int count, struct
> drm_buf_entry *from)
> {
> struct drm_buf_info *request = data;
> struct drm_buf_desc __user *to = &request->list[count];
> - struct drm_buf_desc v = {.count = from->buf_count,
> - .size = from->buf_size,
> - .low_mark = from->low_mark,
> - .high_mark = from->high_mark};
> + struct drm_buf_desc v;
> +
> + memset(&v, 0, sizeof(v));
> +
> + v.count = from->buf_count;
> + v.size = from->buf_size;
> + v.low_mark = from->low_mark;
> + v.high_mark = from->high_mark;
>
> if (copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags)))
> return -EFAULT;
The memset() isn't needed.
The copy_to_user() stops after the 4 'int' values so no 'random'
kernel stack can get copied.
Quite why it is 'right' to leave the remaining part of each
userspace structure unchanged is another matter.
David.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Linux folks, Am 25.07.20 um 07:20 schrieb Mazin Rezk: On Saturday, July 25, 2020 12:59 AM, Duncan wrote: On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: Am 24.07.20 um 19:33 schrieb Kees Cook: There was a fix to disable the async path for this driver that worked around the bug too, yes? That seems like a safer and more focused change that doesn't revert the SLUB defense for all users, and would actually provide a complete, I think, workaround That said, I haven't seen the async disabling patch. If you could link to it, I'd be glad to test it out and perhaps we can use that instead. I'm confused. Not to put words in Kees' mouth; /I/ am confused (which admittedly could well be just because I make no claims to be a coder and am simply reading the bug and thread, but I'd appreciate some "unconfusing" anyway). My interpretation of the "async disabling" reference was that it was to comment #30 on the bug: https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 ... which (if I'm not confused on this point too) appears to be yours. There it was stated... I've also found that this bug exclusively occurs when commit_work is on the workqueue. After forcing drm_atomic_helper_commit to run all of the commits without adding to the workqueue and running the OS, the issue seems to have disappeared. Would not forcing all commits to run directly, without placing them on the workqueue, be "async disabling"? That's what I /thought/ he was referencing. Oh, I thought he was referring to a different patch. Kees, could I get your confirmation on this? The change I made actually affected all of the DRM code, although this could easily be changed to be specific to amdgpu. (By forcing blocking on amdgpu_dm's non-blocking commit code) That said, I'd still need to test further because I only did test it for a couple of hours then. Although it should work in theory. OTOH your base/context swap idea sounds like a possibly "less disturbance" workaround, if it works, and given the point in the commit cycle... (But if it's out Sunday it's likely too late to test and get it in now anyway; if it's another week, tho...) The base/context swap idea should make the use-after-free behave how it did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a "less disturbance" workaround and more of a "no disturbance" workaround. Sorry for bothering, but is there now a solution, besides reverting the commits, to avoid freezes/crashes *without* performance regressions? Kind regards, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v5 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi Emil, Sorry, I left for a long time because of other things. Now i'm back~ V6 fix access registers via readl/writel, check unsupported KMS properties (format, rotation, blend mode, etc) by plane_check callback ops and remove always true checks for dpu core ops Add changelog within the corresponding patch from now on, thanks for your advice. BR, Kevin Emil Velikov 于2020年3月20日周五 上午2:07写道： > > Hey Kevin, > > On Sun, 15 Mar 2020 at 23:19, Kevin Tang wrote: > > > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > > > Cc: Orson Zhai > > Cc: Baolin Wang > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > --- > > drivers/gpu/drm/sprd/Makefile | 5 +- > > drivers/gpu/drm/sprd/dpu/Makefile | 7 + > > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 750 > > > > drivers/gpu/drm/sprd/sprd_dpu.c | 501 > > drivers/gpu/drm/sprd/sprd_dpu.h | 170 > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > Seems like v5 (patch at least, I did not look at the rest) does not > address a handful of the feedback. > - Access registers via readl/writel, instead of current approach > - With ^^ you can drop the compiler workaround > - Checking for unsupported KMS properties (format, rotation, etc) > should happen in the XXX_check callbacks > - Remove always true checks, around the (rather moot) abstraction layer > > For the future, please keep the revision/changelog within the > corresponding patch. This way reviewers can see, from the onset, what > is addressed. > Look at `git log -- drivers/gpu/drm` for examples. > > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
> In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
> runtime-pm reference; and then on any errors it needs to release it
> again.
>
> This leads to somewhat hard to read code. This commit introduces a new
> pwm_lpss_prepare_enable() helper and moves all the steps necessary for
> the not-enabled -> enabled transition there, so that we can error check
> the entire transition in a single place and only have one pm_runtime_put()
> on failure call site.
>
> While working on this I noticed that the enabled -> enabled (update
> settings) path was quite similar, so I've added an enable parameter to
> the new pwm_lpss_prepare_enable() helper, which allows using it in that
> path too.
Reviewed-by: Andy Shevchenko
But see below.
> Suggested-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> drivers/pwm/pwm-lpss.c | 45 --
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index da9bc3d10104..8a136ba2a583 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct
> pwm_device *pwm, bool cond)
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
> }
>
> +static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
> +struct pwm_device *pwm,
> +const struct pwm_state *state,
> +bool enable)
> +{
> + int ret;
> +
> + ret = pwm_lpss_is_updating(pwm);
> + if (ret)
> + return ret;
> +
> + pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
> + pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
> + ret = pwm_lpss_wait_for_update(pwm);
> + if (ret)
> + return ret;
> +
> + pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
> + return 0;
> +}
> +
> static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> const struct pwm_state *state)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> - int ret;
> + int ret = 0;
We can avoid this change...
> if (state->enabled) {
> if (!pwm_is_enabled(pwm)) {
> pm_runtime_get_sync(chip->dev);
> - ret = pwm_lpss_is_updating(pwm);
> - if (ret) {
> - pm_runtime_put(chip->dev);
> - return ret;
> - }
> - pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
> state->period);
> - pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
> - ret = pwm_lpss_wait_for_update(pwm);
> - if (ret) {
> + ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
> + if (ret)
> pm_runtime_put(chip->dev);
> - return ret;
> - }
> - pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
> } else {
> - ret = pwm_lpss_is_updating(pwm);
> - if (ret)
> - return ret;
> - pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
> state->period);
> - return pwm_lpss_wait_for_update(pwm);
> + ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
...by simple return directly from here. But I admit I haven't seen the next
patch yet.
> }
> } else if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> pm_runtime_put(chip->dev);
> }
>
> - return 0;
> + return ret;
> }
>
> static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 5/6] dt-bindings: display: add Unisoc's mipi dsi&dphy bindings
From: Kevin Tang
Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dphy.yaml | 75 +
.../devicetree/bindings/display/sprd/dsi.yaml | 98 ++
2 files changed, 173 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/sprd/dphy.yaml
create mode 100644 Documentation/devicetree/bindings/display/sprd/dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/sprd/dphy.yaml
b/Documentation/devicetree/bindings/display/sprd/dphy.yaml
new file mode 100644
index 000..1b83260
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/dphy.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI-PHY (D-PHY)
+
+maintainers:
+ - Mark Rutland
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-phy
+
+ reg:
+maxItems: 1
+description:
+ Must be the dsi controller base address.
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated panel.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DSI controller.
+
+required:
+ - compatible
+ - reg
+ - port@0
+ - port@1
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+dphy: dphy {
+compatible = "sprd,sharkl3-dsi-phy";
+reg = <0x0 0x6310 0x0 0x1000>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* input port*/
+port@1 {
+reg = <1>;
+dphy_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+};
+};
+
+/* output port */
+port@0 {
+ reg = <0>;
+ dphy_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+};
+};
diff --git a/Documentation/devicetree/bindings/display/sprd/dsi.yaml
b/Documentation/devicetree/bindings/display/sprd/dsi.yaml
new file mode 100644
index 000..d89d957
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/dsi.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI Master
+
+maintainers:
+ - Mark Rutland
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-host
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the registers set for the device.
+
+ interrupts:
+maxItems: 2
+description:
+ Should contain DSI interrupt.
+
+ clocks:
+minItems: 1
+
+ clock-names:
+items:
+ - const: clk_src_96m
+
+ power-domains:
+maxItems: 1
+description: A phandle to DSIM power domain node
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DPU.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DPHY.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port@0
+ - port@1
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dsi: dsi@0x6310 {
+compatible = "sprd,sharkl3-dsi-host";
+reg = <0 0x6310 0 0x1000>;
+interrupts = ,
+ ;
+clock-names = "clk_src_96m";
+clocks = <&pll CLK_TWPLL_96M>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <&dpu_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out: endpoint@1 {
+remote-endpoint = <&dphy_in>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.fre
[PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/drm.yaml | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml
b/Documentation/devicetree/bindings/display/sprd/drm.yaml
new file mode 100644
index 000..b5792c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc DRM master device
+
+maintainers:
+ - Mark Rutland
+
+description: |
+ The Unisoc DRM master device is a virtual device needed to list all
+ DPU devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: sprd,display-subsystem
+
+ ports:
+description:
+ Should contain a list of phandles pointing to display interface port
+ of DPU devices.
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+display-subsystem {
+compatible = "sprd,display-subsystem";
+ports = <&dpu_out>;
+};
+
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 2/3] dt-bindings: Add DT bindings for Powertip PH800480T013
Add DT bindings for Powertip PH800480T013 800x480 parallel LCD, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Eric Anholt Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- V2: Add the bindings to panel-simple.yaml --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 6dd59e59..5a0af2b80aba 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -219,6 +219,8 @@ properties: - osddisplays,osd070t1718-19ts # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel - osddisplays,osd101t2045-53ts +# POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel + - powertip,ph800480t013-idf02 # QiaoDian XianShi Corporation 4"3 TFT LCD panel - qiaodian,qd43003c0-40 # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800 -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
From: Kevin Tang
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sprd/Makefile |7 +-
drivers/gpu/drm/sprd/disp_lib.c | 57 +
drivers/gpu/drm/sprd/disp_lib.h | 16 +
drivers/gpu/drm/sprd/dphy/Makefile|7 +
drivers/gpu/drm/sprd/dphy/pll/Makefile|3 +
drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c | 473 +++
drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c | 201 +++
drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h | 22 +
drivers/gpu/drm/sprd/dsi/Makefile |8 +
drivers/gpu/drm/sprd/dsi/core/Makefile|4 +
drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c | 964 ++
drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h | 1477 +
drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.c | 328 +
drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h | 32 +
drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c | 590
drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h | 26 +
drivers/gpu/drm/sprd/sprd_dphy.c | 209 +++
drivers/gpu/drm/sprd/sprd_dphy.h | 50 +
drivers/gpu/drm/sprd/sprd_dpu.c | 22 +
drivers/gpu/drm/sprd/sprd_dpu.h |3 +
drivers/gpu/drm/sprd/sprd_dsi.c | 571
drivers/gpu/drm/sprd/sprd_dsi.h | 108 ++
22 files changed, 5177 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sprd/disp_lib.c
create mode 100644 drivers/gpu/drm/sprd/disp_lib.h
create mode 100644 drivers/gpu/drm/sprd/dphy/Makefile
create mode 100644 drivers/gpu/drm/sprd/dphy/pll/Makefile
create mode 100644 drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c
create mode 100644 drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c
create mode 100644 drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h
create mode 100644 drivers/gpu/drm/sprd/dsi/Makefile
create mode 100644 drivers/gpu/drm/sprd/dsi/core/Makefile
create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c
create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h
create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.c
create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h
create mode 100644 drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c
create mode 100644 drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
index 88ab32a..c78565d 100644
--- a/drivers/gpu/drm/sprd/Makefile
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -3,6 +3,11 @@
subdir-ccflags-y += -I$(srctree)/$(src)
obj-y := sprd_drm.o \
- sprd_dpu.o
+ sprd_dpu.o \
+ sprd_dsi.o \
+ sprd_dphy.o
+obj-y += disp_lib.o
obj-y += dpu/
+obj-y += dsi/
+obj-y += dphy/
diff --git a/drivers/gpu/drm/sprd/disp_lib.c b/drivers/gpu/drm/sprd/disp_lib.c
new file mode 100644
index 000..b2f8202
--- /dev/null
+++ b/drivers/gpu/drm/sprd/disp_lib.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "disp_lib.h"
+
+struct device *sprd_disp_pipe_get_by_port(struct device *dev, int port)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *endpoint;
+ struct device_node *remote_node;
+ struct platform_device *remote_pdev;
+
+ endpoint = of_graph_get_endpoint_by_regs(np, port, 0);
+ if (!endpoint) {
+ DRM_ERROR("%s/port%d/endpoint0 was not found\n",
+ np->full_name, port);
+ return NULL;
+ }
+
+ remote_node = of_graph_get_remote_port_parent(endpoint);
+ if (!remote_node) {
+ DRM_ERROR("device node was not found by endpoint0\n");
+ return NULL;
+ }
+
+ remote_pdev = of_find_device_by_node(remote_node);
+ if (remote_pdev == NULL) {
+ DRM_ERROR("find %s platform device failed\n",
+ remote_node->full_name);
+ return NULL;
+ }
+
+ return &remote_pdev->dev;
+}
+
+struct device *sprd_disp_pipe_get_input(struct device *dev)
+{
+ return sprd_disp_pipe_get_by_port(dev, 1);
+}
+
+struct device *sprd_disp_pipe_get_output(struct device *dev)
+{
+ return sprd_disp_pipe_get_by_port(dev, 0);
+}
+
+MODULE_AUTHOR("Leon He ");
+MODULE_AUTHOR("Kevin Tang ");
+MODULE_DESCRIPTION("Unisoc display common API library");
+MODULE_LICENSE("GPL v2");
diff --git
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
On 28/07/2020 17:59, Roger Pau Monné wrote:
> On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 27/07/2020 10:13, Roger Pau Monne wrote:
>>> To be used in order to create foreign mappings. This is based on the
>>> ZONE_DEVICE facility which is used by persistent memory devices in
>>> order to create struct pages and kernel virtual mappings for the IOMEM
>>> areas of such devices. Note that on kernels without support for
>>> ZONE_DEVICE Xen will fallback to use ballooned pages in order to
>>> create foreign mappings.
>>>
>>> The newly added helpers use the same parameters as the existing
>>> {alloc/free}_xenballooned_pages functions, which allows for in-place
>>> replacement of the callers. Once a memory region has been added to be
>>> used as scratch mapping space it will no longer be released, and pages
>>> returned are kept in a linked list. This allows to have a buffer of
>>> pages and prevents resorting to frequent additions and removals of
>>> regions.
>>>
>>> If enabled (because ZONE_DEVICE is supported) the usage of the new
>>> functionality untangles Xen balloon and RAM hotplug from the usage of
>>> unpopulated physical memory ranges to map foreign pages, which is the
>>> correct thing to do in order to avoid mappings of foreign pages depend
>>> on memory hotplug.
>> I think this is going to break Dom0 on Arm if the kernel has been built with
>> hotplug. This is because you may end up to re-use region that will be used
>> for the 1:1 mapping of a foreign map.
>>
>> Note that I don't know whether hotplug has been tested on Xen on Arm yet. So
>> it might be possible to be already broken.
>>
>> Meanwhile, my suggestion would be to make the use of hotplug in the balloon
>> code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
> Right, this feature (allocation of unpopulated memory separated from
> the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I
> think could be used on Arm.
>
> IMO the right solution seems to be to subtract the physical memory
> regions that can be used for the identity mappings of foreign pages
> (all RAM on the system AFAICT) from iomem_resource, as that would make
> this and the memory hotplug done in the balloon driver safe?
The right solution is a mechanism for translated guests to query Xen to
find regions of guest physical address space which are unused, and can
be safely be used for foreign/grant/other mappings.
Please don't waste any more time applying more duct tape to a broken
system, and instead spend the time organising some proper foundations.
~Andrew
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master
From: Kevin Tang
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS test tool) and Android HWComposer.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/sprd/Kconfig| 12 +++
drivers/gpu/drm/sprd/Makefile | 5 +
drivers/gpu/drm/sprd/sprd_drm.c | 226
drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
6 files changed, 262 insertions(+)
create mode 100644 drivers/gpu/drm/sprd/Kconfig
create mode 100644 drivers/gpu/drm/sprd/Makefile
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4fd57d..7fe7ab91 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -386,6 +386,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
source "drivers/gpu/drm/tidss/Kconfig"
+source "drivers/gpu/drm/sprd/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7..ee2ccd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -123,3 +123,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
obj-$(CONFIG_DRM_MCDE) += mcde/
obj-$(CONFIG_DRM_TIDSS) += tidss/
+obj-$(CONFIG_DRM_SPRD) += sprd/
diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
new file mode 100644
index 000..b189a54
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Kconfig
@@ -0,0 +1,12 @@
+config DRM_SPRD
+ tristate "DRM Support for Unisoc SoCs Platform"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on DRM && OF
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DSI
+ help
+ Choose this option if you have a Unisoc chipsets.
+ If M is selected the module will be called sprd-drm.
+
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
new file mode 100644
index 000..86d95d9
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+subdir-ccflags-y += -I$(srctree)/$(src)
+
+obj-y := sprd_drm.o
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
new file mode 100644
index 000..4706185
--- /dev/null
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sprd_drm.h"
+
+#define DRIVER_NAME"sprd"
+#define DRIVER_DESC"Spreadtrum SoCs' DRM Driver"
+#define DRIVER_DATE"20200201"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper =
{
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void sprd_drm_mode_config_init(struct drm_device *drm)
+{
+ drm_mode_config_init(drm);
+
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 8192;
+ drm->mode_config.max_height = 8192;
+ drm->mode_config.allow_fb_modifiers = true;
+
+ drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
+ drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
+
+static struct drm_driver sprd_drm_drv = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .fops = &sprd_drm_fops,
+
+ /* GEM Operations */
+ DRM_GEM_CMA_VMAP_DRIVER_OPS,
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+};
+
+static int sprd_drm_bind(struct device *dev)
+{
+ struct drm_device *drm;
+ struct sprd_drm *sprd;
+ int err;
+
+ drm = drm_dev_alloc(&sprd_drm_drv, dev);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
+ dev_set_drvdata(dev, drm);
+
+ sprd = devm_kzalloc(drm->dev, sizeof(*sprd), GFP_KERNEL);
+ if (!sprd)
+ err = -ENOMEM;
+
+ drm->dev_private = sprd;
+
+ sprd_drm_mode_config_
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> Hi,
>
> On 27/07/2020 10:13, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > order to create struct pages and kernel virtual mappings for the IOMEM
> > areas of such devices. Note that on kernels without support for
> > ZONE_DEVICE Xen will fallback to use ballooned pages in order to
> > create foreign mappings.
> >
> > The newly added helpers use the same parameters as the existing
> > {alloc/free}_xenballooned_pages functions, which allows for in-place
> > replacement of the callers. Once a memory region has been added to be
> > used as scratch mapping space it will no longer be released, and pages
> > returned are kept in a linked list. This allows to have a buffer of
> > pages and prevents resorting to frequent additions and removals of
> > regions.
> >
> > If enabled (because ZONE_DEVICE is supported) the usage of the new
> > functionality untangles Xen balloon and RAM hotplug from the usage of
> > unpopulated physical memory ranges to map foreign pages, which is the
> > correct thing to do in order to avoid mappings of foreign pages depend
> > on memory hotplug.
> I think this is going to break Dom0 on Arm if the kernel has been built with
> hotplug. This is because you may end up to re-use region that will be used
> for the 1:1 mapping of a foreign map.
>
> Note that I don't know whether hotplug has been tested on Xen on Arm yet. So
> it might be possible to be already broken.
>
> Meanwhile, my suggestion would be to make the use of hotplug in the balloon
> code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
Right, this feature (allocation of unpopulated memory separated from
the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I
think could be used on Arm.
IMO the right solution seems to be to subtract the physical memory
regions that can be used for the identity mappings of foreign pages
(all RAM on the system AFAICT) from iomem_resource, as that would make
this and the memory hotplug done in the balloon driver safe?
Thanks, Roger.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
From: Kevin Tang Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. RFC v6: - Access registers via readl/writel - Checking for unsupported KMS properties (format, rotation, blend_mode, etc) on plane_check ops - Remove always true checks for dpu core ops Cc: Orson Zhai Cc: Chunyan Zhang Signed-off-by: Kevin Tang --- drivers/gpu/drm/sprd/Makefile | 5 +- drivers/gpu/drm/sprd/dpu/Makefile | 3 + drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503 drivers/gpu/drm/sprd/sprd_dpu.c | 646 drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++ drivers/gpu/drm/sprd/sprd_drm.c | 1 + drivers/gpu/drm/sprd/sprd_drm.h | 2 + 7 files changed, 1346 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile index 86d95d9..88ab32a 100644 --- a/drivers/gpu/drm/sprd/Makefile +++ b/drivers/gpu/drm/sprd/Makefile @@ -2,4 +2,7 @@ subdir-ccflags-y += -I$(srctree)/$(src) -obj-y := sprd_drm.o +obj-y := sprd_drm.o \ + sprd_dpu.o + +obj-y += dpu/ diff --git a/drivers/gpu/drm/sprd/dpu/Makefile b/drivers/gpu/drm/sprd/dpu/Makefile new file mode 100644 index 000..40278b6 --- /dev/null +++ b/drivers/gpu/drm/sprd/dpu/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-y += dpu_r2p0.o diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c new file mode 100644 index 000..4b9521d --- /dev/null +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c @@ -0,0 +1,503 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Unisoc Inc. + */ + +#include +#include +#include +#include + +#include "sprd_dpu.h" + +/* DPU registers size, 4 Bytes(32 Bits) */ +#define DPU_REG_SIZE 0x04 + +/* Layer registers offset */ +#define DPU_LAY_REG_OFFSET 0x0C + +#define DPU_LAY_REG(reg, index) \ + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE) + +#define DPU_REG_RD(reg) readl_relaxed(reg) + +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg) + +#define DPU_REG_SET(reg, mask) \ + writel_relaxed(readl_relaxed(reg) | mask, reg) + +#define DPU_REG_CLR(reg, mask) \ + writel_relaxed(readl_relaxed(reg) & ~mask, reg) + +/* Global control registers */ +#define REG_DPU_CTRL 0x04 +#define REG_DPU_CFG0 0x08 +#define REG_DPU_CFG1 0x0C +#define REG_DPU_CFG2 0x10 +#define REG_PANEL_SIZE 0x20 +#define REG_BLEND_SIZE 0x24 +#define REG_BG_COLOR 0x2C + +/* Layer0 control registers */ +#define REG_LAY_BASE_ADDR0 0x30 +#define REG_LAY_BASE_ADDR1 0x34 +#define REG_LAY_BASE_ADDR2 0x38 +#define REG_LAY_CTRL 0x40 +#define REG_LAY_SIZE 0x44 +#define REG_LAY_PITCH 0x48 +#define REG_LAY_POS0x4C +#define REG_LAY_ALPHA 0x50 +#define REG_LAY_PALLETE0x58 +#define REG_LAY_CROP_START 0x5C + +/* Interrupt control registers */ +#define REG_DPU_INT_EN 0x1E0 +#define REG_DPU_INT_CLR0x1E4 +#define REG_DPU_INT_STS0x1E8 + +/* DPI control registers */ +#define REG_DPI_CTRL 0x1F0 +#define REG_DPI_H_TIMING 0x1F4 +#define REG_DPI_V_TIMING 0x1F8 + +/* MMU control registers */ +#define REG_MMU_EN 0x800 +#define REG_MMU_VPN_RANGE 0x80C +#define REG_MMU_VAOR_ADDR_RD 0x818 +#define REG_MMU_VAOR_ADDR_WR 0x81C +#define REG_MMU_INV_ADDR_RD0x820 +#define REG_MMU_INV_ADDR_WR0x824 +#define REG_MMU_PPN1 0x83C +#define REG_MMU_RANGE1 0x840 +#define REG_MMU_PPN2 0x844 +#define REG_MMU_RANGE2 0x848 + +/* Global control bits */ +#define BIT_DPU_RUNBIT(0) +#define BIT_DPU_STOP BIT(1) +#define BIT_DPU_REG_UPDATE BIT(2) +#define BIT_DPU_IF_EDPIBIT(0) +#define BIT_DPU_COEF_NARROW_RANGE BIT(4) +#define BIT_DPU_Y2R_COEF_ITU709_STANDARD BIT(5) + +/* Layer control bits */ +#define BIT_DPU_LAY_EN BIT(0) + +/* Interrupt control & status bits */ +#define BIT_DPU_INT_DONE BIT(0) +#define BIT_DPU_INT_TE BIT(1) +#define BIT_DPU_INT_ERRBIT(2) +#define BIT_DPU_INT_UPDATE_DONEBIT(4) +#define BIT_DPU_INT_VSYNC BIT(5) +#define BIT_DPU_INT_FBC_PLD_ERRBIT(8) +#define BIT_DPU_INT_FBC_HDR_ERRBIT(9) +#define BIT_DPU_INT_MMU_VAOR_RDBIT(16) +#define BIT_DPU_INT_MMU_VAOR_WRBIT(17) +#define BIT_DPU_INT_MMU_INV_RD BIT(18) +#define BIT_DPU_INT
[Linux-kernel-mentees] [PATCH v2] drm/bufs: Prevent kernel-infoleak in copy_one_buf()
Currently `struct drm_buf_desc` is defined as follows:
struct drm_buf_desc {
int count;
int size;
int low_mark;
int high_mark;
enum {
_DRM_PAGE_ALIGN = 0x01,
_DRM_AGP_BUFFER = 0x02,
_DRM_SG_BUFFER = 0x04,
_DRM_FB_BUFFER = 0x08,
_DRM_PCI_BUFFER_RO = 0x10
} flags;
unsigned long agp_start;
};
copy_one_buf() is potentially copying uninitialized kernel stack memory
to userspace, since the compiler may leave such "holes" (around `.flags`
and `.agp_start` fields) in this statically allocated structure. Prevent
it by initializing `v` with memset().
Cc: sta...@vger.kernel.org
Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
Suggested-by: Dan Carpenter
Acked-by: Arnd Bergmann
Signed-off-by: Peilin Ye
---
Change in v2:
- Improve commit description. (Suggested by Arnd Bergmann
)
drivers/gpu/drm/drm_bufs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index a0735fbc144b..f99cd4a3f951 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1349,10 +1349,14 @@ static int copy_one_buf(void *data, int count, struct
drm_buf_entry *from)
{
struct drm_buf_info *request = data;
struct drm_buf_desc __user *to = &request->list[count];
- struct drm_buf_desc v = {.count = from->buf_count,
-.size = from->buf_size,
-.low_mark = from->low_mark,
-.high_mark = from->high_mark};
+ struct drm_buf_desc v;
+
+ memset(&v, 0, sizeof(v));
+
+ v.count = from->buf_count;
+ v.size = from->buf_size;
+ v.low_mark = from->low_mark;
+ v.high_mark = from->high_mark;
if (copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags)))
return -EFAULT;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/hisilicon: Fixed the warning: Assignment of 0/1 to bool variable
fixed the following warning:
hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
v2:
using the pci_dev.msi_enabled instead of priv->msi_enabled.
v3:
just call pci_enable_msi() and pci_disable_msi(), it's no need to
set dev->pdev->msi_enabled again.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 249c298..b8d839a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -254,9 +254,8 @@ static int hibmc_unload(struct drm_device *dev)
if (dev->irq_enabled)
drm_irq_uninstall(dev);
- if (priv->msi_enabled)
- pci_disable_msi(dev->pdev);
+ pci_disable_msi(dev->pdev);
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
dev->dev_private = NULL;
@@ -294,12 +293,10 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
- priv->msi_enabled = 0;
ret = pci_enable_msi(dev->pdev);
if (ret) {
DRM_WARN("enabling MSI failed: %d\n", ret);
} else {
- priv->msi_enabled = 1;
ret = drm_irq_install(dev, dev->pdev->irq);
if (ret)
DRM_WARN("install irq failed: %d\n", ret);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 6097687..a683763 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -25,7 +25,6 @@ struct hibmc_drm_private {
void __iomem *fb_map;
unsigned long fb_base;
unsigned long fb_size;
- bool msi_enabled;
/* drm */
struct drm_device *dev;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 0/6] Add Unisoc's drm kms module
From: Kevin Tang ChangeList: v1: 1. only upstream modeset and atomic at first commit. 2. remove some unused code; 3. use alpha and blend_mode properties; 3. add yaml support; 4. remove auto-adaptive panel driver; 5. bugfix v2: 1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder 2. remove gem drivers, use generic CMA handlers 3. remove redundant "module_init", all the sub modules loading by KMS v3: 1. multi crtc&encoder design have problem, so rollback to v1 v4: 1. update to gcc-linaro-7.5.0 2. update to Linux 5.6-rc3 3. remove pm_runtime support 4. add COMPILE_TEST, remove unused kconfig 5. "drm_dev_put" on drm_unbind 6. fix some naming convention issue 7. remove semaphore lock for crtc flip 8. remove static variables v5: 1. optimize encoder and connector code implementation 2. use "platform_get_irq" and "platform_get_resource" 3. drop useless function return type, drop unless debug log 4. custom properties should be separate, so drop it 5. use DRM_XXX replase pr_xxx 6. drop dsi&dphy hal callback ops 7. drop unless callback ops checking 8. add comments for sprd dpu structure v6: 1. Access registers via readl/writel 2. Checking for unsupported KMS properties (format, rotation, blend_mode, etc) on plane_check ops 3. Remove always true checks for dpu core ops Kevin Tang (6): dt-bindings: display: add Unisoc's drm master bindings drm/sprd: add Unisoc's drm kms master dt-bindings: display: add Unisoc's dpu bindings drm/sprd: add Unisoc's drm display controller driver dt-bindings: display: add Unisoc's mipi dsi&dphy bindings drm/sprd: add Unisoc's drm mipi dsi&dphy driver .../devicetree/bindings/display/sprd/dphy.yaml | 75 + .../devicetree/bindings/display/sprd/dpu.yaml | 82 ++ .../devicetree/bindings/display/sprd/drm.yaml | 36 + .../devicetree/bindings/display/sprd/dsi.yaml | 98 ++ drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/sprd/Kconfig | 12 + drivers/gpu/drm/sprd/Makefile | 13 + drivers/gpu/drm/sprd/disp_lib.c| 57 + drivers/gpu/drm/sprd/disp_lib.h| 16 + drivers/gpu/drm/sprd/dphy/Makefile |7 + drivers/gpu/drm/sprd/dphy/pll/Makefile |3 + drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c | 473 +++ drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c | 201 +++ drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h | 22 + drivers/gpu/drm/sprd/dpu/Makefile |3 + drivers/gpu/drm/sprd/dpu/dpu_r2p0.c| 503 +++ drivers/gpu/drm/sprd/dsi/Makefile |8 + drivers/gpu/drm/sprd/dsi/core/Makefile |4 + drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c | 964 + drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h | 1477 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.c | 328 + drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h | 32 + drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c| 590 drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h| 26 + drivers/gpu/drm/sprd/sprd_dphy.c | 209 +++ drivers/gpu/drm/sprd/sprd_dphy.h | 50 + drivers/gpu/drm/sprd/sprd_dpu.c| 668 + drivers/gpu/drm/sprd/sprd_dpu.h| 190 +++ drivers/gpu/drm/sprd/sprd_drm.c| 227 +++ drivers/gpu/drm/sprd/sprd_drm.h| 18 + drivers/gpu/drm/sprd/sprd_dsi.c| 571 drivers/gpu/drm/sprd/sprd_dsi.h| 108 ++ 33 files changed, 7074 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sprd/dphy.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/dpu.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/dsi.yaml create mode 100644 drivers/gpu/drm/sprd/Kconfig create mode 100644 drivers/gpu/drm/sprd/Makefile create mode 100644 drivers/gpu/drm/sprd/disp_lib.c create mode 100644 drivers/gpu/drm/sprd/disp_lib.h create mode 100644 drivers/gpu/drm/sprd/dphy/Makefile create mode 100644 drivers/gpu/drm/sprd/dphy/pll/Makefile create mode 100644 drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c create mode 100644 drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c create mode 100644 drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/dsi/Makefile create mode 100644 drivers/gpu/drm/sprd/dsi/core/Makefile create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctr
[PATCH 1/2] drm/ingenic: Handle errors of drm_atomic_get_plane_state
drm_atomic_get_plane_state() can return errors, so we need to handle
these.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ada990a7f911..64eabab3ef69 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -215,10 +215,17 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
if (priv->soc_info->has_osd) {
f1_state = drm_atomic_get_plane_state(state->state, &priv->f1);
+ if (IS_ERR(f1_state))
+ return PTR_ERR(f1_state);
+
f0_state = drm_atomic_get_plane_state(state->state, &priv->f0);
+ if (IS_ERR(f0_state))
+ return PTR_ERR(f0_state);
if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && priv->ipu_plane) {
ipu_state = drm_atomic_get_plane_state(state->state,
priv->ipu_plane);
+ if (IS_ERR(ipu_state))
+ return PTR_ERR(ipu_state);
/* IPU and F1 planes cannot be enabled at the same
time. */
if (f1_state->fb && ipu_state->fb) {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v6 3/6] dt-bindings: display: add Unisoc's dpu bindings
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dpu.yaml | 82 ++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/sprd/dpu.yaml
diff --git a/Documentation/devicetree/bindings/display/sprd/dpu.yaml
b/Documentation/devicetree/bindings/display/sprd/dpu.yaml
new file mode 100644
index 000..54ba9b6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/dpu.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc SoC Display Processor Unit (DPU)
+
+maintainers:
+ - Mark Rutland
+
+description: |
+ DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
+ which transfers the image data from a video memory buffer to an internal
+ LCD interface.
+
+properties:
+ compatible:
+const: sprd,sharkl3-dpu
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the DPU registers set
+
+ interrupts:
+maxItems: 1
+description:
+ The interrupt signal from DPU
+
+ clocks:
+minItems: 2
+
+ clock-names:
+items:
+ - const: clk_src_128m
+ - const: clk_src_384m
+
+ power-domains:
+description: A phandle to DPU power domain node.
+
+ iommus:
+description: A phandle to DPU iommu node.
+
+ port:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DSI.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dpu: dpu@0x6300 {
+ compatible = "sprd,sharkl3-dpu";
+ reg = <0x0 0x6300 0x0 0x1000>;
+ interrupts = ;
+ clock-names = "clk_src_128m",
+ "clk_src_384m";
+
+ clocks = <&pll CLK_TWPLL_128M>,
+<&pll CLK_TWPLL_384M>;
+
+ dpu_port: port {
+ dpu_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm: dts: mt7623: add display subsystem related device nodes
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
arch/arm/boot/dts/mt7623.dtsi | 177 ++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 +
arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 85 +
3 files changed, 347 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index a106c0d90a52..d584a3d678ba 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -24,6 +24,11 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ };
+
cpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-shared;
@@ -321,6 +326,25 @@ pwrap: pwrap@1000d000 {
clock-names = "spi", "wrap";
};
+ mipi_tx0: mipi-dphy@1001 {
+ compatible = "mediatek,mt7623-mipi-tx",
+"mediatek,mt2701-mipi-tx";
+ reg = <0 0x1001 0 0x90>;
+ clocks = <&clk26m>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
+ cec: cec@10012000 {
+ compatible = "mediatek,mt7623-cec",
+"mediatek,mt8173-cec";
+ reg = <0 0x10012000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+ status = "disabled";
+ };
+
cir: cir@10013000 {
compatible = "mediatek,mt7623-cir";
reg = <0 0x10013000 0 0x1000>;
@@ -369,6 +393,18 @@ apmixedsys: syscon@10209000 {
#clock-cells = <1>;
};
+ hdmi_phy: phy@10209100 {
+ compatible = "mediatek,mt7623-hdmi-phy",
+"mediatek,mt2701-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ clock-output-names = "hdmitx_dig_cts";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
rng: rng@1020f000 {
compatible = "mediatek,mt7623-rng";
reg = <0 0x1020f000 0 0x1000>;
@@ -568,6 +604,16 @@ bch: ecc@1100e000 {
status = "disabled";
};
+ hdmiddc0: i2c@11013000 {
+ compatible = "mediatek,mt7623-hdmi-ddc",
+"mediatek,mt8173-hdmi-ddc";
+ interrupts = ;
+ reg = <0 0x11013000 0 0x1C>;
+ clocks = <&pericfg CLK_PERI_I2C3>;
+ clock-names = "ddc-i2c";
+ status = "disabled";
+ };
+
nor_flash: spi@11014000 {
compatible = "mediatek,mt7623-nor",
"mediatek,mt8173-nor";
@@ -766,6 +812,84 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
+ display_components: dispsys@1400 {
+ compatible = "mediatek,mt7623-mmsys",
+"mediatek,mt2701-mmsys";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
+ ovl@14007000 {
+ compatible = "mediatek,mt7623-disp-ovl",
+"mediatek,mt2701-disp-ovl";
+ reg = <0 0x14007000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ rdma0: rdma@14008000 {
+ compatible = "mediatek,mt7623-disp-rdma",
+"mediatek,mt2701-disp-rdma";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
+ wdma@14009000 {
+ compatible = "mediatek,mt7623-disp-wdma",
+"mediatek,mt2701-disp-wdma";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_WDMA>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
+ bls: pwm@1400a000 {
+ compatible = "mediatek,mt7623-disp-pwm",
+"mediatek,mt2701-disp-pwm";
+ reg = <0 0x1400a000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = <&mmsys CLK_MM_MDP_BLS_26M>,
+<&mmsys CLK_MM_DI
[PATCH v2 0/5] make hdmi work on bananapi-r2
This Patch-Series adds missing Patches/Bugfixes to get hdmi working on BPI-R2 This is v2 of series https://patchwork.kernel.org/cover/10903309/ after getting mmsys done v1->v2: - using get_possible_crtc API instead of hardcoded - drop unused dts-nodes - refine commit-messages as far as i can :) "config component output by device node port" is needed to fix a WARN_ON() "fix boot up for 720 and 480 but 1080" fixes flickering, which may cause also some resolutions not working on some TFT (had some problems on my smaller TFT) 2 Patches were already posted, but not yet merged into mainline - config component output by device node port https://patchwork.kernel.org/patch/10609007/ - add display subsystem related device nodes (resend) https://patchwork.kernel.org/patch/10588951/ Bibby Hsieh (1): drm/mediatek: config component output by device node port Jitao Shi (1): drm/mediatek: dpi/dsi: change the getting possible_crtc way Ryder Lee (1): arm: dts: mt7623: add display subsystem related device nodes Stu Hsieh (1): drm: Add get_possible_crtc API for dpi, dsi chunhui dai (1): drm/mediatek: fix boot up for 720 and 480 but 1080 arch/arm/boot/dts/mt7623.dtsi | 177 ++ arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 + arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 85 + drivers/gpu/drm/mediatek/mtk_dpi.c| 3 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c| 46 - drivers/gpu/drm/mediatek/mtk_drm_drv.h| 4 +- drivers/gpu/drm/mediatek/mtk_dsi.c| 3 +- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 3 + drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 + .../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c| 1 + 12 files changed, 442 insertions(+), 10 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Small cleanups to ingenic-drm driver
Here are a few cleanups to the ingenic-drm driver. - some error paths were missing and have been added; - the mode validation has been moved to the .mode_valid helper callback. Cheers, -Paul Paul Cercueil (2): drm/ingenic: Handle errors of drm_atomic_get_plane_state drm/ingenic: Validate mode in a .mode_valid callback drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +++ 1 file changed, 27 insertions(+), 14 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master
On 7/28/20 3:07 AM, Kevin Tang wrote: > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > new file mode 100644 > index 000..b189a54 > --- /dev/null > +++ b/drivers/gpu/drm/sprd/Kconfig > @@ -0,0 +1,12 @@ > +config DRM_SPRD > + tristate "DRM Support for Unisoc SoCs Platform" > + depends on ARCH_SPRD || COMPILE_TEST > + depends on DRM && OF > + select DRM_KMS_HELPER > + select DRM_GEM_CMA_HELPER > + select DRM_KMS_CMA_HELPER > + select DRM_MIPI_DSI > + help > + Choose this option if you have a Unisoc chipsets. chipset. > + If M is selected the module will be called sprd-drm. sprd_drm. > + > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > new file mode 100644 > index 000..86d95d9 > --- /dev/null > +++ b/drivers/gpu/drm/sprd/Makefile > @@ -0,0 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +subdir-ccflags-y += -I$(srctree)/$(src) > + > +obj-y := sprd_drm.o -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
On Thu, Jul 16, 2020 at 6:10 PM Kunihiko Hayashi
wrote:
>
> Current dma-buf heaps can handle only default CMA. This introduces
> dma_heap_add_cma() function to attach CMA heaps that belongs to a device.
>
> At first, the driver calls of_reserved_mem_device_init() to set
> memory-region property associated with reserved-memory defined as CMA
> to the device. And when the driver calls this dma_heap_add_cma(),
> the CMA will be added to dma-buf heaps.
>
> For example, prepare CMA node named "linux,cma@1000" and
> specify the node for memory-region property. After the above calls
> in the driver, a device file "/dev/dma_heap/linux,cma@1000"
> associated with the CMA become available as dma-buf heaps.
>
> Signed-off-by: Kunihiko Hayashi
> ---
> drivers/dma-buf/heaps/cma_heap.c | 12
> include/linux/dma-heap.h | 9 +
> 2 files changed, 21 insertions(+)
Hey! Sorry for the slow response on this! I just realized I never replied!
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 626cf7f..5d2442e 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -162,6 +162,18 @@ static int __add_cma_heap(struct cma *cma, void *data)
> return 0;
> }
>
> +/* add device CMA heap to dmabuf heaps */
> +int dma_heap_add_cma(struct device *dev)
> +{
> + struct cma *cma = dev_get_cma_area(dev);
> +
> + if (!cma)
> + return -ENOMEM;
> +
> + return __add_cma_heap(cma, NULL);
> +}
> +EXPORT_SYMBOL_GPL(dma_heap_add_cma);
> +
> static int add_default_cma_heap(void)
> {
> struct cma *default_cma = dev_get_cma_area(NULL);
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index 454e354..16bec7d 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -56,4 +56,13 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
> */
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>
> +#ifdef CONFIG_DMABUF_HEAPS_CMA
> +/**
> + * dma_heap_add_cma - adds a device CMA heap to dmabuf heaps
> + * @dev: device with a CMA heap to register
> + */
> +int dma_heap_add_cma(struct device *dev);
> +
> +#endif /* CONFIG_DMABUF_HEAPS_CMA */
> +
> #endif /* _DMA_HEAPS_H */
> --
> 2.7.4
Looks sane to me. Being able to expose different multiple CMA heaps
is needed, and I agree this way (as opposed to my earlier dts
appraoch) is probably the best approach. The only bit I'm so-so on is
adding the CMA heap specific call in the dma-heap.h, but at the same
time I can't justify adding a whole new header for a single function.
Do you have a upstream driver that you plan to make use this new call?
We want to have in-tree users of code added.
But if so, feel free to add my:
Acked-by: John Stultz
To this patch when you submit the driver changes.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm/amdgpu: consolidate ttm reserve paths
From: Dave Airlie
Drop the WARN_ON and consolidate the two paths into one.
Use the consolidate slowpath in the execbuf utils code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 12 +--
include/drm/ttm/ttm_bo_driver.h| 91 --
3 files changed, 20 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index afa5189dba7d..e01e8903741e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -160,7 +160,7 @@ static inline int amdgpu_bo_reserve(struct amdgpu_bo *bo,
bool no_intr)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
int r;
- r = __ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
+ r = ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(adev->dev, "%p reserve failed\n", bo);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 1797f04c0534..8a8f1a6a83a6 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -93,7 +93,7 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
- ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
+ ret = ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
if (ret == -EALREADY && dups) {
struct ttm_validate_buffer *safe = entry;
entry = list_prev_entry(entry, head);
@@ -119,13 +119,7 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
ttm_eu_backoff_reservation_reverse(list, entry);
if (ret == -EDEADLK) {
- if (intr) {
- ret =
dma_resv_lock_slow_interruptible(bo->base.resv,
-
ticket);
- } else {
- dma_resv_lock_slow(bo->base.resv, ticket);
- ret = 0;
- }
+ ret = ttm_bo_reserve_slowpath(bo, intr, ticket);
}
if (!ret && entry->num_shared)
@@ -133,8 +127,6 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
entry->num_shared);
if (unlikely(ret != 0)) {
- if (ret == -EINTR)
- ret = -ERESTARTSYS;
if (ticket) {
ww_acquire_done(ticket);
ww_acquire_fini(ticket);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5a37f1cc057e..bfa9d146d3d4 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -597,29 +597,30 @@ int ttm_mem_io_lock(struct ttm_mem_type_manager *man,
bool interruptible);
void ttm_mem_io_unlock(struct ttm_mem_type_manager *man);
/**
- * __ttm_bo_reserve:
+ * ttm_bo_reserve:
*
* @bo: A pointer to a struct ttm_buffer_object.
* @interruptible: Sleep interruptible if waiting.
* @no_wait: Don't sleep while trying to reserve, rather return -EBUSY.
* @ticket: ticket used to acquire the ww_mutex.
*
- * Will not remove reserved buffers from the lru lists.
- * Otherwise identical to ttm_bo_reserve.
+ * Locks a buffer object for validation. (Or prevents other processes from
+ * locking it for validation), while taking a number of measures to prevent
+ * deadlocks.
*
* Returns:
* -EDEADLK: The reservation may cause a deadlock.
* Release all buffer reservations, wait for @bo to become unreserved and
- * try again. (only if use_sequence == 1).
+ * try again.
* -ERESTARTSYS: A wait for the buffer to become unreserved was interrupted by
* a signal. Release all buffer reservations and return to user-space.
* -EBUSY: The function needed to sleep, but @no_wait was true
* -EALREADY: Bo already reserved using @ticket. This error code will only
* be returned if @use_ticket is set to true.
*/
-static inline int __ttm_bo_reserve(struct ttm_buffer_object *bo,
- bool interruptible, bool no_wait,
- struct ww_acquire_ctx *ticket)
+static inline int ttm_bo_reserve(struct ttm_buffer_object *bo,
+bool interruptible, bool no_wait,
+struct ww_acquire_ctx *ticket)
{
int ret = 0;
@@ -641,59 +642,6 @@ static inline int __ttm_bo_reserve(struct
ttm_buffer_object *bo,
return ret;
}
-/**
- * ttm_bo_reserve:
- *
- *
[PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
Tested-by: Laurent Morichetti
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b8c4dd..60b41447bec8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -405,8 +405,10 @@ static int ttm_bo_vm_access_kmap(struct ttm_buffer_object
*bo,
int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
{
- unsigned long offset = (addr) - vma->vm_start;
struct ttm_buffer_object *bo = vma->vm_private_data;
+ unsigned long offset = (addr) - vma->vm_start +
+ ((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node))
+<< PAGE_SHIFT);
int ret;
if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->num_pages)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] drm/ast: Convert to managed initialization
Hi Thomas. On Tue, Jul 28, 2020 at 09:44:12AM +0200, Thomas Zimmermann wrote: > This is the final patchset for converting ast to managed initialization. > > Patches #1 to #4 address I2C helpers. The structures are being stored > in struct ast_connector. The initialization and cleanups is being converted > to managed release helpers. > > Patches #5 to #10 address modesetting and device structures. All are > being embedded into struct ast_private. With struct ast_private being > a subclass of struct drm_device, patch #10 switches ast to DRM's managed- > allocation helpers. > > Patches #11 and #12 address firmware memory that ast allocates > internally. > > Finally, patch #13 removes ast's destroy function in favor of managed > release helpers. > > Tested on AST 2100 HW. > > Thomas Zimmermann (13): > drm/ast: Move I2C code within ast_mode.c > drm/ast: Test if I2C support has been initialized > drm/ast: Embed I2C fields in struct ast_connector > drm/ast: Managed release of I2C adapter > drm/ast: Embed CRTC and connector in struct ast_private > drm/ast: Separate DRM driver from PCI code > drm/ast: Replace driver load/unload functions with device > create/destroy > drm/ast: Replace struct_drm_device.dev_private with to_ast_private() > drm/ast: Don't use ast->dev if dev is available > drm/ast: Embed struct drm_device in struct ast_private > drm/ast: Managed release of ast firmware > drm/ast: Manage release of firmware backup memory > drm/ast: Managed device release A few nits posted to a few patches. Patch 1-11 are all: Acked-by: Sam Ravnborg I did not look at 12 and did not follow all the changes in 13. Not that I found 13 faulty - just lost track and -ENOTIME Sam > > drivers/gpu/drm/ast/ast_cursor.c | 8 +- > drivers/gpu/drm/ast/ast_dp501.c | 23 ++- > drivers/gpu/drm/ast/ast_drv.c| 82 > drivers/gpu/drm/ast/ast_drv.h| 43 +++-- > drivers/gpu/drm/ast/ast_main.c | 74 > drivers/gpu/drm/ast/ast_mm.c | 2 +- > drivers/gpu/drm/ast/ast_mode.c | 310 ++- > drivers/gpu/drm/ast/ast_post.c | 6 +- > 8 files changed, 263 insertions(+), 285 deletions(-) > > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/13] drm/ast: Managed release of I2C adapter
On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
> Managed releases of the device's I2C adapter simplify the connector's
> release.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_mode.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index f421a60d8a96..27eb49bd12b3 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -591,6 +592,14 @@ static void ast_i2c_setsda(void *i2c_priv, int data)
> }
> }
>
> +static void ast_i2c_release(struct drm_device *dev, void *data)
> +{
> + struct ast_i2c_chan *i2c = data;
> +
> + i2c_del_adapter(&i2c->adapter);
> + i2c->dev = NULL; /* clear to signal absence of I2C support */
> +}
> +
> static int ast_i2c_init(struct ast_i2c_chan *i2c, struct drm_device *dev)
> {
> int ret;
> @@ -618,7 +627,7 @@ static int ast_i2c_init(struct ast_i2c_chan *i2c, struct
> drm_device *dev)
>
> i2c->dev = dev; /* signals presence of I2C support */
>
> - return 0;
> + return drmm_add_action_or_reset(dev, ast_i2c_release, i2c);
> }
>
> static bool ast_i2c_is_initialized(struct ast_i2c_chan *i2c)
> @@ -626,14 +635,6 @@ static bool ast_i2c_is_initialized(struct ast_i2c_chan
> *i2c)
> return !!i2c->dev;
> }
>
> -static void ast_i2c_fini(struct ast_i2c_chan *i2c)
> -{
> - if (!ast_i2c_is_initialized(i2c))
> - return;
> - i2c_del_adapter(&i2c->adapter);
> - i2c->dev = NULL; /* clear to signal absence of I2C support */
> -}
The intro of ast_i2c_fini() and then removal again confuses me a little.
But end result looks simple so I guess thats what counts.
Sam
> -
> /*
> * Primary plane
> */
> @@ -1139,8 +1140,6 @@ static enum drm_mode_status ast_mode_valid(struct
> drm_connector *connector,
>
> static void ast_connector_destroy(struct drm_connector *connector)
> {
> - struct ast_connector *ast_connector = to_ast_connector(connector);
> - ast_i2c_fini(&ast_connector->i2c);
> drm_connector_cleanup(connector);
> kfree(connector);
> }
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/ast: Move I2C code within ast_mode.c
Hi Thomas.
A few comments related to the code - but not to this patch and
not to this patch-set.
But I noticed so here goes.
Sam
On Tue, Jul 28, 2020 at 09:44:13AM +0200, Thomas Zimmermann wrote:
> The I2C support feels slammed down to the end of ast_mode.c. Improve
> this by moving the code before it's callers, remove the declarations,
> rename the callbacks to match I2C's get/set sda/scl convention, and
> prefix all functions with ast_. No functional changes have been made.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_mode.c | 249 +
> 1 file changed, 125 insertions(+), 124 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 154cd877d9d1..19f1dfc8e9e0 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -46,9 +46,6 @@
> #include "ast_drv.h"
> #include "ast_tables.h"
>
> -static struct ast_i2c_chan *ast_i2c_create(struct drm_device *dev);
> -static void ast_i2c_destroy(struct ast_i2c_chan *i2c);
> -
> static inline void ast_load_palette_index(struct ast_private *ast,
>u8 index, u8 red, u8 green,
>u8 blue)
> @@ -514,6 +511,131 @@ static void ast_set_start_address_crt1(struct
> ast_private *ast,
>
> }
>
> +/*
> + * I2C
> + */
> +
> +static int ast_i2c_getscl(void *i2c_priv)
> +{
> + struct ast_i2c_chan *i2c = i2c_priv;
> + struct ast_private *ast = to_ast_private(i2c->dev);
> + uint32_t val, val2, count, pass;
s/uint32_t/u32
> +
> + count = 0;
> + pass = 0;
> + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x10) >> 4)
> & 0x01;
So val is a bool - but anyway an int is used.
> + do {
> + val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x10) >> 4) & 0x01;
Likewise for val2.
> + if (val == val2) {
> + pass++;
> + } else {
> + pass = 0;
> + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x10) >> 4) & 0x01;
> + }
> + } while ((pass < 5) && (count++ < 0x1));
> +
> + return val & 1 ? 1 : 0;
bool to int conversion could do the trick here.
> +}
> +
> +static int ast_i2c_getsda(void *i2c_priv)
> +{
> + struct ast_i2c_chan *i2c = i2c_priv;
> + struct ast_private *ast = to_ast_private(i2c->dev);
> + uint32_t val, val2, count, pass;
> +
> + count = 0;
> + pass = 0;
> + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x20) >> 5)
> & 0x01;
> + do {
> + val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x20) >> 5) & 0x01;
> + if (val == val2) {
> + pass++;
> + } else {
> + pass = 0;
> + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x20) >> 5) & 0x01;
> + }
> + } while ((pass < 5) && (count++ < 0x1));
> +
> + return val & 1 ? 1 : 0;
> +}
> +
> +static void ast_i2c_setscl(void *i2c_priv, int clock)
> +{
> + struct ast_i2c_chan *i2c = i2c_priv;
> + struct ast_private *ast = to_ast_private(i2c->dev);
> + int i;
> + u8 ujcrb7, jtemp;
And now u8 is used for registers.
Maybe because ast_get_index_reg_mask() returns uint8_t.
So for consistentcy do the uint8_t => u8 etc. conversion first.
> +
> + for (i = 0; i < 0x1; i++) {
> + ujcrb7 = ((clock & 0x01) ? 0 : 1);
> + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xf4,
> ujcrb7);
> + jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x01);
> + if (ujcrb7 == jtemp)
> + break;
> + }
> +}
> +
> +static void ast_i2c_setsda(void *i2c_priv, int data)
> +{
> + struct ast_i2c_chan *i2c = i2c_priv;
> + struct ast_private *ast = to_ast_private(i2c->dev);
> + int i;
> + u8 ujcrb7, jtemp;
> +
> + for (i = 0; i < 0x1; i++) {
> + ujcrb7 = ((data & 0x01) ? 0 : 1) << 2;
> + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xf1,
> ujcrb7);
> + jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x04);
> + if (ujcrb7 == jtemp)
> + break;
> + }
> +}
> +
> +static struct ast_i2c_chan *ast_i2c_create(struct drm_device *dev)
> +{
> + struct ast_i2c_chan *i2c;
> + int ret;
> +
> + i2c = kzalloc(sizeof(struct ast_i2c_chan), GFP_KERNEL);
> + if (!i2c)
> + return NULL;
> +
> + i2c->adapter.owner = THIS_MODULE;
> + i2c->adapter.class = I2C_CLASS_DDC;
> + i2c->adapter.dev.parent = &dev->pdev->dev;
> + i2c->dev = dev;
> + i2c_set_adapdata(&i2c->adapter, i2c);
If ast_private * was passed here and not i2c.
Then the implementation of ast_i2c_* could be a tad simpler - no
upclassing needed.
And then you could drop the drm_device f
Re: [PATCH 02/13] drm/ast: Test if I2C support has been initialized
Hi Thomas.
On Tue, Jul 28, 2020 at 09:44:14AM +0200, Thomas Zimmermann wrote:
> The ast driver is supposed to work without I2C support. This is
> tested by looking at the connector's i2c field being non-NULL.
>
> After embedding the I2C structure in the connector, the i2c field
> will not be a pointer. So change the test to look at the dev field
> in struct ast_i2c_chan.
>
> ast_get_modes() did not really test if I2C has been initialized, so
> the patch adds this test as well.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_mode.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 19f1dfc8e9e0..45be020afcad 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -603,7 +603,6 @@ static struct ast_i2c_chan *ast_i2c_create(struct
> drm_device *dev)
> i2c->adapter.owner = THIS_MODULE;
> i2c->adapter.class = I2C_CLASS_DDC;
> i2c->adapter.dev.parent = &dev->pdev->dev;
> - i2c->dev = dev;
> i2c_set_adapdata(&i2c->adapter, i2c);
> snprintf(i2c->adapter.name, sizeof(i2c->adapter.name),
>"AST i2c bit bus");
> @@ -622,17 +621,30 @@ static struct ast_i2c_chan *ast_i2c_create(struct
> drm_device *dev)
> goto out_free;
> }
>
> + i2c->dev = dev; /* signals presence of I2C support */
> +
> return i2c;
> out_free:
> kfree(i2c);
> return NULL;
> }
>
> -static void ast_i2c_destroy(struct ast_i2c_chan *i2c)
> +static bool ast_i2c_is_initialized(struct ast_i2c_chan *i2c)
> {
> - if (!i2c)
> + return i2c && !!i2c->dev;
> +}
It seems pointless to convert the pointer to bool here ("!!").
> +
> +static void ast_i2c_fini(struct ast_i2c_chan *i2c)
> +{
> + if (!ast_i2c_is_initialized(i2c))
> return;
Empty line after return?
> i2c_del_adapter(&i2c->adapter);
> + i2c->dev = NULL; /* clear to signal absence of I2C support */
> +}
> +
> +static void ast_i2c_destroy(struct ast_i2c_chan *i2c)
> +{
> + ast_i2c_fini(i2c);
> kfree(i2c);
> }
>
> @@ -1054,6 +1066,7 @@ static int ast_get_modes(struct drm_connector
> *connector)
> {
> struct ast_connector *ast_connector = to_ast_connector(connector);
> struct ast_private *ast = to_ast_private(connector->dev);
> + struct ast_i2c_chan *i2c = ast_connector->i2c;
> struct edid *edid;
> int ret;
> bool flags = false;
> @@ -1069,8 +1082,8 @@ static int ast_get_modes(struct drm_connector
> *connector)
> else
> kfree(edid);
> }
> - if (!flags)
> - edid = drm_get_edid(connector, &ast_connector->i2c->adapter);
> + if (!flags && ast_i2c_is_initialized(i2c))
> + edid = drm_get_edid(connector, &i2c->adapter);
> if (edid) {
> drm_connector_update_edid_property(&ast_connector->base, edid);
> ret = drm_add_edid_modes(connector, edid);
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 3/3] drm/panel: simple: Add DT bindings for Powertip PH800480T013
On Tue, Jul 28, 2020 at 02:12:46PM +0200, Marek Vasut wrote:
> Add support for Powertip PH800480T013 800x480 parallel LCD, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> ---
> V2: Add bus_flags and connector_type
Hi Marek.
Applied the 3 patches to drm-misc-next.
Fixed subject while applying this patch.
Sam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index cb6550d37e85..298e3a26d9ee 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3000,6 +3000,31 @@ static const struct panel_desc pda_91_00156_a0 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> };
>
> +static const struct drm_display_mode powertip_ph800480t013_idf02_mode = {
> + .clock = 24750,
> + .hdisplay = 800,
> + .hsync_start = 800 + 54,
> + .hsync_end = 800 + 54 + 2,
> + .htotal = 800 + 54 + 2 + 44,
> + .vdisplay = 480,
> + .vsync_start = 480 + 49,
> + .vsync_end = 480 + 49 + 2,
> + .vtotal = 480 + 49 + 2 + 22,
> +};
> +
> +static const struct panel_desc powertip_ph800480t013_idf02 = {
> + .modes = &powertip_ph800480t013_idf02_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .connector_type = DRM_MODE_CONNECTOR_DPI,
> +};
>
> static const struct drm_display_mode qd43003c0_40_mode = {
> .clock = 9000,
> @@ -4012,6 +4037,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "pda,91-00156-a0",
> .data = &pda_91_00156_a0,
> + }, {
> + .compatible = "powertip,ph800480t013-idf02",
> + .data = &powertip_ph800480t013_idf02,
> }, {
> .compatible = "qiaodian,qd43003c0-40",
> .data = &qd43003c0_40,
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dma-buf: Fix kerneldoc of dma_buf_set_name()
Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member 'dmabuf' not described in 'dma_buf_set_name' Signed-off-by: Krzysztof Kozlowski --- drivers/dma-buf/dma-buf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 1699a8e309ef..58564d82a3a2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -316,9 +316,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) * name of the dma-buf if the same piece of memory is used for multiple * purpose between different devices. * - * @dmabuf [in] dmabuf buffer that will be renamed. - * @buf: [in] A piece of userspace memory that contains the name of - * the dma-buf. + * @dmabuf: [in] dmabuf buffer that will be renamed. + * @buf:[in] A piece of userspace memory that contains the name of + * the dma-buf. * * Returns 0 on success. If the dma-buf buffer is already attached to * devices, return -EBUSY. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
