Re: [PATCH v2 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi Liu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on shawnguo/for-next] [also build test WARNING on robh/for-next soc/for-next clk/clk-next linus/master v5.10-rc6 next-20201201] [cannot apply to xlnx/master] [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/Liu-Ying/drm-imx-Introduce-i-MX8qm-qxp-DPU-DRM/20201203-111805 base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next config: arm-allyesconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/9782ac29f477208d26405e56ccaa08703bef8354 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Liu-Ying/drm-imx-Introduce-i-MX8qm-qxp-DPU-DRM/20201203-111805 git checkout 9782ac29f477208d26405e56ccaa08703bef8354 # 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 warnings (new ones prefixed by >>): >> drivers/gpu/drm/imx/dpu/dpu-gammacor.c:34: warning: "MODE_MASK" redefined 34 | #define MODE_MASK BIT(0) | In file included from arch/arm/include/asm/ptrace.h:10, from arch/arm/include/asm/irqflags.h:7, from include/linux/irqflags.h:16, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:20, from arch/arm/include/asm/bug.h:60, from include/linux/bug.h:5, from include/linux/io.h:11, from drivers/gpu/drm/imx/dpu/dpu-gammacor.c:7: arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous definition 67 | #define MODE_MASK 0x001f | -- >> drivers/gpu/drm/imx/dpu/dpu-hscaler.c:23: warning: "MODE_MASK" redefined 23 | #define MODE_MASK 0x1 | In file included from arch/arm/include/asm/ptrace.h:10, from arch/arm/include/asm/irqflags.h:7, from include/linux/irqflags.h:16, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:20, from arch/arm/include/asm/bug.h:60, from include/linux/bug.h:5, from include/linux/io.h:11, from drivers/gpu/drm/imx/dpu/dpu-hscaler.c:7: arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous definition 67 | #define MODE_MASK 0x001f | -- >> drivers/gpu/drm/imx/dpu/dpu-layerblend.c:32: warning: "MODE_MASK" redefined 32 | #define MODE_MASKBIT(0) | In file included from arch/arm/include/asm/ptrace.h:10, from arch/arm/include/asm/irqflags.h:7, from include/linux/irqflags.h:16, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:20, from arch/arm/include/asm/bug.h:60, from include/linux/bug.h:5, from include/linux/io.h:11, from drivers/gpu/drm/imx/dpu/dpu-layerblend.c:8: arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous definition 67 | #define MODE_MASK 0x001f | -- >> drivers/gpu/drm/imx/dpu/dpu-vscaler.c:25: warning: "MODE_MASK" redefined 25 | #define MODE_MASK 0x1 | In file included from arch/arm/include/asm/ptrace.h:10, from arch/arm/include/asm/irqflags.h:7, from include/linux/irqflags.h:16, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:20, from arch/arm/include/asm/bug.h:60, from include/linux/bug.h:5, from include/linux/io.h:11, from drivers/gpu/drm/imx/dpu/dpu-vscaler.c:7: arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous
Re: [PATCH] drm/hisilicon: Use managed VRAM-helper initialization
Hi
Am 03.12.20 um 04:09 schrieb Tian Tao:
updated to use drmm_vram_helper_init()
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
As a good follow-up patch, I would suggest to get rig of the entire file
hibmc_ttm.c. drmm_vram_helper_init() can be called directly from
hibmc_load(). hibmc_dumb_create() and hibmc_mode_funcs can go to
hibmc_drm_drv.c.
Best regards
Thomas
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 -
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 19 +++
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 8020604..5aea2e9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -249,7 +249,6 @@ static int hibmc_unload(struct drm_device *dev)
pci_disable_msi(dev->pdev);
hibmc_kms_fini(priv);
- hibmc_mm_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 7e0c756..2786de5 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -64,7 +64,6 @@ int hibmc_de_init(struct hibmc_drm_private *priv);
int hibmc_vdac_init(struct hibmc_drm_private *priv);
int hibmc_mm_init(struct hibmc_drm_private *hibmc);
-void hibmc_mm_fini(struct hibmc_drm_private *hibmc);
int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
int hibmc_ddc_create(struct drm_device *drm_dev, struct hibmc_connector
*connector);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index e84fb81..892d566 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -23,15 +23,12 @@
int hibmc_mm_init(struct hibmc_drm_private *hibmc)
{
- struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = >dev;
- vmm = drm_vram_helper_alloc_mm(dev,
- pci_resource_start(dev->pdev, 0),
- hibmc->fb_size);
- if (IS_ERR(vmm)) {
- ret = PTR_ERR(vmm);
+ ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
+ hibmc->fb_size);
+ if (ret) {
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
return ret;
}
@@ -39,16 +36,6 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc)
return 0;
}
-void hibmc_mm_fini(struct hibmc_drm_private *hibmc)
-{
- struct drm_device *dev = >dev;
-
- if (!dev->vram_mm)
- return;
-
- drm_vram_helper_release_mm(dev);
-}
-
int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] Nouveau video --- [ cut here ] ----- crash dump 5.10.0-rc6
Unfortunately this isn't a crash, but rather a warning that things are timing out. By the time you get this, the display is most likely hung. Was there anything before this, e.g. an error state dump perhaps? What GPU are you using, what displays, and how are they connected? What kind of userspace is running here? X or a Wayland compositor (or something else entirely)? On Thu, Dec 3, 2020 at 12:13 AM Dave Airlie wrote: > > cc'ing Ben + nouveau > > On Thu, 3 Dec 2020 at 14:59, bob wrote: > > > > Hello. I have a crash dump for: > > > > $ uname -a > > Linux freedom 5.10.0-rc6 #1 SMP Sun Nov 29 17:26:13 MST 2020 x86_64 > > x86_64 x86_64 GNU/Linux > > > > Occasionally when this dumps it likes to lock up the computer, but I > > caught it this time. > > > > Also video likes to flicker a lot. Nouveau has been iffy since kernel > > 5.8.0. > > > > This isn't the only dump, it dumped probably 50 times. If you are > > really desperate for all of it, > > > > reply to me directly as I'm not on the mailing list. Here is one of them. > > > > [39019.426580] [ cut here ] > > [39019.426589] WARNING: CPU: 6 PID: 14136 at > > drivers/gpu/drm/nouveau/dispnv50/disp.c:211 nv50_dmac_wait+0x1e1/0x230 > > [39019.426590] Modules linked in: mt2131 s5h1409 fuse tda8290 tuner > > cx25840 rt2800usb rt2x00usb rt2800lib snd_hda_codec_analog > > snd_hda_codec_generic ledtrig_audio rt2x00lib binfmt_misc > > intel_powerclamp coretemp cx23885 mac80211 tda18271 altera_stapl > > videobuf2_dvb m88ds3103 tveeprom cx2341x dvb_core rc_core i2c_mux > > snd_hda_codec_hdmi videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 > > snd_hda_intel videobuf2_common snd_intel_dspcfg kvm_intel snd_hda_codec > > videodev snd_hda_core kvm mc snd_hwdep snd_pcm_oss snd_mixer_oss > > irqbypass snd_pcm cfg80211 snd_seq_dummy snd_seq_midi snd_seq_oss > > snd_seq_midi_event snd_rawmidi snd_seq intel_cstate snd_seq_device > > serio_raw snd_timer input_leds nfsd libarc4 snd asus_atk0110 i7core_edac > > soundcore i5500_temp auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc > > parport_pc ppdev lp parport ip_tables x_tables btrfs blake2b_generic > > libcrc32c xor zstd_compress raid6_pq dm_mirror dm_region_hash dm_log > > pata_acpi pata_marvell hid_generic usbhid hid psmouse firewire_ohci > > [39019.426650] firewire_core crc_itu_t i2c_i801 ahci sky2 libahci > > i2c_smbus lpc_ich > > [39019.426658] CPU: 6 PID: 14136 Comm: kworker/u16:0 Tainted: GW > > I 5.10.0-rc6 #1 > > [39019.426659] Hardware name: System manufacturer System Product > > Name/P6T DELUXE, BIOS 220909/21/2010 > > [39019.426662] Workqueue: events_unbound nv50_disp_atomic_commit_work > > [39019.426665] RIP: 0010:nv50_dmac_wait+0x1e1/0x230 > > [39019.426667] Code: 8d 48 04 48 89 4a 68 c7 00 00 00 00 20 49 8b 46 38 > > 41 c7 86 20 01 00 00 00 00 00 00 49 89 46 68 e8 e4 fc ff ff e9 76 fe ff > > ff <0f> 0b b8 92 ff ff ff e9 ed fe ff ff 49 8b be 80 00 00 00 e8 c7 fc > > [39019.426668] RSP: 0018:b79d028ebd48 EFLAGS: 00010282 > > [39019.426670] RAX: ff92 RBX: 000d RCX: > > > > [39019.426671] RDX: ff92 RSI: b79d028ebc88 RDI: > > b79d028ebd28 > > [39019.426671] RBP: b79d028ebd48 R08: R09: > > b79d028ebc58 > > [39019.426672] R10: 0030 R11: 11c4 R12: > > fffb > > [39019.426673] R13: a05fc1ebd368 R14: a05fc1ebd3a8 R15: > > a05fc2425000 > > [39019.426675] FS: () GS:a061f3d8() > > knlGS: > > [39019.426676] CS: 0010 DS: ES: CR0: 80050033 > > [39019.426677] CR2: 7fb2d58e CR3: 00026280a000 CR4: > > 06e0 > > [39019.426678] Call Trace: > > [39019.426685] base827c_image_set+0x2f/0x1d0 > > [39019.426687] nv50_wndw_flush_set+0x89/0x1c0 > > [39019.426688] nv50_disp_atomic_commit_tail+0x4e7/0x7e0 > > [39019.426693] process_one_work+0x1d4/0x370 > > [39019.426695] worker_thread+0x4a/0x3b0 > > [39019.426697] ? process_one_work+0x370/0x370 > > [39019.426699] kthread+0xfe/0x140 > > [39019.426701] ? kthread_park+0x90/0x90 > > [39019.426704] ret_from_fork+0x22/0x30 > > [39019.426706] ---[ end trace d512d675211c738c ]--- > > [39021.426751] [ cut here ] > > > > > > Thanks in advance, > > > > Bob > > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 Michal Turecki (ture...@gmail.com) changed: What|Removed |Added CC||ture...@gmail.com --- Comment #12 from Michal Turecki (ture...@gmail.com) --- Created attachment 293911 --> https://bugzilla.kernel.org/attachment.cgi?id=293911=edit Another instance on 5.9.11-3-MANJARO #1 SMP PREEMPT Same problem happens often on my desktop PC when resuming from power saving mode with monitor switched off. Like in other cases, switching monitor off/on helps but all open windows although seemingly restored to the original size before power saving, must have been temporarily resized to 640x480 during DP resolution negotiation which results in XFCE compiz (another, unrelated bug) shrinking them to 640x480 after moving for example. Issue occurs very often, maybe about 1 of 5 times power saving mode is on. I am happy to do some more debugging if pointed to the right direction how to do it. Some specs: AMD RX5700 (Navi 10) MSI MAG321CURV monitor. -- 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: Nouveau video --- [ cut here ] ----- crash dump 5.10.0-rc6
cc'ing Ben + nouveau On Thu, 3 Dec 2020 at 14:59, bob wrote: > > Hello. I have a crash dump for: > > $ uname -a > Linux freedom 5.10.0-rc6 #1 SMP Sun Nov 29 17:26:13 MST 2020 x86_64 > x86_64 x86_64 GNU/Linux > > Occasionally when this dumps it likes to lock up the computer, but I > caught it this time. > > Also video likes to flicker a lot. Nouveau has been iffy since kernel > 5.8.0. > > This isn't the only dump, it dumped probably 50 times. If you are > really desperate for all of it, > > reply to me directly as I'm not on the mailing list. Here is one of them. > > [39019.426580] [ cut here ] > [39019.426589] WARNING: CPU: 6 PID: 14136 at > drivers/gpu/drm/nouveau/dispnv50/disp.c:211 nv50_dmac_wait+0x1e1/0x230 > [39019.426590] Modules linked in: mt2131 s5h1409 fuse tda8290 tuner > cx25840 rt2800usb rt2x00usb rt2800lib snd_hda_codec_analog > snd_hda_codec_generic ledtrig_audio rt2x00lib binfmt_misc > intel_powerclamp coretemp cx23885 mac80211 tda18271 altera_stapl > videobuf2_dvb m88ds3103 tveeprom cx2341x dvb_core rc_core i2c_mux > snd_hda_codec_hdmi videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 > snd_hda_intel videobuf2_common snd_intel_dspcfg kvm_intel snd_hda_codec > videodev snd_hda_core kvm mc snd_hwdep snd_pcm_oss snd_mixer_oss > irqbypass snd_pcm cfg80211 snd_seq_dummy snd_seq_midi snd_seq_oss > snd_seq_midi_event snd_rawmidi snd_seq intel_cstate snd_seq_device > serio_raw snd_timer input_leds nfsd libarc4 snd asus_atk0110 i7core_edac > soundcore i5500_temp auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc > parport_pc ppdev lp parport ip_tables x_tables btrfs blake2b_generic > libcrc32c xor zstd_compress raid6_pq dm_mirror dm_region_hash dm_log > pata_acpi pata_marvell hid_generic usbhid hid psmouse firewire_ohci > [39019.426650] firewire_core crc_itu_t i2c_i801 ahci sky2 libahci > i2c_smbus lpc_ich > [39019.426658] CPU: 6 PID: 14136 Comm: kworker/u16:0 Tainted: GW > I 5.10.0-rc6 #1 > [39019.426659] Hardware name: System manufacturer System Product > Name/P6T DELUXE, BIOS 220909/21/2010 > [39019.426662] Workqueue: events_unbound nv50_disp_atomic_commit_work > [39019.426665] RIP: 0010:nv50_dmac_wait+0x1e1/0x230 > [39019.426667] Code: 8d 48 04 48 89 4a 68 c7 00 00 00 00 20 49 8b 46 38 > 41 c7 86 20 01 00 00 00 00 00 00 49 89 46 68 e8 e4 fc ff ff e9 76 fe ff > ff <0f> 0b b8 92 ff ff ff e9 ed fe ff ff 49 8b be 80 00 00 00 e8 c7 fc > [39019.426668] RSP: 0018:b79d028ebd48 EFLAGS: 00010282 > [39019.426670] RAX: ff92 RBX: 000d RCX: > > [39019.426671] RDX: ff92 RSI: b79d028ebc88 RDI: > b79d028ebd28 > [39019.426671] RBP: b79d028ebd48 R08: R09: > b79d028ebc58 > [39019.426672] R10: 0030 R11: 11c4 R12: > fffb > [39019.426673] R13: a05fc1ebd368 R14: a05fc1ebd3a8 R15: > a05fc2425000 > [39019.426675] FS: () GS:a061f3d8() > knlGS: > [39019.426676] CS: 0010 DS: ES: CR0: 80050033 > [39019.426677] CR2: 7fb2d58e CR3: 00026280a000 CR4: > 06e0 > [39019.426678] Call Trace: > [39019.426685] base827c_image_set+0x2f/0x1d0 > [39019.426687] nv50_wndw_flush_set+0x89/0x1c0 > [39019.426688] nv50_disp_atomic_commit_tail+0x4e7/0x7e0 > [39019.426693] process_one_work+0x1d4/0x370 > [39019.426695] worker_thread+0x4a/0x3b0 > [39019.426697] ? process_one_work+0x370/0x370 > [39019.426699] kthread+0xfe/0x140 > [39019.426701] ? kthread_park+0x90/0x90 > [39019.426704] ret_from_fork+0x22/0x30 > [39019.426706] ---[ end trace d512d675211c738c ]--- > [39021.426751] [ cut here ] > > > Thanks in advance, > > Bob > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: amdgpu: fix a kernel-doc markup
On Wed, Dec 2, 2020 at 3:45 AM Christian König wrote: > > Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab: > > The function name at kernel-doc markup doesn't match the name > > of the function: > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting > > prototype for amdgpu_debugfs_print_bo_info(). Prototype was for > > amdgpu_bo_print_info() instead > > > > Fix it. > > > > Signed-off-by: Mauro Carvalho Chehab > > Reviewed-by: Christian König > Applied. Thanks! Alex > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > > index c6c9723d3d8a..fd7a93c32235 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > > @@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct > > amdgpu_device *adev, > > } while (0) > > > > /** > > - * amdgpu_debugfs_print_bo_info - print BO info in debugfs file > > + * amdgpu_bo_print_info - print BO info in debugfs file > >* > >* @id: Index or Id of the BO > >* @bo: Requested BO for printing info > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.10
Hi Dave, Daniel, Fixes for 5.10. The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-12-02 for you to fetch changes up to efd6d85a18102241538dd1cc257948a0dbe6fae6: drm/amdgpu/vcn3.0: remove old DPG workaround (2020-12-02 22:55:48 -0500) amd-drm-fixes-5.10-2020-12-02: amdgpu: - SMU11 manual fan fix - Renoir display clock fix - VCN3 dynamic powergating fix Arunpravin (1): drm/amdgpu/pm/smu11: Fix fan set speed bug Boyuan Zhang (2): drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset drm/amdgpu/vcn3.0: remove old DPG workaround Brandon Syu (1): drm/amd/display: Init clock value by current vbios CLKs drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 25 -- .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 13 +-- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 7 +- 3 files changed, 36 insertions(+), 9 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
> On Dec 2, 2020, at 11:03, Daniel Vetter wrote: > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: >> >> >> >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: >>> >>> Hi >>> >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: Hi Am 30.11.20 um 21:59 schrieb Zack Rusin: > > >> On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: >> >> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >> drm_device.dev. No functional changes. >> >> Signed-off-by: Thomas Zimmermann >> Cc: Roland Scheidegger >> --- >> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- >> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > > Reviewed-by: Zack Rusin Could you add this patch to the vmwgfx tree? >>> >>> AMD devs indicated that they'd prefer to merge the patchset trough >>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through >>> drm-misc-next as well. >> >> Sounds good. I’ll make sure to rebase our latest patch set on top of it when >> it’s in. Thanks! > > btw if you want to avoid multi-tree coordination headaches, we can > also manage vmwgfx in drm-misc and give you & Roland commit rights > there. Up to you. There is some scripting involved for now (but I hope > whenever we move to gitlab we could do the checks server-side): I’d be happy to take you up on that. I would like to move a lot more of our development into public repos and reducing the burden of maintaining multiple trees would help. Is there a lot of changes to drm core that doesn’t go through drm-misc? Or alternatively is drm-misc often pulling from Linus’ master? I’m trying to figure out how much would our need to rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes because that would also allow me to point some internal testing infrastructure at it as well. z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/kmb: Fix possible oops in probe error handling
Thanks Dan.
> -Original Message-
> From: Dan Carpenter
> Sent: Sunday, November 29, 2020 11:48 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; Sam Ravnborg ; dri-
> de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/kmb: Fix possible oops in probe error handling
>
> On Fri, Nov 20, 2020 at 10:15:57PM +, Chrisanthus, Anitha wrote:
> > Hi Dan,
> > I see the problem now, thanks for the patch.
> >
> > > -Original Message-
> > > From: Dan Carpenter
> > > Sent: Friday, November 20, 2020 12:11 AM
> > > To: Chrisanthus, Anitha
> > > Cc: Dea, Edmund J ; David Airlie
> ;
> > > Daniel Vetter ; Sam Ravnborg ; dri-
> > > de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> > > Subject: [PATCH v2] drm/kmb: Fix possible oops in probe error handling
> > >
> > > If kmb_dsi_init() fails the "kmb->kmb_dsi" variable is an error pointer.
> > > The kernel will Oops when we pass it to kmb_dsi_host_unregister().
> > >
> > > Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
> > > Signed-off-by: Dan Carpenter
> > > ---
> > > v2: write a better commit message
> > >
> > > drivers/gpu/drm/kmb/kmb_drv.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/kmb/kmb_drv.c
> > > b/drivers/gpu/drm/kmb/kmb_drv.c
> > > index a31a840ce634..8c43b136765c 100644
> > > --- a/drivers/gpu/drm/kmb/kmb_drv.c
> > > +++ b/drivers/gpu/drm/kmb/kmb_drv.c
> > > @@ -504,7 +504,7 @@ static int kmb_probe(struct platform_device
> *pdev)
> > > if (IS_ERR(kmb->kmb_dsi)) {
> > > drm_err(>drm, "failed to initialize DSI\n");
> > > ret = PTR_ERR(kmb->kmb_dsi);
> > > - goto err_free1;
> > > + goto err_clear_drvdata;
> > > }
> > >
> > > kmb->kmb_dsi->dev = _pdev->dev;
> > > @@ -540,8 +540,9 @@ static int kmb_probe(struct platform_device
> *pdev)
> > > drm_crtc_cleanup(>crtc);
> > > drm_mode_config_cleanup(>drm);
> > > err_free1:
> > > - dev_set_drvdata(dev, NULL);
> > > kmb_dsi_host_unregister(kmb->kmb_dsi);
> > > + err_clear_drvdata:
> > We still need to unregister the dsi_host that was registered in this call
> kmb_dsi_host_bridge_init.
> > This will require more changes in kmb_dsi_host_unregister and/or separate
> out mipi_dsi_host_unregister.
> > FYI - I will be out all of next week, will be back the next Monday.
>
> Hm... Yes. Now that you point it out, there are several bugs related
> to kmb_dsi_host_bridge_init()...
>
>182 void kmb_dsi_host_unregister(struct kmb_dsi *kmb_dsi)
>183 {
>184 kmb_dsi_clk_disable(kmb_dsi);
>185 mipi_dsi_host_unregister(kmb_dsi->host);
> ^
> kmb_dsi->host is dsi_host.
>
> Every user unregisters it, but only the first user registers it. So
> if there are multiple users it will be unregistered prematurely. Should
> there be a kfree to prevent a leak?
>
> kfree(kmb_dsi->host);
> dsi_host = NULL;
>
>186 }
>
> [ snip ]
>
>216 int kmb_dsi_host_bridge_init(struct device *dev)
>217 {
>218 struct device_node *encoder_node, *dsi_out;
>219
>220 /* Create and register MIPI DSI host */
>221 if (!dsi_host) {
>
> This is only allocated for the first user.
>
>222 dsi_host = kzalloc(sizeof(*dsi_host), GFP_KERNEL);
>223 if (!dsi_host)
>224 return -ENOMEM;
>225
>226 dsi_host->ops = _dsi_host_ops;
>227
>228 if (!dsi_device) {
>229 dsi_device = kzalloc(sizeof(*dsi_device),
> GFP_KERNEL);
>230 if (!dsi_device) {
>231 kfree(dsi_host);
> ^^^
> But now it is non-NULL but it is a freed pointer. dsi_host = NULL;
>
>232 return -ENOMEM;
>233 }
>234 }
>235
>236 dsi_host->dev = dev;
>237 mipi_dsi_host_register(dsi_host);
>238 }
>239
>
> [ snip ]
>
>482
>483 of_node_put(dsi_in);
>484 of_node_put(dsi_node);
>485 ret = kmb_dsi_host_bridge_init(get_device(_pdev->dev));
>^^
> This get_device() needs a matching put_device(). I kind of like to put
> the kref_get() calls on their own line so that they're more obvious to
> the reader.
>
> get_device(_pdev->dev);
> kmb_dsi_host_bridge_init(_pdev->dev);
>
>486
>487 if (ret == -EPROBE_DEFER) {
>488 return -EPROBE_DEFER;
>489 } else if (ret) {
>490 DRM_ERROR("probe failed to
Re: [PULL] drm-intel-fixes
On Wed, Dec 02, 2020 at 04:36:24PM -0800, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
> use-after-free.
>
> The commit 6db58901c2aa ("drm/i915/display: return earlier from
> intel_modeset_init() without display") was not actually a crucial fix, but it
> allowed a clean pick of the use-after-free one.
>
> Here goes drm-intel-fixes-2020-12-02:
>
> Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
> use-after-free.
>
> - Program mocs:63 for cache eviction on gen9 (Chris)
> - Split the breadcrumb spinlock between global and contexts (Chris)
Please ignore this for now. I was informed that I missed one patch
that helps this one here. So I'm going to push a new fixes branch now
and will prepare another pull request tomorrow.
> - Retain default context state across shrinking (Venkata)
> - Limit frequency drop to RPe on parking (Chris)
> - Return earlier from intel_modeset_init() without display (Jani)
> - Defer initial modeset until after GGTT is initialized (Chris).
>
> Thanks,
> Rodrigo.
>
> The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:
>
> Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-12-02
>
> for you to fetch changes up to f2f2b21feadcb1eb08687a8b20dcf6442d22be18:
>
> drm/i915/display: Defer initial modeset until after GGTT is initialised
> (2020-12-01 08:36:37 -0800)
>
>
> Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
> use-after-free.
>
> - Program mocs:63 for cache eviction on gen9 (Chris)
> - Split the breadcrumb spinlock between global and contexts (Chris)
> - Retain default context state across shrinking (Venkata)
> - Limit frequency drop to RPe on parking (Chris)
> - Return earlier from intel_modeset_init() without display (Jani)
> - Defer initial modeset until after GGTT is initialized (Chris).
>
>
> Chris Wilson (4):
> drm/i915/gt: Program mocs:63 for cache eviction on gen9
> drm/i915/gt: Split the breadcrumb spinlock between global and contexts
> drm/i915/gt: Limit frequency drop to RPe on parking
> drm/i915/display: Defer initial modeset until after GGTT is initialised
>
> Jani Nikula (1):
> drm/i915/display: return earlier from intel_modeset_init() without
> display
>
> Venkata Ramana Nayana (1):
> drm/i915/gt: Retain default context state across shrinking
>
> drivers/gpu/drm/i915/display/intel_display.c | 24 ++--
> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 168
> ++
> drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 6 +-
> drivers/gpu/drm/i915/gt/intel_context.c | 3 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 12 +-
> drivers/gpu/drm/i915/gt/intel_mocs.c | 14 +-
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 +
> drivers/gpu/drm/i915/gt/shmem_utils.c | 7 +-
> drivers/gpu/drm/i915/i915_request.h | 6 +-
> 9 files changed, 124 insertions(+), 120 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #70 from mirh (m...@protonmail.ch) --- So.. I was also testing this on my Sapphire R9 290 Tri-X OC. And it seems to work pretty good. I noticed an oddity though. The first time I tried it, when I switched to manual fan control, every time I wrote something to pwm1 after one second the thing seemed to reset to the default speed. On subsequent reboots this didn't seem to happen anymore. -- 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
[PULL] drm-intel-fixes
Hi Dave and Daniel,
Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
use-after-free.
The commit 6db58901c2aa ("drm/i915/display: return earlier from
intel_modeset_init() without display") was not actually a crucial fix, but it
allowed a clean pick of the use-after-free one.
Here goes drm-intel-fixes-2020-12-02:
Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
use-after-free.
- Program mocs:63 for cache eviction on gen9 (Chris)
- Split the breadcrumb spinlock between global and contexts (Chris)
- Retain default context state across shrinking (Venkata)
- Limit frequency drop to RPe on parking (Chris)
- Return earlier from intel_modeset_init() without display (Jani)
- Defer initial modeset until after GGTT is initialized (Chris).
Thanks,
Rodrigo.
The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:
Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-12-02
for you to fetch changes up to f2f2b21feadcb1eb08687a8b20dcf6442d22be18:
drm/i915/display: Defer initial modeset until after GGTT is initialised
(2020-12-01 08:36:37 -0800)
Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
use-after-free.
- Program mocs:63 for cache eviction on gen9 (Chris)
- Split the breadcrumb spinlock between global and contexts (Chris)
- Retain default context state across shrinking (Venkata)
- Limit frequency drop to RPe on parking (Chris)
- Return earlier from intel_modeset_init() without display (Jani)
- Defer initial modeset until after GGTT is initialized (Chris).
Chris Wilson (4):
drm/i915/gt: Program mocs:63 for cache eviction on gen9
drm/i915/gt: Split the breadcrumb spinlock between global and contexts
drm/i915/gt: Limit frequency drop to RPe on parking
drm/i915/display: Defer initial modeset until after GGTT is initialised
Jani Nikula (1):
drm/i915/display: return earlier from intel_modeset_init() without display
Venkata Ramana Nayana (1):
drm/i915/gt: Retain default context state across shrinking
drivers/gpu/drm/i915/display/intel_display.c | 24 ++--
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 168 ++
drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 6 +-
drivers/gpu/drm/i915/gt/intel_context.c | 3 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 +-
drivers/gpu/drm/i915/gt/intel_mocs.c | 14 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 4 +
drivers/gpu/drm/i915/gt/shmem_utils.c | 7 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
9 files changed, 124 insertions(+), 120 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: avoid a use-after-free when BO init fails
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm_bo_init() invokes the provided
destructor which should de-initialize and free the memory.
Thus, when nouveau_bo_init() returns an error the gem object has already
been released and the memory freed by nouveau_bo_del_ttm().
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Cc: Thierry Reding
Signed-off-by: Jeremy Cline
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 787d05eefd9c..d30157cc7169 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -211,10 +211,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int
align, uint32_t domain,
}
ret = nouveau_bo_init(nvbo, size, align, domain, NULL, NULL);
- if (ret) {
- nouveau_bo_ref(NULL, );
+ if (ret)
return ret;
- }
/* we restrict allowed domains on nv50+ to only the types
* that were requested at creation time. not possibly on
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] soc: mediatek: cmdq: Remove cmdq_pkt_flush()
rx_callback is a standard mailbox callback mechanism and could
cover the function of proprietary cmdq_task_cb, so it is better
to use the standard one instead of the proprietary one. But
register rx_callback should before mbox_request_channel(),
so remove cmdq_pkt_flush() and let client driver implement
its own synchronous flush.
Signed-off-by: Chun-Kuang Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 32 --
include/linux/soc/mediatek/mtk-cmdq.h | 12 --
2 files changed, 44 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 505651b0d715..fd3bc39538a1 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -502,36 +502,4 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
cmdq_async_flush_cb cb,
}
EXPORT_SYMBOL(cmdq_pkt_flush_async);
-struct cmdq_flush_completion {
- struct completion cmplt;
- bool err;
-};
-
-static void cmdq_pkt_flush_cb(struct cmdq_cb_data data)
-{
- struct cmdq_flush_completion *cmplt;
-
- cmplt = (struct cmdq_flush_completion *)data.data;
- if (data.sta != CMDQ_CB_NORMAL)
- cmplt->err = true;
- else
- cmplt->err = false;
- complete(>cmplt);
-}
-
-int cmdq_pkt_flush(struct cmdq_pkt *pkt)
-{
- struct cmdq_flush_completion cmplt;
- int err;
-
- init_completion();
- err = cmdq_pkt_flush_async(pkt, cmdq_pkt_flush_cb, );
- if (err < 0)
- return err;
- wait_for_completion();
-
- return cmplt.err ? -EFAULT : 0;
-}
-EXPORT_SYMBOL(cmdq_pkt_flush);
-
MODULE_LICENSE("GPL v2");
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 960704d75994..2c6aa84c0e80 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -288,16 +288,4 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
void *data);
-/**
- * cmdq_pkt_flush() - trigger CMDQ to execute the CMDQ packet
- * @pkt: the CMDQ packet
- *
- * Return: 0 for success; else the error code is returned
- *
- * Trigger CMDQ to execute the CMDQ packet. Note that this is a
- * synchronous flush function. When the function returned, the recorded
- * commands have been done.
- */
-int cmdq_pkt_flush(struct cmdq_pkt *pkt);
-
#endif /* __MTK_CMDQ_H__ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Wed, Dec 2, 2020 at 8:48 PM James Park wrote: > > I can avoid modifying drm.h by doing this to drm_fourcc.h: > > #ifdef _WIN32 > #include > typedef uint64_t __u64; > #else > #include "drm.h" > #endif > > And this to amdgpu_drm.h: > > #ifdef _WIN32 > #include > typedef int32_t __s32; > typedef uint32_t __u32; > typedef uint64_t __u64; > #else > #include "drm.h" > #endif > > But now I'm touching two files under drm-uapi instead of one, and weirdly. > > If we're trying to cut ties with the drm-uapi folder entirely, the stuff > ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and > AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these > definitions? The drm_fourcc.h maybe makes some sense (I think in some places mesa uses these internally, and many drivers use the modifiers directly in the main driver). But the amdgpu header should be all ioctl stuff, which should be all entirely in the winsys only. Also kinda disappointing that drm_fourcc.h includes drm.h and isn't standalone, but I guess that sailed (at least for linux). -Daniel > Thanks, > James > > On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer wrote: >> >> On 2020-12-02 1:46 p.m., Daniel Vetter wrote: >> > On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote: >> >> >> >> On 2020-12-01 11:01 a.m., James Park wrote: >> >>> This will allow Mesa to port code to Windows more easily. >> >> >> >> As discussed in >> >> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779 >> >> , including drm.h makes no sense when building for Windows. >> > >> > Yeah I think it'd be cleanest if we can avoid this. If not I think the >> > right fix would be to split out the actually needed parts from drm.h >> > into a new header (still included by drm.h for backwards compat >> > reasons) which mesa can use. Since it looks like the problematic parts >> > are the legacy gunk, and not the new ioctl structures. Pulling out >> > drm_render.h for all the render stuff and mabe drm_vblank.h for the >> > vblank stuff (which would fit better in drm_mode.h but mistakes were >> > made, oops). >> >> If anything currently in drm.h is needed while building for Windows, it >> points to a broken abstraction somewhere in userspace. (Specifically, >> the Mesa Gallium/Vulkan winsys is supposed to abstract away platform >> details like these) >> >> >> -- >> Earthling Michel Dänzer | https://redhat.com >> Libre software enthusiast | Mesa and X developer -- 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
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #69 from fawz (f...@negentropy.io) --- Well, I'll have a read! And thanks anyways, I'll run this going forward, post if there are issues and am looking forward to seeing this in mainline at some point :) -- 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
[PATCH rdma-core v4 4/6] pyverbs: Add dma-buf based MR support
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by: Jianxin Xiong
---
buildlib/pyverbs_functions.cmake | 78 +++
pyverbs/CMakeLists.txt | 11 +-
pyverbs/dmabuf.pxd | 15 +++
pyverbs/dmabuf.pyx | 73 ++
pyverbs/dmabuf_alloc.c | 278 +++
pyverbs/dmabuf_alloc.h | 19 +++
pyverbs/libibverbs.pxd | 2 +
pyverbs/mr.pxd | 6 +
pyverbs/mr.pyx | 105 ++-
9 files changed, 557 insertions(+), 30 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
create mode 100644 pyverbs/dmabuf_alloc.c
create mode 100644 pyverbs/dmabuf_alloc.h
diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index 953cec2..0792410 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -1,35 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2018, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved. See COPYING file
+
+function(build_module_from_cfiles PY_MODULE MODULE_NAME ALL_CFILES
LINKER_FLAGS)
+ string(REGEX REPLACE "\\.so$" "" SONAME
"${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
+ add_library(${SONAME} SHARED ${ALL_CFILES})
+ set_target_properties(${SONAME} PROPERTIES
+COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
+LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
+PREFIX "")
+ target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
+ install(TARGETS ${SONAME}
+DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+endfunction()
function(rdma_cython_module PY_MODULE LINKER_FLAGS)
- foreach(PYX_FILE ${ARGN})
-get_filename_component(FILENAME ${PYX_FILE} NAME_WE)
-get_filename_component(DIR ${PYX_FILE} DIRECTORY)
- if (DIR)
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}/${FILENAME}.pyx")
- else()
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}.pyx")
- endif()
-set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
-include_directories(${PYTHON_INCLUDE_DIRS})
-add_custom_command(
- OUTPUT "${CFILE}"
- MAIN_DEPENDENCY "${PYX}"
- COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
- "-I${PYTHON_INCLUDE_DIRS}"
- COMMENT "Cythonizing ${PYX}"
+ set(ALL_CFILES "")
+ set(MODULE_NAME "")
+ foreach(SRC_FILE ${ARGN})
+get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
+get_filename_component(DIR ${SRC_FILE} DIRECTORY)
+get_filename_component(EXT ${SRC_FILE} EXT)
+if (DIR)
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
+else()
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+endif()
+if (${EXT} STREQUAL ".pyx")
+ # each .pyx file starts a new module, finish the previous module first
+ if (ALL_CFILES AND MODULE_NAME)
+build_module_from_cfiles(${PY_MODULE} ${MODULE_NAME} "${ALL_CFILES}"
"${LINKER_FLAGS}")
+ endif()
+ set(PYX "${SRC_PATH}/${FILENAME}.pyx")
+ set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+ include_directories(${PYTHON_INCLUDE_DIRS})
+ add_custom_command(
+OUTPUT "${CFILE}"
+MAIN_DEPENDENCY "${PYX}"
+COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
+"-I${PYTHON_INCLUDE_DIRS}"
+COMMENT "Cythonizing ${PYX}"
)
-
-string(REGEX REPLACE "\\.so$" "" SONAME
"${FILENAME}${CMAKE_PYTHON_SO_SUFFIX}")
-add_library(${SONAME} SHARED ${CFILE})
-set_target_properties(${SONAME} PROPERTIES
- COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
- LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
- PREFIX "")
-target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
-install(TARGETS ${SONAME}
- DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+ set(MODULE_NAME ${FILENAME})
+ set(ALL_CFILES "${CFILE}")
+elseif(${EXT} STREQUAL ".c")
+ # .c files belong to the same module as the most recent .pyx file,
+ # ignored if appearing before all .pyx files
+ set(CFILE
[PATCH rdma-core v4 1/6] Update kernel headers
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
kernel-headers/rdma/ib_user_verbs.h | 14 --
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
};
enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
};
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+ UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
};
diff --git a/kernel-headers/rdma/ib_user_verbs.h
b/kernel-headers/rdma/ib_user_verbs.h
index 456438c..7ee73a0 100644
--- a/kernel-headers/rdma/ib_user_verbs.h
+++ b/kernel-headers/rdma/ib_user_verbs.h
@@ -596,20 +596,6 @@ enum {
IB_UVERBS_CREATE_QP_SUP_COMP_MASK = IB_UVERBS_CREATE_QP_MASK_IND_TABLE,
};
-enum {
- /*
-* This value is equal to IB_QP_DEST_QPN.
-*/
- IB_USER_LEGACY_LAST_QP_ATTR_MASK = 1ULL << 20,
-};
-
-enum {
- /*
-* This value is equal to IB_QP_RATE_LIMIT.
-*/
- IB_USER_LAST_QP_ATTR_MASK = 1ULL << 25,
-};
-
struct ib_uverbs_ex_create_qp {
__aligned_u64 user_handle;
__u32 pd_handle;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v4 5/6] tests: Add tests for dma-buf based memory regions
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py | 4 +
tests/test_mr.py | 264 ++-
tests/utils.py | 26 +
3 files changed, 293 insertions(+), 1 deletion(-)
diff --git a/tests/args_parser.py b/tests/args_parser.py
index 71a0f34..4e12d52 100644
--- a/tests/args_parser.py
+++ b/tests/args_parser.py
@@ -16,6 +16,10 @@ class ArgsParser(object):
parser = argparse.ArgumentParser()
parser.add_argument('--dev',
help='RDMA device to run the tests on')
+parser.add_argument('--gpu', nargs='?', type=int, const=0, default=0,
+help='GPU unit to allocate dmabuf from')
+parser.add_argument('--gtt', action='store_true', default=False,
+help='Allocate dmabuf from GTT instead of VRAM')
parser.add_argument('-v', '--verbose', dest='verbosity',
action='store_const',
const=2, help='Verbose output')
diff --git a/tests/test_mr.py b/tests/test_mr.py
index adc649c..6915853 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019 Mellanox Technologies, Inc. All rights reserved. See
COPYING file
+# Copyright (c) 2020 Intel Corporation. All rights reserved. See COPYING file
"""
Test module for pyverbs' mr module.
"""
@@ -9,9 +10,10 @@ import errno
from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
import pyverbs.device as d
from pyverbs.pd import PD
import pyverbs.enums as e
@@ -366,3 +368,263 @@ class DMMRTest(PyverbsAPITestCase):
dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
dm=dm, offset=dm_mr_offset)
dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.ENOENT:
+raise unittest.SkipTest(f'Device /dev/dri/renderD{device_num} is
not present')
+if ex.error_code == errno.EACCES:
+raise unittest.SkipTest(f'Lack of permission to access
/dev/dri/renderD{device_num}')
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest(f'Allocating dmabuf is not supported by
/dev/dri/renderD{device_num}')
+
+
+def check_dmabuf_mr_support(pd, unit=0):
+"""
+Check if dma-buf MR registration is supported by the driver.
+Skip the test on failure
+"""
+try:
+DmaBufMR(pd, 1, 0, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest('Reg dma-buf MR is not supported by the
RDMA driver')
+
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def setUp(self):
+super().setUp()
+self.unit = self.config['gpu']
+self.gtt = self.config['gtt']
+
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+ gtt=self.gtt) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+ gtt=self.gtt) as mr:
+
[PATCH rdma-core v4 6/6] tests: Bug fix for get_access_flags()
The filter definition is wrong and causes get_access_flags() always returning empty list. As the result the MR tests using this function are effectively skipped (but report success). Signed-off-by: Jianxin Xiong --- tests/utils.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/utils.py b/tests/utils.py index d3d5c16..8bd0c16 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -56,8 +56,8 @@ def filter_illegal_access_flags(element): :param element: A list of access flags to check :return: True if this list is legal, else False """ -if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE: -if e.IBV_ACCESS_LOCAL_WRITE: +if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in element: +if not e.IBV_ACCESS_LOCAL_WRITE in element: return False return True -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v4 3/6] mlx5: Support dma-buf based memory region
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index 1378acf..b3e2d57 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -96,6 +97,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+ .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr = mlx5_rereg_mr,
.dereg_mr = mlx5_dereg_mr,
.alloc_mw = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index 8c94f72..17a2470 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -903,6 +904,8 @@ void mlx5_async_event(struct ibv_context *context,
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int access);
int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void
*addr,
size_t length, int access);
int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index b956156..a7fc3b0 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -647,6 +648,27 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr,
size_t length,
return >vmr.ibv_mr;
}
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int acc)
+{
+ struct mlx5_mr *mr;
+ int ret;
+
+ mr = calloc(1, sizeof(*mr));
+ if (!mr)
+ return NULL;
+
+ ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, acc,
+ >vmr);
+ if (ret) {
+ free(mr);
+ return NULL;
+ }
+ mr->alloc_flags = acc;
+
+ return >vmr.ibv_mr;
+}
+
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
{
struct mlx5_mr *mr;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v4 0/6] Add user space dma-buf support
This is the fourth version of the patch series. Change log: v4: * Rework the cmake funciton rdma_cython_module to support both single source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead of using two separate functions * Rename 'dri_*' to 'drm_*' for the dmabuf allocation interface * Add option to dmabuf allocation routine to allow allocation from GTT instead of VRAM * Add proper CPU access flags when allocating dmabufs * Remove 'radeon' driver support from the dmabuf allocation routines * Add comand line arguments to the tests for selecting GPU unit and setting the option for allocating from GTT v3: https://www.spinics.net/lists/linux-rdma/msg98059.html * Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API * Change the way of allocating dma-buf object - use /dev/dri/renderD* instead of /dev/dri/card* and use GEM object instead of dumb buffer * Add cmake function to allow building modules with mixed cython and C source files * Add new tests that use dma-buf MRs for send/recv and rdma traffic * Skip dma-buf tests on unsupported systems * Remove some use of random values in the new tests * Add dealloc() and close() methods to the new classes * Replace string.format with f-string in python code * Fix some coding style issues: spacing, indentation, typo, comments v2: https://www.spinics.net/lists/linux-rdma/msg97936.html * Put the kernel header updates into a separate commit * Add comments for the data structure used in python ioctl calls * Fix issues related to symbol versioning * Fix styling issues: extra spaces, unncecessary variable, typo * Fix an inproper error code usage * Put the new op into ibv_context_ops instead if verbs_context v1: https://www.spinics.net/lists/linux-rdma/msg97865.html * Add user space API for registering dma-buf based memory regions * Update pyverbs with the new API * Add new tests This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This series consists of six patches. The first patch updates the kernel headers for dma-buf support. Patch 2 adds the new API function and updates the man pages. Patch 3 implements the new API in the mlx5 provider. Patch 4 adds new class definitions to pyverbs for the new API. Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in the utility code of the tests. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895 Jianxin Xiong (6): Update kernel headers verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() buildlib/pyverbs_functions.cmake | 78 ++--- debian/libibverbs1.symbols | 2 + kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++ kernel-headers/rdma/ib_user_verbs.h | 14 -- libibverbs/CMakeLists.txt| 2 +- libibverbs/cmd_mr.c | 38 + libibverbs/driver.h | 7 + libibverbs/dummy_ops.c | 11 ++ libibverbs/libibverbs.map.in | 6 + libibverbs/man/ibv_reg_mr.3 | 27 ++- libibverbs/verbs.c | 18 ++ libibverbs/verbs.h | 11 ++ providers/mlx5/mlx5.c| 2 + providers/mlx5/mlx5.h| 3 + providers/mlx5/verbs.c | 22 +++ pyverbs/CMakeLists.txt | 11 +- pyverbs/dmabuf.pxd | 15 ++ pyverbs/dmabuf.pyx | 73 pyverbs/dmabuf_alloc.c | 278 +++ pyverbs/dmabuf_alloc.h | 19 +++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 6 + pyverbs/mr.pyx | 105 +++- tests/args_parser.py | 4 + tests/test_mr.py | 264 - tests/utils.py | 30 +++- 26 files changed, 1012 insertions(+), 50 deletions(-) create mode 100644 pyverbs/dmabuf.pxd create mode 100644 pyverbs/dmabuf.pyx create mode 100644 pyverbs/dmabuf_alloc.c create mode 100644 pyverbs/dmabuf_alloc.h -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v4 2/6] verbs: Support dma-buf based memory region
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 ++
libibverbs/driver.h | 7 +++
libibverbs/dummy_ops.c | 11 +++
libibverbs/libibverbs.map.in | 6 ++
libibverbs/man/ibv_reg_mr.3 | 27 +--
libibverbs/verbs.c | 18 ++
libibverbs/verbs.h | 11 +++
9 files changed, 119 insertions(+), 3 deletions(-)
diff --git a/debian/libibverbs1.symbols b/debian/libibverbs1.symbols
index 9130f41..fcf4d87 100644
--- a/debian/libibverbs1.symbols
+++ b/debian/libibverbs1.symbols
@@ -9,6 +9,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
IBVERBS_1.9@IBVERBS_1.9 30
IBVERBS_1.10@IBVERBS_1.10 31
IBVERBS_1.11@IBVERBS_1.11 32
+ IBVERBS_1.12@IBVERBS_1.12 33
(symver)IBVERBS_PRIVATE_33 33
_ibv_query_gid_ex@IBVERBS_1.11 32
_ibv_query_gid_table@IBVERBS_1.11 32
@@ -99,6 +100,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
ibv_rate_to_mbps@IBVERBS_1.1 1.1.8
ibv_rate_to_mult@IBVERBS_1.0 1.1.6
ibv_read_sysfs_file@IBVERBS_1.0 1.1.6
+ ibv_reg_dmabuf_mr@IBVERBS_1.12 33
ibv_reg_mr@IBVERBS_1.0 1.1.6
ibv_reg_mr@IBVERBS_1.1 1.1.6
ibv_reg_mr_iova@IBVERBS_1.7 25
diff --git a/libibverbs/CMakeLists.txt b/libibverbs/CMakeLists.txt
index 0fe4256..d075225 100644
--- a/libibverbs/CMakeLists.txt
+++ b/libibverbs/CMakeLists.txt
@@ -21,7 +21,7 @@ configure_file("libibverbs.map.in"
rdma_library(ibverbs "${CMAKE_CURRENT_BINARY_DIR}/libibverbs.map"
# See Documentation/versioning.md
- 1 1.11.${PACKAGE_VERSION}
+ 1 1.12.${PACKAGE_VERSION}
all_providers.c
cmd.c
cmd_ah.c
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..95ed2d1 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mellanox Technologies, Ltd. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr
*vmr,
return 0;
}
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+ DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
+ 9);
+ struct ib_uverbs_attr *handle;
+ uint32_t lkey, rkey;
+ int ret;
+
+ handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, );
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, );
+
+ fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
access);
+
+ ret = execute_ioctl(pd->context, cmdb);
+ if (ret)
+ return errno;
+
+ vmr->ibv_mr.handle = read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ handle);
+ vmr->ibv_mr.context = pd->context;
+ vmr->ibv_mr.lkey = lkey;
+ vmr->ibv_mr.rkey = rkey;
+ vmr->ibv_mr.pd = pd;
+ vmr->ibv_mr.addr = (void *)offset;
+ vmr->ibv_mr.length = length;
+ vmr->mr_type = IBV_MR_TYPE_MR;
+ return 0;
+}
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index ab80f4b..d6a9d0a 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -2,6 +2,7 @@
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005, 2006 Cisco Systems, Inc. All rights reserved.
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -373,6 +374,9 @@ struct verbs_context_ops {
struct ibv_mr *(*reg_dm_mr)(struct ibv_pd *pd, struct ibv_dm *dm,
uint64_t dm_offset, size_t length,
unsigned int access);
+ struct ibv_mr *(*reg_dmabuf_mr)(struct ibv_pd *pd, uint64_t offset,
+ size_t length, uint64_t iova,
+
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #68 from Alex Deucher (alexdeuc...@gmail.com) --- It's pretty similar to other the code for other smu7 chips (tonga, polaris, etc.). Note that this change is not relevant to newer smu7 chips (rx480, tonga, etc.). -- 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 v4 68/80] drm/panel: panel-dsi-cm: remove extra 'if'
Hi Tomi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on omap/for-next]
[also build test WARNING on robh/for-next balbi-usb/testing/next linus/master
v5.10-rc6]
[cannot apply to next-20201201]
[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/Tomi-Valkeinen/Convert-DSI-code-to-use-drm_mipi_dsi-and-drm_panel/20201124-205129
base: https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
for-next
config: riscv-randconfig-r016-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2671fccf0381769276ca8246ec0499adcb9b0355)
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
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/09d304dc23e60a46580ec8a3d7db7210138fc9db
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Tomi-Valkeinen/Convert-DSI-code-to-use-drm_mipi_dsi-and-drm_panel/20201124-205129
git checkout 09d304dc23e60a46580ec8a3d7db7210138fc9db
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/panel/panel-dsi-cm.c:210:6: warning: variable 'r' is used
>> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (ddata->enabled)
^~
drivers/gpu/drm/panel/panel-dsi-cm.c:216:9: note: uninitialized use occurs
here
return r;
^
drivers/gpu/drm/panel/panel-dsi-cm.c:210:2: note: remove the 'if' if its
condition is always true
if (ddata->enabled)
^~~
drivers/gpu/drm/panel/panel-dsi-cm.c:197:7: note: initialize the variable
'r' to silence this warning
int r;
^
= 0
1 warning generated.
vim +210 drivers/gpu/drm/panel/panel-dsi-cm.c
193
194 static int dsicm_bl_update_status(struct backlight_device *dev)
195 {
196 struct panel_drv_data *ddata = dev_get_drvdata(>dev);
197 int r;
198 int level;
199
200 if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
201 dev->props.power == FB_BLANK_UNBLANK)
202 level = dev->props.brightness;
203 else
204 level = 0;
205
206 dev_dbg(>dsi->dev, "update brightness to %d\n", level);
207
208 mutex_lock(>lock);
209
> 210 if (ddata->enabled)
211 r = dsicm_dcs_write_1(ddata,
MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
212level);
213
214 mutex_unlock(>lock);
215
216 return r;
217 }
218
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #67 from fawz (f...@negentropy.io) --- > I guess we need to fan control parameters. How about this patch? After some quick testing, your latest patch seems to work great! And new code, ie. something not just taken from the other families? I'll try to get an RX 480 user to test this, but seems to work wonders for me. A welcome change with this patch is that the default fan control mode at boot is now 2/auto. Thanks for your help with this! Very much appreciated. -- 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 v2 5/8] drm/amdgpu: Refactor sysfs removal
On 12/2/20 1:20 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
On 12/2/20 12:34 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
On 11/11/20 10:34 AM, Greg KH wrote:
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
On 11/10/20 12:59 PM, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
Hi, back to this after a long context switch for some higher priority stuff.
So here I was able eventually to drop all this code and this change here
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C13040ab9b50947a95acc08d896eec15d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425299507092187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CIXEl9hWHTAdo7t9yrdtu0OdEIZ3X2GQmJRhDUj28mw%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.
A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.
And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.
Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?
Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly. And yes, the driver core will automatically remove them as
well.
Please use the default groups attribute for your bus/subsystem and this
will happen automagically.
Hi Greg, I tried your suggestion to hang amdgpu's sysfs
attributes on default attributes in struct device.groups but turns out it's
not usable since by the
time i have access to struct device from amdgpu code it has already been
initialized by pci core
(i.e. past the point where device_add->device_add_attrs->device_add_groups
with dev->groups is called)
and so i can't really use it.
That's odd, why can't you just set the groups pointer in your pci_driver
structure? That's what it is there for, right?
I am probably missing something but amdgpu sysfs attrs are per device not
per driver
Oops, you are right, you want the 'dev_groups' field. Looks like pci
doesn't export that directly, so you can do:
.driver {
.dev_groups = my_device_groups;
},
in your pci_driver structure.
Or I'm sure the PCI driver maintainer would take a patch like
7d9c1d2f7aca ("USB: add support for dev_groups to struct
usb_device_driver") was done for the USB subsystem, as diving into the
"raw" .driver pointer isn't really that clean or nice in my opinion.
Looks like what I need exactly. I will probably start with assigning raw pointer
just
to push ahead my work and in parallel will probably submit same patch as yours
for PCI subsystem review as the rework to switch to this is really minimal.
Andrey
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
>
> On 12/2/20 12:34 PM, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
> > > On 11/11/20 10:34 AM, Greg KH wrote:
> > > > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > > > > > Hi, back to this after a long context switch for some higher
> > > > > > > priority stuff.
> > > > > > >
> > > > > > > So here I was able eventually to drop all this code and this
> > > > > > > change here
> > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C29ff7efb89bd47d8488708d896e86e7c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425272317529134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Vzc3fVofA6%2BMPSqHmBqcWavQLKWU1%2FXKJFun24irLf0%3Dreserved=0
> > > > > > > was enough for me. Seems like while device_remove_file can handle
> > > > > > > the use
> > > > > > > case where the file and the parent directory already gone,
> > > > > > > sysfs_remove_group goes down in flames in that case
> > > > > > > due to kobj->sd being unset on device removal.
> > > > > > A driver shouldn't ever have to remove individual sysfs groups, the
> > > > > > driver core/bus logic should do it for them automatically.
> > > > > >
> > > > > > And whenever a driver calls a sysfs_* call, that's a hint that
> > > > > > something
> > > > > > is not working properly.
> > > > >
> > > > > Do you mean that while the driver creates the groups and files
> > > > > explicitly
> > > > > from it's different subsystems it should not explicitly remove each
> > > > > one of them because all of them should be removed at once (and
> > > > > recursively) when the device is being removed ?
> > > > Individual drivers should never add groups/files in sysfs, the driver
> > > > core should do it properly for you if you have everything set up
> > > > properly. And yes, the driver core will automatically remove them as
> > > > well.
> > > >
> > > > Please use the default groups attribute for your bus/subsystem and this
> > > > will happen automagically.
> > >
> > > Hi Greg, I tried your suggestion to hang amdgpu's sysfs
> > > attributes on default attributes in struct device.groups but turns out
> > > it's
> > > not usable since by the
> > > time i have access to struct device from amdgpu code it has already been
> > > initialized by pci core
> > > (i.e. past the point where
> > > device_add->device_add_attrs->device_add_groups
> > > with dev->groups is called)
> > > and so i can't really use it.
> > That's odd, why can't you just set the groups pointer in your pci_driver
> > structure? That's what it is there for, right?
>
> I am probably missing something but amdgpu sysfs attrs are per device not
> per driver
Oops, you are right, you want the 'dev_groups' field. Looks like pci
doesn't export that directly, so you can do:
.driver {
.dev_groups = my_device_groups;
},
in your pci_driver structure.
Or I'm sure the PCI driver maintainer would take a patch like
7d9c1d2f7aca ("USB: add support for dev_groups to struct
usb_device_driver") was done for the USB subsystem, as diving into the
"raw" .driver pointer isn't really that clean or nice in my opinion.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On 2020-12-02 1:46 p.m., Daniel Vetter wrote: On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote: On 2020-12-01 11:01 a.m., James Park wrote: This will allow Mesa to port code to Windows more easily. As discussed in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779 , including drm.h makes no sense when building for Windows. Yeah I think it'd be cleanest if we can avoid this. If not I think the right fix would be to split out the actually needed parts from drm.h into a new header (still included by drm.h for backwards compat reasons) which mesa can use. Since it looks like the problematic parts are the legacy gunk, and not the new ioctl structures. Pulling out drm_render.h for all the render stuff and mabe drm_vblank.h for the vblank stuff (which would fit better in drm_mode.h but mistakes were made, oops). If anything currently in drm.h is needed while building for Windows, it points to a broken abstraction somewhere in userspace. (Specifically, the Mesa Gallium/Vulkan winsys is supposed to abstract away platform details like these) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On 12/2/20 12:34 PM, Greg KH wrote: On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote: On 11/11/20 10:34 AM, Greg KH wrote: On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote: On 11/10/20 12:59 PM, Greg KH wrote: On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote: Hi, back to this after a long context switch for some higher priority stuff. So here I was able eventually to drop all this code and this change here https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C29ff7efb89bd47d8488708d896e86e7c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425272317529134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Vzc3fVofA6%2BMPSqHmBqcWavQLKWU1%2FXKJFun24irLf0%3Dreserved=0 was enough for me. Seems like while device_remove_file can handle the use case where the file and the parent directory already gone, sysfs_remove_group goes down in flames in that case due to kobj->sd being unset on device removal. A driver shouldn't ever have to remove individual sysfs groups, the driver core/bus logic should do it for them automatically. And whenever a driver calls a sysfs_* call, that's a hint that something is not working properly. Do you mean that while the driver creates the groups and files explicitly from it's different subsystems it should not explicitly remove each one of them because all of them should be removed at once (and recursively) when the device is being removed ? Individual drivers should never add groups/files in sysfs, the driver core should do it properly for you if you have everything set up properly. And yes, the driver core will automatically remove them as well. Please use the default groups attribute for your bus/subsystem and this will happen automagically. Hi Greg, I tried your suggestion to hang amdgpu's sysfs attributes on default attributes in struct device.groups but turns out it's not usable since by the time i have access to struct device from amdgpu code it has already been initialized by pci core (i.e. past the point where device_add->device_add_attrs->device_add_groups with dev->groups is called) and so i can't really use it. That's odd, why can't you just set the groups pointer in your pci_driver structure? That's what it is there for, right? I am probably missing something but amdgpu sysfs attrs are per device not per driver and their life cycle is bound to the device and their location in the sysfs topology is under each device. Putting them as driver default attr will not put them in their current per device location and won't make them automatically be destroyed once a particular device goes away, no ? Andrey What I can only think of using is creating my own struct attribute_group ** array in amdgpu where I aggregate all amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci probe with that array and on device remove call device_remove_groups with the same array. Horrid, no, see above :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Remove udlfb driver
On Wed, Dec 2, 2020 at 8:55 AM Thomas Zimmermann wrote: > > Hi > > Am 01.12.20 um 12:20 schrieb Mikulas Patocka: > > > > > > On Tue, 1 Dec 2020, Thomas Zimmermann wrote: > > > >> Hi > >> > >> Am 30.11.20 um 19:39 schrieb Mikulas Patocka: > >>> > >>> > >>> On Mon, 30 Nov 2020, Daniel Vetter wrote: > >>> > On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote: > > > > The framebuffer driver supports programs running full-screen directly on > > the framebuffer console, such as web browser "links -g", image viewer > > "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", > > movie player "mplayer -vo fbdev". The DRM driver doesn't run them. > > Hm this should in general work on drm drivers. Without that it's clear > the > switch-over isn't really ready yet. > >>> > >>> I fixed it with this patch two years ago: > >>> https://lists.freedesktop.org/archives/dri-devel/2018-June/179023.html > >>> > >>> But the patch never went through and the fb_defio feature was removed in > >>> the kernel 5.6 (commit d0c4fc5a4814e431c15272935c8dc973c18073aa). > >>> > >>> > >>> Without fb_defio, the only other possibility how to update the screen is > >>> the ioctl DRM_IOCTL_MODE_DIRTYFB. But this ioctl requires master mode, so > >>> user programs like "links -g" can't issue it. > >> > >> That's confusing. DIRTYFB is only for DRM. > > > > Yes, you're right. > > > >> And why can links not run as DRM master mode? If it renders to the > >> terminal, > >> it should act like a composer. In that case it almost certainly wants > >> master > >> status. > >> > >> Best regards > >> Thomas > > > > How can a userspace program acquire master mode without being suid? > > For my understanding, there's no easy solution to that. :/ If you're absolutely the only thing running, the first one to open the card* node wins. But usually you have something like logind managing this for you (for vt switching), since ad-hoc this is a very fragile scheme. I'm not exactly sure how logind gives you an already opened drm device in master mode, that's a bit tricky. Without either being suid root or participating in the logind scheme you won't be able to vt switch though. But bare metal kms usage should work I as-is. -Daniel > > I guess we (DRM devs) have to treat fbdev as the solution for use cases > such as ours. > > For the unplug issue, I'll try to reproduce and fix it. > > For the performance problems, we might be able to squeeze a few more > cycles out of it. > > Best regards > Thomas > > > > > Is there some "Hello World!" program that shows how to use DRM? I'm not an > > expert in DRM, but if there were some tutorial+documentation, I could > > consider porting "links" to it. > > > > Mikulas > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote: > > On 11/11/20 10:34 AM, Greg KH wrote: > > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote: > > > On 11/10/20 12:59 PM, Greg KH wrote: > > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote: > > > > > Hi, back to this after a long context switch for some higher priority > > > > > stuff. > > > > > > > > > > So here I was able eventually to drop all this code and this change > > > > > here > > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0 > > > > > was enough for me. Seems like while device_remove_file can handle the > > > > > use > > > > > case where the file and the parent directory already gone, > > > > > sysfs_remove_group goes down in flames in that case > > > > > due to kobj->sd being unset on device removal. > > > > A driver shouldn't ever have to remove individual sysfs groups, the > > > > driver core/bus logic should do it for them automatically. > > > > > > > > And whenever a driver calls a sysfs_* call, that's a hint that something > > > > is not working properly. > > > > > > > > > Do you mean that while the driver creates the groups and files explicitly > > > from it's different subsystems it should not explicitly remove each > > > one of them because all of them should be removed at once (and > > > recursively) when the device is being removed ? > > Individual drivers should never add groups/files in sysfs, the driver > > core should do it properly for you if you have everything set up > > properly. And yes, the driver core will automatically remove them as > > well. > > > > Please use the default groups attribute for your bus/subsystem and this > > will happen automagically. > > > Hi Greg, I tried your suggestion to hang amdgpu's sysfs > attributes on default attributes in struct device.groups but turns out it's > not usable since by the > time i have access to struct device from amdgpu code it has already been > initialized by pci core > (i.e. past the point where device_add->device_add_attrs->device_add_groups > with dev->groups is called) > and so i can't really use it. That's odd, why can't you just set the groups pointer in your pci_driver structure? That's what it is there for, right? > What I can only think of using is creating my own struct attribute_group ** > array in amdgpu where I aggregate all > amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci > probe with that array and on device remove call > device_remove_groups with the same array. Horrid, no, see above :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Used the vram helper
Hi Tian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.10-rc6 next-20201201]
[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/Tian-Tao/drm-vboxvideo-Used-the-vram-helper/20201127-112000
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
85a2c56cb4454c73f56d3099d96942e7919b292f
config: x86_64-randconfig-a016-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2671fccf0381769276ca8246ec0499adcb9b0355)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/f3abc53a9794f39d04b604a243d28be17a88571f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Tian-Tao/drm-vboxvideo-Used-the-vram-helper/20201127-112000
git checkout f3abc53a9794f39d04b604a243d28be17a88571f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/vboxvideo/vbox_ttm.c:19:6: warning: incompatible integer to
>> pointer conversion assigning to 'struct drm_vram_mm *' from 'int'
>> [-Wint-conversion]
vmm = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
^
1 warning generated.
vim +19 drivers/gpu/drm/vboxvideo/vbox_ttm.c
12
13 int vbox_mm_init(struct vbox_private *vbox)
14 {
15 struct drm_vram_mm *vmm;
16 int ret;
17 struct drm_device *dev = >ddev;
18
> 19 vmm = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev,
0),
20 vbox->available_vram_size);
21 if (IS_ERR(vmm)) {
22 ret = PTR_ERR(vmm);
23 DRM_ERROR("Error initializing VRAM MM; %d\n", ret);
24 return ret;
25 }
26
27 vbox->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev,
0),
28 pci_resource_len(dev->pdev,
0));
29 return 0;
30 }
31
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/msm: adreno: Make speed-bin support generic
On Wed, Dec 02, 2020 at 08:53:51PM +0530, Akhil P Oommen wrote:
> On 11/30/2020 10:32 PM, Jordan Crouse wrote:
> >On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
> >>So far a530v2 gpu has support for detecting its supported opps
> >>based on a fuse value called speed-bin. This patch makes this
> >>support generic across gpu families. This is in preparation to
> >>extend speed-bin support to a6x family.
> >>
> >>Signed-off-by: Akhil P Oommen
> >>---
> >>Changes from v1:
> >>1. Added the changes to support a618 sku to the series.
> >>2. Avoid failing probe in case of an unsupported sku. (Rob)
> >>
> >> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 --
> >> drivers/gpu/drm/msm/adreno/adreno_device.c | 4 ++
> >> drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71
> >> ++
> >> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +++
> >> 4 files changed, 80 insertions(+), 34 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> >>b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> >>index 8fa5c91..7d42321 100644
> >>--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> >>+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> >>@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
> >>.get_timestamp = a5xx_get_timestamp,
> >> };
> >>-static void check_speed_bin(struct device *dev)
> >>-{
> >>- struct nvmem_cell *cell;
> >>- u32 val;
> >>-
> >>- /*
> >>-* If the OPP table specifies a opp-supported-hw property then we have
> >>-* to set something with dev_pm_opp_set_supported_hw() or the table
> >>-* doesn't get populated so pick an arbitrary value that should
> >>-* ensure the default frequencies are selected but not conflict with any
> >>-* actual bins
> >>-*/
> >>- val = 0x80;
> >>-
> >>- cell = nvmem_cell_get(dev, "speed_bin");
> >>-
> >>- if (!IS_ERR(cell)) {
> >>- void *buf = nvmem_cell_read(cell, NULL);
> >>-
> >>- if (!IS_ERR(buf)) {
> >>- u8 bin = *((u8 *) buf);
> >>-
> >>- val = (1 << bin);
> >>- kfree(buf);
> >>- }
> >>-
> >>- nvmem_cell_put(cell);
> >>- }
> >>-
> >>- dev_pm_opp_set_supported_hw(dev, , 1);
> >>-}
> >>-
> >> struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
> >> {
> >>struct msm_drm_private *priv = dev->dev_private;
> >>@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
> >>a5xx_gpu->lm_leakage = 0x4E001A;
> >>- check_speed_bin(>dev);
> >>-
> >>ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
> >>if (ret) {
> >>a5xx_destroy(&(a5xx_gpu->base.base));
> >>diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> >>b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >>index 87c8b03..e0ff16c 100644
> >>--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> >>+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >>@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
> >> MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU
> >> devcoredump (if not fused off)");
> >> module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
> >>+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
> >>+
> >> static const struct adreno_info gpulist[] = {
> >>{
> >>.rev = ADRENO_REV(2, 0, 0, 0),
> >>@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
> >>ADRENO_QUIRK_FAULT_DETECT_MASK,
> >>.init = a5xx_gpu_init,
> >>.zapfw = "a530_zap.mdt",
> >>+ .speedbins = a530v2_speedbins,
> >>+ .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
> >>}, {
> >>.rev = ADRENO_REV(5, 4, 0, 2),
> >>.revn = 540,
> >>diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>index f21561d..b342fa4 100644
> >>--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>@@ -14,6 +14,7 @@
> >> #include
> >> #include
> >> #include
> >>+#include
> >> #include
> >> #include "adreno_gpu.h"
> >> #include "msm_gem.h"
> >>@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
> >>*adreno_ocmem)
> >> adreno_ocmem->hdl);
> >> }
> >>+static int adreno_set_supported_hw(struct device *dev,
> >>+ struct adreno_gpu *adreno_gpu)
> >>+{
> >>+ u8 speedbins_count = adreno_gpu->info->speedbins_count;
> >>+ const u32 *speedbins = adreno_gpu->info->speedbins;
> >>+ struct nvmem_cell *cell;
> >>+ u32 bin, i;
> >>+ u32 val = 0;
> >>+ void *buf, *opp_table;
> >>+
> >>+ cell = nvmem_cell_get(dev, "speed_bin");
> >>+ /*
> >>+* -ENOENT means that the platform doesn't support speedbin which is
> >>+* fine
> >>+*/
> >>+ if (PTR_ERR(cell) == -ENOENT)
> >>+ return 0;
> >>+ else if (IS_ERR(cell))
> >>+ return PTR_ERR(cell);
> >>+
> >>+ if (!speedbins)
> >>+
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added Attachment #293903|0 |1 is obsolete|| --- Comment #66 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 293909 --> https://bugzilla.kernel.org/attachment.cgi?id=293909=edit possible fix I guess we need to fan control parameters. How about this patch? -- 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 v2 2/3] drm/tiny: Add driver for ili9341 with parallel bus
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6
next-20201201]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201201-071109
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
09162bc32c880a791c6c0668ce0745cf7958f576
config: riscv-randconfig-r024-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2671fccf0381769276ca8246ec0499adcb9b0355)
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
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/6d76a991fa9d2c883126667b704c729eaa22df0e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201201-071109
git checkout 6d76a991fa9d2c883126667b704c729eaa22df0e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
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/tiny/ili9341_gpio.c:157:14: error: use of undeclared
>> identifier 'mipi_dbi_release'; did you mean 'mipi_dbi_hw_reset'?
.release= mipi_dbi_release,
^~~~
mipi_dbi_hw_reset
include/drm/drm_mipi_dbi.h:184:6: note: 'mipi_dbi_hw_reset' declared here
void mipi_dbi_hw_reset(struct mipi_dbi *dbi);
^
>> drivers/gpu/drm/tiny/ili9341_gpio.c:158:2: error: use of undeclared
>> identifier 'DRM_GEM_CMA_VMAP_DRIVER_OPS'
DRM_GEM_CMA_VMAP_DRIVER_OPS,
^
>> drivers/gpu/drm/tiny/ili9341_gpio.c:192:8: error: implicit declaration of
>> function 'devm_drm_dev_init' [-Werror,-Wimplicit-function-declaration]
ret = devm_drm_dev_init(dev, drm, _driver);
^
3 errors generated.
vim +157 drivers/gpu/drm/tiny/ili9341_gpio.c
153
154 static struct drm_driver ili9341gpio_driver = {
155 .driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_ATOMIC,
156 .fops = _fops,
> 157 .release= mipi_dbi_release,
> 158 DRM_GEM_CMA_VMAP_DRIVER_OPS,
159 .debugfs_init = mipi_dbi_debugfs_init,
160 .name = "ili9341gpio",
161 .desc = "Ilitek ILI9341",
162 .date = "20201114",
163 .major = 1,
164 .minor = 0,
165 };
166
167 static const struct of_device_id ili9341gpio_of_match[] = {
168 { .compatible = "ronbo,mrb2801" },
169 { }
170 };
171 MODULE_DEVICE_TABLE(of, ili9341gpio_of_match);
172
173 static int ili9341gpio_probe(struct platform_device *pdev)
174 {
175 struct device *dev = >dev;
176 struct mipi_dbi_dev *dbidev;
177 struct drm_device *drm;
178 struct mipi_dbi *dbi;
179 struct gpio_desc *dc;
180 struct gpio_desc *wr;
181 struct gpio_descs *db;
182 u32 rotation = 0;
183 u32 wr_delays[2] = {15, 60};
184 int ret;
185
186 dbidev = kzalloc(sizeof(*dbidev), GFP_KERNEL);
187 if (!dbidev)
188 return -ENOMEM;
189
190 dbi = >dbi;
191 drm = >drm;
> 192 ret = devm_drm_dev_init(dev, drm, _driver);
193 if (ret) {
194 kfree(dbidev);
195 return ret;
196 }
197
198 drm_mode_config_init(drm);
199
200 dbi->reset = devm_gpiod_get_optional(dev, "reset",
GPIOD_OUT_HIGH);
201 if (IS_ERR(dbi->reset)) {
202 DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
203 return PTR_ERR(dbi->reset);
204 }
205
206 dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_HIGH);
207 if
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > > > > > On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > > > > Hi > > > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >> Hi > >> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>> > >>> > On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: > > Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > drm_device.dev. No functional changes. > > Signed-off-by: Thomas Zimmermann > Cc: Roland Scheidegger > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>> > >>> Reviewed-by: Zack Rusin > >> Could you add this patch to the vmwgfx tree? > > > > AMD devs indicated that they'd prefer to merge the patchset trough > > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > > drm-misc-next as well. > > Sounds good. I’ll make sure to rebase our latest patch set on top of it when > it’s in. Thanks! btw if you want to avoid multi-tree coordination headaches, we can also manage vmwgfx in drm-misc and give you & Roland commit rights there. Up to you. There is some scripting involved for now (but I hope whenever we move to gitlab we could do the checks server-side): https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, 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 v7 2/3] drm: Add support for the LogiCVC display controller
Hi, On Tue 03 Nov 20, 10:46, Maxime Ripard wrote: > On Mon, Nov 02, 2020 at 04:53:07PM +0100, Paul Kocialkowski wrote: > > Introduces a driver for the LogiCVC display controller, a programmable > > logic controller optimized for use in Xilinx Zynq-7000 SoCs and other > > Xilinx FPGAs. The controller is mostly configured at logic synthesis > > time so only a subset of configuration is left for the driver to > > handle. > > > > The following features are implemented and tested: > > - LVDS 4-bit interface; > > - RGB565 pixel formats; > > - Multiple layers and hardware composition; > > - Layer-wide alpha mode; > > > > The following features are implemented but untested: > > - Other RGB pixel formats; > > - Layer framebuffer configuration for version 4; > > - Lowest-layer used as background color; > > - Per-pixel alpha mode. > > > > The following features are not implemented: > > - YUV pixel formats; > > - DVI, LVDS 3-bit, ITU656 and camera link interfaces; > > - External parallel input for layer; > > - Color-keying; > > - LUT-based alpha modes. > > > > Additional implementation-specific notes: > > - Panels are only enabled after the first page flip to avoid flashing a > > white screen. > > - Depth used in context of the LogiCVC driver only counts color components > > to match the definition of the synthesis parameters. > > > > Support is implemented for both version 3 and 4 of the controller. > > > > With version 3, framebuffers are stored in a dedicated contiguous > > memory area, with a base address hardcoded for each layer. This requires > > using a dedicated CMA pool registered at the base address and tweaking a > > few offset-related registers to try to use any buffer allocated from > > the pool. This is done on a best-effort basis to have the hardware cope > > with the DRM framebuffer allocation model and there is no guarantee > > that each buffer allocated by GEM CMA can be used for any layer. > > In particular, buffers allocated below the base address for a layer are > > guaranteed not to be configurable for that layer. See the implementation of > > logicvc_layer_buffer_find_setup for specifics. > > > > Version 4 allows configuring each buffer address directly, which > > guarantees that any buffer can be configured. > > > > Signed-off-by: Paul Kocialkowski > > Reviewed-by: Maxime Ripard > > There's a bunch of checkpatch issues here Okay, I'll take a look! > > --- > > MAINTAINERS | 6 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile| 1 + > > drivers/gpu/drm/logicvc/Kconfig | 9 + > > drivers/gpu/drm/logicvc/Makefile| 4 + > > drivers/gpu/drm/logicvc/logicvc_crtc.c | 277 + > > drivers/gpu/drm/logicvc/logicvc_crtc.h | 21 + > > drivers/gpu/drm/logicvc/logicvc_drm.c | 472 +++ > > drivers/gpu/drm/logicvc/logicvc_drm.h | 64 ++ > > drivers/gpu/drm/logicvc/logicvc_interface.c | 224 +++ > > drivers/gpu/drm/logicvc/logicvc_interface.h | 30 + > > drivers/gpu/drm/logicvc/logicvc_layer.c | 615 > > drivers/gpu/drm/logicvc/logicvc_layer.h | 64 ++ > > drivers/gpu/drm/logicvc/logicvc_mode.c | 101 > > drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + > > drivers/gpu/drm/logicvc/logicvc_of.c| 197 +++ > > drivers/gpu/drm/logicvc/logicvc_of.h| 46 ++ > > drivers/gpu/drm/logicvc/logicvc_regs.h | 88 +++ > > 18 files changed, 2236 insertions(+) > > create mode 100644 drivers/gpu/drm/logicvc/Kconfig > > create mode 100644 drivers/gpu/drm/logicvc/Makefile > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 71e29dc0ab9d..9c4c5edef0ba 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5522,6 +5522,12 @@ S: Orphan / Obsolete > > F: drivers/gpu/drm/i810/ > > F: include/uapi/drm/i810_drm.h > > > > +DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER > > +M: Paul Kocialkowski > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > +S: Supported > > +F: drivers/gpu/drm/logicvc/ > > + > > Do you have the rights to commit in drm-misc or will
Re: [PATCH v2 1/5] drm: add legacy support for using degamma for gamma
On 30/11/2020 16:10, Daniel Vetter wrote: > The thing is, the legacy helpers should be able to pull off what userspace > needs to do when it's using atomic anyway. Hard-coding information in the > kernel means we have a gap here. Hence imo legacy helpers doing the right > thing in all reasonable cases is imo better. > > In many cases I think we should even go further, and ditch driver ability > to overwrite legacy helper hooks like this. I thought we'd need that > flexibility for legacy userspace being incompatible in awkward ways, but > wasn't ever really needed. Worse, many drivers forget to wire up the > compat hooks. > > tldr, imo right thing to do here: > - move legacy gamma function from helpers into core code > - call it unconditionally for all atomic drivers (if there's no legacy > drivers using the hook left then we can outright remove it) > - make sure it dtrt in all cases There are atomic drivers which have their custom gamma_set function. I guess they don't support atomic color mgmt, but do support (legacy) gamma. We could make the core code call the gamma legacy helper automatically for atomic drivers that don't have gamma_set defined but do have GAMMA_LUT or DEGAMMA_LUT. But the gamma_set function is called also in a few places from drm_fb_helper.c, so this code wouldn't be fully inside drm_color_mgmt.c. Or we could just change drm_atomic_helper_legacy_gamma_set() to do the right thing, depending on GAMMA_LUT & DEGAMMA_LUT existence. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On 11/11/20 10:34 AM, Greg KH wrote: On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote: On 11/10/20 12:59 PM, Greg KH wrote: On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote: Hi, back to this after a long context switch for some higher priority stuff. So here I was able eventually to drop all this code and this change here https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0 was enough for me. Seems like while device_remove_file can handle the use case where the file and the parent directory already gone, sysfs_remove_group goes down in flames in that case due to kobj->sd being unset on device removal. A driver shouldn't ever have to remove individual sysfs groups, the driver core/bus logic should do it for them automatically. And whenever a driver calls a sysfs_* call, that's a hint that something is not working properly. Do you mean that while the driver creates the groups and files explicitly from it's different subsystems it should not explicitly remove each one of them because all of them should be removed at once (and recursively) when the device is being removed ? Individual drivers should never add groups/files in sysfs, the driver core should do it properly for you if you have everything set up properly. And yes, the driver core will automatically remove them as well. Please use the default groups attribute for your bus/subsystem and this will happen automagically. Hi Greg, I tried your suggestion to hang amdgpu's sysfs attributes on default attributes in struct device.groups but turns out it's not usable since by the time i have access to struct device from amdgpu code it has already been initialized by pci core (i.e. past the point where device_add->device_add_attrs->device_add_groups with dev->groups is called) and so i can't really use it. What I can only think of using is creating my own struct attribute_group ** array in amdgpu where I aggregate all amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci probe with that array and on device remove call device_remove_groups with the same array. Do you maybe have a better suggestion for me ? Andrey thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/3] drm: Add support for the LogiCVC display controller
Hi Sam, On Wed 04 Nov 20, 22:22, Sam Ravnborg wrote: > Hi Paul. > > A few comments in the following. I did not find time to read all of the > driver. Thanks for taking a look at the driver! > > Sam > > On Mon, Nov 02, 2020 at 04:53:07PM +0100, Paul Kocialkowski wrote: > > Introduces a driver for the LogiCVC display controller, a programmable > > logic controller optimized for use in Xilinx Zynq-7000 SoCs and other > > Xilinx FPGAs. The controller is mostly configured at logic synthesis > > time so only a subset of configuration is left for the driver to > > handle. > > > > The following features are implemented and tested: > > - LVDS 4-bit interface; > > - RGB565 pixel formats; > > - Multiple layers and hardware composition; > > - Layer-wide alpha mode; > > > > The following features are implemented but untested: > > - Other RGB pixel formats; > > - Layer framebuffer configuration for version 4; > > - Lowest-layer used as background color; > > - Per-pixel alpha mode. > > > > The following features are not implemented: > > - YUV pixel formats; > > - DVI, LVDS 3-bit, ITU656 and camera link interfaces; > > - External parallel input for layer; > > - Color-keying; > > - LUT-based alpha modes. > > > > Additional implementation-specific notes: > > - Panels are only enabled after the first page flip to avoid flashing a > > white screen. > > - Depth used in context of the LogiCVC driver only counts color components > > to match the definition of the synthesis parameters. > > > > Support is implemented for both version 3 and 4 of the controller. > > > > With version 3, framebuffers are stored in a dedicated contiguous > > memory area, with a base address hardcoded for each layer. This requires > > using a dedicated CMA pool registered at the base address and tweaking a > > few offset-related registers to try to use any buffer allocated from > > the pool. This is done on a best-effort basis to have the hardware cope > > with the DRM framebuffer allocation model and there is no guarantee > > that each buffer allocated by GEM CMA can be used for any layer. > > In particular, buffers allocated below the base address for a layer are > > guaranteed not to be configurable for that layer. See the implementation of > > logicvc_layer_buffer_find_setup for specifics. > > > > Version 4 allows configuring each buffer address directly, which > > guarantees that any buffer can be configured. > > > > Signed-off-by: Paul Kocialkowski > > Reviewed-by: Maxime Ripard > > --- > > MAINTAINERS | 6 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile| 1 + > > drivers/gpu/drm/logicvc/Kconfig | 9 + > > drivers/gpu/drm/logicvc/Makefile| 4 + > > drivers/gpu/drm/logicvc/logicvc_crtc.c | 277 + > > drivers/gpu/drm/logicvc/logicvc_crtc.h | 21 + > > drivers/gpu/drm/logicvc/logicvc_drm.c | 472 +++ > > drivers/gpu/drm/logicvc/logicvc_drm.h | 64 ++ > > drivers/gpu/drm/logicvc/logicvc_interface.c | 224 +++ > > drivers/gpu/drm/logicvc/logicvc_interface.h | 30 + > > drivers/gpu/drm/logicvc/logicvc_layer.c | 615 > > drivers/gpu/drm/logicvc/logicvc_layer.h | 64 ++ > > drivers/gpu/drm/logicvc/logicvc_mode.c | 101 > > drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + > > drivers/gpu/drm/logicvc/logicvc_of.c| 197 +++ > > drivers/gpu/drm/logicvc/logicvc_of.h| 46 ++ > > drivers/gpu/drm/logicvc/logicvc_regs.h | 88 +++ > > 18 files changed, 2236 insertions(+) > > create mode 100644 drivers/gpu/drm/logicvc/Kconfig > > create mode 100644 drivers/gpu/drm/logicvc/Makefile > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 71e29dc0ab9d..9c4c5edef0ba 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5522,6 +5522,12 @@ S: Orphan / Obsolete > > F: drivers/gpu/drm/i810/ > > F: include/uapi/drm/i810_drm.h > > > > +DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER > > +M: Paul Kocialkowski > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > +S: Supported > > +F:
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > > Hi > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >> Hi >> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>> >>> On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann Cc: Roland Scheidegger --- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- >>> >>> Reviewed-by: Zack Rusin >> Could you add this patch to the vmwgfx tree? > > AMD devs indicated that they'd prefer to merge the patchset trough > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > drm-misc-next as well. Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/msm: adreno: Make speed-bin support generic
<< Resending since Jordan wasn't in the CC list >>
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.
Signed-off-by: Akhil P Oommen
---
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 --
drivers/gpu/drm/msm/adreno/adreno_device.c | 4 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +++
4 files changed, 80 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
};
-static void check_speed_bin(struct device *dev)
-{
- struct nvmem_cell *cell;
- u32 val;
-
- /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
- val = 0x80;
-
- cell = nvmem_cell_get(dev, "speed_bin");
-
- if (!IS_ERR(cell)) {
- void *buf = nvmem_cell_read(cell, NULL);
-
- if (!IS_ERR(buf)) {
- u8 bin = *((u8 *) buf);
-
- val = (1 << bin);
- kfree(buf);
- }
-
- nvmem_cell_put(cell);
- }
-
- dev_pm_opp_set_supported_hw(dev, , 1);
-}
-
struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
- check_speed_bin(>dev);
-
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU devcoredump
(if not fused off)");
module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
static const struct adreno_info gpulist[] = {
{
.rev = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+ .speedbins = a530v2_speedbins,
+ .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
}, {
.rev = ADRENO_REV(5, 4, 0, 2),
.revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..b342fa4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "adreno_gpu.h"
#include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
*adreno_ocmem)
adreno_ocmem->hdl);
}
+static int adreno_set_supported_hw(struct device *dev,
+ struct adreno_gpu *adreno_gpu)
+{
+ u8 speedbins_count = adreno_gpu->info->speedbins_count;
+ const u32 *speedbins = adreno_gpu->info->speedbins;
+ struct nvmem_cell *cell;
+ u32 bin, i;
+ u32 val = 0;
+ void *buf, *opp_table;
+
+ cell = nvmem_cell_get(dev, "speed_bin");
+ /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+ if (PTR_ERR(cell) == -ENOENT)
+ return 0;
+ else if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ if (!speedbins)
+ goto done;
+
+ buf = nvmem_cell_read(cell, NULL);
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ return PTR_ERR(buf);
+ }
+
+ bin = *((u32 *) buf);
+
+ for (i = 0; i < speedbins_count; i++) {
+ if (bin ==
Re: [PATCH v2 1/3] drm/msm: adreno: Make speed-bin support generic
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.
Signed-off-by: Akhil P Oommen
---
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 --
drivers/gpu/drm/msm/adreno/adreno_device.c | 4 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +++
4 files changed, 80 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
};
-static void check_speed_bin(struct device *dev)
-{
- struct nvmem_cell *cell;
- u32 val;
-
- /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
- val = 0x80;
-
- cell = nvmem_cell_get(dev, "speed_bin");
-
- if (!IS_ERR(cell)) {
- void *buf = nvmem_cell_read(cell, NULL);
-
- if (!IS_ERR(buf)) {
- u8 bin = *((u8 *) buf);
-
- val = (1 << bin);
- kfree(buf);
- }
-
- nvmem_cell_put(cell);
- }
-
- dev_pm_opp_set_supported_hw(dev, , 1);
-}
-
struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
- check_speed_bin(>dev);
-
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU devcoredump
(if not fused off)");
module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
static const struct adreno_info gpulist[] = {
{
.rev = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+ .speedbins = a530v2_speedbins,
+ .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
}, {
.rev = ADRENO_REV(5, 4, 0, 2),
.revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..b342fa4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "adreno_gpu.h"
#include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
*adreno_ocmem)
adreno_ocmem->hdl);
}
+static int adreno_set_supported_hw(struct device *dev,
+ struct adreno_gpu *adreno_gpu)
+{
+ u8 speedbins_count = adreno_gpu->info->speedbins_count;
+ const u32 *speedbins = adreno_gpu->info->speedbins;
+ struct nvmem_cell *cell;
+ u32 bin, i;
+ u32 val = 0;
+ void *buf, *opp_table;
+
+ cell = nvmem_cell_get(dev, "speed_bin");
+ /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+ if (PTR_ERR(cell) == -ENOENT)
+ return 0;
+ else if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ if (!speedbins)
+ goto done;
+
+ buf = nvmem_cell_read(cell, NULL);
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ return PTR_ERR(buf);
+ }
+
+ bin = *((u32 *) buf);
+
+ for (i = 0; i < speedbins_count; i++) {
+ if (bin == speedbins[i]) {
+ val = (1 << i);
+
[PATCH v3 13/13] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 117 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1c2fdaa4f81a..c2bc18ee5641 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3652,6 +3652,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_check_frl_training(intel_dp, crtc_state);
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
/*
* 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e3da73499e5a..87a335084056 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4035,9 +4035,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+ max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+ dsc_rate_per_lane =
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
+
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4167,6 +4179,105 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp,
}
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int hdmi_throughput =
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+ int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+ int pcon_max_slices =
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+ int pcon_max_slice_width =
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+ return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int output_format = crtc_state->output_format;
+ bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
+ int pcon_fractional_bpp =
drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
+ int hdmi_max_chunk_bytes =
+ connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
+
+ return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
+ num_slices, output_format, hdmi_all_bpp,
+ hdmi_max_chunk_bytes);
+}
+
+void
+intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ u8 pps_param[6];
+ int
[PATCH v3 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.
v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.
v3: rebase
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 20 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 997247db499c..604ba249fa51 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1346,6 +1346,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+ u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7d7010b148ec..e3da73499e5a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3980,6 +3980,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /* Clear the cached register set to avoid using stale values */
+
+ memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+ if (drm_dp_dpcd_read(_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+ drm_err(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_PCON_DSC_ENCODER);
+
+ drm_dbg_kms(>drm, "PCON ENCODER DSC DPCD: %*ph\n",
+ (int)sizeof(intel_dp->pcon_dsc_dpcd),
intel_dp->pcon_dsc_dpcd);
+}
+
static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
{
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
@@ -6753,6 +6771,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw,
intel_dp->dfp.sink_max_frl_bw);
+
+ intel_dp_get_pcon_dsc_cap(intel_dp);
}
static void
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/13] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just after FEC READY, before starting DP link training. v3: rebase Signed-off-by: Ankit Nautiyal Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 76e975b4765b..1c2fdaa4f81a 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3651,6 +3651,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, */ intel_dp_sink_set_fec_ready(intel_dp, crtc_state); + intel_dp_check_frl_training(intel_dp, crtc_state); + /* * 7.i Follow DisplayPort specification training sequence (see notes for * failure handling) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 1396ee25812c..58c7e080d918 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4279,6 +4279,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_set_power(intel_dp, DP_SET_POWER_D0); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp, pipe_config); intel_dp_start_link_train(intel_dp, pipe_config); intel_dp_stop_link_train(intel_dp, pipe_config); @@ -6200,6 +6201,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, !intel_dp_mst_is_master_trans(crtc_state)) continue; + intel_dp_check_frl_training(intel_dp, crtc_state); intel_dp_start_link_train(intel_dp, crtc_state); intel_dp_stop_link_train(intel_dp, crtc_state); break; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/13] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 240 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e10fdb369daa..41eb1c175a0e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
}
+
+/*
+ * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
+ * @vactive: Vactive of a display mode
+ *
+ * @return: appropriate dsc slice height for a given mode.
+ */
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+/*
+ * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc encoder
+ * and dsc decoder capabilites
+ *
+ * @crtc_state: intel crtc_state
+ * @src_max_slices: maximum slices supported by the DSC encoder
+ * @src_max_slice_width: maximum slice width supported by DSC encoder
+ * @hdmi_max_slices: maximum slices supported by sink DSC decoder
+ * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI sink
+ *
+ * @return: num of dsc slices that can be supported by the dsc encoder
+ * and decoder.
+ */
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+/*
+ * Rates at which the source and sink are required to process pixels in each
+ * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
+ */
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
+
+/* Spec limits the slice width to 2720 pixels */
+#define MAX_HDMI_SLICE_WIDTH 2720
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; /* max clock freq. in khz per slice */
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ if (!hdmi_throughput)
+ return 0;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+ crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+ kslice_adjust = 10;
+ else
+ kslice_adjust = 5;
+
+ /*
+* As per spec, the rate at which the source and the sink process
+* the pixels per slice are at two levels: atleast 340Mhz or 400Mhz.
+* This depends upon the pixel clock rate and output formats
+* (kslice adjust).
+* If pixel clock * kslice adjust >= 2720MHz slices can be processed
+* at max 340MHz, otherwise they can be processed at max 400MHz.
+*/
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width = min(MAX_HDMI_SLICE_WIDTH,
[PATCH v3 10/13] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)
v3: rearranged code to re-start FRL link training or fall back to
TMDS mode.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 68 +++--
1 file changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 58c7e080d918..7d7010b148ec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6028,6 +6028,43 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
_dp->attached_connector->base);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ /* Restart FRL training or fall back to TMDS mode */
+ if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
+ int ret, mode;
+
+ drm_dbg(_priv->drm, "Couldnt restart FRL,
continuing with TMDS mode\n");
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ mode = drm_dp_pcon_hdmi_link_mode(_dp->aux, NULL);
+
+ if (ret < 0 || mode != DP_PCON_HDMI_MODE_TMDS)
+ drm_dbg(_priv->drm, "Issue with PCON, cannot set
TMDS mode\n");
+ } else {
+ drm_dbg(_priv->drm, "FRL Re-training Completed\n");
+ }
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6393,7 +6430,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6417,6 +6454,30 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val) {
+ drm_dbg_kms(>drm, "Error in reading link service irq
vector\n");
+ return;
+ }
+
+ if (drm_dp_dpcd_writeb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+ drm_dbg_kms(>drm, "Error in writing link service irq
vector\n");
+ return;
+ }
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6456,7 +6517,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6890,7 +6952,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH v3 08/13] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 174 ++
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 00412e248426..997247db499c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1323,6 +1323,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1444,6 +1449,8 @@ struct intel_dp {
bool hobl_failed;
bool hobl_active;
+
+ struct intel_dp_pcon_frl frl;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fefb16ae3208..1396ee25812c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3883,6 +3883,8 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3978,6 +3980,175 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+ switch (max_frl) {
+ case 48:
+ return DP_PCON_FRL_BW_MASK_48GBPS;
+ case 40:
+ return DP_PCON_FRL_BW_MASK_40GBPS;
+ case 32:
+ return DP_PCON_FRL_BW_MASK_32GBPS;
+ case 24:
+ return DP_PCON_FRL_BW_MASK_24GBPS;
+ case 18:
+ return DP_PCON_FRL_BW_MASK_18GBPS;
+ case 9:
+ return DP_PCON_FRL_BW_MASK_9GBPS;
+ }
+
+ return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+ u8 max_frl_bw_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+ drm_dbg(>drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+ max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+ drm_dbg(>drm, "Sink max rate from EDID = %d Gbps\n",
max_edid_frl_bw);
+
+ max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+ if (max_frl_bw <= 0)
+ return -EINVAL;
+
+ ret = drm_dp_pcon_frl_prepare(_dp->aux, false);
+ if (ret < 0)
+ return ret;
+ /* Wait for PCON to be FRL Ready */
+ wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true,
TIMEOUT_FRL_READY_MS);
+
+ if (!is_active)
+ return -ETIMEDOUT;
+
+ max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
+ ret = drm_dp_pcon_frl_configure_1(_dp->aux, max_frl_bw,
[PATCH v3 07/13] drm/i915: Capture max frl rate for PCON in dfp cap structure
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 38 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 491e3550174f..00412e248426 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1434,6 +1434,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+ int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 21a0ca6ae2a6..fefb16ae3208 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,6 +716,29 @@ intel_dp_mode_valid_downstream(struct intel_connector
*connector,
const struct drm_display_info *info = >base.display_info;
int tmds_clock;
+ /*
+* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
+* bandwidth constraints.
+*/
+ if (intel_dp->dfp.pcon_max_frl_bw) {
+ int target_bw;
+ int max_frl_bw;
+ int bpp = intel_dp_mode_min_output_bpp(>base, mode);
+
+ target_bw = bpp * target_clock;
+
+ max_frl_bw = min(intel_dp->dfp.pcon_max_frl_bw,
+intel_dp->dfp.sink_max_frl_bw);
+
+ /* converting bw from Gbps to Kbps*/
+ max_frl_bw = max_frl_bw * 100;
+
+ if (target_bw > max_frl_bw)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+ }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6480,13 +6503,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->downstream_ports,
edid);
+ intel_dp->dfp.pcon_max_frl_bw =
+ drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+
+ intel_dp->dfp.sink_max_frl_bw =
drm_dp_get_hdmi_sink_max_frl_bw(_dp->aux);
+
drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d\n",
+ "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
- intel_dp->dfp.max_tmds_clock);
+ intel_dp->dfp.max_tmds_clock,
+ intel_dp->dfp.pcon_max_frl_bw,
+ intel_dp->dfp.sink_max_frl_bw);
}
static void
@@ -6578,6 +6609,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
+ intel_dp->dfp.pcon_max_frl_bw = 0;
+ intel_dp->dfp.sink_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/13] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 197
include/drm/drm_dp_helper.h | 114 ++
2 files changed, 311 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a9303de9ac2..e876ccbbafb8 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2937,3 +2937,200 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+ u8 major_v, minor_v;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+ major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+ minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+ if (major_v == 1 && minor_v == 2)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 slice_cap1, slice_cap2;
+
+ slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 -
DP_PCON_DSC_ENCODER];
+ slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 -
DP_PCON_DSC_ENCODER];
+
+ if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+ return 24;
+ if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+ return 20;
+ if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+ return 16;
+ if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+ return 12;
+ if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+ return 10;
+ if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+ return 8;
+ if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+ return 6;
+ if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+ return 4;
+ if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+ return 2;
+ if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+ return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+ switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+ case DP_PCON_DSC_ONE_16TH_BPP:
+ return 16;
+ case DP_PCON_DSC_ONE_8TH_BPP:
+ return 8;
+ case DP_PCON_DSC_ONE_4TH_BPP:
+ return 4;
+ case DP_PCON_DSC_ONE_HALF_BPP:
+ return 2;
+ case DP_PCON_DSC_ONE_BPP:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+ u8 buf = DP_PCON_ENABLE_DSC_ENCODER;
+ int ret;
+
+ if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+ buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+ buf |= pps_buf_config << 2;
+ }
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+/**
+ * drm_dp_pcon_pps_default() - Let PCON fill the default pps parameters
+ * for DSC1.2 between PCON & HDMI2.1 sink
+ *
[PATCH v3 05/13] drm/dp_helper: Add support for link failure detection
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.
This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.
v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 39 +
include/drm/drm_dp_helper.h | 17 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0aba865ff6be..5a9303de9ac2 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2898,3 +2898,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lanes; i++) {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i,
) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+ switch (error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 6afd314a33b8..ab6b7e4fb9ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -2047,5 +2062,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/13] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 302
include/drm/drm_dp_helper.h | 81 +
2 files changed, 383 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..0aba865ff6be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,305 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ **/
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_sink_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * returns 0, if not supported.
+ **/
+int drm_dp_get_hdmi_sink_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, );
+ if (ret < 0)
+ return 0;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_sink_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+
[PATCH v3 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 6 +
2 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..e657c321d9e4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4851,6 +4851,41 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
*max_rate_per_lane)
+{
+ switch (max_frl_rate) {
+ case 1:
+ *max_lanes = 3;
+ *max_rate_per_lane = 3;
+ break;
+ case 2:
+ *max_lanes = 3;
+ *max_rate_per_lane = 6;
+ break;
+ case 3:
+ *max_lanes = 4;
+ *max_rate_per_lane = 6;
+ break;
+ case 4:
+ *max_lanes = 4;
+ *max_rate_per_lane = 8;
+ break;
+ case 5:
+ *max_lanes = 4;
+ *max_rate_per_lane = 10;
+ break;
+ case 6:
+ *max_lanes = 4;
+ *max_rate_per_lane = 12;
+ break;
+ case 0:
+ default:
+ *max_lanes = 0;
+ *max_rate_per_lane = 0;
+ }
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4904,6 +4939,15 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ u8 max_frl_rate;
+
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+ >max_frl_rate_per_lane);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fcdc58d8b88b..1a3b4776b458 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lanes: supported by sink */
+ u8 max_lanes;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 59 +
include/drm/drm_connector.h | 43 +++
2 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e657c321d9e4..ca368df2e5ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4941,11 +4941,70 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
if (hf_vsdb[7]) {
u8 max_frl_rate;
+ u8 dsc_max_frl_rate;
+ u8 dsc_max_slices;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+ hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+ if (hdmi_dsc->v_1p2) {
+ hdmi_dsc->native_420 = hf_vsdb[11] &
DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ hdmi_dsc->bpc_supported = 0;
+
+ dsc_max_frl_rate = (hf_vsdb[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
+ _dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+ }
}
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1a3b4776b458..1922b278ffad 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
};
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+ /** @v_1p2: flag for dsc1.2 version support by sink */
+ bool v_1p2;
+
+ /** @native_420: Does sink support DSC with 4:2:0 compression */
+ bool native_420;
+
+ /**
+* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+
[PATCH v3 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e97daf6ffbb1..a158f585f658 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/13] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Addressed review comments and re-organized patches as suggested in comments on RFC patches. v3: Addressed review comments on previous version. Ankit Nautiyal (9): drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link failure detection drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 538 ++ drivers/gpu/drm/drm_edid.c| 103 drivers/gpu/drm/i915/display/intel_ddi.c | 3 + .../drm/i915/display/intel_display_types.h| 9 + drivers/gpu/drm/i915/display/intel_dp.c | 415 +- drivers/gpu/drm/i915/display/intel_dp.h | 5 + drivers/gpu/drm/i915/display/intel_hdmi.c | 233 drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 49 ++ include/drm/drm_dp_helper.h | 212 +++ include/drm/drm_edid.h| 30 + 11 files changed, 1599 insertions(+), 5 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
Hi Am 02.12.20 um 15:02 schrieb Alex Deucher: On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann wrote: Hi Am 02.12.20 um 09:43 schrieb Christian König: Am 02.12.20 um 08:59 schrieb Thomas Zimmermann: Hi Am 01.12.20 um 11:40 schrieb Christian König: Reviewed-by: Christian König on patch #1 and #15. Acked-by: Christian König on patch #2 and #16. Could you add these patches to the AMD tree? Alex is usually the one who picks such stuff up. But when people send out patch sets which mix changes from different drivers it is more common to push them through drm-misc-next. I'm OK with drm-misc-next. I just don't want to add too many merge conflicts in your side. Yeah, it doesn't matter to me. I assumed you wanted to land this whole series so you could move forward with further cleanups. If we merge via different trees, you'll have to wait for all of this to come together again in drm-next. OK, sure. I'll merge it through drm-misc-next. Best regards Thomas Alex Best regards Thomas Regards, Christian. Best regards Thomas Regards, Christian. Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Acked-by: Sam Ravnborg Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5f304425c948..da23c0f21311 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4922,8 +4922,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta case pci_channel_io_normal: return PCI_ERS_RESULT_CAN_RECOVER; /* Fatal error, prepare for slot reset */ -case pci_channel_io_frozen: -/* +case pci_channel_io_frozen: +/* * Cancel and wait for all TDRs in progress if failing to * set adev->in_gpu_reset in amdgpu_device_lock_adev * @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) goto out; } -adev->in_pci_err_recovery = true; +adev->in_pci_err_recovery = true; r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset); adev->in_pci_err_recovery = false; if (r) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
Hi Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: Hi Am 30.11.20 um 21:59 schrieb Zack Rusin: On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann Cc: Roland Scheidegger --- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- Reviewed-by: Zack Rusin Could you add this patch to the vmwgfx tree? AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. Best regards Thomas Best regards Thomas z ___ Nouveau mailing list nouv...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/13] drm/i915: Configure PCON for DSC1.1 to DSC1.2 encoding
Thanks Uma for the comments.
Please find my responses inline:
On 11/26/2020 2:15 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Sunday, November 1, 2020 3:37 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
Sharma, Swati2
Subject: [PATCH v2 13/13] drm/i915: Configure PCON for DSC1.1 to DSC1.2
encoding
May be good to append i915/ with display as well.
Alright, will change to drm/i915/display.
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink via DP
HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based on the
PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder capabilities.
v2: Rebase
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 128 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e76fb1117df..dbf28d021d08 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3493,6 +3493,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_check_frl_training(intel_dp);
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
These are called here unconditionally, I think we should invoke them only if
we are driving a pcon and not a native DP.
Right. I will add the condition to check if its a DP branched device and
have hdmi2.1 as sink inside these functions.
So for native DP, these will just return. Will fix this in next patch set.
/*
* 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2e7ddb062efe..bc1f1afc35ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -788,6 +788,16 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock,
mode->hdisplay);
}
+
+ /*
+* TODO: If its a PCON with HDMI sink:
+* Assumption : Source only supports DSC1.1
+*
+* If HDMI supports DSC 1.2 but PCON does not support
+* DSC1.1->DSC1.2 encoding Then return MODE_CLOCK_HIGH.
+* Otherwise check if the mode can be applied according to
+* DSC capablities of the PCON and HDMI Sink combine.
+*/
}
if ((mode_rate > max_rate && !(dsc_max_output_bpp &&
dsc_slice_count)) || @@ -3936,9 +3946,21 @@ static int
intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp) {
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
+
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+ max_dsc_lanes = connector-
display_info.hdmi.dsc_cap.max_lanes;
+ dsc_rate_per_lane = connector-
display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp) @@ -
4071,6 +4093,106 @@ void intel_dp_check_frl_training(struct intel_dp *intel_dp)
}
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state
+*crtc_state) {
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state) {
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int hdmi_throughput = connector-
display_info.hdmi.dsc_cap.clk_per_slice;
+ int hdmi_max_slices =
Re: [PATCH v2 12/13] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
Hi Uma,
Thanks for the comments and spotting the errors. I agree to most of the
comments and will address them in the next version.
Please find my responses inline:
On 11/26/2020 1:58 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Sunday, November 1, 2020 3:37 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
Sharma, Swati2
Subject: [PATCH v2 12/13] drm/i915: Add helper functions for calculating DSC
parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on the HDMI2.1
sink capabilities. The DSC encoder of the PCON will respect these parameters,
while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as per the
HDMI2.1 specification.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 181 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 188 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index f90838bc74fb..6b9b9ea7f9b0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3438,3 +3438,184 @@ void intel_hdmi_init(struct drm_i915_private
*dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector); }
+
+int intel_hdmi_dsc_get_slice_height(int vactive) {
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput) {
It would be good to add a comment describing each of the function parameters,
this
will make following code easier.
Alright, I will add documentation here.
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
It would be good to add a comment to describe what actually this represent.
Agreed will have a comment to describe these macros.
+#define MAX_HDMI_SLICE_WIDTH 2720
How this limit is defined, may be mention of the spec details.
Agreed, will provide details in next patch version.
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; /* max clock freq. in khz per slice */
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ if (!hdmi_throughput)
+ return 0;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ kslice_adjust = 5;
+ else
+ kslice_adjust = 10;
May be add a note for 422 formats, or fail in that case, not sure if value of 1
holds
good for 422 as well. If it's 1, then ignore the comment.
You are right, for 422 format correct value is 0.5.
I will set the value of 1 for 444 formats and the else case for 422 and
420 will be then 0.5
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
A comment describing slight details will be good.
Will add the comments in this part in next version.
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ if (!max_throughput)
+ return 0;
hdmi_throughput is already checked for 0, so this is not needed.
Agreed, this is redundant, will get rid of this condition.
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width =
Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann wrote: > > Hi > > Am 02.12.20 um 09:43 schrieb Christian König: > > Am 02.12.20 um 08:59 schrieb Thomas Zimmermann: > >> Hi > >> > >> Am 01.12.20 um 11:40 schrieb Christian König: > >>> Reviewed-by: Christian König on patch #1 > >>> and #15. > >>> > >>> Acked-by: Christian König on patch #2 and > >>> #16. > >> > >> Could you add these patches to the AMD tree? > > > > Alex is usually the one who picks such stuff up. > > > > But when people send out patch sets which mix changes from different > > drivers it is more common to push them through drm-misc-next. > > I'm OK with drm-misc-next. I just don't want to add too many merge > conflicts in your side. Yeah, it doesn't matter to me. I assumed you wanted to land this whole series so you could move forward with further cleanups. If we merge via different trees, you'll have to wait for all of this to come together again in drm-next. Alex > > Best regards > Thomas > > > > > Regards, > > Christian. > > > >> > >> Best regards > >> Thomas > >> > >>> > >>> Regards, > >>> Christian. > >>> > >>> Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: > Adhere to kernel coding style. > > Signed-off-by: Thomas Zimmermann > Acked-by: Alex Deucher > Acked-by: Sam Ravnborg > Cc: Alex Deucher > Cc: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index 5f304425c948..da23c0f21311 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -4922,8 +4922,8 @@ pci_ers_result_t > amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta > case pci_channel_io_normal: > return PCI_ERS_RESULT_CAN_RECOVER; > /* Fatal error, prepare for slot reset */ > -case pci_channel_io_frozen: > -/* > +case pci_channel_io_frozen: > +/* > * Cancel and wait for all TDRs in progress if failing to > * set adev->in_gpu_reset in amdgpu_device_lock_adev > * > @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct > pci_dev *pdev) > goto out; > } > -adev->in_pci_err_recovery = true; > +adev->in_pci_err_recovery = true; > r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset); > adev->in_pci_err_recovery = false; > if (r) > >>> > >> > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote: > > On 2020-12-01 11:01 a.m., James Park wrote: > > This will allow Mesa to port code to Windows more easily. > > As discussed in > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779 > , including drm.h makes no sense when building for Windows. Yeah I think it'd be cleanest if we can avoid this. If not I think the right fix would be to split out the actually needed parts from drm.h into a new header (still included by drm.h for backwards compat reasons) which mesa can use. Since it looks like the problematic parts are the legacy gunk, and not the new ioctl structures. Pulling out drm_render.h for all the render stuff and mabe drm_vblank.h for the vblank stuff (which would fit better in drm_mode.h but mistakes were made, oops). -Daniel > > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > ___ > 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 v2 1/5] drm: add legacy support for using degamma for gamma
On Wed, Dec 2, 2020 at 12:52 PM Tomi Valkeinen wrote: > > On 30/11/2020 16:10, Daniel Vetter wrote: > > > The thing is, the legacy helpers should be able to pull off what userspace > > needs to do when it's using atomic anyway. Hard-coding information in the > > kernel means we have a gap here. Hence imo legacy helpers doing the right > > thing in all reasonable cases is imo better. > > > > In many cases I think we should even go further, and ditch driver ability > > to overwrite legacy helper hooks like this. I thought we'd need that > > flexibility for legacy userspace being incompatible in awkward ways, but > > wasn't ever really needed. Worse, many drivers forget to wire up the > > compat hooks. > > > > tldr, imo right thing to do here: > > - move legacy gamma function from helpers into core code > > - call it unconditionally for all atomic drivers (if there's no legacy > > drivers using the hook left then we can outright remove it) > > - make sure it dtrt in all cases > > There are atomic drivers which have their custom gamma_set function. I guess > they don't support > atomic color mgmt, but do support (legacy) gamma. Hm yeah, but it's this kind of feature disparity which is why I think we should at least try to unify more. > We could make the core code call the gamma legacy helper automatically for > atomic drivers that don't > have gamma_set defined but do have GAMMA_LUT or DEGAMMA_LUT. But the > gamma_set function is called > also in a few places from drm_fb_helper.c, so this code wouldn't be fully > inside drm_color_mgmt.c. > > Or we could just change drm_atomic_helper_legacy_gamma_set() to do the right > thing, depending on > GAMMA_LUT & DEGAMMA_LUT existence. Yeah that would be at least better than pushing more decisions onto drivers as hard-coding. I still think that maybe just automatically calling the helper when either a GAMMA or DEGAMMA lut is set up would be better. -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 v4] Add power/gpu_frequency tracepoint.
Hi Peiyong, On Mon, Nov 30, 2020 at 02:33:59PM -0800, Peiyong Lin wrote: > On Tue, Nov 17, 2020 at 1:31 PM Peiyong Lin wrote: > > > > On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin wrote: > > > > > > Historically there is no common trace event for GPU frequency, in > > > downstream Android each different hardware vendor implements their own > > > way to expose GPU frequency, for example as a debugfs node. This patch > > > standardize it as a common trace event in upstream linux kernel to help > > > the ecosystem have a common implementation across hardware vendors. > > > Toolings in the Linux ecosystem will benefit from this especially in the > > > downstream Android, where this information is critical to graphics > > > developers. > > > > > > Signed-off-by: Peiyong Lin > > > --- > > > > > > Changelog since v3: > > > - Correct copyright title. > > > > > > Changelog since v2: > > > - Add more comments to indicate when the event should be emitted. > > > - Change state to frequency. > > > > > > Changelog since v1: > > > - Use %u in TP_printk > > > > > > drivers/gpu/Makefile| 1 + > > > drivers/gpu/trace/Kconfig | 3 +++ > > > drivers/gpu/trace/Makefile | 1 + > > > drivers/gpu/trace/trace_gpu_frequency.c | 13 ++ > > > include/trace/events/power.h| 33 + > > > 5 files changed, 51 insertions(+) > > > create mode 100644 drivers/gpu/trace/trace_gpu_frequency.c > > > > > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile > > > index 835c88318cec..f289a47eb031 100644 > > > --- a/drivers/gpu/Makefile > > > +++ b/drivers/gpu/Makefile > > > @@ -6,3 +6,4 @@ obj-$(CONFIG_TEGRA_HOST1X) += host1x/ > > > obj-y += drm/ vga/ > > > obj-$(CONFIG_IMX_IPUV3_CORE) += ipu-v3/ > > > obj-$(CONFIG_TRACE_GPU_MEM)+= trace/ > > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace/ > > > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig > > > index c24e9edd022e..ac4aec8d5845 100644 > > > --- a/drivers/gpu/trace/Kconfig > > > +++ b/drivers/gpu/trace/Kconfig > > > @@ -2,3 +2,6 @@ > > > > > > config TRACE_GPU_MEM > > > bool > > > + > > > +config TRACE_GPU_FREQUENCY > > > + bool > > > diff --git a/drivers/gpu/trace/Makefile b/drivers/gpu/trace/Makefile > > > index b70fbdc5847f..2b7ae69327d6 100644 > > > --- a/drivers/gpu/trace/Makefile > > > +++ b/drivers/gpu/trace/Makefile > > > @@ -1,3 +1,4 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > obj-$(CONFIG_TRACE_GPU_MEM) += trace_gpu_mem.o > > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace_gpu_frequency.o > > > diff --git a/drivers/gpu/trace/trace_gpu_frequency.c > > > b/drivers/gpu/trace/trace_gpu_frequency.c > > > new file mode 100644 > > > index ..668fabd6b77a > > > --- /dev/null > > > +++ b/drivers/gpu/trace/trace_gpu_frequency.c > > > @@ -0,0 +1,13 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * GPU frequency trace points > > > + * > > > + * Copyright (C) 2020 Google LLC > > > + */ > > > + > > > +#include > > > + > > > +#define CREATE_TRACE_POINTS > > > +#include > > > + > > > +EXPORT_TRACEPOINT_SYMBOL(gpu_frequency); > > > diff --git a/include/trace/events/power.h b/include/trace/events/power.h > > > index af5018aa9517..343825a76953 100644 > > > --- a/include/trace/events/power.h > > > +++ b/include/trace/events/power.h > > > @@ -500,6 +500,39 @@ DEFINE_EVENT(dev_pm_qos_request, > > > dev_pm_qos_remove_request, > > > > > > TP_ARGS(name, type, new_value) > > > ); > > > + > > > +/** > > > + * gpu_frequency - Reports the GPU frequency in GPU clock domains. > > > + * > > > + * This event should be emitted whenever there's a GPU frequency change > > > happens, > > > + * or a GPU goes from idle state to active state, or vice versa. > > > + * > > > + * When the GPU goes from idle state to active state, this event should > > > report > > > + * the GPU frequency of the active state. When the GPU goes from active > > > state to > > > + * idle state, this event should report a zero frequency value. > > > + * > > > + * @frequency: New frequency (in KHz) > > > + * @gpu_id: Id for each GPU clock domain Thinking about options for how to assign this, there are a few existing tracepoints (I see block device and jb2) which use dev_t, so perhaps that would be an option. We'd still want to be able to expose multiple clocks per device though, either with a separate field or with a defined packing into this one. dev_t is a little bit tricky because the packing can (is?) different between the kernel and C library. major + minor + clock domain as 3 separate fields would be the most explicit. As the intended use-case is tools, I imagine userspace will want to link this to data exposed via other APIs, so gpu_id needs to somehow allow that. That probably means some opaque integer assigned within the kernel isn't OK. Hopefully some other vendors have thoughts on what
Re: [PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void
On Wed, 02 Dec 2020 13:14:06 +0100, Michael Ellerman wrote: > > Uwe Kleine-König writes: > > Hello Michael, > > > > On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote: > >> On Thu, 26 Nov 2020 17:59:50 +0100, > >> Uwe Kleine-König wrote: > >> > > >> > The driver core ignores the return value of struct device_driver::remove > >> > because there is only little that can be done. For the shutdown callback > >> > it's ps3_system_bus_shutdown() which ignores the return value. > >> > > >> > To simplify the quest to make struct device_driver::remove return void, > >> > let struct ps3_system_bus_driver::remove return void, too. All users > >> > already unconditionally return 0, this commit makes it obvious that > >> > returning an error code is a bad idea and ensures future users behave > >> > accordingly. > >> > > >> > Signed-off-by: Uwe Kleine-König > >> > >> For the sound bit: > >> Acked-by: Takashi Iwai > > > > assuming that you are the one who will apply this patch: Note that it > > depends on patch 1 that Takashi already applied to his tree. So you > > either have to wait untils patch 1 appears in some tree that you merge > > before applying, or you have to take patch 1, too. (With Takashi > > optinally dropping it then.) > > Thanks. I've picked up both patches. > > If Takashi doesn't want to rebase his tree to drop patch 1 that's OK, it > will just arrive in mainline via two paths, but git should handle it. Yeah, I'd like to avoid rebasing, so let's get it merge from both trees. git can handle such a case gracefully. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On 2020-12-01 11:01 a.m., James Park wrote: This will allow Mesa to port code to Windows more easily. As discussed in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779 , including drm.h makes no sense when building for Windows. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/virtio: virtio_{blah} --> virtio_gpu_{blah}
On Mon, Nov 30, 2020 at 06:16:21PM -0800, Gurchetan Singh wrote: > virtio_gpu typically uses the prefix virtio_gpu, but there are > a few places where the virtio prefix is used. Modify this for > consistency. > > v3: add r-b tags > > Signed-off-by: Gurchetan Singh > Reviewed-by: Anthoine Bourgeois Pushed all to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon v2 2/3] drm/irq: Add the new api to install irq
Am 02.12.20 um 10:26 schrieb Tian Tao:
Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_irq.c | 32
include/drm/drm_irq.h | 2 +-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e..803af4b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -214,6 +214,38 @@ int drm_irq_uninstall(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_irq_uninstall);
+static void devm_drm_irq_uninstall(void *data)
+{
+ drm_irq_uninstall(data);
+}
+
+/**
+ * devm_drm_irq_install - install IRQ handler
+ * @dev: DRM device
+ * @irq: IRQ number to install the handler for
+ *
+ * devm_drm_irq_install is a help function of drm_irq_install.
+ *
+ * if the driver uses devm_drm_irq_install, there is no need
+ * to call drm_irq_uninstall when the drm module get unloaded,
+ * as this will done automagically.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_irq_install(struct drm_device *dev, int irq)
+{
+ int ret;
+
+ ret = drm_irq_install(dev, irq);
+ if (ret)
+ return ret;
+
+ return devm_add_action_or_reset(dev->dev,
+ devm_drm_irq_uninstall, dev);
+}
+EXPORT_SYMBOL(devm_drm_irq_install);
+
#if IS_ENABLED(CONFIG_DRM_LEGACY)
int drm_legacy_irq_control(struct drm_device *dev, void *data,
struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index d77f6e6..631b22f 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -28,5 +28,5 @@ struct drm_device;
int drm_irq_install(struct drm_device *dev, int irq);
int drm_irq_uninstall(struct drm_device *dev);
-
+int devm_drm_irq_install(struct drm_device *dev, int irq);
#endif
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #65 from fawz (f...@negentropy.io) --- Unfortunately, your patch leads to a stuck boot. There's some minor "corruption" visible on the bottom of the screen while still booting up, and then it gets stuck. I don't think I mentioned this in the previous posts, but I tried setting this cap myself, but in the thermal init function instead of in the process pp tables one, which had the same effect. The boot seems to be stuck completely, since I can't ssh into the box either. Any suggestions for debugging this crash caused by enabling the MicrocodeFanControl cap are appreciated. On 01/12/2020 23.47, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=201539 > > --- Comment #59 from Alex Deucher (alexdeuc...@gmail.com) --- > Created attachment 293903 >--> https://bugzilla.kernel.org/attachment.cgi?id=293903=edit > possible fix > > The attached patch should fix it. > -- 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 drm/hisilicon 1/3] drm/hisilicon: Code refactoring for hibmc_drm_drv
Am 02.12.20 um 09:47 schrieb Tian Tao:
Use the devm_drm_dev_alloc provided by the drm framework to alloc
a structure hibmc_drm_private.
Signed-off-by: Tian Tao
This looks good now. Thanks for sticking to it.
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 46 +++-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 4 +--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 +++--
5 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct drm_crtc *crtc = >crtc;
struct drm_plane *plane = >primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..13e8a28 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
static int hibmc_kms_init(struct hibmc_drm_private *priv)
{
+ struct drm_device *dev = >dev;
int ret;
- drm_mode_config_init(priv->dev);
+ drm_mode_config_init(dev);
priv->mode_config_initialized = true;
- priv->dev->mode_config.min_width = 0;
- priv->dev->mode_config.min_height = 0;
- priv->dev->mode_config.max_width = 1920;
- priv->dev->mode_config.max_height = 1200;
+ dev->mode_config.min_width = 0;
+ dev->mode_config.min_height = 0;
+ dev->mode_config.max_width = 1920;
+ dev->mode_config.max_height = 1200;
- priv->dev->mode_config.fb_base = priv->fb_base;
- priv->dev->mode_config.preferred_depth = 32;
- priv->dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = priv->fb_base;
+ dev->mode_config.preferred_depth = 32;
+ dev->mode_config.prefer_shadow = 1;
- priv->dev->mode_config.funcs = (void *)_mode_funcs;
+ dev->mode_config.funcs = (void *)_mode_funcs;
ret = hibmc_de_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init de: %d\n", ret);
+ drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
ret = hibmc_vdac_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+ drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
static void hibmc_kms_fini(struct hibmc_drm_private *priv)
{
if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(priv->dev);
+ drm_mode_config_cleanup(>dev);
priv->mode_config_initialized = false;
}
}
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
@@ -258,17 +259,9 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
- struct hibmc_drm_private *priv;
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
- priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- drm_err(dev, "no memory to allocate for hibmc_drm_private\n");
- return -ENOMEM;
- }
- dev->dev_private = priv;
- priv->dev = dev;
-
ret = hibmc_hw_init(priv);
if (ret)
goto err;
@@ -310,6 +303,7 @@ static int hibmc_load(struct drm_device *dev)
static int hibmc_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ struct hibmc_drm_private *priv;
struct drm_device *dev;
int ret;
@@ -318,12 +312,14 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- dev = drm_dev_alloc(_driver, >dev);
- if (IS_ERR(dev)) {
+ priv = devm_drm_dev_alloc(>dev, _driver,
+ struct hibmc_drm_private, dev);
+ if (IS_ERR(priv)) {
DRM_ERROR("failed to allocate drm_device\n");
- return PTR_ERR(dev);
+ return
Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq
Hi
Am 02.12.20 um 09:47 schrieb Tian Tao:
Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_irq.c | 35 +++
include/drm/drm_irq.h | 2 +-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e..b363dec 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -214,6 +214,41 @@ int drm_irq_uninstall(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_irq_uninstall);
+static void devm_drm_irq_uninstall(void *data)
+{
+ drm_irq_uninstall(data);
+}
+
+/**
+ * devm_drm_irq_install - install IRQ handler
+ * @dev: DRM device
+ * @irq: IRQ number to install the handler for
+ *
+ * devm_drm_irq_install is a help function of drm_irq_install.
+ *
+ * if the driver uses devm_drm_irq_install, there is no need
+ * to call drm_irq_uninstall when the drm module get unloaded,
+ * as this will done automagically.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_irq_install(struct drm_device *dev, int irq)
+{
+ int ret;
+
+ ret = drm_irq_install(dev, irq);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
+ if (ret)
+ devm_drm_irq_uninstall(dev);
If anything went wrong, devm_add_action_or_reset() will have already
cleaned up for you. [1] So just return the result of
devm_add_action_or_reset().
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L255
+
+ return ret;
+}
+EXPORT_SYMBOL(devm_drm_irq_install);
+
#if IS_ENABLED(CONFIG_DRM_LEGACY)
int drm_legacy_irq_control(struct drm_device *dev, void *data,
struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index d77f6e6..631b22f 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -28,5 +28,5 @@ struct drm_device;
int drm_irq_install(struct drm_device *dev, int irq);
int drm_irq_uninstall(struct drm_device *dev);
-
+int devm_drm_irq_install(struct drm_device *dev, int irq);
#endif
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
Hi Am 02.12.20 um 09:43 schrieb Christian König: Am 02.12.20 um 08:59 schrieb Thomas Zimmermann: Hi Am 01.12.20 um 11:40 schrieb Christian König: Reviewed-by: Christian König on patch #1 and #15. Acked-by: Christian König on patch #2 and #16. Could you add these patches to the AMD tree? Alex is usually the one who picks such stuff up. But when people send out patch sets which mix changes from different drivers it is more common to push them through drm-misc-next. I'm OK with drm-misc-next. I just don't want to add too many merge conflicts in your side. Best regards Thomas Regards, Christian. Best regards Thomas Regards, Christian. Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Acked-by: Sam Ravnborg Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5f304425c948..da23c0f21311 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4922,8 +4922,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta case pci_channel_io_normal: return PCI_ERS_RESULT_CAN_RECOVER; /* Fatal error, prepare for slot reset */ - case pci_channel_io_frozen: - /* + case pci_channel_io_frozen: + /* * Cancel and wait for all TDRs in progress if failing to * set adev->in_gpu_reset in amdgpu_device_lock_adev * @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) goto out; } - adev->in_pci_err_recovery = true; + adev->in_pci_err_recovery = true; r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset); adev->in_pci_err_recovery = false; if (r) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
Can you add a Signed-off-by line to your commit message? This means you agree to the Developer Certificate of Origin [1]. [1]: https://developercertificate.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: amdgpu: fix a kernel-doc markup
Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab: The function name at kernel-doc markup doesn't match the name of the function: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting prototype for amdgpu_debugfs_print_bo_info(). Prototype was for amdgpu_bo_print_info() instead Fix it. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index c6c9723d3d8a..fd7a93c32235 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct amdgpu_device *adev, } while (0) /** - * amdgpu_debugfs_print_bo_info - print BO info in debugfs file + * amdgpu_bo_print_info - print BO info in debugfs file * * @id: Index or Id of the BO * @bo: Requested BO for printing info ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
Am 02.12.20 um 08:59 schrieb Thomas Zimmermann: Hi Am 01.12.20 um 11:40 schrieb Christian König: Reviewed-by: Christian König on patch #1 and #15. Acked-by: Christian König on patch #2 and #16. Could you add these patches to the AMD tree? Alex is usually the one who picks such stuff up. But when people send out patch sets which mix changes from different drivers it is more common to push them through drm-misc-next. Regards, Christian. Best regards Thomas Regards, Christian. Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Acked-by: Sam Ravnborg Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5f304425c948..da23c0f21311 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4922,8 +4922,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta case pci_channel_io_normal: return PCI_ERS_RESULT_CAN_RECOVER; /* Fatal error, prepare for slot reset */ - case pci_channel_io_frozen: - /* + case pci_channel_io_frozen: + /* * Cancel and wait for all TDRs in progress if failing to * set adev->in_gpu_reset in amdgpu_device_lock_adev * @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) goto out; } - adev->in_pci_err_recovery = true; + adev->in_pci_err_recovery = true; r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset); adev->in_pci_err_recovery = false; if (r) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #64 from fawz (f...@negentropy.io) --- Of course, that makes sense! Should've realized that there must be correspondig logic for non-vega12/20 hardware. If this patch works, are you going to submit it or should I? Afterall, you found it :) On 01/12/2020 23.47, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=201539 > > --- Comment #59 from Alex Deucher (alexdeuc...@gmail.com) --- > Created attachment 293903 >--> https://bugzilla.kernel.org/attachment.cgi?id=293903=edit > possible fix > > The attached patch should fix it. > -- 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] fbdev: Remove udlfb driver
On Wed, 2 Dec 2020 08:55:52 +0100 Thomas Zimmermann wrote: > Hi > > Am 01.12.20 um 12:20 schrieb Mikulas Patocka: > > > > > > On Tue, 1 Dec 2020, Thomas Zimmermann wrote: > > ... > >> And why can links not run as DRM master mode? If it renders to the > >> terminal, > >> it should act like a composer. In that case it almost certainly wants > >> master > >> status. > >> > >> Best regards > >> Thomas > > > > How can a userspace program acquire master mode without being suid? > > For my understanding, there's no easy solution to that. :/ Hi, there are several ways, though whether they are "easy" depends on your mindset. The best thing is to connect to logind D-Bus API and ask that for session control, set up your session, and logind will open all input and DRM devices for you, and logind will even handle most of the complicated setup, DRM master and VT-switching for you. Or, if no-one else has the DRM device open and you open it, you automatically become DRM master. AFAIU, after recent kernel changes, it is even possible to use dropMaster and setMaster after this without being root, as long as you once in the file description lifetime had DRM master. Since this is about switching from fbdev to KMS API, you already have all the tricky, complicated, arcane code to deal with tty setup and VT-switching. However, doing all that patching to all apps you want to use is such an effort, that I'd ask if it would not be easier to just run a light-weight Wayland compositor and run your apps in Wayland mode. Of course, that requires choosing apps that run on Wayland to begin with, so maybe it's not for you. Thanks, pq pgp9njFWal368.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: amdgpu: fix a kernel-doc markup
The function name at kernel-doc markup doesn't match the name of the function: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting prototype for amdgpu_debugfs_print_bo_info(). Prototype was for amdgpu_bo_print_info() instead Fix it. Signed-off-by: Mauro Carvalho Chehab --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index c6c9723d3d8a..fd7a93c32235 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct amdgpu_device *adev, } while (0) /** - * amdgpu_debugfs_print_bo_info - print BO info in debugfs file + * amdgpu_bo_print_info - print BO info in debugfs file * * @id: Index or Id of the BO * @bo: Requested BO for printing info -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Fix some kernel-doc markups with wrong identifiers
After applying this patch over next-20201201: https://lore.kernel.org/linux-doc/cover.1606823973.git.mchehab+hua...@kernel.org/T/#m0072adc6eb1af595a31fcc3b019cb81ab28c7b9f There are a couple of new warnings that the kernel-doc prototype doesn't match the documented function. This series address them. Mauro Carvalho Chehab (2): asm: sgx.h: fix a typo on a kernel-doc markup drm: amdgpu: fix a kernel-doc markup arch/x86/include/uapi/asm/sgx.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon v2 1/4] drm/hisilicon: Assgin local variable to drm_device
在 2020/12/1 21:44, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 14:05 schrieb tiantao (H):
在 2020/12/1 20:36, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to struct drm_device *dev because they are
used multiple times within a function.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 30
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 ---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct drm_crtc *crtc = >crtc;
struct drm_plane *plane = >primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..dd9fadc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
static int hibmc_kms_init(struct hibmc_drm_private *priv)
{
+ struct drm_device *dev = >dev;
int ret;
- drm_mode_config_init(priv->dev);
+ drm_mode_config_init(dev);
priv->mode_config_initialized = true;
- priv->dev->mode_config.min_width = 0;
- priv->dev->mode_config.min_height = 0;
- priv->dev->mode_config.max_width = 1920;
- priv->dev->mode_config.max_height = 1200;
+ dev->mode_config.min_width = 0;
+ dev->mode_config.min_height = 0;
+ dev->mode_config.max_width = 1920;
+ dev->mode_config.max_height = 1200;
- priv->dev->mode_config.fb_base = priv->fb_base;
- priv->dev->mode_config.preferred_depth = 32;
- priv->dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = priv->fb_base;
+ dev->mode_config.preferred_depth = 32;
+ dev->mode_config.prefer_shadow = 1;
- priv->dev->mode_config.funcs = (void *)_mode_funcs;
+ dev->mode_config.funcs = (void *)_mode_funcs;
ret = hibmc_de_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init de: %d\n", ret);
+ drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
ret = hibmc_vdac_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+ drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
static void hibmc_kms_fini(struct hibmc_drm_private *priv)
{
if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(priv->dev);
+ drm_mode_config_cleanup(>dev);
priv->mode_config_initialized = false;
}
}
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct
hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
@@ -258,7 +259,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
- struct hibmc_drm_private *priv;
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -267,7 +268,6 @@ static int hibmc_load(struct drm_device *dev)
return -ENOMEM;
}
dev->dev_private = priv;
- priv->dev = dev;
I'm sure this either does not build or does not work. There's a
call to drm_dev_alloc(), which initialized the DRM device. You need
to assign the returned device here. The embedding of dev only work
after you switched to devm_drm_dev_alloc() in the next patch.
For the patch at hand, just keep struct hibmc_drm_private.dev as a
pointer and you should be fine.
Changing drm_device *dev to drm_device dev and using
devm_drm_dev_alloc does not easily split into two patches.
The patch does not compile well on its own, but it will compile fine
with patch #2.
Can patch #1 and patch #2 be combined into a single patch,just like V1.
Most of the code in this patch does
struct drm_device *dev = >dev;
to get dev as a local variable. Why don't you do
struct drm_device *dev = priv->dev;
?
That's all that's really needed.
+ priv =
[PATCH drm/hisilicon v2 0/4] Add the new api to install irq
patch #1 is code refactorings to use devm_drm_irq_install. patch #2 add the new api to install irq, patch #3 is hibmc driver uses the newly added api to register interrupts. Changes since v1: Splits the original patch #1 into two patches,rewrite to_hibmc_drm_private() function in patch #2.Fix the comment error in patch #3, and use devm_add_action_or_reset instead of devm_add_action. Tian Tao (4): drm/hisilicon: Assgin local variable to drm_device drm/hisilicon: Code refactoring for hibmc_drm_drv drm/irq: Add the new api to install irq drm/hisilicon: Use the new api devm_drm_irq_install drivers/gpu/drm/drm_irq.c| 35 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 51 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 4 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 ++-- include/drm/drm_irq.h| 2 +- 7 files changed, 67 insertions(+), 37 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
01.12.2020 17:34, Mark Brown пишет: > On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote: >> 01.12.2020 16:57, Mark Brown пишет: > >>> [1/1] regulator: Allow skipping disabled regulators in >>> regulator_check_consumers() >>> (no commit info) > >> Could you please hold on this patch? It won't be needed in a v2, which >> will use power domains. > >> Also, I'm not sure whether the "sound" tree is suitable for any of the >> patches in this series. > > It didn't actually get applied (note the "no commit info") - it looks > like b4's matching code got confused and decided to generate mails for > anything that I've ever downloaded and not posted. > Alright, thank you for the clarification. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] thermal: devfreq_cooling: get a copy of device status
On Tuesday 01 Dec 2020 at 12:19:18 (+), Lukasz Luba wrote:
>
>
> On 12/1/20 10:36 AM, Ionela Voinescu wrote:
> > Hi,
> >
> > Sorry for the delay and for the noise on this older version. I first
> > want to understand the code better.
> >
> > On Thursday 22 Oct 2020 at 11:55:28 (+0100), Lukasz Luba wrote:
> > [..]
> > >
> > > >
> > > > > +{
> > > > > + /* Make some space if needed */
> > > > > + if (status->busy_time > 0x) {
> > > > > + status->busy_time >>= 10;
> > > > > + status->total_time >>= 10;
> > > > > + }
> > > >
> > > > How about removing the above code and adding here:
> > > >
> > > > status->busy_time = status->busy_time ? : 1;
> > >
> > > It's not equivalent. The code operates on raw device values, which
> > > might be big (e.g. read from counters). If it's lager than the 0x,
> > > it is going to be shifted to get smaller.
> > >
> >
> > Yes, the big values are handled below through the division and by making
> > total_time = 1024. These two initial checks are only to cover the
> > possibility for busy_time and total_time being 0, or busy_time >
> > total_time.
> >
> > > >
> > > > > +
> > > > > + if (status->busy_time > status->total_time)
> > > >
> > > > This check would then cover the possibility that total_time is 0.
> > > >
> > > > > + status->busy_time = status->total_time;
> > > >
> > > > But a reversal is needed here:
> > > > status->total_time = status->busy_time;
> > >
> > > No, I want to clamp the busy_time, which should not be bigger that
> > > total time. It could happen when we deal with 'raw' values from device
> > > counters.
> > >
> >
> > Yes, I understand. But isn't making total_time = busy_time accomplishing
> > the same thing?
> >
> > > >
> > > > > +
> > > > > + status->busy_time *= 100;
> > > > > + status->busy_time /= status->total_time ? : 1;
> > > > > +
> > > > > + /* Avoid division by 0 */
> > > > > + status->busy_time = status->busy_time ? : 1;
> > > > > + status->total_time = 100;
> > > >
> > > > Then all of this code can be replaced by:
> > > >
> > > > status->busy_time = (unsigned long)div64_u64((u64)status->busy_time <<
> > > > 10,
> > > > status->total_time);
> > > > status->total_time = 1 << 10;
> > >
> > > No, the total_time closed to 'unsigned long' would overflow.
> > >
> >
> > I'm not sure I understand. total_time gets a value of 1024, it's not
> > itself shifted by 10.
> >
> > > >
> > > > This way you gain some resolution to busy_time and the divisions in the
> > > > callers would just become shifts by 10.
> > >
> > >
> > > I don't want to gain more resolution here. I want to be prepare for raw
> > > (not processed yet) big values coming from driver.
> > >
> >
> > Agreed! The higher resolution is an extra benefit. The more important
> > benefit is that, through my suggestion, you'd be replacing all future
> > divisions by shifts.
>
> You have probably missed some bits.
> I don't see benefits, you have div64_u64() which is heavy on 32bit CPUs.
>
> Then, what is the range of these values:
> busy_time [0, 1024], total_time 1024 in your case.
> These values are used for estimating power in two cases:
> 1. in devfreq_cooling_get_requested_power()
> est_power = power * busy_time / total_time
> 2. in devfreq_cooling_power2state():
> est_power = power * total_time / busy_time
>
> As you can see above, the est_power values could overflow if total_time,
> busy_time are raw values (like in old implementation). So normalize them
> into 'some' scale. That was the motivation ('scale' motivation below).
>
Agreed! I do think scaling is necessary, but in my mind the [0, 1024] scale
made more sense.
> In your case you cannot avoid division in 2. use case, because busy_time
> can be any value in range [0, 1024].
> We could avoid the division in 1. use case, but load in cpufreq cooling
> is also in range of [0, 100], so this devfreq cooling is aligned. I
> would like to avoid situation when someone is parsing the traces
> and these two devices present different load scale.
>
Got it! Looking through the code I did overlook that 2 was reversed.
> I will think about better 'devfreq utilization' (as also Daniel
> suggested)in future, but first this EM must be in mainline and cpufreq
> cooling changes made by Viresh also there.
> But it would be more then just scale change to [0, 1024]...
>
Okay, looking forward to this. It would be nice to align all of these
utilization metrics in the future for all kinds of devices.
Thanks,
Ionela.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/rockchip: vop: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in functions vop_enable and vop_enable.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: 5e570373c015 ("drm/rockchip: vop: Enable pm domain before vop_initial")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd..006988a6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -587,7 +587,7 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
struct vop *vop = to_vop(crtc);
int ret, i;
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
@@ -1908,7 +1908,7 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..9fb7a77c86e8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,16 +170,39 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, _state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
_state->base);
+
+ return _state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in functions v3d_get_param_ioctl and v3d_job_init.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
Fixes: 935f3d88434b ("drm/v3d: Make sure the GPU is on when measuring clocks.")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index e76b24bb8..91ceed774 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -132,7 +132,7 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void
*unused)
u32 ident0, ident1, ident2, ident3, cores;
int ret, core;
- ret = pm_runtime_get_sync(v3d->drm.dev);
+ ret = pm_runtime_resume_and_get(v3d->drm.dev);
if (ret < 0)
return ret;
@@ -219,7 +219,7 @@ static int v3d_measure_clock(struct seq_file *m, void
*unused)
int measure_ms = 1000;
int ret;
- ret = pm_runtime_get_sync(v3d->drm.dev);
+ ret = pm_runtime_resume_and_get(v3d->drm.dev);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 182c58652..765683569 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -439,7 +439,7 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
job->v3d = v3d;
job->free = free;
- ret = pm_runtime_get_sync(v3d->drm.dev);
+ ret = pm_runtime_resume_and_get(v3d->drm.dev);
if (ret < 0)
return ret;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/6] dt-bindings: display: simple: Add EDT ETM0700G0BDH6 display
On Tue, Dec 01, 2020 at 12:56:12PM +0100, Sam Ravnborg wrote: > Hi Oleksij > > On Tue, Dec 01, 2020 at 10:27:37AM +0100, Oleksij Rempel wrote: > > This display is already supported by the panel-simple driver, so add it > > to the bindings documentation. > > > > This patch is needed to fix checkpatch warnings for the PLYM2M dts. > > > > Signed-off-by: Oleksij Rempel > > --- > > .../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 edb53ab0d9eb..a011d9e44af3 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > @@ -117,6 +117,8 @@ properties: > >- edt,etm0700g0dh6 > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same as ETM0700G0DH6 but with inverted pixel clock. > > + - edt,etm0700g0bdh6 > > +# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > >- edt,etm070080bdh6 > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same display as the ETM0700G0BDH6, but with changed hardware for > > the > > The panels should be listed in alphabetic order which is not the case > here. Could you fix the alphabetic order for the edt panels and then > insert the new panel in the right spot? ack, will be done -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/3] tests/etnaviv_2d_test: some test improvements
Hi, patches chained to this message contains changes I've found useful when testing whether 2d rendering works well with the etnaviv driver on my platform. Perhaps they're useful enough for merging upstream. Thanks Lubo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9fb7a77c86e8..61baf3c39d43 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,6 +192,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
_state->base);
return _state->base;
@@ -609,9 +610,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = >crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -623,7 +644,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -795,6 +816,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = _state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -822,6 +844,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in these tegra functions.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/tegra/dc.c | 2 +-
drivers/gpu/drm/tegra/dsi.c | 2 +-
drivers/gpu/drm/tegra/hdmi.c | 2 +-
drivers/gpu/drm/tegra/hub.c | 2 +-
drivers/gpu/drm/tegra/sor.c | 2 +-
drivers/gpu/drm/tegra/vic.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 424ad60b4..b2c8c68b7 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2184,7 +2184,7 @@ static int tegra_dc_runtime_resume(struct host1x_client
*client)
struct device *dev = client->dev;
int err;
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "failed to get runtime PM: %d\n", err);
return err;
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 5691ef1b0..f46d377f0 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -,7 +,7 @@ static int tegra_dsi_runtime_resume(struct host1x_client
*client)
struct device *dev = client->dev;
int err;
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "failed to get runtime PM: %d\n", err);
return err;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index d09a24931..e5d2a4026 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1510,7 +1510,7 @@ static int tegra_hdmi_runtime_resume(struct host1x_client
*client)
struct device *dev = client->dev;
int err;
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "failed to get runtime PM: %d\n", err);
return err;
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 22a03f7ff..5ce771cba 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -789,7 +789,7 @@ static int tegra_display_hub_runtime_resume(struct
host1x_client *client)
unsigned int i;
int err;
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "failed to get runtime PM: %d\n", err);
return err;
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index e88a17c29..fa1272155 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3214,7 +3214,7 @@ static int tegra_sor_runtime_resume(struct host1x_client
*client)
struct device *dev = client->dev;
int err;
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "failed to get runtime PM: %d\n", err);
return err;
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index ade56b860..b77f72630 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -314,7 +314,7 @@ static int vic_open_channel(struct tegra_drm_client *client,
struct vic *vic = to_vic(client);
int err;
- err = pm_runtime_get_sync(vic->dev);
+ err = pm_runtime_resume_and_get(vic->dev);
if (err < 0)
return err;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index b5a97931af30..47768f582261 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -179,6 +190,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
kfree(connector->state);
+ conn_state->base.max_bpc = 8;
+ conn_state->base.max_requested_bpc = 8;
+
__drm_atomic_helper_connector_reset(connector, _state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
@@ -226,12 +240,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -497,6 +519,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -540,7 +563,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -560,6 +585,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -585,6 +613,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+
Re: [PATCH 5/6] dt-bindings: display: add Unisoc's mipi dsi bindings
Hi Rob,
Rob Herring 于2020年12月1日周二 上午4:31写道：
> On Mon, Nov 30, 2020 at 7:29 AM Kevin Tang wrote:
> >
> > 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
> > ---
> > .../display/sprd/sprd,sharkl3-dsi-host.yaml| 107
> +
> > .../display/sprd/sprd,sharkl3-dsi-phy.yaml | 84
>
> > 2 files changed, 191 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> > create mode 100644
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
> >
> > diff --git
> a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> > new file mode 100644
> > index 000..fe0e89d
> > --- /dev/null
> > +++
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> > @@ -0,0 +1,107 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc MIPI DSI Controller
> > +
> > +maintainers:
> > + - Kevin Tang
> > +
> > +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
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + "#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:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - port@0
> > + - port@1
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +dsi: dsi@6310 {
> > +compatible = "sprd,sharkl3-dsi-host";
> > +reg = <0x6310 0x1000>;
> > +interrupts = ,
> > + ;
> > +clock-names = "clk_src_96m";
> > +clocks = < CLK_TWPLL_96M>;
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port@0 {
> > +reg = <0>;
> > +dsi_in: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +port@1 {
> > +reg = <1>;
> > +dsi_out: endpoint {
> > +remote-endpoint = <_in>;
> > +};
> > +};
> > +};
> > +};
> > diff --git
> a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
> > new file mode 100644
> > index 000..b4715d5
> > --- /dev/null
> > +++
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
> > @@ -0,0 +1,84 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc MIPI DSI-PHY (D-PHY)
> > +
> > +maintainers:
> > + - Kevin Tang
> > +
> > +properties:
> > + compatible:
> > +const: sprd,sharkl3-dsi-phy
> > +
> > + reg:
> > +maxItems: 1
> > +description:
> > + Must be the dsi controller base address.
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + port@0:
> > +
Re: [PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support
On Mon, Nov 30, 2020 at 05:53:39PM +, Xiong, Jianxin wrote: > > From: Jason Gunthorpe > > Sent: Monday, November 30, 2020 8:08 AM > > To: Xiong, Jianxin > > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug > > Ledford ; Leon Romanovsky > > ; Sumit Semwal ; Christian Koenig > > ; Vetter, Daniel > > > > Subject: Re: [PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support > > > > On Fri, Nov 27, 2020 at 12:55:41PM -0800, Jianxin Xiong wrote: > > > > > > +function(rdma_multifile_module PY_MODULE MODULE_NAME LINKER_FLAGS) > > > > I think just replace rdma_cython_module with this? No good reason I can see > > to have two APIs? > > rdma_cython_module can handle many modules, but this one is for a single > module. > If you agree, I can merge the two by slightly tweaking the logic: each module > starts > with a .pyx file, followed by 0 or more .c and .h files. Then have rdma_cython_module call some rdam_single_cython_module() multiple times that has this code below? > > Here too? You probably don't need to specify h files at all, at > > worst they should only be used with publish_internal_headers > > Without the .h link, the compiler fail to find the header file (both > dmabuf_alloc.c and the generated "dmabuf.c" contain #include > "dmabuf_alloc.h"). Header files are made 'cross module' using the "publish_internal_headers" command But we could also hack in a -I directive to fix up the "" include for the cython outupt.. But it should not be handled here in the cython module command Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
re: video: fbdev: sis: Fix set but not used warnings in init.c
Hi,
Static analysis on linux-next with Coverity had detected a minor issue
in the following commit:
commit 2a74e8682a39d00e04ca278459ae7d7ecbdfb394
Author: Sam Ravnborg
Date: Sat Nov 28 23:40:55 2020 +0100
video: fbdev: sis: Fix set but not used warnings in init.c
The analysis is as follows:
2659 if(SiS_Pr->UseCustomMode) {
2660 infoflag = SiS_Pr->CInfoFlag;
2661 } else {
Useless call (USELESS_CALL) side_effect_free: Calling
SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its
return value, which is ignored.
2662 SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
2663 if(ModeNo > 0x13) {
2664 infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag;
2665 }
2666 }
.. SiSGetResInfo() just returns an unsigned short and this returns a
values is not being used. The function does not side effect anything, so
it does look like a redundant call. Is this intentional?
3044 unsigned short
3045 SiS_GetResInfo(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
unsigned short ModeIdIndex)
3046 {
3047 if(ModeNo <= 0x13)
3048 return ((unsigned
short)SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ResInfo);
3049 else
3050 return ((unsigned
short)SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO);
3051 }
Colin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/20] drm/hibmc: Remove references to struct drm_device.pdev
在 2020/12/1 18:35, Thomas Zimmermann 写道:
Using struct drm_device.pdev is deprecated. Convert hibmc to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 10 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657fd99c..ac5868343d0c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -203,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
struct drm_device *dev = priv->dev;
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
resource_size_t addr, size, ioaddr, iosize;
ioaddr = pci_resource_start(pdev, 1);
@@ -249,7 +249,7 @@ static int hibmc_unload(struct drm_device *dev)
if (dev->irq_enabled)
drm_irq_uninstall(dev);
- pci_disable_msi(dev->pdev);
+ pci_disable_msi(to_pci_dev(dev->dev));
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
dev->dev_private = NULL;
@@ -258,6 +258,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct hibmc_drm_private *priv;
int ret;
@@ -287,11 +288,11 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
- ret = pci_enable_msi(dev->pdev);
+ ret = pci_enable_msi(pdev);
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = drm_irq_install(dev, dev->pdev->irq);
+ ret = drm_irq_install(dev, pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
@@ -324,7 +325,6 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
return PTR_ERR(dev);
}
- dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
ret = pci_enable_device(pdev);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
index 86d712090d87..410bd019bb35 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
@@ -83,7 +83,7 @@ int hibmc_ddc_create(struct drm_device *drm_dev,
connector->adapter.owner = THIS_MODULE;
connector->adapter.class = I2C_CLASS_DDC;
snprintf(connector->adapter.name, I2C_NAME_SIZE, "HIS i2c bit bus");
- connector->adapter.dev.parent = _dev->pdev->dev;
+ connector->adapter.dev.parent = drm_dev->dev;
i2c_set_adapdata(>adapter, connector);
connector->adapter.algo_data = >bit_data;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 602ece11bb4a..77f075075db2 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -26,9 +26,9 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc)
struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = hibmc->dev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
- vmm = drm_vram_helper_alloc_mm(dev,
- pci_resource_start(dev->pdev, 0),
+ vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(pdev, 0),
hibmc->fb_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
Reviewed-by: Tian Tao
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
01.12.2020 16:57, Mark Brown пишет: > On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote: >> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces >> power consumption and heating of the Tegra chips. Tegra SoC has multiple >> hardware units which belong to a core power domain of the SoC and share >> the core voltage. The voltage must be selected in accordance to a minimum >> requirement of every core hardware unit. >> >> The minimum core voltage requirement depends on: >> >> [...] > > Applied to > >https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [1/1] regulator: Allow skipping disabled regulators in > regulator_check_consumers() > (no commit info) > > All being well this means that it will be integrated into the linux-next > tree (usually sometime in the next 24 hours) and sent to Linus during > the next merge window (or sooner if it is a bug fix), however if > problems are discovered then the patch may be dropped or reverted. > > You may get further e-mails resulting from automated or manual testing > and review of the tree, please engage with people reporting problems and > send followup patches addressing any issues that are reported if needed. > > If any updates are required or you are submitting further changes they > should be sent as incremental updates against current git, existing > patches will not be replaced. > > Please add any relevant lists and maintainers to the CCs when replying > to this mail. Hello Mark, Could you please hold on this patch? It won't be needed in a v2, which will use power domains. Also, I'm not sure whether the "sound" tree is suitable for any of the patches in this series. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/7] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
+static void
[PATCH drm/hisilicon v2 4/4] drm/hisilicon: Use the new api devm_drm_irq_install
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not called when hibmc is removed.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index c5b0b57..c918b6a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -247,9 +247,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
- if (dev->irq_enabled)
- drm_irq_uninstall(dev);
-
pci_disable_msi(dev->pdev);
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
@@ -284,7 +281,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = drm_irq_install(dev, dev->pdev->irq);
+ ret = devm_drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
