Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
Am 03.01.22 um 19:57 schrieb John Stultz: On Mon, Dec 27, 2021 at 1:52 AM wrote: From: Guangming Thanks for submitting this! Add a size check for allcation since the allocation size is nit: "allocation" above. always less than the total DRAM size. In general, it might be good to add more context to the commit message to better answer *why* this change is needed rather than what the change is doing. ie: What negative thing happens without this change? And so how does this change avoid or improve things? Completely agree, just one little addition: Could you also add this why as comment to the code? When we stumble over this five years from now it is absolutely not obvious why we do this. Thanks, Christian. Signed-off-by: Guangming Signed-off-by: jianjiao zeng --- v2: 1. update size limitation as total_dram page size. 2. update commit message --- drivers/dma-buf/dma-heap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 56bf5ad01ad5..e39d2be98d69 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len, struct dma_buf *dmabuf; int fd; + if (len / PAGE_SIZE > totalram_pages()) + return -EINVAL; This seems sane. I know ION used to have some 1/2 of memory cap to avoid unnecessary memory pressure on crazy allocations. Could you send again with an improved commit message? thanks -john
Re: [PATCH] dma-buf: cma_heap: Fix mutex locking section
On Mon, Jan 3, 2022 at 11:36 PM Weizhao Ouyang wrote:
>
> Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt
> and vaddr.
>
> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
> cma_heap implementation")
> Signed-off-by: Weizhao Ouyang
Looks good to me! Thanks so much for sending this in!
Acked-by: John Stultz
thanks again
-john
Re: [PATCH v4] drm/mediatek: Fix mtk_cec_mask()
Hi, Miles:
Miles Chen 於 2022年1月3日 週一 下午1:47寫道：
>
> In current implementation, mtk_cec_mask() writes val into target register
> and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
> should read a register, clean only mask bits, and update (val | mask) bits
> to the register.
Reviewed-by: Chun-Kuang Hu
>
> Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
>
> Cc: Zhiqiang Lin
> Cc: CK Hu
> Cc: Matthias Brugger
>
> Signed-off-by: Miles Chen
>
> ---
>
> Change since v1:
> add Fixes tag
>
> Change since v2:
> add explanation of mtk_cec_mask()
>
> Change since v3:
> change misleading subject and modify the commit message since this is a bug
> fix patch
>
> ---
> drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c
> b/drivers/gpu/drm/mediatek/mtk_cec.c
> index e9cef5c0c8f7..cdfa648910b2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int
> offset,
> u32 tmp = readl(cec->regs + offset) & ~mask;
>
> tmp |= val & mask;
> - writel(val, cec->regs + offset);
> + writel(tmp, cec->regs + offset);
> }
>
> void mtk_cec_set_hpd_event(struct device *dev,
> --
> 2.18.0
>
RE: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
Regards, Oak > -Original Message- > From: Thomas Hellström > Sent: January 3, 2022 1:58 PM > To: Zeng, Oak ; intel-...@lists.freedesktop.org; > dri-devel@lists.freedesktop.org > Cc: Auld, Matthew > Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as > argument for gtt binding / unbinding > > Hi, Oak. > > On 1/3/22 19:17, Zeng, Oak wrote: > > > > Regards, > > Oak > > > >> -Original Message- > >> From: Intel-gfx On Behalf Of > >> Thomas Hellström > >> Sent: January 3, 2022 7:00 AM > >> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > >> Cc: Thomas Hellström ; Auld, Matthew > >> > >> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as > >> argument for gtt binding / unbinding > >> > >> When introducing asynchronous unbinding, the vma itself may no longer > >> be alive when the actual binding or unbinding takes place. > > Can we take an extra reference counter of the vma to keep the vma alive, > > until the actual binding/unbinding takes place? > > The point here is that that's not needed, and should be avoided. Can you explain more why "keeping vma alive until unbinding takes place" should be avoided? As I understand it, your series introduce asynchronized unbinding. But since vma might be no longer alive at the time of unbinding. To overcome this difficulty, you introduce a vma resource structure and you guarantee vma resource is alive at bind/unbind time. So you can use vma resource for the bind/unbind operation. My question is, can we achieve the asynchronized unbinding still using vma structure by keeping vma structure alive ( by ref count it). This way the change should be much smaller (compared to this series). Why it is harmful to keep the vma alive? Maybe you have other reasons to introduce vma resource that I don't see. Regards, Oak If the > vma is no longer alive, that means nobody uses it anymore, but the GPU > may still have work in the pipe that references the GPU virtual address. > > /Thomas. >
Re: [PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses
On Tue, Dec 21, 2021 at 09:46:29PM +0200, Andi Shyti wrote:
> Hi Matt,
>
> > > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > > b/drivers/gpu/drm/i915/i915_perf.c
> > > index 170bba913c30..128315aec517 100644
> > > --- a/drivers/gpu/drm/i915/i915_perf.c
> > > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > > @@ -1630,7 +1630,7 @@ static int alloc_noa_wait(struct i915_perf_stream
> > > *stream)
> > > struct drm_i915_gem_object *bo;
> > > struct i915_vma *vma;
> > > const u64 delay_ticks = 0x -
> > > - intel_gt_ns_to_clock_interval(stream->perf->i915->ggtt.vm.gt,
> > > +
> > > intel_gt_ns_to_clock_interval(to_gt(stream->perf->i915)->ggtt->vm.gt,
> >
> > I'm not too familiar with the perf code, but this looks a bit roundabout
> > since we're ultimately trying to get to a GT...do we even need to go
> > through the ggtt structure here or can we just pass
> > "to_gt(stream->perf->i915)" as the first parameter?
> >
> > >
> > > atomic64_read(>perf->noa_programming_delay));
> > > const u32 base = stream->engine->mmio_base;
> > > #define CS_GPR(x) GEN8_RING_CS_GPR(base, x)
> > > @@ -3542,7 +3542,7 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
> > >
> > > static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent)
> > > {
> > > - return intel_gt_clock_interval_to_ns(perf->i915->ggtt.vm.gt,
> > > + return intel_gt_clock_interval_to_ns(to_gt(perf->i915)->ggtt->vm.gt,
> >
> > Ditto; this looks like "to_gt(perf->i915)" might be all we need?
>
> I think this function is looking for the GT coming from the VM,
> otherwise originally it could have taken it from >gt. In my
> first version I proposed a wrapper around this but it was
> rejected by Lucas.
>
> Besides, as we discussed earlier when I was proposed the static
> allocation, the ggtt might not always be linked to the same gt,
> so that I assumed that sometimes:
>
>to_gt(perf->i915)->ggtt->vm.gt != to_gt(perf->i915)
>
> if two GTs are sharing the same ggtt, what would the ggtt->vm.gt
> link be?
>From the git history, it doesn't look like this really needs to care
about the GGTT at all; I think it was just unintentionally written in a
roundabout manner when intel_gt was first being introduced in the code.
The reference here first showed up in commit f170523a7b8e ("drm/i915/gt:
Consolidate the CS timestamp clocks").
Actually the most correct thing to do is probably to use
'stream->engine->gt' to ensure we grab the GT actually associated with
the stream's engine.
Matt
>
> Thanks,
> Andi
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: softlockup in v5.15.12 in dcn20_post_unlock_program_front_end
On Sun, 2022-01-02 at 09:30 -0500, Jeff Layton wrote: > I'm seeing a reproducible softlockup on amdgpu on v5.15.12: > > [ 861.656146] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 861.914848] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 862.173368] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 862.381635] [drm] enabling link 0 failed: 15 > [ 862.640908] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 862.743704] [drm:dcn20_wait_for_blank_complete [amdgpu]] *ERROR* DC: > failed to blank crtc! > [ 863.002846] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 863.261451] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for > DMUB idle: status=3 > [ 863.262090] [drm] REG_WAIT timeout 1us * 10 tries - optc3_lock line:112 > [ 863.532231] [drm] REG_WAIT timeout 1us * 10 tries - > optc1_wait_for_state line:835 > [ 888.900914] watchdog: BUG: soft lockup - CPU#11 stuck for 26s! > [gnome-shell:2306] > [ 888.900921] Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer > rpcrdma rdma_cm iw_cm ib_cm ib_core nft_objref nf_conntrack_netbios_ns > nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib > nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat > bridge stp llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security > iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle > iptable_raw iptable_security ip_set nf_tables nfnetlink ip6table_filter > ip6_tables iptable_filter qrtr ns bnep vfat fat snd_hda_codec_realtek > intel_rapl_msr snd_hda_codec_generic intel_rapl_common ledtrig_audio > snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd > snd_intel_sdw_acpi snd_usb_audio snd_hda_codec kvm_amd snd_hda_core btusb > snd_usbmidi_lib btrtl snd_rawmidi snd_hwdep btbcm ppdev kvm snd_seq btintel > uvcvideo snd_seq_device videobuf2_vmalloc videobuf2_memops bluetooth > videobuf2_v4l2 snd_pcm videobuf2_common irqbypass wmi_bmof mxm_wmi > [ 888.900963] pcspkr snd_timer rapl k10temp i2c_piix4 videodev snd > ecdh_generic rfkill joydev soundcore mc parport_pc parport gpio_amdpt > gpio_generic acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc zram > ip_tables amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched i2c_algo_bit > drm_kms_helper cec drm crct10dif_pclmul crc32_pclmul crc32c_intel uas ccp > ghash_clmulni_intel sp5100_tco usb_storage r8169 nvme nvme_core wmi > ipmi_devintf ipmi_msghandler fuse > [ 888.900989] CPU: 11 PID: 2306 Comm: gnome-shell Not tainted > 5.15.12-200.fc35.x86_64 #1 > [ 888.900992] Hardware name: Micro-Star International Co., Ltd. MS-7A33/X370 > SLI PLUS (MS-7A33), BIOS 3.JR 11/29/2019 > [ 888.900993] RIP: 0010:delay_halt_mwaitx+0x39/0x40 > [ 888.900999] Code: 03 05 cb b6 95 4d 31 d2 48 89 d1 0f 01 fa b8 ff ff ff ff > b9 02 00 00 00 48 39 c6 48 0f 46 c6 48 89 c3 b8 f0 00 00 00 0f 01 fb <5b> c3 > 0f 1f 44 00 00 0f 1f 44 00 00 48 8b 05 9c 2f 03 01 e9 7f 47 > [ 888.901001] RSP: 0018:b7f243e63878 EFLAGS: 0293 > [ 888.901003] RAX: 00f0 RBX: 002dc50a RCX: > 0002 > [ 888.901005] RDX: RSI: 002dc50a RDI: > 027b5712e506 > [ 888.901006] RBP: 002dc50a R08: b7f243e63824 R09: > 0001 > [ 888.901007] R10: b7f243e63660 R11: 000d R12: > 917bd719 > [ 888.901009] R13: 917dd450 R14: 917dd45006a0 R15: > 917bd541fc00 > [ 888.901010] FS: 7f2912683d80() GS:918a9ecc() > knlGS: > [ 888.901011] CS: 0010 DS: ES: CR0: 80050033 > [ 888.901013] CR2: 33910fce CR3: 000105b22000 CR4: > 003506e0 > [ 888.901014] Call Trace: > [ 888.901016] > [ 888.901018] delay_halt+0x3b/0x60 > [ 888.901021] dcn20_post_unlock_program_front_end+0xf4/0x2c0 [amdgpu] > [ 888.901209] dc_commit_state+0x4b6/0xa50 [amdgpu] > [ 888.901382] amdgpu_dm_atomic_commit_tail+0x55c/0x2610 [amdgpu] > [ 888.901557] ? dcn20_calculate_dlg_params+0x4f4/0x540 [amdgpu] > [ 888.901735] ? dcn20_calculate_dlg_params+0x4f4/0x540 [amdgpu] > [ 888.901916] ? dcn30_calculate_wm_and_dlg_fp+0x707/0x8a0 [amdgpu] > [ 888.902090] ? dcn30_validate_bandwidth+0x10f/0x240 [amdgpu] > [ 888.902261] ? kfree+0xaa/0x3f0 > [ 888.902265] ? dcn30_validate_bandwidth+0x10f/0x240 [amdgpu] > [ 888.902435] ? dc_validate_global_state+0x31f/0x3c0 [amdgpu] > [ 888.902604] ? ttm_bo_mem_compat+0x2c/0x90 [ttm] > [ 888.902609] ? ttm_bo_validate+0x42/0x100 [ttm] > [ 888.902614] ? __raw_callee_save___native_queued_spin_unlock+0x11/0x1e > [ 888.902619] ? amdgpu_bo_destroy+0x70/0x70 [amdgpu] > [ 888.902746] ? dm_plane_helper_prepare_fb+0x1f4/0x260 [amdgpu] > [ 888.902924] ? __cond_resched+0x16/0x40 > [
Re: [PATCH v2 08/11] lib: add support for device coherent type in test_hmm
* Alex Sierra [211206 14:00]:
> Device Coherent type uses device memory that is coherently accesible by
> the CPU. This could be shown as SP (special purpose) memory range
> at the BIOS-e820 memory enumeration. If no SP memory is supported in
> system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
>
> Currently, test_hmm only supports two different SP ranges of at least
> 256MB size. This could be specified in the kernel parameter variable
> efi_fake_mem. Ex. Two SP ranges of 1GB starting at 0x1 &
> 0x14000 physical address. Ex.
> efi_fake_mem=1G@0x1:0x4,1G@0x14000:0x4
>
> Private and coherent device mirror instances can be created in the same
> probed. This is done by passing the module parameters spm_addr_dev0 &
> spm_addr_dev1. In this case, it will create four instances of
> device_mirror. The first two correspond to private device type, the
> last two to coherent type. Then, they can be easily accessed from user
> space through /dev/hmm_mirror. Usually num_device 0 and 1
> are for private, and 2 and 3 for coherent types. If no module
> parameters are passed, two instances of private type device_mirror will
> be created only.
>
> Signed-off-by: Alex Sierra
> ---
> lib/test_hmm.c | 252 +---
> lib/test_hmm_uapi.h | 15 ++-
> 2 files changed, 198 insertions(+), 69 deletions(-)
>
> diff --git a/lib/test_hmm.c b/lib/test_hmm.c
> index 9edeff52302e..a1985226d788 100644
> --- a/lib/test_hmm.c
> +++ b/lib/test_hmm.c
> @@ -29,11 +29,22 @@
>
> #include "test_hmm_uapi.h"
>
> -#define DMIRROR_NDEVICES 2
> +#define DMIRROR_NDEVICES 4
> #define DMIRROR_RANGE_FAULT_TIMEOUT 1000
> #define DEVMEM_CHUNK_SIZE(256 * 1024 * 1024U)
> #define DEVMEM_CHUNKS_RESERVE16
>
> +/*
> + * For device_private pages, dpage is just a dummy struct page
> + * representing a piece of device memory. dmirror_devmem_alloc_page
> + * allocates a real system memory page as backing storage to fake a
> + * real device. zone_device_data points to that backing page. But
> + * for device_coherent memory, the struct page represents real
> + * physical CPU-accessible memory that we can use directly.
> + */
> +#define BACKING_PAGE(page) (is_device_private_page((page)) ? \
> +(page)->zone_device_data : (page))
> +
> static unsigned long spm_addr_dev0;
> module_param(spm_addr_dev0, long, 0644);
> MODULE_PARM_DESC(spm_addr_dev0,
> @@ -122,6 +133,21 @@ static int dmirror_bounce_init(struct dmirror_bounce
> *bounce,
> return 0;
> }
>
> +static bool dmirror_is_private_zone(struct dmirror_device *mdevice)
> +{
> + return (mdevice->zone_device_type ==
> + HMM_DMIRROR_MEMORY_DEVICE_PRIVATE) ? true : false;
> +}
> +
> +static enum migrate_vma_direction
> + dmirror_select_device(struct dmirror *dmirror)
> +{
> + return (dmirror->mdevice->zone_device_type ==
> + HMM_DMIRROR_MEMORY_DEVICE_PRIVATE) ?
> + MIGRATE_VMA_SELECT_DEVICE_PRIVATE :
> + MIGRATE_VMA_SELECT_DEVICE_COHERENT;
> +}
> +
> static void dmirror_bounce_fini(struct dmirror_bounce *bounce)
> {
> vfree(bounce->ptr);
> @@ -572,16 +598,19 @@ static int dmirror_allocate_chunk(struct dmirror_device
> *mdevice,
> static struct page *dmirror_devmem_alloc_page(struct dmirror_device *mdevice)
> {
> struct page *dpage = NULL;
> - struct page *rpage;
> + struct page *rpage = NULL;
>
> /*
> - * This is a fake device so we alloc real system memory to store
> - * our device memory.
> + * For ZONE_DEVICE private type, this is a fake device so we alloc real
> + * system memory to store our device memory.
> + * For ZONE_DEVICE coherent type we use the actual dpage to store the
> data
> + * and ignore rpage.
>*/
> - rpage = alloc_page(GFP_HIGHUSER);
> - if (!rpage)
> - return NULL;
> -
> + if (dmirror_is_private_zone(mdevice)) {
> + rpage = alloc_page(GFP_HIGHUSER);
> + if (!rpage)
> + return NULL;
> + }
> spin_lock(>lock);
>
> if (mdevice->free_pages) {
> @@ -601,7 +630,8 @@ static struct page *dmirror_devmem_alloc_page(struct
> dmirror_device *mdevice)
> return dpage;
>
> error:
> - __free_page(rpage);
> + if (rpage)
> + __free_page(rpage);
> return NULL;
> }
>
> @@ -627,12 +657,15 @@ static void dmirror_migrate_alloc_and_copy(struct
> migrate_vma *args,
>* unallocated pte_none() or read-only zero page.
>*/
> spage = migrate_pfn_to_page(*src);
> + WARN(spage && is_zone_device_page(spage),
> + "page already in device spage pfn: 0x%lx\n",
> + page_to_pfn(spage));
>
> dpage = dmirror_devmem_alloc_page(mdevice);
> if (!dpage)
> continue;
Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
Hi, Oak. On 1/3/22 19:17, Zeng, Oak wrote: Regards, Oak -Original Message- From: Intel-gfx On Behalf Of Thomas Hellström Sent: January 3, 2022 7:00 AM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Cc: Thomas Hellström ; Auld, Matthew Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding When introducing asynchronous unbinding, the vma itself may no longer be alive when the actual binding or unbinding takes place. Can we take an extra reference counter of the vma to keep the vma alive, until the actual binding/unbinding takes place? The point here is that that's not needed, and should be avoided. If the vma is no longer alive, that means nobody uses it anymore, but the GPU may still have work in the pipe that references the GPU virtual address. /Thomas.
Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
On Mon, Dec 27, 2021 at 1:52 AM wrote: > > From: Guangming > Thanks for submitting this! > Add a size check for allcation since the allocation size is nit: "allocation" above. > always less than the total DRAM size. In general, it might be good to add more context to the commit message to better answer *why* this change is needed rather than what the change is doing. ie: What negative thing happens without this change? And so how does this change avoid or improve things? > Signed-off-by: Guangming > Signed-off-by: jianjiao zeng > --- > v2: 1. update size limitation as total_dram page size. > 2. update commit message > --- > drivers/dma-buf/dma-heap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 56bf5ad01ad5..e39d2be98d69 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, > size_t len, > struct dma_buf *dmabuf; > int fd; > > + if (len / PAGE_SIZE > totalram_pages()) > + return -EINVAL; This seems sane. I know ION used to have some 1/2 of memory cap to avoid unnecessary memory pressure on crazy allocations. Could you send again with an improved commit message? thanks -john
Re: [PATCH RESEND] dma-buf: heaps: Fix mutex lock area and generalize struct dma_heap_attachment
On Tue, Dec 28, 2021 at 11:09 PM Weizhao Ouyang wrote: > > Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And > move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps > can use it, the same behaviour as struct dma_buf_attachment. > Hey! Thanks for submitting this patch! Apologies for the slow reply (was out for the holidays). This patch is combining two changes in one patch, so they need to be split up. The locking change looks sane, but moving the dma_heap_attachment may need some extra justification as changing upstream code just to support out of tree code isn't usually done (if there was some benefit to the in-tree code, that would be fine though). I'd also be eager to try to get the vendor heap to be merged, assuming we can also merge an upstream user for it. thanks -john
RE: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
Regards,
Oak
> -Original Message-
> From: Intel-gfx On Behalf Of Thomas
> Hellström
> Sent: January 3, 2022 7:00 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Thomas Hellström ; Auld, Matthew
>
> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as
> argument for gtt binding / unbinding
>
> When introducing asynchronous unbinding, the vma itself may no longer
> be alive when the actual binding or unbinding takes place.
Can we take an extra reference counter of the vma to keep the vma alive, until
the actual binding/unbinding takes place?
Regards,
Oak
>
> Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
> instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
> Similarly change the insert_entries() op for struct i915_address_space.
>
> Replace a couple of i915_vma_snapshot members with their newly introduced
> i915_vma_resource counterparts, since they have the same lifetime.
>
> Also make sure to avoid changing the struct i915_vma_flags (in particular
> the bind flags) async. That should now only be done sync under the
> vm mutex.
>
> v2:
> - Update the vma_res::bound_flags when binding to the aliased ggtt
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 27 ++---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +++
> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 ++--
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +++
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 70 ++---
> drivers/gpu/drm/i915/gt/intel_gtt.h | 16 +--
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +++--
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 ++-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
> drivers/gpu/drm/i915/i915_vma.c | 24 -
> drivers/gpu/drm/i915/i915_vma.h | 11 +--
> drivers/gpu/drm/i915/i915_vma_resource.c | 9 +-
> drivers/gpu/drm/i915/i915_vma_resource.h | 99 ++-
> drivers/gpu/drm/i915/i915_vma_snapshot.c | 4 -
> drivers/gpu/drm/i915/i915_vma_snapshot.h | 8 --
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 64
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +--
> 21 files changed, 308 insertions(+), 206 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 8f674745e7e0..63a83d5f85a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -48,7 +48,7 @@ static void dpt_insert_page(struct i915_address_space *vm,
> }
>
> static void dpt_insert_entries(struct i915_address_space *vm,
> -struct i915_vma *vma,
> +struct i915_vma_resource *vma_res,
> enum i915_cache_level level,
> u32 flags)
> {
> @@ -64,8 +64,8 @@ static void dpt_insert_entries(struct i915_address_space
> *vm,
>* not to allow the user to override access to a read only page.
>*/
>
> - i = vma->node.start / I915_GTT_PAGE_SIZE;
> - for_each_sgt_daddr(addr, sgt_iter, vma->pages)
> + i = vma_res->start / I915_GTT_PAGE_SIZE;
> + for_each_sgt_daddr(addr, sgt_iter, vma_res->bi.pages)
> gen8_set_pte([i++], pte_encode | addr);
> }
>
> @@ -76,35 +76,38 @@ static void dpt_clear_range(struct i915_address_space *vm,
>
> static void dpt_bind_vma(struct i915_address_space *vm,
>struct i915_vm_pt_stash *stash,
> - struct i915_vma *vma,
> + struct i915_vma_resource *vma_res,
>enum i915_cache_level cache_level,
>u32 flags)
> {
> - struct drm_i915_gem_object *obj = vma->obj;
> u32 pte_flags;
>
> + if (vma_res->bound_flags)
> + return;
> +
> /* Applicable to VLV (gen8+ do not support RO in the GGTT) */
> pte_flags = 0;
> - if (vma->vm->has_read_only && i915_gem_object_is_readonly(obj))
> + if (vm->has_read_only && vma_res->bi.readonly)
> pte_flags |= PTE_READ_ONLY;
> - if (i915_gem_object_is_lmem(obj))
> + if (vma_res->bi.lmem)
> pte_flags |= PTE_LM;
>
> - vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
> + vm->insert_entries(vm, vma_res, cache_level, pte_flags);
>
> - vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
> + vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
>
> /*
>* Without aliasing PPGTT there's no difference between
>* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #18 from spassw...@web.de ---
The problem seems to be that rn_update_clocks tries to call
rn_vbios_smu_set_dcn_low power before adev->in_s0ix is set to 1 in
amdpgu_pmops_suspend:
Changes to rn_update_clocks:
dev_info(adev->dev, "adev->in_s0ix = %d\n", adev->in_s0ix);
//if (display_count == 0 && (adev->in_s0ix || !hpd_state)) {
if (display_count == 0) {
dev_info(adev->dev, "calling rn_vbios_smu_set_dcn_low_power\n");
rn_vbios_smu_set_dcn_low_power_state(clk_mgr, DCN_PWR_STATE_LOW_POWER);
Changes to amdgpu_pmops_suspend:
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
dev_info(adev->dev, "amdgpu_pmops_suspend: adev->in_s0ix = %d\n",
adev->in_s0ix);
[ 36.010259] wlp4s0: deauthenticating from 54:67:51:3d:a2:e0 by local choice
(Reason: 3=DEAUTH_LEAVING)
[ 36.043902] amdgpu :08:00.0: amdgpu: adev->in_s0ix = 0
[ 36.043904] amdgpu :08:00.0: amdgpu: calling
rn_vbios_smu_set_dcn_low_power
[ 40.015570] PM: suspend entry (s2idle)
[ 40.239013] Filesystems sync: 0.223 seconds
[ 40.239912] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 40.242407] OOM killer disabled.
[ 40.242407] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 40.243513] printk: Suspending console(s) (use no_console_suspend to debug)
[ 40.246850] amdgpu :08:00.0: amdgpu: amdgpu_pmops_suspend: adev->in_s0ix
= 1
[ 40.266376] queueing ieee80211 work while going to suspend
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436 mario.limoncie...@amd.com changed: What|Removed |Added Attachment #300214|0 |1 is obsolete|| --- Comment #17 from mario.limoncie...@amd.com --- Created attachment 300215 --> https://bugzilla.kernel.org/attachment.cgi?id=300215=edit Possible patch that ignores WA in s0ix w/ debugging statements (v2) OK thanks for trying it! Here's an updated patch, to try to give an extra explicit call to update the clocks again during the suspend path. Also included a debugging statement so we can see the state of the variables that matter in each call to update_clocks. If you can please share the output from your kernel log again with it applied. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 5/5] drm/vc4: dpi: Support DPI interface in mode3 for RGB565
From: Chris Morgan
Add support for the VC4 DPI driver to utilize DPI mode 3. This is
defined here as xxxRxxGGxxxB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#parallel-display-interface-dpi
This mode is required to use the Geekworm MZP280 DPI display.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/vc4/vc4_dpi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c180eb60bee8..3c58ade2549e 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -173,6 +173,10 @@ static void vc4_dpi_encoder_enable(struct drm_encoder
*encoder)
dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_3,
DPI_FORMAT);
break;
+ case MEDIA_BUS_FMT_RGB565_1X24_CPADHI:
+ dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_2,
+ DPI_FORMAT);
+ break;
default:
DRM_ERROR("Unknown media bus format %d\n", bus_format);
break;
--
2.25.1
[PATCH 4/5] drm/panel: simple: add Geekworm MZP280 Panel
From: Chris Morgan
Add support for the Geekworm MZP280 Panel
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index eb475a3a774b..f40f4e9a0e08 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1824,6 +1824,32 @@ static const struct panel_desc friendlyarm_hd702e = {
},
};
+static const struct drm_display_mode geekworm_mzp280_mode = {
+ .clock = 32000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 41,
+ .hsync_end = 480 + 41 + 20,
+ .htotal = 480 + 41 + 20 + 60,
+ .vdisplay = 640,
+ .vsync_start = 640 + 5,
+ .vsync_end = 640 + 5 + 10,
+ .vtotal = 640 + 5 + 10 + 10,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc geekworm_mzp280 = {
+ .modes = _mzp280_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 47,
+ .height = 61,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X24_CPADHI,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3713,6 +3739,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "friendlyarm,hd702e",
.data = _hd702e,
+ }, {
+ .compatible = "geekworm,mzp280",
+ .data = _mzp280,
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
--
2.25.1
[PATCH 3/5] dt-bindings: display: simple: add Geekworm MZP280 Panel
From: Chris Morgan The Geekworm MZP280 panel is a 480x640 (portrait) panel with a capacitive touch interface and a 40 pin header meant to interface directly with the Raspberry Pi. The screen is 2.8 inches diagonally, and there appear to be at least 4 distinct versions all with the same panel timings. Timings were derived from drivers posted on the github located here: https://github.com/tianyoujian/MZDPI/tree/master/vga Additional details about this panel family can be found here: https://wiki.geekworm.com/2.8_inch_Touch_Screen_for_Pi_zero Signed-off-by: Chris Morgan --- .../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 f3c9395d23b6..659db7206c96 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -148,6 +148,8 @@ properties: - frida,frd350h54004 # FriendlyELEC HD702E 800x1280 LCD panel - friendlyarm,hd702e +# Geekworm MZP280 2.8" 480x640 LCD panel with capacitive touch + - geekworm,mzp280 # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel - giantplus,gpg48273qs5 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel -- 2.25.1
[PATCH 2/5] media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI
From: Chris Morgan Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm MZP280 panel for the Raspberry Pi. Signed-off-by: Chris Morgan --- include/uapi/linux/media-bus-format.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 0dfc11ee243a..a7b7654985ee 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,13 +34,14 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101e */ +/* RGB - next is 0x101f */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 +#define MEDIA_BUS_FMT_RGB565_1X24_CPADHI 0x101e #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007 -- 2.25.1
[PATCH 1/5] media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI
From: Chris Morgan Add support for MEDIA_BUS_FMT_RGB565_1X24_CPADHI. This format is used by the Geekworm MZP280 panel which interfaces with the Raspberry Pi. Signed-off-by: Chris Morgan --- .../media/v4l/subdev-formats.rst | 37 +++ 1 file changed, 37 insertions(+) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index bd68588b2683..f3dcfa763ebc 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -624,6 +624,43 @@ The following tables list existing packed RGB formats. - b\ :sub:`2` - b\ :sub:`1` - b\ :sub:`0` +* .. _MEDIA_BUS_FMT_RGB565_1X24_CPADHI: + + - MEDIA_BUS_FMT_RGB565_1X24_CPADHI + - 0x101e + - + - + - + - + - + - + - + - + - + - 0 + - 0 + - 0 + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - 0 + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` * .. _MEDIA-BUS-FMT-BGR565-2X8-BE: - MEDIA_BUS_FMT_BGR565_2X8_BE -- 2.25.1
[PATCH 0/5] Support Geekworm MZP280 Panel for Raspberry Pi
From: Chris Morgan This patch series is to add support for the MZP280 panel for the Raspberry Pi. This panel requires adding support for Mode 3 of the Raspberry Pi DPI connector, which necessitates a new media bus format. This patch series has been tested on my Raspberry Pi 4 with version 1 of the panel in question. Signed-off-by: Chris Morgan Chris Morgan (5): media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI dt-bindings: display: simple: add Geekworm MZP280 Panel drm/panel: simple: add Geekworm MZP280 Panel drm/vc4: dpi: Support DPI interface in mode3 for RGB565 .../bindings/display/panel/panel-simple.yaml | 2 + .../media/v4l/subdev-formats.rst | 37 +++ drivers/gpu/drm/panel/panel-simple.c | 29 +++ drivers/gpu/drm/vc4/vc4_dpi.c | 4 ++ include/uapi/linux/media-bus-format.h | 3 +- 5 files changed, 74 insertions(+), 1 deletion(-) -- 2.25.1
[PATCH AUTOSEL 5.10 7/8] drm/amd/display: Added power down for DCN10
From: "Lai, Derek"
[ Upstream commit d97e631af2db84c8c9d63abf68d487d0bb559e4c ]
[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.
[How]
Added power down for DCN10.
Tested-by: Daniel Wheeler
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Derek Lai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
index b24c8ae8b1ece..7e228c181b298 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
@@ -77,6 +77,7 @@ static const struct hw_sequencer_funcs dcn10_funcs = {
.get_clock = dcn10_get_clock,
.get_vupdate_offset_from_vsync = dcn10_get_vupdate_offset_from_vsync,
.calc_vupdate_position = dcn10_calc_vupdate_position,
+ .power_down = dce110_power_down,
.set_backlight_level = dce110_set_backlight_level,
.set_abm_immediate_disable = dce110_set_abm_immediate_disable,
.set_pipe = dce110_set_pipe,
--
2.34.1
[PATCH AUTOSEL 5.15 14/16] drm/amd/display: Added power down for DCN10
From: "Lai, Derek"
[ Upstream commit d97e631af2db84c8c9d63abf68d487d0bb559e4c ]
[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.
[How]
Added power down for DCN10.
Tested-by: Daniel Wheeler
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Derek Lai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
index 34001a30d449a..10e613ec7d24f 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c
@@ -78,6 +78,7 @@ static const struct hw_sequencer_funcs dcn10_funcs = {
.get_clock = dcn10_get_clock,
.get_vupdate_offset_from_vsync = dcn10_get_vupdate_offset_from_vsync,
.calc_vupdate_position = dcn10_calc_vupdate_position,
+ .power_down = dce110_power_down,
.set_backlight_level = dce110_set_backlight_level,
.set_abm_immediate_disable = dce110_set_abm_immediate_disable,
.set_pipe = dce110_set_pipe,
--
2.34.1
[PATCH AUTOSEL 5.15 13/16] drm/amd/display: fix B0 TMDS deepcolor no dislay issue
From: Charlene Liu
[ Upstream commit 2eb82577a16d4c8eb31e4ed520649850bb95b223 ]
[why]
B0 PHY C map to F, D map to G driver use logic instance, dmub does the
remap. Driver still need use the right PHY instance to access right HW.
[how]
use phyical instance when program PHY register.
[note]
could move resync_control programming to dmub next.
Tested-by: Daniel Wheeler
Reviewed-by: Dmytro Laktyushkin
Reviewed-by: Jun Lei
Acked-by: Rodrigo Siqueira
Signed-off-by: Charlene Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dcn31/dcn31_resource.c | 25 +--
.../drm/amd/display/dc/dcn31/dcn31_resource.h | 31 +++
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index 79e92ecca96c1..0c0fe3fb70e19 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -352,6 +352,14 @@ static const struct dce110_clk_src_regs clk_src_regs[] = {
clk_src_regs(3, D),
clk_src_regs(4, E)
};
+/*pll_id being rempped in dmub, in driver it is logical instance*/
+static const struct dce110_clk_src_regs clk_src_regs_b0[] = {
+ clk_src_regs(0, A),
+ clk_src_regs(1, B),
+ clk_src_regs(2, F),
+ clk_src_regs(3, G),
+ clk_src_regs(4, E)
+};
static const struct dce110_clk_src_shift cs_shift = {
CS_COMMON_MASK_SH_LIST_DCN2_0(__SHIFT)
@@ -2019,14 +2027,27 @@ static bool dcn31_resource_construct(
dcn30_clock_source_create(ctx, ctx->dc_bios,
CLOCK_SOURCE_COMBO_PHY_PLL1,
_src_regs[1], false);
- pool->base.clock_sources[DCN31_CLK_SRC_PLL2] =
+ /*move phypllx_pixclk_resync to dmub next*/
+ if (dc->ctx->asic_id.hw_internal_rev == YELLOW_CARP_B0) {
+ pool->base.clock_sources[DCN31_CLK_SRC_PLL2] =
+ dcn30_clock_source_create(ctx, ctx->dc_bios,
+ CLOCK_SOURCE_COMBO_PHY_PLL2,
+ _src_regs_b0[2], false);
+ pool->base.clock_sources[DCN31_CLK_SRC_PLL3] =
+ dcn30_clock_source_create(ctx, ctx->dc_bios,
+ CLOCK_SOURCE_COMBO_PHY_PLL3,
+ _src_regs_b0[3], false);
+ } else {
+ pool->base.clock_sources[DCN31_CLK_SRC_PLL2] =
dcn30_clock_source_create(ctx, ctx->dc_bios,
CLOCK_SOURCE_COMBO_PHY_PLL2,
_src_regs[2], false);
- pool->base.clock_sources[DCN31_CLK_SRC_PLL3] =
+ pool->base.clock_sources[DCN31_CLK_SRC_PLL3] =
dcn30_clock_source_create(ctx, ctx->dc_bios,
CLOCK_SOURCE_COMBO_PHY_PLL3,
_src_regs[3], false);
+ }
+
pool->base.clock_sources[DCN31_CLK_SRC_PLL4] =
dcn30_clock_source_create(ctx, ctx->dc_bios,
CLOCK_SOURCE_COMBO_PHY_PLL4,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
index 93571c9769967..cc4bed675588c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
@@ -39,4 +39,35 @@ struct resource_pool *dcn31_create_resource_pool(
const struct dc_init_data *init_data,
struct dc *dc);
+/*temp: B0 specific before switch to dcn313 headers*/
+#ifndef regPHYPLLF_PIXCLK_RESYNC_CNTL
+#define regPHYPLLF_PIXCLK_RESYNC_CNTL 0x007e
+#define regPHYPLLF_PIXCLK_RESYNC_CNTL_BASE_IDX 1
+#define regPHYPLLG_PIXCLK_RESYNC_CNTL 0x005f
+#define regPHYPLLG_PIXCLK_RESYNC_CNTL_BASE_IDX 1
+
+//PHYPLLF_PIXCLK_RESYNC_CNTL
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_RESYNC_ENABLE__SHIFT 0x0
+#define
PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_DEEP_COLOR_DTO_ENABLE_STATUS__SHIFT 0x1
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_DCCG_DEEP_COLOR_CNTL__SHIFT 0x4
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_ENABLE__SHIFT 0x8
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_DOUBLE_RATE_ENABLE__SHIFT
0x9
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_RESYNC_ENABLE_MASK
0x0001L
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_DEEP_COLOR_DTO_ENABLE_STATUS_MASK
0x0002L
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_DCCG_DEEP_COLOR_CNTL_MASK
0x0030L
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_ENABLE_MASK 0x0100L
+#define PHYPLLF_PIXCLK_RESYNC_CNTL__PHYPLLF_PIXCLK_DOUBLE_RATE_ENABLE_MASK
0x0200L
+
+//PHYPLLG_PIXCLK_RESYNC_CNTL
+#define PHYPLLG_PIXCLK_RESYNC_CNTL__PHYPLLG_PIXCLK_RESYNC_ENABLE__SHIFT 0x0
+#define
[PATCH AUTOSEL 5.15 11/16] drm/amdgpu: put SMU into proper state on runpm suspending for BOCO capable platform
From: Evan Quan
[ Upstream commit 7be3be2b027c12e84833b3dc9597d3bb7e4c5464 ]
By setting mp1_state as PP_MP1_STATE_UNLOAD, MP1 will do some proper cleanups
and
put itself into a state ready for PNP. That can workaround some random resuming
failure observed on BOCO capable platforms.
Signed-off-by: Evan Quan
Acked-by: Alex Deucher
Reviewed-by: Guchun Chen
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index ada083fbc052b..6e682bf8c2d6a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1578,12 +1578,27 @@ static int amdgpu_pmops_runtime_suspend(struct device
*dev)
if (amdgpu_device_supports_px(drm_dev))
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
+ /*
+* By setting mp1_state as PP_MP1_STATE_UNLOAD, MP1 will do some
+* proper cleanups and put itself into a state ready for PNP. That
+* can address some random resuming failure observed on BOCO capable
+* platforms.
+* TODO: this may be also needed for PX capable platform.
+*/
+ if (amdgpu_device_supports_boco(drm_dev))
+ adev->mp1_state = PP_MP1_STATE_UNLOAD;
+
ret = amdgpu_device_suspend(drm_dev, false);
if (ret) {
adev->in_runpm = false;
+ if (amdgpu_device_supports_boco(drm_dev))
+ adev->mp1_state = PP_MP1_STATE_NONE;
return ret;
}
+ if (amdgpu_device_supports_boco(drm_dev))
+ adev->mp1_state = PP_MP1_STATE_NONE;
+
if (amdgpu_device_supports_px(drm_dev)) {
/* Only need to handle PCI state in the driver for ATPX
* PCI core handles it for _PR3.
--
2.34.1
[PATCH AUTOSEL 5.15 10/16] drm/amdgpu: always reset the asic in suspend (v2)
From: Alex Deucher [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ] If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by: Luben Tuikov Acked-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index f18240f873878..ada083fbc052b 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1498,7 +1498,10 @@ static int amdgpu_pmops_suspend(struct device *dev) adev->in_s3 = true; r = amdgpu_device_suspend(drm_dev, true); adev->in_s3 = false; - + if (r) + return r; + if (!adev->in_s0ix) + r = amdgpu_asic_reset(adev); return r; } -- 2.34.1
[PATCH AUTOSEL 5.15 09/16] drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume
From: Prike Liang
[ Upstream commit 8c45096c60d6ce6341c374636100ed1b2c1c33a1 ]
In the s0ix entry need retain gfx in the gfxoff state,so here need't
set gfx cgpg in the S0ix suspend-resume process. Moreover move the S0ix
check into SMU12 can simplify the code condition check.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1712
Signed-off-by: Prike Liang
Reviewed-by: Evan Quan
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 ++-
drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 3 ++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 04863a7971155..30ee8819587e2 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1536,9 +1536,7 @@ static int smu_suspend(void *handle)
smu->watermarks_bitmap &= ~(WATERMARKS_LOADED);
- /* skip CGPG when in S0ix */
- if (smu->is_apu && !adev->in_s0ix)
- smu_set_gfx_cgpg(>smu, false);
+ smu_set_gfx_cgpg(>smu, false);
return 0;
}
@@ -1569,8 +1567,7 @@ static int smu_resume(void *handle)
return ret;
}
- if (smu->is_apu)
- smu_set_gfx_cgpg(>smu, true);
+ smu_set_gfx_cgpg(>smu, true);
smu->disable_uclk_switch = 0;
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
index 43028f2cd28b5..9c91e79c955fb 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
@@ -120,7 +120,8 @@ int smu_v12_0_powergate_sdma(struct smu_context *smu, bool
gate)
int smu_v12_0_set_gfx_cgpg(struct smu_context *smu, bool enable)
{
- if (!(smu->adev->pg_flags & AMD_PG_SUPPORT_GFX_PG))
+ /* Until now the SMU12 only implemented for Renoir series so here
neen't do APU check. */
+ if (!(smu->adev->pg_flags & AMD_PG_SUPPORT_GFX_PG) ||
smu->adev->in_s0ix)
return 0;
return smu_cmn_send_smc_msg_with_param(smu,
--
2.34.1
[PATCH AUTOSEL 5.15 03/16] drm/amd/pm: Fix xgmi link control on aldebaran
From: Lijo Lazar
[ Upstream commit 19e66d512e4182a0461530fa3159638e0f55d97e ]
Fix the message argument.
0: Allow power down
1: Disallow power down
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 5019903db492a..c9cfeb094750d 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -1619,7 +1619,7 @@ static int aldebaran_allow_xgmi_power_down(struct
smu_context *smu, bool en)
{
return smu_cmn_send_smc_msg_with_param(smu,
SMU_MSG_GmiPwrDnControl,
- en ? 1 : 0,
+ en ? 0 : 1,
NULL);
}
--
2.34.1
[PATCH AUTOSEL 5.15 02/16] drm/amdgpu: fix dropped backing store handling in amdgpu_dma_buf_move_notify
From: Christian König [ Upstream commit fc74881c28d314b10efac016ef49df4ff40b8b97 ] bo->tbo.resource can now be NULL. Signed-off-by: Christian König Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1811 Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20211210083927.1754-1-christian.koe...@amd.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index ae6ab93c868b8..784a12bf8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -384,7 +384,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach) struct amdgpu_vm_bo_base *bo_base; int r; - if (bo->tbo.resource->mem_type == TTM_PL_SYSTEM) + if (!bo->tbo.resource || bo->tbo.resource->mem_type == TTM_PL_SYSTEM) return; r = ttm_bo_validate(>tbo, , ); -- 2.34.1
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #16 from spassw...@web.de ---
Added a dev_info:
dev_info(adev->dev, "adev->in_s0ix = %d\n", adev->in_s0ix);
if (display_count == 0 && (adev->in_s0ix || !hpd_state)) {
with the result:
It seems that adev->in_s0ix = 0 during suspend. Only later during resume (after
ACPI: EC: interrupt unblocked) do we have adev->in_s0ix = 1.
Jan 3 18:00:24 lisa kernel: [ 40.367310] wlp4s0: deauthenticating from
54:67:51:3d:a2:e0 by local choice (Reason: 3=DEAUTH_LEAVING)
Jan 3 18:00:24 lisa kernel: [ 40.437382] amdgpu :08:00.0: amdgpu:
adev->in_s0ix = 0
Jan 3 18:00:27 lisa kernel: [ 44.031004] PM: suspend entry (s2idle)
Jan 3 18:00:28 lisa kernel: [ 44.252353] Filesystems sync: 0.221 seconds
Jan 3 18:00:58 lisa kernel: [ 44.253185] Freezing user space processes ...
(elapsed 0.002 seconds) done.
Jan 3 18:00:58 lisa kernel: [ 44.255407] OOM killer disabled.
Jan 3 18:00:58 lisa kernel: [ 44.255407] Freezing remaining freezable tasks
... (elapsed 0.000 seconds) done.
Jan 3 18:00:58 lisa kernel: [ 44.256406] printk: Suspending console(s) (use
no_console_suspend to debug)
Jan 3 18:00:58 lisa kernel: [ 44.277805] queueing ieee80211 work while going
to suspend
Jan 3 18:00:58 lisa kernel: [ 44.831434] [drm] PCIE GART of 512M enabled
(table at 0x0080).
Jan 3 18:00:58 lisa kernel: [ 44.831464] [drm] PSP is resuming...
Jan 3 18:00:58 lisa kernel: [ 45.019729] [drm] reserve 0xa0 from
0x81fe00 for PSP TMR
Jan 3 18:00:58 lisa kernel: [ 45.091174] amdgpu :03:00.0: amdgpu: RAS:
optional ras ta ucode is not available
Jan 3 18:00:58 lisa kernel: [ 45.100301] amdgpu :03:00.0: amdgpu:
SECUREDISPLAY: securedisplay ta ucode is not available
Jan 3 18:00:58 lisa kernel: [ 45.100305] amdgpu :03:00.0: amdgpu: SMU is
resuming...
Jan 3 18:00:58 lisa kernel: [ 45.100308] amdgpu :03:00.0: amdgpu: smu
driver if version = 0x000f, smu fw if version = 0x0013, smu fw version
= 0x003b2500 (59.37.0)
Jan 3 18:00:58 lisa kernel: [ 45.100311] amdgpu :03:00.0: amdgpu: SMU
driver if version not matched
Jan 3 18:00:58 lisa kernel: [ 45.151255] amdgpu :03:00.0: amdgpu: SMU is
resumed successfully!
Jan 3 18:00:58 lisa kernel: [ 45.152433] [drm] DMUB hardware initialized:
version=0x02020007
Jan 3 18:00:58 lisa kernel: [ 45.194058] [drm] kiq ring mec 2 pipe 1 q 0
Jan 3 18:00:58 lisa kernel: [ 45.198331] [drm] VCN decode and encode
initialized successfully(under DPG Mode).
Jan 3 18:00:58 lisa kernel: [ 45.198603] [drm] JPEG decode initialized
successfully.
Jan 3 18:00:58 lisa kernel: [ 45.198652] amdgpu :03:00.0: amdgpu: ring
gfx_0.0.0 uses VM inv eng 0 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198654] amdgpu :03:00.0: amdgpu: ring
comp_1.0.0 uses VM inv eng 1 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198655] amdgpu :03:00.0: amdgpu: ring
comp_1.1.0 uses VM inv eng 4 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198655] amdgpu :03:00.0: amdgpu: ring
comp_1.2.0 uses VM inv eng 5 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198656] amdgpu :03:00.0: amdgpu: ring
comp_1.3.0 uses VM inv eng 6 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198657] amdgpu :03:00.0: amdgpu: ring
comp_1.0.1 uses VM inv eng 7 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198658] amdgpu :03:00.0: amdgpu: ring
comp_1.1.1 uses VM inv eng 8 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198659] amdgpu :03:00.0: amdgpu: ring
comp_1.2.1 uses VM inv eng 9 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198659] amdgpu :03:00.0: amdgpu: ring
comp_1.3.1 uses VM inv eng 10 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198660] amdgpu :03:00.0: amdgpu: ring
kiq_2.1.0 uses VM inv eng 11 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198661] amdgpu :03:00.0: amdgpu: ring
sdma0 uses VM inv eng 12 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198661] amdgpu :03:00.0: amdgpu: ring
sdma1 uses VM inv eng 13 on hub 0
Jan 3 18:00:58 lisa kernel: [ 45.198662] amdgpu :03:00.0: amdgpu: ring
vcn_dec_0 uses VM inv eng 0 on hub 1
Jan 3 18:00:58 lisa kernel: [ 45.198662] amdgpu :03:00.0: amdgpu: ring
vcn_enc_0.0 uses VM inv eng 1 on hub 1
Jan 3 18:00:58 lisa kernel: [ 45.198663] amdgpu :03:00.0: amdgpu: ring
vcn_enc_0.1 uses VM inv eng 4 on hub 1
Jan 3 18:00:58 lisa kernel: [ 45.198663] amdgpu :03:00.0: amdgpu: ring
jpeg_dec uses VM inv eng 5 on hub 1
Jan 3 18:00:58 lisa kernel: [ 45.202326] amdgpu :03:00.0: [drm] Cannot
find any crtc or sizes
Jan 3 18:00:58 lisa kernel: [ 45.527398] [drm] Register(0)
[mmUVD_POWER_STATUS] failed to reach value 0x0001 != 0x0002
Jan 3 18:00:58 lisa kernel: [ 45.844705] [drm] Register(0)
[mmUVD_POWER_STATUS] failed to reach value 0x0001 != 0x0002
Jan 3 18:00:58 lisa kernel: [ 45.889752] [drm] free PSP TMR buffer
Jan 3 18:00:58 lisa kernel: [ 45.939048] amdgpu :03:00.0: amdgpu: MODE1
reset
Jan 3
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436 mario.limoncie...@amd.com changed: What|Removed |Added CC||mario.limoncie...@amd.com --- Comment #15 from mario.limoncie...@amd.com --- Created attachment 300214 --> https://bugzilla.kernel.org/attachment.cgi?id=300214=edit Possible patch that ignores WA in s0ix Actually this is more like what I was suggesting. It effectively doesn't use the WA during s0ix suspend or resume. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/4] phy: mediatek: phy-mtk-hdmi: Reorder and stop implicit header inclusion
All the headers for phy-mtk-{hdmi,hdmi-mt2701,hdmi-mt8183}.c were
included from phy-mtk-mipi-dsi.h, but this isn't optimal: in order to
increase readability and sensibly reduce build times, the inclusions
should be done per-file, also avoiding to include unused headers and
should not be implicit.
For this reason, move the inclusions to each file and remove unused ones.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c | 5 +
drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c | 5 +
drivers/phy/mediatek/phy-mtk-hdmi.c| 8
drivers/phy/mediatek/phy-mtk-hdmi.h| 10 +-
4 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
index 09e0dd7499d8..270c5f538483 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
@@ -4,6 +4,11 @@
* Author: Chunhui Dai
*/
+#include
+#include
+#include
+#include
+#include
#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
index e317bf4a9db9..87ba9a3687b7 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
@@ -4,6 +4,11 @@
* Author: Jie Qiu
*/
+#include
+#include
+#include
+#include
+#include
#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index b4193cb4e4e3..e037fa89696c 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -4,6 +4,14 @@
* Author: Jie Qiu
*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include "phy-mtk-hdmi.h"
inline struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.h
b/drivers/phy/mediatek/phy-mtk-hdmi.h
index a0571271d730..ef81e44a235d 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.h
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.h
@@ -6,17 +6,9 @@
#ifndef _MTK_HDMI_PHY_H
#define _MTK_HDMI_PHY_H
-#include
+
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
struct mtk_hdmi_phy;
--
2.33.1
[PATCH 4/4] phy: mediatek: phy-mtk-hdmi: Simplify with dev_err_probe()
Use the dev_err_probe() helper to simplify error handling during probe.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 50 +++--
1 file changed, 19 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index e037fa89696c..4f40a6eea004 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -104,20 +104,16 @@ static int mtk_hdmi_phy_probe(struct platform_device
*pdev)
return PTR_ERR(hdmi_phy->regmap);
ref_clk = devm_clk_get(dev, "pll_ref");
- if (IS_ERR(ref_clk)) {
- ret = PTR_ERR(ref_clk);
- dev_err(>dev, "Failed to get PLL reference clock: %d\n",
- ret);
- return ret;
- }
+ if (IS_ERR(ref_clk))
+ return dev_err_probe(dev, PTR_ERR(ref_clk),
+"Failed to get PLL reference clock\n");
+
ref_clk_name = __clk_get_name(ref_clk);
ret = of_property_read_string(dev->of_node, "clock-output-names",
_init.name);
- if (ret < 0) {
- dev_err(dev, "Failed to read clock-output-names: %d\n", ret);
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read
clock-output-names\n");
hdmi_phy->dev = dev;
hdmi_phy->conf =
@@ -125,25 +121,19 @@ static int mtk_hdmi_phy_probe(struct platform_device
*pdev)
mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
hdmi_phy->pll_hw.init = _init;
hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
- if (IS_ERR(hdmi_phy->pll)) {
- ret = PTR_ERR(hdmi_phy->pll);
- dev_err(dev, "Failed to register PLL: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(hdmi_phy->pll))
+ return dev_err_probe(dev, PTR_ERR(hdmi_phy->pll),
+ "Failed to register PLL\n");
ret = of_property_read_u32(dev->of_node, "mediatek,ibias",
_phy->ibias);
- if (ret < 0) {
- dev_err(>dev, "Failed to get ibias: %d\n", ret);
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get ibias\n");
ret = of_property_read_u32(dev->of_node, "mediatek,ibias_up",
_phy->ibias_up);
- if (ret < 0) {
- dev_err(>dev, "Failed to get ibias up: %d\n", ret);
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get ibias_up\n");
dev_info(dev, "Using default TX DRV impedance: 4.2k/36\n");
hdmi_phy->drv_imp_clk = 0x30;
@@ -152,17 +142,15 @@ static int mtk_hdmi_phy_probe(struct platform_device
*pdev)
hdmi_phy->drv_imp_d0 = 0x30;
phy = devm_phy_create(dev, NULL, mtk_hdmi_phy_dev_get_ops(hdmi_phy));
- if (IS_ERR(phy)) {
- dev_err(dev, "Failed to create HDMI PHY\n");
- return PTR_ERR(phy);
- }
+ if (IS_ERR(phy))
+ return dev_err_probe(dev, PTR_ERR(phy), "Cannot create HDMI
PHY\n");
+
phy_set_drvdata(phy, hdmi_phy);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- if (IS_ERR(phy_provider)) {
- dev_err(dev, "Failed to register HDMI PHY\n");
- return PTR_ERR(phy_provider);
- }
+ if (IS_ERR(phy_provider))
+ return dev_err_probe(dev, PTR_ERR(phy_provider),
+"Failed to register HDMI PHY\n");
if (hdmi_phy->conf->pll_default_off)
hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy);
--
2.33.1
[PATCH 2/4] phy: mediatek: phy-mtk-hdmi: Reorder to remove forward declarations
Forward declarations for mtk_hdmi_power_{on,off} aren't necessary:
move mtk_hdmi_phy_dev_ops down to remove forward declarations.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 707e90691e6e..b4193cb4e4e3 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -6,15 +6,6 @@
#include "phy-mtk-hdmi.h"
-static int mtk_hdmi_phy_power_on(struct phy *phy);
-static int mtk_hdmi_phy_power_off(struct phy *phy);
-
-static const struct phy_ops mtk_hdmi_phy_dev_ops = {
- .power_on = mtk_hdmi_phy_power_on,
- .power_off = mtk_hdmi_phy_power_off,
- .owner = THIS_MODULE,
-};
-
inline struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw)
{
return container_of(hw, struct mtk_hdmi_phy, pll_hw);
@@ -43,6 +34,12 @@ static int mtk_hdmi_phy_power_off(struct phy *phy)
return 0;
}
+static const struct phy_ops mtk_hdmi_phy_dev_ops = {
+ .power_on = mtk_hdmi_phy_power_on,
+ .power_off = mtk_hdmi_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
static const struct phy_ops *
mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy *hdmi_phy)
{
--
2.33.1
[PATCH 1/4] phy: mediatek: phy-mtk-hdmi: Switch to regmap for mmio access
Switch to using the generic regmap API instead of calls to readl/writel
for MMIO register access, removing custom crafted update/set/clear_bits
functions and also allowing us to reduce code size.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c | 165 ++---
drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c | 126
drivers/phy/mediatek/phy-mtk-hdmi.c| 51 ++-
drivers/phy/mediatek/phy-mtk-hdmi.h| 9 +-
4 files changed, 158 insertions(+), 193 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
index b74c65a1762c..09e0dd7499d8 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
@@ -69,19 +69,19 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
{
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON7, RG_HTPLL_AUTOK_EN);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_RLH_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_MBIAS);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON7, RG_HTPLL_AUTOK_EN);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_RLH_EN);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_EN_MBIAS);
usleep_range(80, 100);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_EN);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
+ regmap_set_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
usleep_range(80, 100);
return 0;
}
@@ -90,19 +90,19 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
{
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_EN);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_EN);
usleep_range(80, 100);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_MBIAS);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_RLH_EN);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON7, RG_HTPLL_AUTOK_EN);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON2, RG_HDMITX_EN_MBIAS);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON6, RG_HTPLL_RLH_EN);
+ regmap_clear_bits(hdmi_phy->regmap, HDMI_CON7, RG_HTPLL_AUTOK_EN);
usleep_range(80, 100);
}
@@ -125,37 +125,34 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
else
pos_div = 1;
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
- mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
[Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=215443 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- (In reply to Alex Deucher from comment #2) > does appending amdgpu.runpm=0 on the kernel command line help? I doubt it as amdgpu is not even built (# CONFIG_DRM_AMDGPU is not set, see attached .config). The card in question is a Radeon HD 6670 using the radeon drm module. Sorry I forgot to mention that! -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.
[Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=215443 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- does appending amdgpu.runpm=0 on the kernel command line help? -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH 22/22] drm: rockchip: Add VOP2 driver
Hi Nicolas,
Thanks for the review. I have changed the points I don't comment on here
according to your suggestions.
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Alphabetically sort these includes? Not sure on what the
> convention is in the DRM subsystem.
Me neither. The first random file I looked at in drivers/gpu/drm/ has
the includes sorted alphabetically, so I'll do the same.
>
> > +static void vop2_cfg_done(struct vop2_video_port *vp)
> > +{
> > + struct vop2 *vop2 = vp->vop2;
> > + uint32_t val;
> > +
> > + val = vop2_readl(vop2, RK3568_REG_CFG_DONE);
> > +
> > + val &= 0x7;
>
> GENMASK(2, 0) instead of 0x7, should that be a constant somewhere?
>
> > +
> > + vop2_writel(vop2, RK3568_REG_CFG_DONE,
> > + val | BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
Replaced that with the following which doesn't need a mask:
regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE,
BIT(vp->id) |
RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
> > +}
> > +
> > +static void vop2_win_disable(struct vop2_win *win)
> > +{
> > + vop2_win_write(win, VOP2_WIN_ENABLE, 0);
> > +
> > + if (vop2_cluster_window(win))
> > + vop2_win_write(win, VOP2_WIN_CLUSTER_ENABLE, 0);
> > +}
> > +
> > +static uint32_t vop2_afbc_transform_offset(struct drm_plane_state *pstate,
> > + bool afbc_half_block_en)
> > +{
> > + struct drm_rect *src = >src;
> > + struct drm_framebuffer *fb = pstate->fb;
> > + uint32_t bpp = fb->format->cpp[0] * 8;
> > + uint32_t vir_width = (fb->pitches[0] << 3) / bpp;
> > + uint32_t width = drm_rect_width(src) >> 16;
> > + uint32_t height = drm_rect_height(src) >> 16;
> > + uint32_t act_xoffset = src->x1 >> 16;
> > + uint32_t act_yoffset = src->y1 >> 16;
> > + uint32_t align16_crop = 0;
> > + uint32_t align64_crop = 0;
> > + uint32_t height_tmp = 0;
> > + uint32_t transform_tmp = 0;
> > + uint8_t transform_xoffset = 0;
> > + uint8_t transform_yoffset = 0;
> > + uint8_t top_crop = 0;
> > + uint8_t top_crop_line_num = 0;
> > + uint8_t bottom_crop_line_num = 0;
> > +
> > + /* 16 pixel align */
> > + if (height & 0xf)
> > + align16_crop = 16 - (height & 0xf);
> > +
> > + height_tmp = height + align16_crop;
> > +
> > + /* 64 pixel align */
> > + if (height_tmp & 0x3f)
> > + align64_crop = 64 - (height_tmp & 0x3f);
> > +
> > + top_crop_line_num = top_crop << 2;
> > + if (top_crop == 0)
> > + bottom_crop_line_num = align16_crop + align64_crop;
> > + else if (top_crop == 1)
> > + bottom_crop_line_num = align16_crop + align64_crop + 12;
> > + else if (top_crop == 2)
> > + bottom_crop_line_num = align16_crop + align64_crop + 8;
>
> top_crop == 0 is always taken from what I can gather, rest is
> dead code. Is this intentional? It doesn't seem intentional.
It's the same in the downstream driver. I don't know what top_crop is
good for. I just removed the dead code for now.
> > + transform_xoffset = transform_tmp & 0xf;
> > + transform_tmp = vir_width - width - act_xoffset;
> > + transform_yoffset = transform_tmp & 0xf;
> > + break;
> > + case 0:
> > + transform_tmp = act_xoffset;
> > + transform_xoffset = transform_tmp & 0xf;
> > + transform_tmp = top_crop_line_num + act_yoffset;
> > +
> > + if (afbc_half_block_en)
> > + transform_yoffset = transform_tmp & 0x7;
> > + else
> > + transform_yoffset = transform_tmp & 0xf;
> > +
> > + break;
> > + }
> > +
> > + return (transform_xoffset & 0xf) | ((transform_yoffset & 0xf) << 16);
> > +}
>
> 0xf, 0x3f, 0x7 might be more clear as GENMASK.
> if (afbc_half_block_en) branches can be moved out of cases and
> assign a transform mask variable instead.
Sure. Other than that the function can be simplified a bit more.
>
> > +
> > +/*
> > + * A Cluster window has 2048 x 16 line buffer, which can
> > + * works at 2048 x 16(Full) or 4096 x 8 (Half) mode.
> > + * for Cluster_lb_mode register:
> > + * 0: half mode, for plane input width range 2048 ~ 4096
> > + * 1: half mode, for cluster work at 2 * 2048 plane mode
> > + * 2: half mode, for rotate_90/270 mode
> > + *
> > + */
> > +static int vop2_get_cluster_lb_mode(struct vop2_win *win, struct
> > drm_plane_state *pstate)
> > +{
> > + if ((pstate->rotation & DRM_MODE_ROTATE_270) || (pstate->rotation &
> > DRM_MODE_ROTATE_90))
> > + return 2;
> > + else
> > + return 0;
> > +}
>
> What about 1?
1 is used in the downstream driver for cluster sub windows. These are
currently not supported, I don't know yet where this is leading to.
>
> > +
> > +/*
> > + * bli_sd_factor = (src - 1) / (dst - 1) << 12;
> > + * avg_sd_factor:
> > + * bli_su_factor:
> > + * bic_su_factor:
>
[PATCH 3/3] phy: mediatek: phy-mtk-mipi-dsi: Simplify with dev_err_probe()
Use the dev_err_probe() helper to simplify error handling during probe.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 29 +
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 6f7425b0bf5b..4b77508f5241 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -148,11 +148,9 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
return PTR_ERR(mipi_tx->regmap);
ref_clk = devm_clk_get(dev, NULL);
- if (IS_ERR(ref_clk)) {
- ret = PTR_ERR(ref_clk);
- dev_err(dev, "Failed to get reference clock: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(ref_clk))
+ return dev_err_probe(dev, PTR_ERR(ref_clk),
+"Failed to get reference clock\n");
ret = of_property_read_u32(dev->of_node, "drive-strength-microamp",
_tx->mipitx_drive);
@@ -172,27 +170,20 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
ret = of_property_read_string(dev->of_node, "clock-output-names",
_init.name);
- if (ret < 0) {
- dev_err(dev, "Failed to read clock-output-names: %d\n", ret);
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read
clock-output-names\n");
clk_init.ops = mipi_tx->driver_data->mipi_tx_clk_ops;
mipi_tx->pll_hw.init = _init;
mipi_tx->pll = devm_clk_register(dev, _tx->pll_hw);
- if (IS_ERR(mipi_tx->pll)) {
- ret = PTR_ERR(mipi_tx->pll);
- dev_err(dev, "Failed to register PLL: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(mipi_tx->pll))
+ return dev_err_probe(dev, PTR_ERR(mipi_tx->pll), "Cannot
register PLL\n");
phy = devm_phy_create(dev, NULL, _mipi_tx_ops);
- if (IS_ERR(phy)) {
- ret = PTR_ERR(phy);
- dev_err(dev, "Failed to create MIPI D-PHY: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(phy))
+ return dev_err_probe(dev, PTR_ERR(phy), "Failed to create MIPI
D-PHY\n");
+
phy_set_drvdata(phy, mipi_tx);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
2.33.1
[PATCH 2/3] phy: mediatek: phy-mtk-mipi-dsi: Reorder and stop implicit header inclusion
All the headers for phy-mtk-mipi-{dsi,dsi-mt8173,dsi-mt8183}.c were
included from phy-mtk-mipi-dsi.h, but this isn't optimal: in order to
increase readability and sensibly reduce build times, the inclusions
should be done per-file, also avoiding to include unused headers and
should not be implicit.
For this reason, move the inclusions to each file and remove unused ones.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c | 4
drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c | 4
drivers/phy/mediatek/phy-mtk-mipi-dsi.c| 7 +++
drivers/phy/mediatek/phy-mtk-mipi-dsi.h| 10 ++
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
index 95a0d9a3cca7..59f028da9d3e 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
@@ -4,7 +4,11 @@
* Author: jitao.shi
*/
+#include
+#include
+#include
#include
+#include
#include "phy-mtk-mipi-dsi.h"
#define MIPITX_DSI_CON 0x00
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
index 01b59527669e..6c6b192485ba 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
@@ -4,7 +4,11 @@
* Author: jitao.shi
*/
+#include
+#include
+#include
#include
+#include
#include "phy-mtk-mipi-dsi.h"
#define MIPITX_LANE_CON0x000c
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 51b1b1d4ad38..6f7425b0bf5b 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -3,7 +3,14 @@
* Copyright (c) 2015 MediaTek Inc.
*/
+#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
#include "phy-mtk-mipi-dsi.h"
inline struct mtk_mipi_tx *mtk_mipi_tx_from_clk_hw(struct clk_hw *hw)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
index 8d32e9027a15..4eb5fc91e083 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
@@ -7,16 +7,10 @@
#ifndef _MTK_MIPI_TX_H
#define _MTK_MIPI_TX_H
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
+#include
+#include
#include
-#include
struct mtk_mipitx_data {
const u32 mppll_preserve;
--
2.33.1
[PATCH 1/3] phy: mediatek: phy-mtk-mipi-dsi: Switch to regmap for mmio access
Switch to using the generic regmap API instead of calls to readl/writel for MMIO register access, removing custom crafted update/set/clear_bits functions and also allowing us to reduce code size. Signed-off-by: AngeloGioacchino Del Regno --- .../phy/mediatek/phy-mtk-mipi-dsi-mt8173.c| 45 ++--- .../phy/mediatek/phy-mtk-mipi-dsi-mt8183.c| 63 ++- drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 43 + drivers/phy/mediatek/phy-mtk-mipi-dsi.h | 6 +- 4 files changed, 72 insertions(+), 85 deletions(-) diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c index 7a847954594f..95a0d9a3cca7 100644 --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c @@ -4,6 +4,7 @@ * Author: jitao.shi */ +#include #include "phy-mtk-mipi-dsi.h" #define MIPITX_DSI_CON 0x00 @@ -145,7 +146,7 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw) return -EINVAL; } - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_BG_CON, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_BG_CON, RG_DSI_VOUT_MSK | RG_DSI_BG_CKEN | RG_DSI_BG_CORE_EN, (4 << 20) | (4 << 17) | (4 << 14) | @@ -154,22 +155,22 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw) usleep_range(30, 100); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_TOP_CON, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_TOP_CON, RG_DSI_LNT_IMP_CAL_CODE | RG_DSI_LNT_HS_BIAS_EN, (8 << 4) | RG_DSI_LNT_HS_BIAS_EN); - mtk_mipi_tx_set_bits(mipi_tx, MIPITX_DSI_CON, + regmap_set_bits(mipi_tx->regmap, MIPITX_DSI_CON, RG_DSI_CKG_LDOOUT_EN | RG_DSI_LDOCORE_EN); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_PWR, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_PLL_PWR, RG_DSI_MPPLL_SDM_PWR_ON | RG_DSI_MPPLL_SDM_ISO_EN, RG_DSI_MPPLL_SDM_PWR_ON); - mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_PLL_CON0, + regmap_clear_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON0, RG_DSI_MPPLL_PLL_EN); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_CON0, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON0, RG_DSI_MPPLL_TXDIV0 | RG_DSI_MPPLL_TXDIV1 | RG_DSI_MPPLL_PREDIV, (txdiv0 << 3) | (txdiv1 << 5)); @@ -184,19 +185,19 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw) */ pcw = div_u64(((u64)mipi_tx->data_rate * 2 * txdiv) << 24, 2600); - writel(pcw, mipi_tx->regs + MIPITX_DSI_PLL_CON2); + regmap_write(mipi_tx->regmap, MIPITX_DSI_PLL_CON2, pcw); - mtk_mipi_tx_set_bits(mipi_tx, MIPITX_DSI_PLL_CON1, + regmap_set_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON1, RG_DSI_MPPLL_SDM_FRA_EN); - mtk_mipi_tx_set_bits(mipi_tx, MIPITX_DSI_PLL_CON0, RG_DSI_MPPLL_PLL_EN); + regmap_set_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON0, RG_DSI_MPPLL_PLL_EN); usleep_range(20, 100); - mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_PLL_CON1, + regmap_clear_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON1, RG_DSI_MPPLL_SDM_SSC_EN); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_TOP, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_PLL_TOP, RG_DSI_MPPLL_PRESERVE, mipi_tx->driver_data->mppll_preserve); @@ -209,27 +210,27 @@ static void mtk_mipi_tx_pll_unprepare(struct clk_hw *hw) dev_dbg(mipi_tx->dev, "unprepare\n"); - mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_PLL_CON0, + regmap_clear_bits(mipi_tx->regmap, MIPITX_DSI_PLL_CON0, RG_DSI_MPPLL_PLL_EN); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_TOP, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_PLL_TOP, RG_DSI_MPPLL_PRESERVE, 0); - mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_PWR, + regmap_update_bits(mipi_tx->regmap, MIPITX_DSI_PLL_PWR, RG_DSI_MPPLL_SDM_ISO_EN | RG_DSI_MPPLL_SDM_PWR_ON, RG_DSI_MPPLL_SDM_ISO_EN); - mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_TOP_CON, + regmap_clear_bits(mipi_tx->regmap, MIPITX_DSI_TOP_CON, RG_DSI_LNT_HS_BIAS_EN); - mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_CON, + regmap_clear_bits(mipi_tx->regmap, MIPITX_DSI_CON,
Re: [PATCH v2] drm/mediatek: Set default value for Panel Orientation connector prop.
Hi, Mark:
Mark Yacoub 於 2021年12月30日 週四 上午2:44寫道：
>
> [Why]
> Creating the prop uses UNKNOWN as the initial value, which is not a
> supported value if the prop is to be supported.
>
> [How]
> Set the panel orientation default value to NORMAL right after creating
> the prop if no DSI panel exists.
> Panels have their own orientations, and panel orientation can't be
> overriden once initialized to a value.
>
> v1:
> Set panel orientation only if DSI panel does not exist.
>
> Tested on Jacuzzi(MTK)
> Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
>
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0ad7157660afa..9d33dd93118e0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1040,6 +1040,13 @@ static int mtk_dsi_encoder_init(struct drm_device
> *drm, struct mtk_dsi *dsi)
> goto err_cleanup_encoder;
> }
>
> + /* A drm_panel can have its own orientation. If there is no panel,
> set the
> +* orientation to NORMAL. */
> + if (!dsi->panel) {
Please send patch based on latest kernel version. In latest kernel
version, struct mtk_dsi{} has no member 'panel'.
Regards,
Chun-Kuang.
> + drm_connector_set_panel_orientation(
> + dsi->connector, DRM_MODE_PANEL_ORIENTATION_NORMAL);
> + }
> +
> drm_connector_attach_encoder(dsi->connector, >encoder);
>
> return 0;
> --
> 2.34.1.448.ga2b2bfdf31-goog
>
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Laurent, On Mon, Jan 3, 2022 at 8:48 AM Laurent Pinchart wrote: > With the comment from 2/2 taken into account, > > Reviewed-by: Laurent Pinchart Thanks for the review. I addressed your feedback and sent v2. I noticed a problem when removing/inserting the HDMI cable. If I boot the board with the HDMI cable connected, then after removal/insertion of the HDMI cable, the following kernel warning is observed: # [ 23.201080] [ cut here ] [ 23.207275] WARNING: CPU: 0 PID: 56 at drivers/gpu/drm/drm_atomic_helper.c:1514 drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294 [ 23.221469] [CRTC:35:crtc-0] vblank wait timed out [ 23.226448] Modules linked in: [ 23.230255] CPU: 0 PID: 56 Comm: kworker/0:3 Not tainted 5.15.12-3-g27f29fb60028 #94 [ 23.238508] Hardware name: Freescale i.MX6 SoloX (Device Tree) [ 23.244457] Workqueue: events output_poll_execute [ 23.249377] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 23.257316] [] (show_stack) from [] (dump_stack_lvl+0x58/0x70) [ 23.265059] [] (dump_stack_lvl) from [] (__warn+0xd8/0x114) [ 23.272533] [] (__warn) from [] (warn_slowpath_fmt+0x90/0xc4) [ 23.280166] [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294) [ 23.291054] [] (drm_atomic_helper_wait_for_vblanks.part.0) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [ 23.303150] [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x9c/0x190) [ 23.312717] [] (commit_tail) from [] (drm_atomic_helper_commit+0x158/0x18c) [ 23.321588] [] (drm_atomic_helper_commit) from [] (drm_client_modeset_commit_atomic+0x238/0x284) [ 23.332314] [] (drm_client_modeset_commit_atomic) from [] (drm_client_modeset_commit_locked+0x60/0x1cc) [ 23.343615] [] (drm_client_modeset_commit_locked) from [] (drm_client_modeset_commit+0x24/0x40) [ 23.354218] [] (drm_client_modeset_commit) from [] (__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc8) [ 23.365803] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x38/0x68) [ 23.377015] [] (drm_fb_helper_set_par) from [] (drm_fb_helper_hotplug_event.part.0+0xa4/0xc0) [ 23.387443] [] (drm_fb_helper_hotplug_event.part.0) from [] (drm_client_dev_hotplug+0x6c/0xb4) [ 23.397959] [] (drm_client_dev_hotplug) from [] (output_poll_execute+0x200/0x21c) [ 23.407346] [] (output_poll_execute) from [] (process_one_work+0x298/0x7cc) [ 23.416224] [] (process_one_work) from [] (worker_thread+0x30/0x50c) [ 23.424479] [] (worker_thread) from [] (kthread+0x154/0x17c) [ 23.432039] [] (kthread) from [] (ret_from_fork+0x14/0x38) [ 23.439413] Exception stack(0xc42a1fb0 to 0xc42a1ff8) [ 23.444588] 1fa0: [ 23.452888] 1fc0: [ 23.461182] 1fe0: 0013 [ 23.468734] irq event stamp: 43775 [ 23.472305] hardirqs last enabled at (43783): [] __up_console_sem+0x50/0x60 [ 23.480785] hardirqs last disabled at (43792): [] __up_console_sem+0x3c/0x60 [ 23.489224] softirqs last enabled at (43774): [] __do_softirq+0x2ec/0x5a4 [ 23.497163] softirqs last disabled at (43747): [] irq_exit+0x18c/0x210 [ 23.505106] ---[ end trace 86572327287ca501 ]--- I haven't managed to fix this yet, but if you have any suggestions, please let me know. Thanks, Fabio Estevam
[PATCH v2 2/2] drm/i2c/tda998x: Implement atomic_get_input_bus_fmts
Implement the .atomic_get_input_bus_fmts callback to let the bridge
indicate the pixel format it requires on the parallel bus to the LCDIF.
Based on Marek's commit db8b7ca5b232 ("drm/bridge: ti-sn65dsi83: Replace
connector format patching with atomic_get_input_bus_fmts").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Laurent Pinchart
---
Changes since v1:
- Move .atomic_duplicate_state,.atomic_destroy_state .atomic_reset from
patch 2/2 to 1/2. (Laurent)
drivers/gpu/drm/i2c/tda998x_drv.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 45d52b8a4026..d987481e97c1 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1678,6 +1678,31 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
mutex_unlock(>audio_mutex);
}
+#define MAX_INPUT_SEL_FORMATS 1
+
+static u32 *
+tda998x_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
@@ -1688,6 +1713,7 @@ static const struct drm_bridge_funcs tda998x_bridge_funcs
= {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = tda998x_atomic_get_input_bus_fmts,
};
/* I2C driver functions */
--
2.25.1
[PATCH v2 1/2] drm/i2c/tda998x: Switch to atomic operations
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.
Based on Laurent's commit a6ea7d268a63("drm: bridge: ti-sn65dsi83:
Switch to atomic operations").
Tested on a imx6sx-udoo-neo board.
Suggested-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Laurent Pinchart
---
Changes since v1:
- Move .atomic_duplicate_state,.atomic_destroy_state .atomic_reset from
patch 2/2 to 1/2. (Laurent)
drivers/gpu/drm/i2c/tda998x_drv.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b7ec6c374fbd..45d52b8a4026 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1395,7 +1395,8 @@ static enum drm_mode_status
tda998x_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void tda998x_bridge_enable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1413,7 +1414,8 @@ static void tda998x_bridge_enable(struct drm_bridge
*bridge)
}
}
-static void tda998x_bridge_disable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
@@ -1680,9 +1682,12 @@ static const struct drm_bridge_funcs
tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
.mode_valid = tda998x_bridge_mode_valid,
- .disable = tda998x_bridge_disable,
+ .atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
- .enable = tda998x_bridge_enable,
+ .atomic_enable = tda998x_bridge_atomic_enable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
};
/* I2C driver functions */
--
2.25.1
Re: [PATCH 11/24] drm/amdgpu: use dma_resv_for_each_fence for CS workaround
Am 22.12.21 um 22:37 schrieb Daniel Vetter:
On Tue, Dec 07, 2021 at 01:33:58PM +0100, Christian König wrote:
Get the write fence using dma_resv_for_each_fence instead of accessing
it manually.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 53e407ea4c89..7facd614e50a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1268,6 +1268,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
amdgpu_bo_list_for_each_entry(e, p->bo_list) {
struct dma_resv *resv = e->tv.bo->base.resv;
struct dma_fence_chain *chain = e->chain;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
if (!chain)
continue;
@@ -1277,9 +1279,10 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
* submission in a dma_fence_chain and add it as exclusive
* fence.
*/
- dma_fence_chain_init(chain, dma_resv_excl_fence(resv),
-dma_fence_get(p->fence), 1);
-
+ dma_resv_for_each_fence(, resv, false, fence) {
+ break;
+ }
+ dma_fence_chain_init(chain, fence, dma_fence_get(p->fence), 1);
Uh this needs a TODO. I'm assuming you'll fix this up later on when
there's more than write fence, but in case of bisect or whatever this is a
bit too clever. Like you just replace one "dig around in dma-resv
implementation details" with one that's not even a documented interface
:-)
Ah, yes. There is a rather big TODO just above this, but I should
probably make that even more stronger.
With an adequately loud comment added interim:
Reviewed-by: Daniel Vetter
Thanks,
Christian.
rcu_assign_pointer(resv->fence_excl, >base);
e->chain = NULL;
}
--
2.25.1
[PATCH v4 4/4] drm/i915: Use struct vma_resource instead of struct vma_snapshot
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a small price to pay for the simplification.
v2:
- Fix a missing include and declaration (kernel test robot )
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++--
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 14 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 4 +
drivers/gpu/drm/i915/i915_vma_resource.h | 28 +++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 125 --
drivers/gpu/drm/i915/i915_vma_snapshot.h | 101 --
11 files changed, 89 insertions(+), 313 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 98433ad74194..aa86ac33effc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -175,7 +175,6 @@ i915-y += \
i915_ttm_buddy_manager.o \
i915_vma.o \
i915_vma_resource.o \
- i915_vma_snapshot.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 72e497745c12..2f85fe557ad2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,7 +29,6 @@
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#include "i915_vma_snapshot.h"
struct eb_vma {
struct i915_vma *vma;
@@ -1952,7 +1951,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
- struct i915_vma_snapshot *vsnap;
while (i--) {
struct eb_vma *ev = >vma[i];
@@ -1962,11 +1960,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
- vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
- if (!vsnap)
- continue;
-
- i915_vma_snapshot_init(vsnap, vma, "user");
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
@@ -1975,10 +1968,9 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
continue;
capture->next = eb->capture_lists[j];
- capture->vma_snapshot = i915_vma_snapshot_get(vsnap);
+ capture->vma_res = i915_vma_resource_get(vma->resource);
eb->capture_lists[j] = capture;
}
- i915_vma_snapshot_put(vsnap);
}
}
@@ -3281,9 +3273,8 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
* _onstack interface.
*/
if (eb->batches[i]->vma)
-
i915_vma_snapshot_init_onstack(>requests[i]->batch_snapshot,
- eb->batches[i]->vma,
- "batch");
+ eb->requests[i]->batch_res =
+
i915_vma_resource_get(eb->batches[i]->vma->resource);
if (eb->batch_pool) {
GEM_BUG_ON(intel_context_is_parallel(eb->context));
intel_gt_buffer_pool_mark_active(eb->batch_pool,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 74aa90587061..d1daa4cc2895 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1708,18 +1708,15 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
static void print_request_ring(struct drm_printer *m, struct i915_request *rq)
{
- struct i915_vma_snapshot *vsnap = >batch_snapshot;
+ struct i915_vma_resource *vma_res = rq->batch_res;
void *ring;
int size;
- if (!i915_vma_snapshot_present(vsnap))
- vsnap = NULL;
-
drm_printf(m,
"[head %04x, postfix %04x, tail %04x, batch 0x%08x_%08x]:\n",
rq->head, rq->postfix, rq->tail,
- vsnap ? upper_32_bits(vsnap->vma_resource->start)
[PATCH v4 3/4] drm/i915: Use vma resources for async unbinding
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to avoid stalling the migration blit waiting for unbind, as they
can certainly go on in parallel, but since we don't yet have a
reasonable data structure to use to coalesce fences and attach the
resulting fence to a timeline, we defer that for now.
Note that with async unbinding, even while the unbind waits for the
preceding bind to complete before unbinding, the vma itself might have been
destroyed in the process, clearing the vma pages. Therefore we can
only allow async unbinding if we have a refcounted sg-list and keep a
refcount on that for the vma resource pages to stay intact until
binding occurs. If this condition is not met, a request for an async
unbind is diverted to a sync unbind.
v2:
- Use a separate kmem_cache for vma resources for now to isolate their
memory allocation and aid debugging.
- Move the check for vm closed to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
v4:
- Take cache coloring into account when searching for vma resources
pending unbind. (Matthew Auld)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 12 +-
drivers/gpu/drm/i915/i915_module.c | 3 +
drivers/gpu/drm/i915/i915_vma.c | 196 --
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 354 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 48 +++
11 files changed, 571 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index ee9612a3ee5e..0f514435b9c5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -142,7 +142,16 @@ int i915_ttm_move_notify(struct ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
int ret;
- ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE);
+ /*
+* Note: The async unbinding here will actually transform the
+* blocking wait for unbind into a wait before finally submitting
+* evict / migration blit and thus stall the migration timeline
+* which may not be good for overall throughput. We should make
+* sure we await the unbind fences *after* the migration blit
+* instead of *before* as we currently do.
+*/
+ ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE |
+I915_GEM_OBJECT_UNBIND_ASYNC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 0137b6af0973..ae7bbd8914c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -142,7 +142,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
continue;
if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
- __i915_vma_evict(vma);
+ __i915_vma_evict(vma, false);
drm_mm_remove_node(>node);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index a94be0306464..46be4197b93f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -161,6 +161,9 @@ static void __i915_vm_release(struct work_struct *work)
struct i915_address_space *vm =
container_of(work, struct i915_address_space, release_work);
+ /* Synchronize async unbinds. */
+ i915_vma_resource_bind_dep_sync_all(vm);
+
vm->cleanup(vm);
i915_address_space_fini(vm);
@@ -189,6 +192,7 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
if (!kref_read(>resv_ref))
kref_init(>resv_ref);
+ vm->pending_unbind = RB_ROOT_CACHED;
INIT_WORK(>release_work, __i915_vm_release);
atomic_set(>open, 1);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 676b839d1a34..8073438b67c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -265,6 +265,9 @@ struct i915_address_space {
/* Flags used when creating
[PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the insert_entries() op for struct i915_address_space.
Replace a couple of i915_vma_snapshot members with their newly introduced
i915_vma_resource counterparts, since they have the same lifetime.
Also make sure to avoid changing the struct i915_vma_flags (in particular
the bind flags) async. That should now only be done sync under the
vm mutex.
v2:
- Update the vma_res::bound_flags when binding to the aliased ggtt
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dpt.c | 27 ++---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 ++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 70 ++---
drivers/gpu/drm/i915/gt/intel_gtt.h | 16 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 24 -
drivers/gpu/drm/i915/i915_vma.h | 11 +--
drivers/gpu/drm/i915/i915_vma_resource.c | 9 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 99 ++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 4 -
drivers/gpu/drm/i915/i915_vma_snapshot.h | 8 --
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 64
drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +--
21 files changed, 308 insertions(+), 206 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 8f674745e7e0..63a83d5f85a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -48,7 +48,7 @@ static void dpt_insert_page(struct i915_address_space *vm,
}
static void dpt_insert_entries(struct i915_address_space *vm,
- struct i915_vma *vma,
+ struct i915_vma_resource *vma_res,
enum i915_cache_level level,
u32 flags)
{
@@ -64,8 +64,8 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
- for_each_sgt_daddr(addr, sgt_iter, vma->pages)
+ i = vma_res->start / I915_GTT_PAGE_SIZE;
+ for_each_sgt_daddr(addr, sgt_iter, vma_res->bi.pages)
gen8_set_pte([i++], pte_encode | addr);
}
@@ -76,35 +76,38 @@ static void dpt_clear_range(struct i915_address_space *vm,
static void dpt_bind_vma(struct i915_address_space *vm,
struct i915_vm_pt_stash *stash,
-struct i915_vma *vma,
+struct i915_vma_resource *vma_res,
enum i915_cache_level cache_level,
u32 flags)
{
- struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
+ if (vma_res->bound_flags)
+ return;
+
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (vma->vm->has_read_only && i915_gem_object_is_readonly(obj))
+ if (vm->has_read_only && vma_res->bi.readonly)
pte_flags |= PTE_READ_ONLY;
- if (i915_gem_object_is_lmem(obj))
+ if (vma_res->bi.lmem)
pte_flags |= PTE_LM;
- vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+ vm->insert_entries(vm, vma_res, cache_level, pte_flags);
- vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
+ vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
/*
* Without aliasing PPGTT there's no difference between
* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence unconditionally
* upgrade to both bound if we bind either to avoid double-binding.
*/
- atomic_or(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND, >flags);
+ vma_res->bound_flags = I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
-static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
+static void dpt_unbind_vma(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
static void dpt_cleanup(struct
[PATCH v4 1/4] drm/i915: Initial introduction of vma resources
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 55 +++-
drivers/gpu/drm/i915/i915_vma.h | 19 ++-
drivers/gpu/drm/i915/i915_vma_resource.c | 124 ++
drivers/gpu/drm/i915/i915_vma_resource.h | 70 ++
drivers/gpu/drm/i915/i915_vma_snapshot.c | 15 +--
drivers/gpu/drm/i915/i915_vma_snapshot.h | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 99 --
10 files changed, 334 insertions(+), 63 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..98433ad74194 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -174,6 +174,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
+ i915_vma_resource.o \
i915_vma_snapshot.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9541244027a..72e497745c12 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1422,7 +1422,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
mutex_lock(>vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
- PIN_GLOBAL, NULL);
+ PIN_GLOBAL, NULL, NULL);
mutex_unlock(>vm->mutex);
reloc_cache_remap(>reloc_cache, ev->vma->obj);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index be208a8f1ed0..7097c5016431 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -37,6 +37,7 @@
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_vma.h"
+#include "i915_vma_resource.h"
static struct kmem_cache *slab_vmas;
@@ -380,6 +381,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
* @cache_level: mapping cache level
* @flags: flags like global or local mapping
* @work: preallocated worker for allocating and binding the PTE
+ * @vma_res: pointer to a preallocated vma resource. The resource is either
+ * consumed or freed.
*
* DMA addresses are taken from the scatter-gather table of this object (or of
* this VMA in case of non-default GGTT views) and PTE entries set up.
@@ -388,7 +391,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
int i915_vma_bind(struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 flags,
- struct i915_vma_work *work)
+ struct i915_vma_work *work,
+ struct i915_vma_resource *vma_res)
{
u32 bind_flags;
u32 vma_flags;
@@ -399,11 +403,15 @@ int i915_vma_bind(struct i915_vma *vma,
if (GEM_DEBUG_WARN_ON(range_overflows(vma->node.start,
vma->node.size,
- vma->vm->total)))
+ vma->vm->total))) {
+ kfree(vma_res);
return -ENODEV;
+ }
- if (GEM_DEBUG_WARN_ON(!flags))
+ if (GEM_DEBUG_WARN_ON(!flags)) {
+ kfree(vma_res);
return -EINVAL;
+ }
bind_flags = flags;
bind_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
@@ -412,11 +420,21 @@ int i915_vma_bind(struct i915_vma *vma,
vma_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
bind_flags &= ~vma_flags;
- if (bind_flags == 0)
+ if (bind_flags == 0) {
+ kfree(vma_res);
return 0;
+ }
GEM_BUG_ON(!atomic_read(>pages_count));
+ if (vma->resource || !vma_res) {
+ /* Rebinding with an additional I915_VMA_*_BIND */
+ GEM_WARN_ON(!vma_flags);
+ kfree(vma_res);
+ } else {
+ i915_vma_resource_init(vma_res);
+ vma->resource = vma_res;
+ }
trace_i915_vma_bind(vma, bind_flags);
if (work && bind_flags & vma->vm->bind_async_flags) {
struct dma_fence *prev;
@@ -1279,6
[PATCH v4 0/4] drm/i915: Asynchronous vma unbinding
This patch series introduces infrastructure for asynchronous vma unbinding. The single enabled use-case is initially at buffer object migration where we otherwise sync when unbinding vmas before migration. This in theory allows us to pipeline any number of migrations, but in practice the number is restricted by a sync wait when filling the migration context ring. We might want to look at that moving forward if needed. The other main use-case is to be able to pipeline vma evictions, for example with softpinning where a new vma wants to reuse the vm range of an already active vma. We can't support this just yet because we need dma_resv locking around vma eviction for that, which is under implementation. Patch 1 introduces vma resource first for error capture purposes. Patch 2 changes the vm backend interface to take vma resources rather than vmas, Patch 3 introduces the async unbinding itself, and finally Patch 4 realizes we have duplicated functionality and removes the vma snapshots. v2: -- Some kernel test robot reports addressed. -- kmem cache for vma resources, See patch 6 -- Various fixes all over the place. See separate commit messages. v3: -- Re-add a missing i915_vma_resource_put() -- Remove a stray debug printout v4: -- Patch series split in two. This is the second part. -- Take cache coloring into account when searching for vma_resources pengind unbind. (Matthew Auld) Thomas Hellström (4): drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Use vma resources for async unbinding drm/i915: Use struct vma_resource instead of struct vma_snapshot drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/display/intel_dpt.c | 27 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 17 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 4 + drivers/gpu/drm/i915/gt/intel_gtt.h | 19 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 12 +- drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++-- drivers/gpu/drm/i915/i915_module.c| 3 + drivers/gpu/drm/i915/i915_request.c | 12 +- drivers/gpu/drm/i915/i915_request.h | 6 +- drivers/gpu/drm/i915/i915_vma.c | 227 +- drivers/gpu/drm/i915/i915_vma.h | 33 +- drivers/gpu/drm/i915/i915_vma_resource.c | 417 ++ drivers/gpu/drm/i915/i915_vma_resource.h | 235 ++ drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 -- drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 - drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 --- drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +- 31 files changed, 1215 insertions(+), 561 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1
Re: [PATCH 1/3] dt-bindings: display: meson-dw-hdmi: add missing sound-name-prefix property
On 03/01/2022 12:32, Neil Armstrong wrote:
> On 23/12/2021 13:24, Alexander Stein wrote:
>> This is used in meson-gx and meson-g12. Add the property to the binding.
>> This fixes the dtschema warning:
>> hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the
>> regexes: 'pinctrl-[0-9]+'
>>
>> Signed-off-by: Alexander Stein
>> ---
>> .../devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> index cf5a208f2f10..343598c9f473 100644
>> --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> @@ -10,6 +10,9 @@ title: Amlogic specific extensions to the Synopsys
>> Designware HDMI Controller
>> maintainers:
>>- Neil Armstrong
>>
>> +allOf:
>> + - $ref: /schemas/sound/name-prefix.yaml#
>> +
>> description: |
>>The Amlogic Meson Synopsys Designware Integration is composed of
>>- A Synopsys DesignWare HDMI Controller IP
>> @@ -99,6 +102,8 @@ properties:
>>"#sound-dai-cells":
>> const: 0
>>
>> + sound-name-prefix: true
>> +
>> required:
>>- compatible
>>- reg
>>
>
> Fixes: 376bf52deef5 ("dt-bindings: display: amlogic, meson-dw-hdmi: convert
> to yaml")
>
> Acked-by: Neil Armstrong
>
Applied to drm-misc-fixes
Thanks,
Neil
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Fabio,
Thank you for the patch.
On Thu, Dec 30, 2021 at 10:39:29PM -0300, Fabio Estevam wrote:
> Use the atomic version of the enable/disable operations to continue the
> transition to the atomic API, started with the introduction of
> .atomic_get_input_bus_fmts(). This will be needed to access the mode
> from the atomic state.
>
> Based on Laurent's commit a6ea7d268a63("drm: bridge: ti-sn65dsi83:
> Switch to atomic operations").
>
> Tested on a imx6sx-udoo-neo board.
>
> Suggested-by: Marek Vasut
> Signed-off-by: Fabio Estevam
With the comment from 2/2 taken into account,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index b7ec6c374fbd..adaa985af87e 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1395,7 +1395,8 @@ static enum drm_mode_status
> tda998x_bridge_mode_valid(struct drm_bridge *bridge,
> return MODE_OK;
> }
>
> -static void tda998x_bridge_enable(struct drm_bridge *bridge)
> +static void tda998x_bridge_atomic_enable(struct drm_bridge *bridge,
> + struct drm_bridge_state
> *old_bridge_state)
> {
> struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
>
> @@ -1413,7 +1414,8 @@ static void tda998x_bridge_enable(struct drm_bridge
> *bridge)
> }
> }
>
> -static void tda998x_bridge_disable(struct drm_bridge *bridge)
> +static void tda998x_bridge_atomic_disable(struct drm_bridge *bridge,
> +struct drm_bridge_state
> *old_bridge_state)
> {
> struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
>
> @@ -1680,9 +1682,9 @@ static const struct drm_bridge_funcs
> tda998x_bridge_funcs = {
> .attach = tda998x_bridge_attach,
> .detach = tda998x_bridge_detach,
> .mode_valid = tda998x_bridge_mode_valid,
> - .disable = tda998x_bridge_disable,
> + .atomic_disable = tda998x_bridge_atomic_disable,
> .mode_set = tda998x_bridge_mode_set,
> - .enable = tda998x_bridge_enable,
> + .atomic_enable = tda998x_bridge_atomic_enable,
> };
>
> /* I2C driver functions */
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] drm/i2c/tda998x: Implement atomic_get_input_bus_fmts
Hi Fabio,
Thank you for the patch.
On Thu, Dec 30, 2021 at 10:39:30PM -0300, Fabio Estevam wrote:
> Implement the .atomic_get_input_bus_fmts callback to let the bridge
> indicate the pixel format it requires on the parallel bus to the LCDIF.
>
> Based on Marek's commit db8b7ca5b232 ("drm/bridge: ti-sn65dsi83: Replace
> connector format patching with atomic_get_input_bus_fmts").
>
> Tested on a imx6sx-udoo-neo board.
>
> Suggested-by: Marek Vasut
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index adaa985af87e..d987481e97c1 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1678,6 +1678,31 @@ static void tda998x_bridge_mode_set(struct drm_bridge
> *bridge,
> mutex_unlock(>audio_mutex);
> }
>
> +#define MAX_INPUT_SEL_FORMATS 1
> +
> +static u32 *
> +tda998x_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> +struct drm_bridge_state *bridge_state,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state,
> +u32 output_fmt,
> +unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts;
> +
> + *num_input_fmts = 0;
> +
> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> + GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> + *num_input_fmts = 1;
> +
> + return input_fmts;
> +}
> +
> static const struct drm_bridge_funcs tda998x_bridge_funcs = {
> .attach = tda998x_bridge_attach,
> .detach = tda998x_bridge_detach,
> @@ -1685,6 +1710,10 @@ static const struct drm_bridge_funcs
> tda998x_bridge_funcs = {
> .atomic_disable = tda998x_bridge_atomic_disable,
> .mode_set = tda998x_bridge_mode_set,
> .atomic_enable = tda998x_bridge_atomic_enable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
I think this should go to 1/2.
Reviewed-by: Laurent Pinchart
> + .atomic_get_input_bus_fmts = tda998x_atomic_get_input_bus_fmts,
> };
>
> /* I2C driver functions */
--
Regards,
Laurent Pinchart
[PATCH 3/3] drm/panel: nt35560: Support also ACX424AKM
Add some code and config to also support the ACX424AKM used in
some Sony (Ericsson) Mobile phones.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-novatek-nt35560.c | 72 ++-
1 file changed, 69 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35560.c
b/drivers/gpu/drm/panel/panel-novatek-nt35560.c
index 41dc278faf80..778542a956f7 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35560.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35560.c
@@ -10,12 +10,15 @@
* Author: Linus Walleij
* Based on code and know-how from Marcus Lorentzon
* Copyright (C) ST-Ericsson SA 2010
+ * Based on code and know-how from Johan Olson and Joakim Wesslen
+ * Copyright (C) Sony Ericsson Mobile Communications 2010
*/
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -41,7 +44,13 @@
*/
#define DISPLAY_SONY_ACX424AKP_ID4 0x8000
+struct nt35560_config {
+ const struct drm_display_mode *vid_mode;
+ const struct drm_display_mode *cmd_mode;
+};
+
struct nt35560 {
+ const struct nt35560_config *conf;
struct drm_panel panel;
struct device *dev;
struct regulator *supply;
@@ -86,6 +95,49 @@ static const struct drm_display_mode sony_acx424akp_cmd_mode
= {
.height_mm = 84,
};
+static const struct nt35560_config sony_acx424akp_data = {
+ .vid_mode = _acx424akp_vid_mode,
+ .cmd_mode = _acx424akp_cmd_mode,
+};
+
+static const struct drm_display_mode sony_acx424akm_vid_mode = {
+ .clock = 27234,
+ .hdisplay = 480,
+ .hsync_start = 480 + 15,
+ .hsync_end = 480 + 15 + 0,
+ .htotal = 480 + 15 + 0 + 15,
+ .vdisplay = 854,
+ .vsync_start = 854 + 14,
+ .vsync_end = 854 + 14 + 1,
+ .vtotal = 854 + 14 + 1 + 11,
+ .width_mm = 46,
+ .height_mm = 82,
+ .flags = DRM_MODE_FLAG_PVSYNC,
+};
+
+/*
+ * The timings are not very helpful as the display is used in
+ * command mode using the maximum HS frequency.
+ */
+static const struct drm_display_mode sony_acx424akm_cmd_mode = {
+ .clock = 35478,
+ .hdisplay = 480,
+ .hsync_start = 480 + 154,
+ .hsync_end = 480 + 154 + 16,
+ .htotal = 480 + 154 + 16 + 32,
+ .vdisplay = 854,
+ .vsync_start = 854 + 1,
+ .vsync_end = 854 + 1 + 1,
+ .vtotal = 854 + 1 + 1 + 1,
+ .width_mm = 46,
+ .height_mm = 82,
+};
+
+static const struct nt35560_config sony_acx424akm_data = {
+ .vid_mode = _acx424akm_vid_mode,
+ .cmd_mode = _acx424akm_cmd_mode,
+};
+
static inline struct nt35560 *panel_to_nt35560(struct drm_panel *panel)
{
return container_of(panel, struct nt35560, panel);
@@ -369,14 +421,15 @@ static int nt35560_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
struct nt35560 *nt = panel_to_nt35560(panel);
+ const struct nt35560_config *conf = nt->conf;
struct drm_display_mode *mode;
if (nt->video_mode)
mode = drm_mode_duplicate(connector->dev,
- _acx424akp_vid_mode);
+ conf->vid_mode);
else
mode = drm_mode_duplicate(connector->dev,
- _acx424akp_cmd_mode);
+ conf->cmd_mode);
if (!mode) {
dev_err(panel->dev, "bad mode or failed to add mode\n");
return -EINVAL;
@@ -413,6 +466,12 @@ static int nt35560_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, nt);
nt->dev = dev;
+ nt->conf = of_device_get_match_data(dev);
+ if (!nt->conf) {
+ dev_err(dev, "missing device configuration\n");
+ return -ENODEV;
+ }
+
dsi->lanes = 2;
dsi->format = MIPI_DSI_FMT_RGB888;
/*
@@ -475,7 +534,14 @@ static int nt35560_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id nt35560_of_match[] = {
- { .compatible = "sony,acx424akp" },
+ {
+ .compatible = "sony,acx424akp",
+ .data = _acx424akp_data,
+ },
+ {
+ .compatible = "sony,acx424akm",
+ .data = _acx424akm_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, nt35560_of_match);
--
2.31.1
[PATCH 2/3] drm/panel: nt35560: Support more panel IDs
These IDs were found in the wild in a Sony Xperia vendor tree.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-novatek-nt35560.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35560.c
b/drivers/gpu/drm/panel/panel-novatek-nt35560.c
index 620876225384..41dc278faf80 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35560.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35560.c
@@ -32,13 +32,14 @@
/*
* Sony seems to use vendor ID 0x81
*/
-#define DISPLAY_SONY_ACX424AKP_ID1 0x811b
+#define DISPLAY_SONY_ACX424AKP_ID1 0x8103
#define DISPLAY_SONY_ACX424AKP_ID2 0x811a
+#define DISPLAY_SONY_ACX424AKP_ID3 0x811b
/*
* The third ID looks like a bug, vendor IDs begin at 0x80
* and panel 00 ... seems like default values.
*/
-#define DISPLAY_SONY_ACX424AKP_ID3 0x8000
+#define DISPLAY_SONY_ACX424AKP_ID4 0x8000
struct nt35560 {
struct drm_panel panel;
@@ -225,6 +226,7 @@ static int nt35560_read_id(struct nt35560 *nt)
case DISPLAY_SONY_ACX424AKP_ID1:
case DISPLAY_SONY_ACX424AKP_ID2:
case DISPLAY_SONY_ACX424AKP_ID3:
+ case DISPLAY_SONY_ACX424AKP_ID4:
dev_info(nt->dev, "MTP vendor: %02x, version: %02x, panel:
%02x\n",
vendor, version, panel);
break;
--
2.31.1
[PATCH 1/3] drm/panel: Rename Sony ACX424 to Novatek NT35560
A code drop from Sony Mobile reveals that the ACX424 panels are
built around the Novatek NT35560 panel controllers so just bite
the bullet and rename the driver and all basic symbols so that
we can modify this driver to cover any other panels also using
the Novatek NT35560 display controller.
Signed-off-by: Linus Walleij
---
MAINTAINERS | 13 +-
drivers/gpu/drm/panel/Kconfig | 23 +-
drivers/gpu/drm/panel/Makefile| 2 +-
...ny-acx424akp.c => panel-novatek-nt35560.c} | 215 +-
4 files changed, 129 insertions(+), 124 deletions(-)
rename drivers/gpu/drm/panel/{panel-sony-acx424akp.c =>
panel-novatek-nt35560.c} (57%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..631e68ae923a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6054,6 +6054,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
+DRM DRIVER FOR NOVATEK NT35560 PANELS
+M: Linus Walleij
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
+F: drivers/gpu/drm/panel/panel-novatek-nt35560.c
+
DRM DRIVER FOR NOVATEK NT36672A PANELS
M: Sumit Semwal
S: Maintained
@@ -6171,12 +6178,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
F: drivers/gpu/drm/tiny/st7735r.c
-DRM DRIVER FOR SONY ACX424AKP PANELS
-M: Linus Walleij
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/panel/panel-sony-acx424akp.c
-
DRM DRIVER FOR ST-ERICSSON MCDE
M: Linus Walleij
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index cfc8d644cedf..f6b54fd41d85 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -272,6 +272,18 @@ config DRM_PANEL_NOVATEK_NT35510
around the Novatek NT35510 display controller, such as some
Hydis panels.
+config DRM_PANEL_NOVATEK_NT35560
+ tristate "Novatek NT35560 DSI command mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable the Novatek NT35560 display
+ controller. This panel supports DSI in both command and video
+ mode. This supports several panels such as Sony ACX424AKM and
+ ACX424AKP.
+
config DRM_PANEL_NOVATEK_NT36672A
tristate "Novatek NT36672A DSI panel"
depends on OF
@@ -561,17 +573,6 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
-config DRM_PANEL_SONY_ACX424AKP
- tristate "Sony ACX424AKP DSI command mode panel"
- depends on OF
- depends on DRM_MIPI_DSI
- depends on BACKLIGHT_CLASS_DEVICE
- select VIDEOMODE_HELPERS
- help
- Say Y here if you want to enable the Sony ACX424 display
- panel. This panel supports DSI in both command and video
- mode.
-
config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index bca4cc1f2715..540e303a90c5 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
@@ -57,7 +58,6 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS060T1SX01) +=
panel-sharp-ls060t1sx01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
-obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
b/drivers/gpu/drm/panel/panel-novatek-nt35560.c
similarity index 57%
rename from drivers/gpu/drm/panel/panel-sony-acx424akp.c
rename to drivers/gpu/drm/panel/panel-novatek-nt35560.c
index
Re: [PATCH 1/3] dt-bindings: display: meson-dw-hdmi: add missing sound-name-prefix property
On 23/12/2021 13:24, Alexander Stein wrote:
> This is used in meson-gx and meson-g12. Add the property to the binding.
> This fixes the dtschema warning:
> hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the
> regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Alexander Stein
> ---
> .../devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
> index cf5a208f2f10..343598c9f473 100644
> --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
> @@ -10,6 +10,9 @@ title: Amlogic specific extensions to the Synopsys
> Designware HDMI Controller
> maintainers:
>- Neil Armstrong
>
> +allOf:
> + - $ref: /schemas/sound/name-prefix.yaml#
> +
> description: |
>The Amlogic Meson Synopsys Designware Integration is composed of
>- A Synopsys DesignWare HDMI Controller IP
> @@ -99,6 +102,8 @@ properties:
>"#sound-dai-cells":
> const: 0
>
> + sound-name-prefix: true
> +
> required:
>- compatible
>- reg
>
Fixes: 376bf52deef5 ("dt-bindings: display: amlogic, meson-dw-hdmi: convert to
yaml")
Acked-by: Neil Armstrong
Re: [PATCH 1/2] drm/meson: osd_afbcd: Add an exit callback to struct meson_afbcd_ops
On 31/12/2021 00:55, Martin Blumenstingl wrote:
> Use this to simplify the driver shutdown. It will also come handy when
> fixing the error handling in meson_drv_bind_master().
>
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++--
> drivers/gpu/drm/meson/meson_osd_afbcd.c | 41 -
> drivers/gpu/drm/meson/meson_osd_afbcd.h | 1 +
> 3 files changed, 30 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 80f1d439841a..b919271a6e50 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -385,10 +385,8 @@ static void meson_drv_unbind(struct device *dev)
> free_irq(priv->vsync_irq, drm);
> drm_dev_put(drm);
>
> - if (priv->afbcd.ops) {
> - priv->afbcd.ops->reset(priv);
> - meson_rdma_free(priv);
> - }
> + if (priv->afbcd.ops)
> + priv->afbcd.ops->exit(priv);
> }
>
> static const struct component_master_ops meson_drv_master_ops = {
> diff --git a/drivers/gpu/drm/meson/meson_osd_afbcd.c
> b/drivers/gpu/drm/meson/meson_osd_afbcd.c
> index ffc6b584dbf8..0cdbe899402f 100644
> --- a/drivers/gpu/drm/meson/meson_osd_afbcd.c
> +++ b/drivers/gpu/drm/meson/meson_osd_afbcd.c
> @@ -79,11 +79,6 @@ static bool meson_gxm_afbcd_supported_fmt(u64 modifier,
> uint32_t format)
> return meson_gxm_afbcd_pixel_fmt(modifier, format) >= 0;
> }
>
> -static int meson_gxm_afbcd_init(struct meson_drm *priv)
> -{
> - return 0;
> -}
> -
> static int meson_gxm_afbcd_reset(struct meson_drm *priv)
> {
> writel_relaxed(VIU_SW_RESET_OSD1_AFBCD,
> @@ -93,6 +88,16 @@ static int meson_gxm_afbcd_reset(struct meson_drm *priv)
> return 0;
> }
>
> +static int meson_gxm_afbcd_init(struct meson_drm *priv)
> +{
> + return 0;
> +}
> +
> +static void meson_gxm_afbcd_exit(struct meson_drm *priv)
> +{
> + meson_gxm_afbcd_reset(priv);
> +}
> +
> static int meson_gxm_afbcd_enable(struct meson_drm *priv)
> {
> writel_relaxed(FIELD_PREP(OSD1_AFBCD_ID_FIFO_THRD, 0x40) |
> @@ -172,6 +177,7 @@ static int meson_gxm_afbcd_setup(struct meson_drm *priv)
>
> struct meson_afbcd_ops meson_afbcd_gxm_ops = {
> .init = meson_gxm_afbcd_init,
> + .exit = meson_gxm_afbcd_exit,
> .reset = meson_gxm_afbcd_reset,
> .enable = meson_gxm_afbcd_enable,
> .disable = meson_gxm_afbcd_disable,
> @@ -269,6 +275,18 @@ static bool meson_g12a_afbcd_supported_fmt(u64 modifier,
> uint32_t format)
> return meson_g12a_afbcd_pixel_fmt(modifier, format) >= 0;
> }
>
> +static int meson_g12a_afbcd_reset(struct meson_drm *priv)
> +{
> + meson_rdma_reset(priv);
> +
> + meson_rdma_writel_sync(priv, VIU_SW_RESET_G12A_AFBC_ARB |
> +VIU_SW_RESET_G12A_OSD1_AFBCD,
> +VIU_SW_RESET);
> + meson_rdma_writel_sync(priv, 0, VIU_SW_RESET);
> +
> + return 0;
> +}
> +
> static int meson_g12a_afbcd_init(struct meson_drm *priv)
> {
> int ret;
> @@ -286,16 +304,10 @@ static int meson_g12a_afbcd_init(struct meson_drm *priv)
> return 0;
> }
>
> -static int meson_g12a_afbcd_reset(struct meson_drm *priv)
> +static void meson_g12a_afbcd_exit(struct meson_drm *priv)
> {
> - meson_rdma_reset(priv);
> -
> - meson_rdma_writel_sync(priv, VIU_SW_RESET_G12A_AFBC_ARB |
> -VIU_SW_RESET_G12A_OSD1_AFBCD,
> -VIU_SW_RESET);
> - meson_rdma_writel_sync(priv, 0, VIU_SW_RESET);
> -
> - return 0;
> + meson_g12a_afbcd_reset(priv);
> + meson_rdma_free(priv);
> }
>
> static int meson_g12a_afbcd_enable(struct meson_drm *priv)
> @@ -380,6 +392,7 @@ static int meson_g12a_afbcd_setup(struct meson_drm *priv)
>
> struct meson_afbcd_ops meson_afbcd_g12a_ops = {
> .init = meson_g12a_afbcd_init,
> + .exit = meson_g12a_afbcd_exit,
> .reset = meson_g12a_afbcd_reset,
> .enable = meson_g12a_afbcd_enable,
> .disable = meson_g12a_afbcd_disable,
> diff --git a/drivers/gpu/drm/meson/meson_osd_afbcd.h
> b/drivers/gpu/drm/meson/meson_osd_afbcd.h
> index 5e5523304f42..e77ddeb6416f 100644
> --- a/drivers/gpu/drm/meson/meson_osd_afbcd.h
> +++ b/drivers/gpu/drm/meson/meson_osd_afbcd.h
> @@ -14,6 +14,7 @@
>
> struct meson_afbcd_ops {
> int (*init)(struct meson_drm *priv);
> + void (*exit)(struct meson_drm *priv);
> int (*reset)(struct meson_drm *priv);
> int (*enable)(struct meson_drm *priv);
> int (*disable)(struct meson_drm *priv);
>
Acked-by: Neil Armstrong
Thanks for fixing this
Neil
Re: [PATCH 2/2] drm/meson: Fix error handling when afbcd.ops->init fails
On 31/12/2021 00:55, Martin Blumenstingl wrote:
> When afbcd.ops->init fails we need to free the struct drm_device. Also
> all errors which come after afbcd.ops->init was successful need to exit
> the AFBCD, just like meson_drv_unbind() does.
>
> Fixes: d1b5e41e13a7e9 ("drm/meson: Add AFBCD module driver")
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/gpu/drm/meson/meson_drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index b919271a6e50..26aeaf0ab86e 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -302,42 +302,42 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
> if (priv->afbcd.ops) {
> ret = priv->afbcd.ops->init(priv);
> if (ret)
> - return ret;
> + goto free_drm;
> }
>
> /* Encoder Initialization */
>
> ret = meson_encoder_cvbs_init(priv);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> if (has_components) {
> ret = component_bind_all(drm->dev, drm);
> if (ret) {
> dev_err(drm->dev, "Couldn't bind all components\n");
> - goto free_drm;
> + goto exit_afbcd;
> }
> }
>
> ret = meson_encoder_hdmi_init(priv);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> ret = meson_plane_create(priv);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> ret = meson_overlay_create(priv);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> ret = meson_crtc_create(priv);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> ret = request_irq(priv->vsync_irq, meson_irq, 0, drm->driver->name,
> drm);
> if (ret)
> - goto free_drm;
> + goto exit_afbcd;
>
> drm_mode_config_reset(drm);
>
> @@ -355,6 +355,9 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
>
> uninstall_irq:
> free_irq(priv->vsync_irq, drm);
> +exit_afbcd:
> + if (priv->afbcd.ops)
> + priv->afbcd.ops->exit(priv);
> free_drm:
> drm_dev_put(drm);
>
>
Acked-by: Neil Armstrong
Thanks,
But this depends on patch 1, so I'll add the same Fixes tag on patch 1 and add
to drm-misc-next so it won't pollute -fixes but will still be eventually be
backported when landing on linus master.
Neil
Re: [PATCH 04/24] dma-buf: add dma_resv_get_singleton v2
Am 22.12.21 um 22:21 schrieb Daniel Vetter:
On Tue, Dec 07, 2021 at 01:33:51PM +0100, Christian König wrote:
Add a function to simplify getting a single fence for all the fences in
the dma_resv object.
v2: fix ref leak in error handling
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 52 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 480c305554a1..694716a3d66d 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
*/
#include
+#include
#include
#include
#include
@@ -657,6 +658,57 @@ int dma_resv_get_fences(struct dma_resv *obj, bool write,
}
EXPORT_SYMBOL_GPL(dma_resv_get_fences);
+/**
+ * dma_resv_get_singleton - Get a single fence for all the fences
+ * @obj: the reservation object
+ * @write: true if we should return all fences
+ * @fence: the resulting fence
+ *
+ * Get a single fence representing all the fences inside the resv object.
+ * Returns either 0 for success or -ENOMEM.
+ *
+ * Warning: This can't be used like this when adding the fence back to the resv
+ * object since that can lead to stack corruption when finalizing the
+ * dma_fence_array.
Uh I don't get this one? I thought the only problem with nested fences is
the signalling recursion, which we work around with the irq_work?
Nope, the main problem is finalizing the dma_fence_array.
E.g. imagine that you build up a chain of dma_fence_array objects like this:
a<-b<-c<-d<-e<-f.
With each one referencing the previous dma_fence_array and then you call
dma_fence_put() on the last one. That in turn will cause calling
dma_fence_put() on the previous one, which in turn will cause
dma_fence_put() one the one before the previous one etc
In other words you recurse because each dma_fence_array instance drops
the last reference of it's predecessor.
What we could do is to delegate dropping the reference to the containing
fences in a dma_fence_array as well, but that would require some changes
to the irq_work_run_list() function to be halve way efficient.
Also if there's really an issue with dma_fence_array fences, then that
warning should be on the dma_resv kerneldoc, not somewhere hidden like
this. And finally I really don't see what can go wrong, sure we'll end up
with the same fence once in the dma_resv_list and then once more in the
fence array. But they're all refcounted, so really shouldn't matter.
The code itself looks correct, but me not understanding what even goes
wrong here freaks me out a bit.
Yeah, IIRC we already discussed that with Jason in length as well.
Essentially what you can't do is to put a dma_fence_array into another
dma_fence_array without causing issues.
So I think we should maybe just add a WARN_ON() into
dma_fence_array_init() to make sure that this never happens.
Regards,
Christian.
I guess something to figure out next year, I kinda hoped I could squeeze a
review in before I disappear :-/
-Daniel
+ */
+int dma_resv_get_singleton(struct dma_resv *obj, bool write,
+ struct dma_fence **fence)
+{
+ struct dma_fence_array *array;
+ struct dma_fence **fences;
+ unsigned count;
+ int r;
+
+ r = dma_resv_get_fences(obj, write, , );
+if (r)
+ return r;
+
+ if (count == 0) {
+ *fence = NULL;
+ return 0;
+ }
+
+ if (count == 1) {
+ *fence = fences[0];
+ kfree(fences);
+ return 0;
+ }
+
+ array = dma_fence_array_create(count, fences,
+ dma_fence_context_alloc(1),
+ 1, false);
+ if (!array) {
+ while (count--)
+ dma_fence_put(fences[count]);
+ kfree(fences);
+ return -ENOMEM;
+ }
+
+ *fence = >base;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dma_resv_get_singleton);
+
/**
* dma_resv_wait_timeout - Wait on reservation's objects
* shared and/or exclusive fences.
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index fa2002939b19..cdfbbda6f600 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -438,6 +438,8 @@ void dma_resv_replace_fences(struct dma_resv *obj, uint64_t
context,
void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence);
int dma_resv_get_fences(struct dma_resv *obj, bool write,
unsigned int *num_fences, struct dma_fence ***fences);
+int dma_resv_get_singleton(struct dma_resv *obj, bool write,
+ struct dma_fence **fence);
int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
unsigned long timeout);
--
Re: [PATCH 01/24] dma-buf: add dma_resv_replace_fences
Am 22.12.21 um 22:05 schrieb Daniel Vetter:
On Tue, Dec 07, 2021 at 01:33:48PM +0100, Christian König wrote:
This function allows to replace fences from the shared fence list when
we can gurantee that the operation represented by the original fence has
finished or no accesses to the resources protected by the dma_resv
object any more when the new fence finishes.
Then use this function in the amdkfd code when BOs are unmapped from the
process.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c| 43
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 49 +++
include/linux/dma-resv.h | 2 +
3 files changed, 52 insertions(+), 42 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 4deea75c0b9c..a688dbded3d3 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -284,6 +284,49 @@ void dma_resv_add_shared_fence(struct dma_resv *obj,
struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_shared_fence);
+/**
+ * dma_resv_replace_fences - replace fences in the dma_resv obj
+ * @obj: the reservation object
+ * @context: the context of the fences to replace
+ * @replacement: the new fence to use instead
+ *
+ * Replace fences with a specified context with a new fence. Only valid if the
+ * operation represented by the original fences is completed or has no longer
+ * access to the resources protected by the dma_resv object when the new fence
+ * completes.
+ */
+void dma_resv_replace_fences(struct dma_resv *obj, uint64_t context,
+struct dma_fence *replacement)
+{
+ struct dma_resv_list *list;
+ struct dma_fence *old;
+ unsigned int i;
+
+ dma_resv_assert_held(obj);
+
+ write_seqcount_begin(>seq);
+
+ old = dma_resv_excl_fence(obj);
+ if (old->context == context) {
+ RCU_INIT_POINTER(obj->fence_excl, dma_fence_get(replacement));
+ dma_fence_put(old);
+ }
+
+ list = dma_resv_shared_list(obj);
+ for (i = 0; list && i < list->shared_count; ++i) {
+ old = rcu_dereference_protected(list->shared[i],
+ dma_resv_held(obj));
+ if (old->context != context)
+ continue;
+
+ rcu_assign_pointer(list->shared[i], dma_fence_get(replacement));
+ dma_fence_put(old);
Since the fences are all guaranteed to be from the same context, maybe we
should have a WARN_ON(__dma_fence_is_later()); here just to be safe?
First of all happy new year!
Then to answer your question, no :)
This here is the case where we replace an preemption fence with a VM
page table update fence. So both fences are not from the same context.
But since you ask that means that I somehow need to improve the
documentation.
Regards,
Christian.
With that added:
Reviewed-by: Daniel Vetter
+ }
+
+ write_seqcount_end(>seq);
+}
+EXPORT_SYMBOL(dma_resv_replace_fences);
+
/**
* dma_resv_add_excl_fence - Add an exclusive fence.
* @obj: the reservation object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 71acd577803e..b558ef0f8c4a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -236,53 +236,18 @@ void amdgpu_amdkfd_release_notify(struct amdgpu_bo *bo)
static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
struct amdgpu_amdkfd_fence *ef)
{
- struct dma_resv *resv = bo->tbo.base.resv;
- struct dma_resv_list *old, *new;
- unsigned int i, j, k;
+ struct dma_fence *replacement;
if (!ef)
return -EINVAL;
- old = dma_resv_shared_list(resv);
- if (!old)
- return 0;
-
- new = kmalloc(struct_size(new, shared, old->shared_max), GFP_KERNEL);
- if (!new)
- return -ENOMEM;
-
- /* Go through all the shared fences in the resevation object and sort
-* the interesting ones to the end of the list.
+ /* TODO: Instead of block before we should use the fence of the page
+* table update and TLB flush here directly.
*/
- for (i = 0, j = old->shared_count, k = 0; i < old->shared_count; ++i) {
- struct dma_fence *f;
-
- f = rcu_dereference_protected(old->shared[i],
- dma_resv_held(resv));
-
- if (f->context == ef->base.context)
- RCU_INIT_POINTER(new->shared[--j], f);
- else
- RCU_INIT_POINTER(new->shared[k++], f);
- }
- new->shared_max = old->shared_max;
- new->shared_count = k;
-
- /* Install the new fence list, seqcount provides the barriers */
-
Re: [PATCH v2] drm/bridge: sn65dsi83: Fix an error handling path in sn65dsi83_probe()
Applied to drm-misc-next
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436 --- Comment #14 from spassw...@web.de --- Created attachment 300212 --> https://bugzilla.kernel.org/attachment.cgi?id=300212=edit dmesg with linux-5.16-rc8 while ignoring adev->in_s0ix Simply ignoring the value of adev->in_s0ix and calling reset anyway does not work either: Jan 3 11:23:51 lisa kernel: [ 32.649142] amdgpu :08:00.0: amdgpu: amdgpu_device_suspend(...) = 0 Jan 3 11:23:51 lisa kernel: [ 32.649146] amdgpu :08:00.0: amdgpu: adev->in_s0ix = 1 Jan 3 11:23:51 lisa kernel: [ 32.649149] amdgpu :08:00.0: amdgpu: MODE2 reset Jan 3 11:23:51 lisa kernel: [ 37.404614] amdgpu :08:00.0: amdgpu: Mode2 reset failed! Jan 3 11:23:51 lisa kernel: [ 37.404616] PM: pci_pm_suspend(): amdgpu_pmops_suspend+0x0/0x60 [amdgpu] returns -62 Jan 3 11:23:51 lisa kernel: [ 37.404733] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -62 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] radeon: add a force flush to delay work when radeon suspend
Am 25.12.21 um 03:56 schrieb 周雪梅:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a corner case that radeon lockup work queue may not be
fully flushed,
and meanwhile the radeon_suspend_kms() function has called
pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
> Configuration and Message requests are the only TLPs accepted by a
Function in
> the D3hot state. All other received Requests must be handled as
Unsupported Requests,
> and all received Completions may optionally be handled as Unexpected
Completions.
Well first of all this is the completely wrong place for this. The flush
belongs into the fence code and not here.
Then I don't think that this is a good idea since it might cause deadlocks.
Christian.
This issue will happen in following logs:
1Unable to handle kernel paging request at virtual address
8800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [] ra = [] ps =
Tainted: G W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = t0 = fff08800e0008010 t1 = 0001
t2 = 8010 t3 = fff7e3c0 t4 = fff7e3c00258
t5 = t6 = 0001 t7 = fff7ef078000
s0 = fff7e3c016e8 s1 = fff7e3c0 s2 = fff7e3c00018
s3 = fff7e3c0 s4 = fff7fff59d80 s5 =
s6 = fff7ef07bd98
a0 = fff7e3c0 a1 = fff7e3c016e8 a2 = 0008
a3 = 0001 a4 = 8f5c28f5c28f5c29 a5 = 810f4338
t8 = 0275 t9 = 809b66f8 t10 = ff6769c5d964b800
t11= b886 pv = 811bea20 at =
gp = 81d89690 sp = aa814126
4Disabling lock debugging due to kernel taint
Trace:
[] si_dma_is_lockup+0x34/0xd0
[] radeon_fence_check_lockup+0xd0/0x290
[] process_one_work+0x280/0x550
[] worker_thread+0x70/0x7c0
[] worker_thread+0x130/0x7c0
[] kthread+0x200/0x210
[] worker_thread+0x0/0x7c0
[] kthread+0x14c/0x210
[] ret_from_kernel_thread+0x18/0x20
[] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<8821> 4821ed21
So force lockup work queue flush to fix this problem.
Reviewed-by: Su Weiqiang
Reviewed-by: Zhou Xuemei
Signed-off-by: Xu Chenjiao
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 59c8a6647ff2..cc1c07963116 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1625,6 +1625,9 @@ int radeon_suspend_kms(struct drm_device *dev,
bool suspend,
if (r) {
/* delay GPU reset to resume */
radeon_fence_driver_force_completion(rdev, i);
+} else {
+/* finish executing delayed work */
+flush_delayed_work(>fence_drv[i].lockup_work);
}
}
--
2.17.1
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #13 from spassw...@web.de ---
I added a some dev_info calls:
static int amdgpu_pmops_suspend(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
int r;
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
adev->in_s3 = true;
r = amdgpu_device_suspend(drm_dev, true);
dev_info(adev->dev, "amdgpu_device_suspend(...) = %d\n", r);
adev->in_s3 = false;
if (r)
return r;
dev_info(adev->dev, "adev->in_s0ix = %d\n", adev->in_s0ix);
if (!adev->in_s0ix)
r = amdgpu_asic_reset(adev);
return r;
}
which gives
Jan 3 11:13:40 lisa kernel: [ 38.792335] amdgpu :08:00.0: amdgpu:
amdgpu_device_suspend(...) = 0
Jan 3 11:13:40 lisa kernel: [ 38.792341] amdgpu :08:00.0: amdgpu:
adev->in_s0ix = 1
So the gpu is not actually reset ...
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV
Please don't. This patch is vital to the cleanup of the reset procedure. If SRIOV doesn't work with that we need to change SRIOV and not the driver. Christian. Am 30.12.21 um 19:45 schrieb Andrey Grodzovsky: Sure, I guess i can drop this patch then. Andrey On 2021-12-24 4:57 a.m., JingWen Chen wrote: I do agree with shaoyun, if the host find the gpu engine hangs first, and do the flr, guest side thread may not know this and still try to access HW(e.g. kfd is using a lot of amdgpu_in_reset and reset_sem to identify the reset status). And this may lead to very bad result. On 2021/12/24 下午4:58, Deng, Emily wrote: These patches look good to me. JingWen will pull these patches and do some basic TDR test on sriov environment, and give feedback. Best wishes Emily Deng -Original Message- From: Liu, Monk Sent: Thursday, December 23, 2021 6:14 PM To: Koenig, Christian ; Grodzovsky, Andrey ; dri-devel@lists.freedesktop.org; amd- g...@lists.freedesktop.org; Chen, Horace ; Chen, JingWen ; Deng, Emily Cc: dan...@ffwll.ch Subject: RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV [AMD Official Use Only] @Chen, Horace @Chen, JingWen @Deng, Emily Please take a review on Andrey's patch Thanks --- Monk Liu | Cloud GPU & Virtualization Solution | AMD --- we are hiring software manager for CVS core team --- -Original Message- From: Koenig, Christian Sent: Thursday, December 23, 2021 4:42 PM To: Grodzovsky, Andrey ; dri- de...@lists.freedesktop.org; amd-...@lists.freedesktop.org Cc: dan...@ffwll.ch; Liu, Monk ; Chen, Horace Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky: Since now flr work is serialized against GPU resets there is no need for this. Signed-off-by: Andrey Grodzovsky Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 --- drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 --- 2 files changed, 22 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c index 487cd654b69e..7d59a66e3988 100644 --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c @@ -248,15 +248,7 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct *work) struct amdgpu_device *adev = container_of(virt, struct amdgpu_device, virt); int timeout = AI_MAILBOX_POLL_FLR_TIMEDOUT; - /* block amdgpu_gpu_recover till msg FLR COMPLETE received, - * otherwise the mailbox msg will be ruined/reseted by - * the VF FLR. - */ - if (!down_write_trylock(>reset_sem)) - return; - amdgpu_virt_fini_data_exchange(adev); - atomic_set(>in_gpu_reset, 1); xgpu_ai_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0); @@ -269,9 +261,6 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct *work) } while (timeout > 1); flr_done: - atomic_set(>in_gpu_reset, 0); - up_write(>reset_sem); - /* Trigger recovery for world switch failure if no TDR */ if (amdgpu_device_should_recover_gpu(adev) && (!amdgpu_device_has_job_running(adev) || diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c index e3869067a31d..f82c066c8e8d 100644 --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c @@ -277,15 +277,7 @@ static void xgpu_nv_mailbox_flr_work(struct work_struct *work) struct amdgpu_device *adev = container_of(virt, struct amdgpu_device, virt); int timeout = NV_MAILBOX_POLL_FLR_TIMEDOUT; - /* block amdgpu_gpu_recover till msg FLR COMPLETE received, - * otherwise the mailbox msg will be ruined/reseted by - * the VF FLR. - */ - if (!down_write_trylock(>reset_sem)) - return; - amdgpu_virt_fini_data_exchange(adev); - atomic_set(>in_gpu_reset, 1); xgpu_nv_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0); @@ -298,9 +290,6 @@ static void xgpu_nv_mailbox_flr_work(struct work_struct *work) } while (timeout > 1); flr_done: - atomic_set(>in_gpu_reset, 0); - up_write(>reset_sem); - /* Trigger recovery for world switch failure if no TDR */ if (amdgpu_device_should_recover_gpu(adev) && (!amdgpu_device_has_job_running(adev) ||
[PATCH] drm/panel: Extend ACX424AKP bindings to ACX424AKM
The panel ACX424AKP seems to only be used in prototypes, whereas real products use the 10 pixels shorter ACX424AKM. Extend the ACX424AKP bindings to also cover the ACX424AKM. The ACX424AKM was used in a few different mobile phones from Sony Mobile. Cc: devicet...@vger.kernel.org Cc: phone-de...@vger.kernel.org Signed-off-by: Linus Walleij --- .../bindings/display/panel/sony,acx424akp.yaml| 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml index 78d060097052..059cc6dbcfca 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml @@ -4,7 +4,12 @@ $id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Sony ACX424AKP 4" 480x864 AMOLED panel +title: Sony ACX424AKP/ACX424AKM 4" 480x864/480x854 AMOLED panel + +description: The Sony ACX424AKP and ACX424AKM are panels built around + the Novatek NT35560 display controller. The only difference is that + the AKM is configured to use 10 pixels less in the Y axis than the + AKP. maintainers: - Linus Walleij @@ -14,7 +19,9 @@ allOf: properties: compatible: -const: sony,acx424akp +enum: + - sony,acx424akp + - sony,acx424akm reg: true reset-gpios: true vddi-supply: -- 2.31.1
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436
spassw...@web.de changed:
What|Removed |Added
Kernel Version|5.16-rc{1-7}|5.16-rc{1-8}
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #12 from spassw...@web.de ---
Suspend works again if I ignore hpd_state in rn_update_clocks.
// if (display_count == 0 && !hpd_state) {
if (display_count == 0) {
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 215436] admgpu: suspend and resuming from suspend don't work
https://bugzilla.kernel.org/show_bug.cgi?id=215436 --- Comment #11 from spassw...@web.de --- Created attachment 300211 --> https://bugzilla.kernel.org/attachment.cgi?id=300211=edit dmesg with linux-5.16-rc8 With linux-5.16-rc8, suspend does still not work properly (fan stays on). Resume seemed to work at first, but on the next suspend/resume test I get the usual hang. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v10 19/22] drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support
Hi, Nancy:
On Wed, 2021-12-08 at 10:44 +0800, Nancy.Lin wrote:
> MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
> The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
> only one drm driver register as the drm device.
> Each drm driver binds its own component. The last bind drm driver
> allocates and registers the drm device to drm core.
> Each crtc path is created with the corresponding drm driver data.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 24 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 300 ++--
>
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 10 +-
> 4 files changed, 246 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index d661edf7e0fe..fe2871aca859 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -847,21 +847,28 @@ static int mtk_drm_crtc_init_comp_planes(struct
> drm_device *drm_dev,
> }
>
> int mtk_drm_crtc_create(struct drm_device *drm_dev,
> - const enum mtk_ddp_comp_id *path, unsigned int
> path_len)
> + const enum mtk_ddp_comp_id *path, unsigned int
> path_len,
> + int priv_data_index)
> {
> struct mtk_drm_private *priv = drm_dev->dev_private;
> struct device *dev = drm_dev->dev;
> struct mtk_drm_crtc *mtk_crtc;
> unsigned int num_comp_planes = 0;
> - int pipe = priv->num_pipes;
> int ret;
> int i;
> bool has_ctm = false;
> uint gamma_lut_size = 0;
> + struct drm_crtc *tmp;
> + int crtc_i = 0;
>
> if (!path)
> return 0;
>
> + priv = priv->all_drm_private[priv_data_index];
> +
> + drm_for_each_crtc(tmp, drm_dev)
> + crtc_i++;
> +
> for (i = 0; i < path_len; i++) {
> enum mtk_ddp_comp_id comp_id = path[i];
> struct device_node *node;
> @@ -873,7 +880,7 @@ int mtk_drm_crtc_create(struct drm_device
> *drm_dev,
> if (!node) {
> dev_info(dev,
>"Not creating crtc %d because
> component %d is disabled or missing\n",
> - pipe, comp_id);
> + crtc_i, comp_id);
> return 0;
> }
>
> @@ -926,29 +933,28 @@ int mtk_drm_crtc_create(struct drm_device
> *drm_dev,
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> ret = mtk_drm_crtc_init_comp_planes(drm_dev, mtk_crtc,
> i,
> - pipe);
> + crtc_i);
> if (ret)
> return ret;
> }
>
> - ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, pipe);
> + ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, crtc_i);
> if (ret < 0)
> return ret;
>
> if (gamma_lut_size)
> drm_mode_crtc_set_gamma_size(_crtc->base,
> gamma_lut_size);
> drm_crtc_enable_color_mgmt(_crtc->base, 0, has_ctm,
> gamma_lut_size);
> - priv->num_pipes++;
> mutex_init(_crtc->hw_lock);
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + i = (priv->data->mbox_index) ? priv->data-
> >mbox_index[drm_crtc_index(_crtc->base)] : 0;
> mtk_crtc->cmdq_client.client.dev = mtk_crtc->mmsys_dev;
> mtk_crtc->cmdq_client.client.tx_block = false;
> mtk_crtc->cmdq_client.client.knows_txdone = true;
> mtk_crtc->cmdq_client.client.rx_callback = ddp_cmdq_cb;
> mtk_crtc->cmdq_client.chan =
> - mbox_request_channel(_crtc-
> >cmdq_client.client,
> - drm_crtc_index(_crtc-
> >base));
> + mbox_request_channel(_crtc-
> >cmdq_client.client, i);
I really do not understand how does i work. Could you give an example
of the i value for mt8173 crtc0, mt8173 crtc1, and all mt8195 crtcs.
> if (IS_ERR(mtk_crtc->cmdq_client.chan)) {
> dev_dbg(dev, "mtk_crtc %d failed to create mailbox
> client, writing register by CPU now\n",
> drm_crtc_index(_crtc->base));
> @@ -958,7 +964,7 @@ int mtk_drm_crtc_create(struct drm_device
> *drm_dev,
> if (mtk_crtc->cmdq_client.chan) {
> ret = of_property_read_u32_index(priv->mutex_node,
>"mediatek,gce-events",
> - drm_crtc_index(_cr
> tc->base),
> + i,
>_crtc-
> >cmdq_event);
> if (ret) {
> dev_dbg(dev, "mtk_crtc %d failed to get
> mediatek,gce-events property\n",
>
[snip]
>
> static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data
> = {
>
回复: Re: [PATCH] gpu/drm/radeon:Fix null pointer risk
Then the judgment in line 944 is needed. Are the possibilities of these two positions consistent.Why keep this judgment？Regards,Wen Zhiwei.
主 题：Re: [PATCH] gpu/drm/radeon:Fix null pointer risk
日 期：2021-12-31 00:36
发件人：Christian König
收件人：Wen zhiweialexander.deuc...@amd.comxinhui.pan@amd.comairlied@linux.iedan...@ffwll.ch
Am 28.12.21 um 08:31 schrieb Wen Zhiwei:> If the null pointer is not judged in advance,> there is a risk that the pointer will cross> the boundaryAs far as I can see that case is impossible, why do you want to add a check for it?Regards,Christian.>> Signed-off-by: Wen Zhiwei> ---> drivers/gpu/drm/radeon/radeon_vm.c | 2 +-> 1 file changed, 1 insertion(+), 1 deletion(-)>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c> index bb53016f3138..d3d342041adf 100644> --- a/drivers/gpu/drm/radeon/radeon_vm.c> +++ b/drivers/gpu/drm/radeon/radeon_vm.c> @@ -951,7 +951,7 @@ int radeon_vm_bo_update(struct radeon_device *rdev,> > if (mem->mem_type == TTM_PL_TT) {> bo_va->flags |= RADEON_VM_PAGE_SYSTEM;> - if (!(bo_va->bo->flags & (RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC)))> + if (bo_va->bo && !(bo_va->bo->flags & (RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC)))> bo_va->flags |= RADEON_VM_PAGE_SNOOPED;> > } else {
Re: [PATCH v3] drm/mediatek: Fix unused-but-set variable warning
> I'm still not happy with the commit subject, I think it is misleading. Clang
> only helped to find the bug, but the we are fixing something else, that's not
> just a clang warning. But I don't want to nit-pick too much so:
>
> Reviewed-by: Matthias Brugger
thanks. I think you are right.
I will change the subject to "drm/mediatek: Fix mtk_cec_mask()", remove the
clang part and submit patch v4.
e.g,
"""
drm/mediatek: Fix mtk_cec_mask()
In current implementation, mtk_cec_mask() writes val into target register
and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
should read a register, clean only mask bits, and update (val | mask) bits
to the register.
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
"""
[PATCH v4] drm/mediatek: Fix mtk_cec_mask()
In current implementation, mtk_cec_mask() writes val into target register
and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
should read a register, clean only mask bits, and update (val | mask) bits
to the register.
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Cc: Zhiqiang Lin
Cc: CK Hu
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v1:
add Fixes tag
Change since v2:
add explanation of mtk_cec_mask()
Change since v3:
change misleading subject and modify the commit message since this is a bug fix
patch
---
drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c
b/drivers/gpu/drm/mediatek/mtk_cec.c
index e9cef5c0c8f7..cdfa648910b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int
offset,
u32 tmp = readl(cec->regs + offset) & ~mask;
tmp |= val & mask;
- writel(val, cec->regs + offset);
+ writel(tmp, cec->regs + offset);
}
void mtk_cec_set_hpd_event(struct device *dev,
--
2.18.0
