Re: [pull] amdgpu, amdkfd drm-fixes-6.9

[Dave Airlie]

On Thu, 9 May 2024 at 09:00, Alex Deucher  wrote:
>
> Hi Dave, Sima,
>
> Fixes for 6.9.
>
> The following changes since commit dd5a440a31fae6e459c0d627162825505361:
>
>   Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.9-2024-05-08
>
> for you to fetch changes up to 3d09248a06d285397e7b873415505d299202e1c6:
>
>   drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible (2024-05-08 18:47:52 
> -0400)
>
> 
> amd-drm-fixes-6.9-2024-05-08:
>
> amdgpu:
> - DCN 3.5 fix
> - MST DSC fixes
> - S0i3 fix
> - S4 fix
> - Warning fix
> - HDP MMIO mapping fix
> - Fix a regression in visible vram handling
>
> amdkfd:
> - Spatial partition fix
>
> 
> Agustin Gutierrez (2):
>   drm/amd/display: Fix DSC-re-computing
>   drm/amd/display: MST DSC check for older devices
>
> Alex Deucher (1):
>   drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
>
> Lijo Lazar (2):
>   Revert "drm/amdkfd: Add partition id field to location_id"
>   drm/amd/amdxcp: Fix warnings

Hey, this has a "fixes:" for a patch that doesn't exist.

Can we fix that up? I can pull this but I'd prefer it to get fixed if
you have a chance.

Dave.

Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

[Dave Airlie]

On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann  wrote:
>
> On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 03:11, Samuel Holland  
> > wrote:
> >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> >> > Samuel Holland  writes:
> >>
> >> >> The short-term fix would be to drop the `select 
> >> >> ARCH_HAS_KERNEL_FPU_SUPPORT` for
> >> >> 32-bit arm until we can provide these runtime library functions.
> >> >
> >> > Does this mean that patch 2 in this series:
> >> >
> >> > [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
> >> >
> >> > will be dropped?
> >>
> >> No, because later patches in the series (3, 6) depend on the definition of
> >> CC_FLAGS_FPU from that patch. I will need to send a fixup patch unless I 
> >> can
> >> find a GPL-2 compatible implementation of the runtime library functions.
> >>
> >
> > Is there really a point to doing that? Do 32-bit ARM systems even have
> > enough address space to the map the BARs of the AMD GPUs that need
> > this support?
> >
> > Given that this was not enabled before, I don't think the upshot of
> > this series should be that we enable support for something on 32-bit
> > ARM that may cause headaches down the road without any benefit.
> >
> > So I'd prefer a fixup patch that opts ARM out of this over adding
> > support code for 64-bit conversions.
>
> I have not found any dts file for a 32-bit platform with support
> for a 64-bit prefetchable BAR, and there are very few that even
> have a pcie slot (as opposed on on-board devices) you could
> plug a card into.
>
> That said, I also don't think we should encourage the use of
> floating-point code in random device drivers. There is really
> no excuse for the amdgpu driver to use floating point math
> here, and we should get AMD to fix their driver instead.

That would be nice, but it won't happen, there are many reasons for
that code to exist like it does, unless someone can write an automated
converter to fixed point and validate it produces the same results for
a long series of input values, it isn't really something that will get
"fixed".

AMD's hardware team produces the calculations, and will only look into
hardware problems in that area if the driver is using the calculations
they produce and validate.

If you've looked at the calculation complexity you'd understand this
isn't a trivial use of float-point for no reason.

Dave.

Re: [pull] amdgpu, amdkfd drm-fixes-6.8

[Dave Airlie]

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_dpia_bw.c:548:24:
error: arithmetic between different enumeration types ('const enum
dc_link_rate' and 'const enum dc_lane_count')
[-Werror,-Wenum-enum-conversion]
link_cap->link_rate * link_cap->lane_count *
LINK_RATE_REF_FREQ_IN_KHZ * 8;
~~~ ^ 
1 error generated.

clang said no.

Dave.

On Sat, 13 Jan 2024 at 03:57, Alex Deucher  wrote:
>
> Hi Dave, Sima,
>
> Fixes for 6.8.
>
> The following changes since commit e54478fbdad20f2c58d0a4f99d01299ed8e7fe9c:
>
>   Merge tag 'amd-drm-next-6.8-2024-01-05' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (2024-01-09 09:07:50 
> +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.8-2024-01-12
>
> for you to fetch changes up to 3b23fd46e2af68b47902caa3f88d60f73c5d85f7:
>
>   drm/amd/pm: Fix smuv13.0.6 current clock reporting (2024-01-11 23:33:37 
> -0500)
>
> 
> amd-drm-fixes-6.8-2024-01-12:
>
> amdgpu:
> - SubVP fixes
> - VRR fixes
> - USB4 fixes
> - DCN 3.5 fixes
> - GFX11 harvesting fix
> - RAS fixes
> - Misc small fixes
> - KFD dma-buf import fixes
> - Power reporting fixes
> - ATHUB 3.3 fix
> - SR-IOV fix
> - Add missing fw release for fiji
> - GFX 11.5 fix
> - Debugging module parameter fix
> - SMU 13.0.6 fixes
>
> amdkfd:
> - Fix lockdep warnings
> - Fix sparse __rcu warnings
> - Bump interface version so userspace knows that the kernel supports dma-bufs 
> exported from KFD
>   Most of the fixes for this went into 6.7, but the last fix is in this PR
> - HMM fix
> - SVM fix
>
> 
> Alex Deucher (4):
>   drm/amdgpu: fix avg vs input power reporting on smu7
>   drm/amdgpu: fall back to INPUT power for AVG power via INFO IOCTL
>   drm/amdgpu/pm: clarify debugfs pm output
>   drm/amdgpu: drop exp hw support check for GC 9.4.3
>
> Aric Cyr (1):
>   drm/amd/display: 3.2.266
>
> Candice Li (2):
>   drm/amdgpu: Drop unnecessary sentences about CE and deferred error.
>   drm/amdgpu: Support poison error injection via ras_ctrl debugfs
>
> Charlene Liu (1):
>   drm/amd/display: Update z8 latency
>
> Dafna Hirschfeld (1):
>   drm/amdkfd: fixes for HMM mem allocation
>
> Daniel Miess (1):
>   Revert "drm/amd/display: Fix conversions between bytes and KB"
>
> Felix Kuehling (4):
>   drm/amdkfd: Fix lock dependency warning
>   drm/amdkfd: Fix sparse __rcu annotation warnings
>   drm/amdgpu: Auto-validate DMABuf imports in compute VMs
>   drm/amdkfd: Bump KFD ioctl version
>
> George Shen (1):
>   drm/amd/display: Disconnect phantom pipe OPP from OPTC being disabled
>
> Hawking Zhang (1):
>   drm/amdgpu: Packed socket_id to ras feature mask
>
> Ivan Lipski (1):
>   Revert "drm/amd/display: fix bandwidth validation failure on DCN 2.1"
>
> James Zhu (1):
>   drm/amdgpu: make a correction on comment
>
> Le Ma (3):
>   Revert "drm/amdgpu: add param to specify fw bo location for front-door 
> loading"
>   drm/amdgpu: add debug flag to place fw bo on vram for frontdoor loading
>   drm/amdgpu: move debug options init prior to amdgpu device init
>
> Lijo Lazar (2):
>   drm/amd/pm: Add error log for smu v13.0.6 reset
>   drm/amd/pm: Fix smuv13.0.6 current clock reporting
>
> Likun Gao (1):
>   drm/amdgpu: correct the cu count for gfx v11
>
> Martin Leung (2):
>   drm/amd/display: revert "for FPO & SubVP/DRR config program vmin/max"
>   drm/amd/display: revert "Optimize VRR updates to only necessary ones"
>
> Martin Tsai (1):
>   drm/amd/display: To adjust dprefclk by down spread percentage
>
> Meenakshikumar Somasundaram (1):
>   drm/amd/display: Dpia hpd status not in sync after S4
>
> Melissa Wen (1):
>   drm/amd/display: cleanup inconsistent indenting in amdgpu_dm_color
>
> Peichen Huang (1):
>   drm/amd/display: Request usb4 bw for mst streams
>
> Philip Yang (1):
>   drm/amdkfd: Fix lock dependency warning with srcu
>
> Srinivasan Shanmugam (6):
>   drm/amd/powerplay: Fix kzalloc parameter 'ATOM_Tonga_PPM_Table' in 
> 'get_platform_power_management_table()'
>   drm/amdgpu: Fix with right return code '-EIO' in 
> 'amdgpu_gmc_vram_checking()'
>   drm/amdgpu: Fix unsigned comparison with less than zero in 
> vpe_u1_8_from_fraction()
>   drm/amdgpu: Release 'adev->pm.fw' before return in 
> 'amdgpu_device_need_post()'
>   drm/amd/display: Fix variable deferencing before NULL check in 
> edp_setup_replay()
>   drm/amdkfd: Fix 'node' NULL check in 'svm_range_get_range_boundaries()'
>
> Victor Lu (1):
>   drm/amdgpu: Do not program VM_L2_CNTL under SRIOV
>
> Yifan Zhang (3):
>   drm/amdgpu: update headers for nbio v7.11
>   

Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

[Dave Airlie]

On Tue, 28 Nov 2023 at 23:07, Christian König  wrote:
>
> Am 28.11.23 um 13:50 schrieb Weixi Zhu:
> > The problem:
> >
> > Accelerator driver developers are forced to reinvent external MM subsystems
> > case by case, because Linux core MM only considers host memory resources.
> > These reinvented MM subsystems have similar orders of magnitude of LoC as
> > Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and Huawei NPU has
> > 30K. Meanwhile, more and more vendors are implementing their own
> > accelerators, e.g. Microsoft's Maia 100. At the same time,
> > application-level developers suffer from poor programmability -- they must
> > consider parallel address spaces and be careful about the limited device
> > DRAM capacity. This can be alleviated if a malloc()-ed virtual address can
> > be shared by the accelerator, or the abundant host DRAM can further
> > transparently backup the device local memory.
> >
> > These external MM systems share similar mechanisms except for the
> > hardware-dependent part, so reinventing them is effectively introducing
> > redundant code (14K~70K for each case). Such developing/maintaining is not
> > cheap. Furthermore, to share a malloc()-ed virtual address, device drivers
> > need to deeply interact with Linux MM via low-level MM APIs, e.g. MMU
> > notifiers/HMM. This raises the bar for driver development, since developers
> > must understand how Linux MM works. Further, it creates code maintenance
> > problems -- any changes to Linux MM potentially require coordinated changes
> > to accelerator drivers using low-level MM APIs.
> >
> > Putting a cache-coherent bus between host and device will not make these
> > external MM subsystems disappear. For example, a throughput-oriented
> > accelerator will not tolerate executing heavy memory access workload with
> > a host MMU/IOMMU via a remote bus. Therefore, devices will still have
> > their own MMU and pick a simpler page table format for lower address
> > translation overhead, requiring external MM subsystems.
> >
> > 
> >
> > What GMEM (Generalized Memory Management [1]) does:
> >
> > GMEM extends Linux MM to share its machine-independent MM code. Only
> > high-level interface is provided for device drivers. This prevents
> > accelerator drivers from reinventing the wheel, but relies on drivers to
> > implement their hardware-dependent functions declared by GMEM. GMEM's key
> > interface include gm_dev_create(), gm_as_create(), gm_as_attach() and
> > gm_dev_register_physmem(). Here briefly describe how a device driver
> > utilizes them:
> > 1. At boot time, call gm_dev_create() and registers the implementation of
> > hardware-dependent functions as declared in struct gm_mmu.
> >   - If the device has local DRAM, call gm_dev_register_physmem() to
> > register available physical addresses.
> > 2. When a device context is initialized (e.g. triggered by ioctl), check if
> > the current CPU process has been attached to a gmem address space
> > (struct gm_as). If not, call gm_as_create() and point current->mm->gm_as
> > to it.
> > 3. Call gm_as_attach() to attach the device context to a gmem address space.
> > 4. Invoke gm_dev_fault() to resolve a page fault or prepare data before
> > device computation happens.
> >
> > GMEM has changed the following assumptions in Linux MM:
> >1. An mm_struct not only handle a single CPU context, but may also handle
> >   external memory contexts encapsulated as gm_context listed in
> >   mm->gm_as. An external memory context can include a few or all of the
> >   following parts: an external MMU (that requires TLB invalidation), an
> >   external page table (that requires PTE manipulation) and external DRAM
> >   (that requires physical memory management).
>
> Well that is pretty much exactly what AMD has already proposed with KFD
> and was rejected for rather good reasons.

> >
> > MMU functions
> > The MMU functions peer_map() and peer_unmap() overlap other functions,
> > leaving a question if the MMU functions should be decoupled as more basic
> > operations. Decoupling them could potentially prevent device drivers
> > coalescing these basic steps within a single host-device communication
> > operation, while coupling them makes it more difficult for device drivers
> > to utilize GMEM interface.
>
> Well to be honest all of this sounds like history to me. We have already
> seen the same basic approach in KFD, HMM and to some extend in TTM as well.
>
> And all of them more or less failed. Why should this here be different?


Any info we have on why this has failed to work in the past would be
useful to provide. This is one of those cases where we may not have
documented the bad ideas to stop future developers from thinking they
are bad.

I do think we would want more common code in this area, but I would
think we'd have it more on the driver infrastructure side, than in the
core mm.

Dave.

Re: Radeon regression in 6.6 kernel

[Dave Airlie]

>
> On 12.11.23 01:46, Phillip Susi wrote:
> > I had been testing some things on a post 6.6-rc5 kernel for a week or
> > two and then when I pulled to a post 6.6 release kernel, I found that
> > system suspend was broken.  It seems that the radeon driver failed to
> > suspend, leaving the display dead, the wayland display server hung, and
> > the system still running.  I have been trying to bisect it for the last
> > few days and have only been able to narrow it down to the following 3
> > commits:
> >
> > There are only 'skip'ped commits left to test.
> > The first bad commit could be any of:
> > 56e449603f0ac580700621a356d35d5716a62ce5
> > c07bf1636f0005f9eb7956404490672286ea59d3
> > b70438004a14f4d0f9890b3297cd66248728546c
> > We cannot bisect more!
>
> Hmm, not a single reply from the amdgpu folks. Wondering how we can
> encourage them to look into this.
>
> Phillip, reporting issues by mail should still work, but you might have
> more luck here, as that's where the amdgpu afaics prefer to track bugs:
> https://gitlab.freedesktop.org/drm/amd/-/issues
>
> When you file an issue there, please mention it here.
>
> Furthermore it might help if you could verify if 6.7-rc1 (or rc2, which
> comes out later today) or 6.6.2-rc1 improve things.

It would also be good to test if reverting any of these is possible or not.

File the gitlab issue and we should poke amd a but more to take a look.

Dave.

Re: [pull] amdgpu drm-fixes-6.4

[Dave Airlie]

Hi Linus,

Can you please pull this directly,

Thanks,
Dave.

On Sat, 24 Jun 2023 at 07:18, Alex Deucher  wrote:
>
> Hi Dave, Daniel, Linus,
>
> Last few fixes for 6.4.  Dave already sent out the drm-fixes PR this week.
> I was out of the office earlier in the week and just got this out now.
>
> The following changes since commit 9bd9be5cbaf8a8faa175ef4fba04a5623281debe:
>
>   Merge tag 'drm-misc-fixes-2023-06-21' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-06-23 
> 12:16:48 +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.4-2023-06-23
>
> for you to fetch changes up to 134ea95255cf359a2e6d70308c15243c3fdf8eaf:
>
>   drm/amd: Don't try to enable secure display TA multiple times (2023-06-23 
> 16:44:45 -0400)
>
> 
> amd-drm-fixes-6.4-2023-06-23:
>
> amdgpu:
> - BO locking fixes
> - MCBP fix
> - GPU mapping clear fix for always valid BOs
> - ASPM fixes
> - SDMA4 hang fix
> - Misc display fixes
> - Parade TCON PSR hang fix
> - SMU13 fixes
> - Gang submit fence fix
> - Secure display fix
>
> 
> Alex Deucher (1):
>   drm/amdgpu/sdma4: set align mask to 255
>
> Christian König (3):
>   drm/amdgpu: make sure BOs are locked in amdgpu_vm_get_memory
>   drm/amdgpu: make sure that BOs have a backing store
>   drm/amdgpu: fix number of fence calculations
>
> Evan Quan (2):
>   drm/amd/pm: revise the ASPM settings for thunderbolt attached scenario
>   drm/amd/pm: update the LC_L1_INACTIVITY setting to address possible 
> noise issue
>
> Hamza Mahfooz (1):
>   drm/amd/display: perform a bounds check before filling dirty rectangles
>
> Ilya Bakoulin (1):
>   drm/amd/display: Fix 128b132b link loss handling
>
> Jiadong Zhu (1):
>   drm/amdgpu: Skip mark offset for high priority rings
>
> Kenneth Feng (1):
>   drm/amd/pm: add abnormal fan detection for smu 13.0.0
>
> Leo Chen (1):
>   drm/amd/display: disable seamless boot if force_odm_combine is enabled
>
> Mario Limonciello (2):
>   drm/amd: Disable PSR-SU on Parade 0803 TCON
>   drm/amd: Don't try to enable secure display TA multiple times
>
> Samuel Pitoiset (1):
>   drm/amdgpu: fix clearing mappings for BOs that are always valid in VM
>
> Sung-huai Wang (1):
>   drm/amd/display: add a NULL pointer check
>
> Tao Zhou (1):
>   drm/amdgpu: check RAS irq existence for VCN/JPEG
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|  2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c   |  3 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 81 
> ++
>  drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 13 ++--
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c   |  4 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 13 ++--
>  drivers/gpu/drm/amd/display/dc/core/dc.c   |  3 +
>  .../drm/amd/display/dc/dce112/dce112_resource.c| 10 +--
>  .../dc/link/protocols/link_dp_irq_handler.c| 11 ++-
>  .../drm/amd/display/modules/power/power_helpers.c  |  2 +
>  .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c   |  1 +
>  16 files changed, 108 insertions(+), 62 deletions(-)

Re: [PATCH v4 0/9] drm: fdinfo memory stats

[Dave Airlie]

On Sun, 21 May 2023 at 10:03, Dmitry Baryshkov
 wrote:
>
> On 15/05/2023 17:30, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Similar motivation to other similar recent attempt[1].  But with an
> > attempt to have some shared code for this.  As well as documentation.
> >
> > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > some placement stats as well.  But this seems like a reasonable start.
> >
> > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> >
> > I've combined the separate series to add comm/cmdline override onto
> > the end of this, simply out of convenience (they would otherwise
> > conflict in a bunch of places).
> >
> > v2: Extend things to allow for multiple regions other than just system
> >  "memory", make drm_show_memory_stats() a helper so that, drivers
> >  can use it or not based on their needs (but in either case, re-
> >  use drm_print_memory_stats()
> > v3: Docs fixes
> > v4: use u64 for drm_memory_stats, small docs update and collected
> >  Tvrtko's a-b
> >
> > [1] https://patchwork.freedesktop.org/series/112397/
> >
> > Rob Clark (9):
> >drm/docs: Fix usage stats typos
> >drm: Add common fdinfo helper
> >drm/msm: Switch to fdinfo helper
> >drm/amdgpu: Switch to fdinfo helper
> >drm: Add fdinfo memory stats
> >drm/msm: Add memory stats to fdinfo
> >drm/doc: Relax fdinfo string constraints
> >drm/fdinfo: Add comm/cmdline override fields
> >drm/msm: Wire up comm/cmdline override for fdinfo
> >
> >   Documentation/gpu/drm-usage-stats.rst  | 101 ++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  16 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |   2 +-
> >   drivers/gpu/drm/drm_file.c | 147 +
> >   drivers/gpu/drm/msm/adreno/adreno_gpu.c|  24 +++-
> >   drivers/gpu/drm/msm/msm_drv.c  |  15 ++-
> >   drivers/gpu/drm/msm/msm_gem.c  |  15 +++
> >   drivers/gpu/drm/msm/msm_gpu.c  |   2 -
> >   drivers/gpu/drm/msm/msm_gpu.h  |  10 ++
> >   include/drm/drm_drv.h  |   7 +
> >   include/drm/drm_file.h |  51 +++
> >   include/drm/drm_gem.h  |  32 +
> >   13 files changed, 378 insertions(+), 47 deletions(-)
>
> What is the expected merge plan for this series? msm-next? drm-misc?

I'm fine with this going via drm-misc,

Acked-by: Dave Airlie  if that is the plan.

Dave.

Re: [PATCH 0/8] AMDGPU usermode queues

[Dave Airlie]

On Sat, 4 Feb 2023 at 07:54, Shashank Sharma  wrote:
>
> From: Shashank Sharma 
>
> This patch series introduces AMDGPU usermode graphics queues.
> User queues is a method of GPU workload submission into the graphics
> hardware without any interaction with kernel/DRM schedulers. In this
> method, a userspace graphics application can create its own workqueue
> and submit it directly in the GPU HW.
>
> The general idea of how this is supposed to work:
> - The application creates the following GPU objetcs:
>   - A queue object to hold the workload packets.
>   - A read pointer object.
>   - A write pointer object.
>   - A doorbell page.
> - Kernel picks any 32-bit offset in the doorbell page for this queue.
> - The application uses the usermode_queue_create IOCTL introduced in
>   this patch, by passing the the GPU addresses of these objects (read
>   ptr, write ptr, queue base address and doorbell address)
> - The kernel creates the queue and maps it in the HW.
> - The application can start submitting the data in the queue as soon as
>   the kernel IOCTL returns.
> - Once the data is filled in the queue, the app must write the number of
>   dwords in the doorbell offset, and the GPU will start fetching the data.

So I just have one question about forward progress here, let's call it
the 51% of VRAM problem.

You have two apps they both have working sets that allocate > 51% of VRAM.

Application (a) has the VRAM and mapping for the user queues and is
submitting work
Application (b) wants to submit work, it has no queue mapping as it
was previously evicted, does (b) have to call an ioctl to get it's
mapping back?
When (b) calls the ioctl (a) loses it mapping. Control returns to (b),
but before it submits any work on the ring mapping it has, (a) gets
control and notices it has no queues, so calls the ioctl, and (b)
loses it mapping, and around and around they go never making forward
progress.

What's the exit strategy for something like that, fall back to kernel
submit so you can get a memory objects validated and submit some work?

Dave.

Re: [PATCH] drm/amdgpu/display/mst: fix an unused-variable warning

[Dave Airlie]

On Fri, 27 Jan 2023 at 07:06, Hamza Mahfooz  wrote:
>
> On 1/26/23 11:35, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> >
> > The newly added code is in an #ifdef, so the variables that
> > are only used in there cause a warning if CONFIG_DRM_AMD_DC_DCN
> > is disabled:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
> > 'amdgpu_dm_atomic_check':
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9698:43: error: 
> > unused variable 'mst_state' [-Werror=unused-variable]
> >   9698 | struct drm_dp_mst_topology_state *mst_state;
> >|   ^
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9697:41: error: 
> > unused variable 'mgr' [-Werror=unused-variable]
> >   9697 | struct drm_dp_mst_topology_mgr *mgr;
> >| ^~~
> >
> > Fixes: c689e1e362ea ("drm/amdgpu/display/mst: Fix mst_state->pbn_div and 
> > slot count assignments")
> > Signed-off-by: Arnd Bergmann 
>
> Applied, thanks!
>
> > ---
> >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index be1232356f9e..c966bb05f6c7 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -9694,8 +9694,10 @@ static int amdgpu_dm_atomic_check(struct drm_device 
> > *dev,
> >   struct drm_connector_state *old_con_state, *new_con_state;
> >   struct drm_crtc *crtc;
> >   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > +#if defined(CONFIG_DRM_AMD_DC_DCN)
> >   struct drm_dp_mst_topology_mgr *mgr;
> >   struct drm_dp_mst_topology_state *mst_state;
> > +#endif
> >   struct drm_plane *plane;
> >   struct drm_plane_state *old_plane_state, *new_plane_state;
> >   enum dc_status status;
>

I've pushed an alternate fix to drm-fixes as I pulled in a tree this
morning and it failed to build on arm here.

Dave.

Re: [PATCH 6/9] drm/qxl: stop using ttm_bo_wait

[Dave Airlie]

Acked-by: Dave Airlie 

On Fri, 16 Dec 2022 at 00:20, Christian König
 wrote:
>
> Am 25.11.22 um 11:21 schrieb Christian König:
> > TTM is just wrapping core DMA functionality here, remove the mid-layer.
> > No functional change.
>
> Any objections to this guys?
>
> I'm basically just following a suggestion from Daniel here and it
> already triggered a discussion about the timeout for i915.
>
> Thanks,
> Christian.
>
> >
> > Signed-off-by: Christian König 
> > ---
> >   drivers/gpu/drm/qxl/qxl_cmd.c | 16 ++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> > index 63aa96a69752..281edab518cd 100644
> > --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> > +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> > @@ -579,7 +579,7 @@ void qxl_surface_evict(struct qxl_device *qdev, struct 
> > qxl_bo *surf, bool do_upd
> >
> >   static int qxl_reap_surf(struct qxl_device *qdev, struct qxl_bo *surf, 
> > bool stall)
> >   {
> > - int ret;
> > + long ret;
> >
> >   ret = qxl_bo_reserve(surf);
> >   if (ret)
> > @@ -588,7 +588,19 @@ static int qxl_reap_surf(struct qxl_device *qdev, 
> > struct qxl_bo *surf, bool stal
> >   if (stall)
> >   mutex_unlock(>surf_evict_mutex);
> >
> > - ret = ttm_bo_wait(>tbo, true, !stall);
> > + if (stall) {
> > + ret = dma_resv_wait_timeout(surf->tbo.base.resv,
> > + DMA_RESV_USAGE_BOOKKEEP, true,
> > + 15 * HZ);
> > + if (ret > 0)
> > + ret = 0;
> > + else if (ret == 0)
> > + ret = -EBUSY;
> > + } else {
> > + ret = dma_resv_test_signaled(surf->tbo.base.resv,
> > +  DMA_RESV_USAGE_BOOKKEEP);
> > + ret = ret ? -EBUSY : 0;
> > + }
> >
> >   if (stall)
> >   mutex_lock(>surf_evict_mutex);
>

Re: [pull] amdgpu, amdkfd, radeon drm-next-6.2

[Dave Airlie]

arm32 build fails

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:
In function ‘disable_dangling_plane’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1134:46:
error: ‘const struct timing_generator_funcs’ has no member named
‘disable_phantom_crtc’
 1134 | if (tg->funcs->disable_phantom_crtc)
  |  ^~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1135:50:
error: ‘const struct timing_generator_funcs’ has no member named
‘disable_phantom_crtc’
 1135 |
tg->funcs->disable_phantom_crtc(tg);
  |  ^~
make[6]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:250:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.o] Error 1

Dave.

On Sat, 12 Nov 2022 at 06:19, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 6.2.
>
> The following changes since commit a143bc517bf31c4575191efbaac216a11ec016e0:
>
>   Merge branch '00.06-gr-ampere' of 
> https://gitlab.freedesktop.org/skeggsb/nouveau into drm-next (2022-11-09 
> 11:18:56 +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-6.2-2022-11-11
>
> for you to fetch changes up to 2ebf61f2cfb9a11bc17db30df3e675a4cd7418d3:
>
>   drm/amdgpu: Fix memory leak in amdgpu_cs_pass1 (2022-11-10 15:30:34 -0500)
>
> 
> amd-drm-next-6.2-2022-11-11:
>
> amdgpu:
> - SMU 13.x updates
> - GPUVM TLB race fix
> - DCN 3.1.4 updates
> - DCN 3.2.x updates
> - PSR fixes
> - Kerneldoc fix
> - Vega10 fan fix
> - GPUVM locking fixes in error pathes
> - BACO fix for Beige Goby
> - EEPROM I2C address cleanup
> - GFXOFF fix
> - Fix DC memory leak in error pathes
> - Flexible array updates
> - Mtype fix for GPUVM PTEs
> - Move Kconfig into amdgpu directory
> - SR-IOV updates
> - Fix possible memory leak in CS IOCTL error path
>
> amdkfd:
> - Fix possible memory overrun
> - CRIU fixes
>
> radeon:
> - ACPI ref count fix
> - HDA audio notifier support
> - Move Kconfig into radeon directory
>
> UAPI:
> - Add new GEM_CREATE flags to help to transition more KFD functionality to 
> the DRM UAPI.
>   These are used internally in the driver to align location based memory 
> coherency
>   requirements from memory allocated in the KFD with how we manage GPUVM 
> PTEs.  They
>   are currently blocked in the GEM_CREATE IOCTL as we don't have a user right 
> now.
>   They are just used internally in the kernel driver for now for existing KFD 
> memory
>   allocations. So a change to the UAPI header, but no functional change in 
> the UAPI.
>
> 
> Alvin Lee (4):
>   drm/amd/display: Wait for VBLANK during pipe programming
>   drm/amd/display: Use min transition for SubVP into MPO
>   drm/amd/display: Disable phantom OTG after enable for plane disable
>   drm/amd/display: Add margin for max vblank time for SubVP + DRR
>
> Andrew Davis (1):
>   drm: Move radeon and amdgpu Kconfig options into their directories
>
> Aric Cyr (1):
>   drm/amd/display: 3.2.211
>
> Asher Song (1):
>   Revert "drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for 
> vega10 properly""
>
> Aurabindo Pillai (1):
>   drm/amd/display: Zeromem mypipe heap struct before using it
>
> Chaitanya Dhere (1):
>   drm/amd/display: Fix FCLK deviation and tool compile issues
>
> Christian König (1):
>   drm/amdgpu: workaround for TLB seq race
>
> Dillon Varone (1):
>   drm/amd/display: Enforce minimum prefetch time for low memclk on DCN32
>
> Dong Chenchen (1):
>   drm/amdgpu: Fix memory leak in amdgpu_cs_pass1
>
> Felix Kuehling (3):
>   drm/amdkfd: Fix error handling in kfd_criu_restore_events
>   drm/amdkfd: Fix error handling in criu_checkpoint
>   drm/amdgpu: Set MTYPE in PTE based on BO flags
>
> Gavin Wan (1):
>   drm/amdgpu: Ignore stop rlc on SRIOV environment.
>
> George Shen (1):
>   drm/amd/display: Populate DP2.0 output type for DML pipe
>
> Guchun Chen (1):
>   drm/amdgpu: disable BACO on special BEIGE_GOBY card
>
> Hamza Mahfooz (1):
>   drm/amd/display: only fill dirty rectangles when PSR is enabled
>
> Hanjun Guo (1):
>   drm/radeon: Add the missed acpi_put_table() to fix memory leak
>
> Harsh Jain (1):
>   drm/amdgpu: complete gfxoff allow signal during suspend without delay
>
> Kenneth Feng (2):
>   drm/amd/pm: enable mode1 reset on smu_v13_0_10
>   drm/amd/pm: skip disabling all smu features on smu_v13_0_10 in suspend
>
> Leo Ma (1):
>   drm/amd/display: Adding HDMI SCDC DEVICE_ID define
>
> Liu Jian (1):
>   drm/amd/display: delete the duplicate .set_odm_bypass initialization in 
> dcn314_tg_funcs
>
> LongJun Tang (1):
>   drm/amd/display: Have risk for memory 

Re: [PATCH v2] drm/amdkfd: Try to schedule bottom half on same core

[Dave Airlie]

On Sat, 13 Aug 2022 at 04:11, Felix Kuehling  wrote:
>
>
> On 2022-08-12 09:55, Philip Yang wrote:
> >
> > On 2022-08-11 15:04, Felix Kuehling wrote:
> >> On systems that support SMT (hyperthreading) schedule the bottom half of
> >> the KFD interrupt handler on the same core. This makes it possible to
> >> reserve a core for interrupt handling and have the bottom half run on
> >> that same core.
> >>
> >> On systems without SMT, pick another core in the same NUMA node, as
> >> before.
> >>
> >> Use for_each_cpu_wrap instead of open-coding it.
> >>
> >> Signed-off-by: Felix Kuehling 
> >
> > nit-pick below, looks better to use new_cpu as iterator, either way
> > this is
> >
> > Reviewed-by: Philip Yang 
>
> Thank you. I think I prefer cpu as the iterator and new_cpu as the
> variable that holds the CPU we choose to schedule to.

I don't think this sort of thing should be in a driver.

queue_work_node seems like it should be used or enhanced. Doing this
sort of thing in driver code should be the last place to do it.

At least please task someone to work on an upstream answer to this
sort of hacky downstream thing.

Dave.

Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"

[Dave Airlie]

On Fri, 5 Aug 2022 at 01:53, Mike Lothian  wrote:
>
> Hi
>
> When is this relanding?

It should be in Linus tree now enabled.

Dave.

gcc 12.1.1 warnings around display writeback

[Dave Airlie]

I recently finally got my build box updated to a modern gcc, and I
started seeing

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:
In function ‘dc_stream_remove_writeback’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:523:55:
warning: array subscript [0, 0] is outside array bounds of ‘struct
dc_writeback_info[1]’ [-Warray-bounds]
  523 | stream->writeback_info[j] =
stream->writeback_info[i];
  | ~~^~~
In file included from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:1110,
 from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/inc/core_types.h:29,
 from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/basics/dc_common.h:29,
 from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:30:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_stream.h:230:34:
note: while referencing ‘writeback_info’
  230 | struct dc_writeback_info writeback_info[MAX_DWB_PIPES];
  |  ^~

There's a bunch of code in dc_stream.c to handle multiple writeback
info, but MAX_DWB_PIPES is set to 1, will this ever be increased? can
we rip out the code that assumes it's > 1?

Dave.

[PATCH] drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.

[Dave Airlie]

From: Dave Airlie 

Submitting a cs with 0 chunks, causes an oops later, found trying
to execute the wrong userspace driver.

MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo

[172536.665184] BUG: kernel NULL pointer dereference, address: 01d8
[172536.665188] #PF: supervisor read access in kernel mode
[172536.665189] #PF: error_code(0x) - not-present page
[172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0
[172536.665195] Oops:  [#1] SMP NOPTI
[172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P   O  
5.10.81 #1-NixOS
[172536.665199] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015
[172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]
[172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 
49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba 
d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10
[172536.665276] RSP: 0018:b47c0e81bbe0 EFLAGS: 00010246
[172536.665277] RAX:  RBX:  RCX: 

[172536.665278] RDX:  RSI: b47c0e81be28 RDI: 
b47c0e81bd68
[172536.665279] RBP: 936524080010 R08:  R09: 
b47c0e81be38
[172536.665281] R10: 936524080010 R11: 93652408 R12: 
b47c0e81bc40
[172536.665282] R13: b47c0e81be28 R14: 9367bc41 R15: 
b47c0e81be28
[172536.665283] FS:  7fe35e05d740() GS:936c1edc() 
knlGS:
[172536.665284] CS:  0010 DS:  ES:  CR0: 80050033
[172536.665286] CR2: 01d8 CR3: 000532e46000 CR4: 
000406e0
[172536.665287] Call Trace:
[172536.665322]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665332]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[172536.665338]  drm_ioctl+0x201/0x3b0 [drm]
[172536.665369]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665372]  ? selinux_file_ioctl+0x135/0x230
[172536.665399]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[172536.665403]  __x64_sys_ioctl+0x83/0xb0
[172536.665406]  do_syscall_64+0x33/0x40
[172536.665409]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
Reported-by: Michael Bishop
Signed-off-by: Dave Airlie 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d0d0ea565e3d..2019622191b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -116,7 +116,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser 
*p, union drm_amdgpu_cs
int ret;
 
if (cs->in.num_chunks == 0)
-   return 0;
+   return -EINVAL;
 
chunk_array = kvmalloc_array(cs->in.num_chunks, sizeof(uint64_t), 
GFP_KERNEL);
if (!chunk_array)
-- 
2.35.3

Re: [PATCH] drm/amdgpu: fix drm-next merge fallout

[Dave Airlie]

On Tue, 3 May 2022 at 23:03, Alex Deucher  wrote:
>
> On Tue, May 3, 2022 at 2:36 AM Christian König
>  wrote:
> >
> > That hunk somehow got missing while solving the conflict between the TTM
> > and AMDGPU changes for drm-next.
> >
> > Signed-off-by: Christian König 
>
> Acked-by: Alex Deucher 
>

I'll pick this directly into drm-next.

Dave.

> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > index 7761a3ea172e..88de9f0d4728 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > @@ -631,9 +631,13 @@ static void amdgpu_vm_pt_free(struct amdgpu_vm_bo_base 
> > *entry)
> > if (!entry->bo)
> > return;
> > shadow = amdgpu_bo_shadowed(entry->bo);
> > +   if (shadow) {
> > +   ttm_bo_set_bulk_move(>tbo, NULL);
> > +   amdgpu_bo_unref();
> > +   }
> > +   ttm_bo_set_bulk_move(>bo->tbo, NULL);
> > entry->bo->vm_bo = NULL;
> > list_del(>vm_status);
> > -   amdgpu_bo_unref();
> > amdgpu_bo_unref(>bo);
> >  }
> >
> > --
> > 2.25.1
> >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Dave Airlie]

On Tue, 15 Mar 2022 at 00:23, Alex Deucher  wrote:
>
> On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen  wrote:
> >
> > On Thu, 10 Mar 2022 11:56:41 -0800
> > Rob Clark  wrote:
> >
> > > For something like just notifying a compositor that a gpu crash
> > > happened, perhaps drm_event is more suitable.  See
> > > virtio_gpu_fence_event_create() for an example of adding new event
> > > types.  Although maybe you want it to be an event which is not device
> > > specific.  This isn't so much of a debugging use-case as simply
> > > notification.
> >
> > Hi,
> >
> > for this particular use case, are we now talking about the display
> > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing?
> >
> > If the former, I wasn't aware that display device crashes are a thing.
> > How should a userspace display server react to those?
> >
> > If the latter, don't we have EGL extensions or Vulkan API already to
> > deliver that?
> >
> > The above would be about device crashes that directly affect the
> > display server. Is that the use case in mind here, or is it instead
> > about notifying the display server that some application has caused a
> > driver/hardware crash? If the latter, how should a display server react
> > to that? Disconnect the application?
> >
> > Shashank, what is the actual use case you are developing this for?
> >
> > I've read all the emails here so far, and I don't recall seeing it
> > explained.
> >
>
> The idea is that a support daemon or compositor would listen for GPU
> reset notifications and do something useful with them (kill the guilty
> app, restart the desktop environment, etc.).  Today when the GPU
> resets, most applications just continue assuming nothing is wrong,
> meanwhile the GPU has stopped accepting work until the apps re-init
> their context so all of their command submissions just get rejected.

Just one thing comes to mind reading this, racy PID reuse.

process 1234 does something bad to GPU.
process 1234 dies in parallel to sysfs notification being sent.
other process 1234 reuses the pid
new process 1234 gets destroyed by receiver of sysfs notification.

Dave.

Re: [pull] amdgpu, amdkfd drm-next-5.18

[Dave Airlie]

On Thu, 10 Mar 2022 at 08:16, Alex Deucher  wrote:
>
> On Wed, Mar 9, 2022 at 5:12 PM Dave Airlie  wrote:
> >
> > On Tue, 8 Mar 2022 at 06:08, Alex Deucher  wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > Same PR as last week, just fixed up a bad Fixes tag.
> > >
> > > The following changes since commit 
> > > 38a15ad9488e21cad8f42d3befca20f91e5b2874:
> > >
> > >   Merge tag 'amd-drm-next-5.18-2022-02-25' of 
> > > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-03-01 
> > > 16:19:02 +1000)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.freedesktop.org/agd5f/linux.git 
> > > tags/amd-drm-next-5.18-2022-03-07
> > >
> > > for you to fetch changes up to 53b97af4a44abd21344cc9f13986ba53051287bb:
> > >
> > >   drm/amdkfd: Add format attribute to kfd_smi_event_add (2022-03-07 
> > > 14:59:59 -0500)
> >
> > clang says no.
> >
> > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:508:6:
> > error: variable 'vmid' is used uninitialized whenever 'if' condition
> > is false [-Werror,-Wsometimes-uninitialized]
> > if (dev->kfd2kgd->get_atc_vmid_pasid_mapping_info) {
> > ^
> > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:521:6:
> > note: uninitialized use occurs here
> > if (vmid > last_vmid_to_scan) {
> > ^~~~
> > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:508:2:
> > note: remove the 'if' if its condition is always true
> > if (dev->kfd2kgd->get_atc_vmid_pasid_mapping_info) {
> > ^~~
> > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:490:19:
> > note: initialize the variable 'vmid' to silence this warning
> > unsigned int vmid;
> >  ^
> >   = 0
> >
>
> Already fixed in:
> https://gitlab.freedesktop.org/agd5f/linux/-/commit/455331caeea5058d6df20f31a414b68ca502ec25
> was going to send that out with additional fixes this week, but I can
> just spin a new PR if you'd prefer.

A respin would be great,

Thanks,
Dave.

Re: [pull] amdgpu, amdkfd drm-next-5.18

[Dave Airlie]

On Tue, 8 Mar 2022 at 06:08, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> Same PR as last week, just fixed up a bad Fixes tag.
>
> The following changes since commit 38a15ad9488e21cad8f42d3befca20f91e5b2874:
>
>   Merge tag 'amd-drm-next-5.18-2022-02-25' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-03-01 16:19:02 
> +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-5.18-2022-03-07
>
> for you to fetch changes up to 53b97af4a44abd21344cc9f13986ba53051287bb:
>
>   drm/amdkfd: Add format attribute to kfd_smi_event_add (2022-03-07 14:59:59 
> -0500)

clang says no.

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:508:6:
error: variable 'vmid' is used uninitialized whenever 'if' condition
is false [-Werror,-Wsometimes-uninitialized]
if (dev->kfd2kgd->get_atc_vmid_pasid_mapping_info) {
^
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:521:6:
note: uninitialized use occurs here
if (vmid > last_vmid_to_scan) {
^~~~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:508:2:
note: remove the 'if' if its condition is always true
if (dev->kfd2kgd->get_atc_vmid_pasid_mapping_info) {
^~~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:490:19:
note: initialize the variable 'vmid' to silence this warning
unsigned int vmid;
 ^
  = 0

Dave.
>
> 
> amd-drm-next-5.18-2022-03-07:
>
> amdgpu:
> - Misc code cleanups
> - Misc display fixes
> - PSR display fixes
> - More RAS cleanup
> - Hotplug fix
> - Bump minor version for hotplug tests
> - SR-IOV fixes
> - GC 10.3.7 updates
> - Remove some firmwares which are no longer used
> - Mode2 reset refactor
> - Aldebaran fixes
> - Add VCN fwlog feature for VCN debugging
> - CS code cleanup
>
> amdkfd:
> - SVM fixes
> - SMI event fixes and cleanups
> - vmid_pasid mapping fix for gfx10.3
>
> 
> Alex Deucher (4):
>   drm/amdgpu: Use IP versions in convert_tiling_flags_to_modifier()
>   drm/amdgpu: remove unused gpu_info firmwares
>   drm/amdgpu/gfx10: drop unused cyan skillfish firmware
>   drm/amdgpu/sdma5: drop unused cyan skillfish firmware
>
> Andrey Grodzovsky (2):
>   drm/amdgpu: Fix sigsev when accessing MMIO on hot unplug.
>   drm/amdgpu: Bump minor version for hot plug tests enabling.
>
> Anthony Koo (1):
>   drm/amd/display: [FW Promotion] Release 0.0.106.0
>
> Aric Cyr (1):
>   drm/amd/display: 3.2.175
>
> Charlene Liu (1):
>   drm/amd/display: add verify_link_cap back for hdmi
>
> Chris Park (1):
>   drm/amd/display: Reset VIC if HDMI_VIC is present
>
> Christian König (5):
>   drm/amdgpu: install ctx entities with cmpxchg
>   drm/amdgpu: header cleanup
>   drm/amdgpu: use job and ib structures directly in CS parsers
>   drm/amdgpu: properly embed the IBs into the job
>   drm/amdgpu: initialize the vmid_wait with the stub fence
>
> Danijel Slivka (1):
>   drm/amd/pm: new v3 SmuMetrics data structure for Sienna Cichlid
>
> David Yu (1):
>   drm/amdgpu: Add DFC CAP support for aldebaran
>
> Dillon Varone (2):
>   drm/amd/display: Add frame alternate 3D & restrict HW packed on dongles
>   drm/amd/display: Modify plane removal sequence to avoid hangs.
>
> George Shen (1):
>   drm/amd/display: Refactor fixed VS w/a for PHY tests
>
> Hansen Dsouza (1):
>   drm/amd/display: Remove invalid RDPCS Programming in DAL
>
> Harish Kasiviswanathan (1):
>   drm/amdgpu: Set correct DMA mask for aldebaran
>
> Jingwen Chen (1):
>   drm/amd/amdgpu: set disabled vcn to no_schduler
>
> Lijo Lazar (1):
>   drm/amdgpu: Refactor mode2 reset logic for v13.0.2
>
> Luben Tuikov (1):
>   drm/amd/display: Don't fill up the logs
>
> Meng Tang (1):
>   gpu/amd: vega10_hwmgr: fix inappropriate private variable name
>
> Michael Strauss (1):
>   drm/amd/display: Pass HostVM enable flag into DCN3.1 DML
>
> Nicholas Kazlauskas (1):
>   drm/amd/display: Make functional resource functions non-static
>
> Philip Yang (4):
>   Revert "drm/amdkfd: process_info lock not needed for svm"
>   drm/amdkfd: Correct SMI event read size
>   drm/amdkfd: Add SMI add event helper
>   drm/amdkfd: Add format attribute to kfd_smi_event_add
>
> Prike Liang (4):
>   drm/amdgpu: enable gfx clock gating control for GC 10.3.7
>   drm/amdgpu/nv: enable clock gating for GC 10.3.7 subblock
>   drm/amdgpu: enable gfx power gating for GC 10.3.7
>   drm/amdgpu: enable gfxoff routine 

Re: [pull] amdgpu, amdkfd drm-next-5.18

[Dave Airlie]

On Tue, 1 Mar 2022 at 03:11, Alex Deucher  wrote:
>
> On Mon, Feb 28, 2022 at 1:55 AM Dave Airlie  wrote:
> >
> > On Sat, 26 Feb 2022 at 04:35, Alex Deucher  
> > wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > New stuff for 5.18.
> > >
> > > The following changes since commit 
> > > b63c54d978236dd6014cf2ffba96d626e97c915c:
> > >
> > >   drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 
> > > 15:59:06 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.freedesktop.org/agd5f/linux.git 
> > > tags/amd-drm-next-5.18-2022-02-25
> > >
> > > for you to fetch changes up to 111aeed25ec6bf4d5b4a7b4cb5654f002ba9f795:
> > >
> > >   drm/amdgpu: add gfxoff support for smu 13.0.5 (2022-02-25 11:51:18 
> > > -0500)
> > >
> > > 
> > > amd-drm-next-5.18-2022-02-25:
> > >
> > > amdgpu:
> > > - Raven2 suspend/resume fix
> > > - SDMA 5.2.6 updates
> > > - VCN 3.1.2 updates
> > > - SMU 13.0.5 updates
> > > - DCN 3.1.5 updates
> > > - Virtual display fixes
> > > - SMU code cleanup
> > > - Harvest fixes
> > > - Expose benchmark tests via debugfs
> > > - Drop no longer relevant gart aperture tests
> > > - More RAS restructuring
> > > - W=1 fixes
> > > - PSR rework
> > > - DP/VGA adapter fixes
> > > - DP MST fixes
> > > - GPUVM eviction fix
> > > - GPU reset debugfs register dumping support
> >
> > (this time keeping cc).
> >
> > ^ this seems to conflict with the removal of reset_sem or something in
> > that area.
> >
> > Can you trial merge this to drm-next and send a fixup patch I should
> > apply with it?
>
> reset_sem moved from adev->reset_sem to adev->reset_domain->sem.  See
> the attached diff.  I also pushed a sample merge if that is helpful:
> https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next-amd-drm-next-merge-5.18
>
> Thanks!
>

Excellent thanks Alex.

Dave.

Re: [pull] amdgpu, amdkfd drm-next-5.18

[Dave Airlie]

On Sat, 26 Feb 2022 at 04:35, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.18.
>
> The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c:
>
>   drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 15:59:06 
> -0500)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-5.18-2022-02-25
>
> for you to fetch changes up to 111aeed25ec6bf4d5b4a7b4cb5654f002ba9f795:
>
>   drm/amdgpu: add gfxoff support for smu 13.0.5 (2022-02-25 11:51:18 -0500)
>
> 
> amd-drm-next-5.18-2022-02-25:
>
> amdgpu:
> - Raven2 suspend/resume fix
> - SDMA 5.2.6 updates
> - VCN 3.1.2 updates
> - SMU 13.0.5 updates
> - DCN 3.1.5 updates
> - Virtual display fixes
> - SMU code cleanup
> - Harvest fixes
> - Expose benchmark tests via debugfs
> - Drop no longer relevant gart aperture tests
> - More RAS restructuring
> - W=1 fixes
> - PSR rework
> - DP/VGA adapter fixes
> - DP MST fixes
> - GPUVM eviction fix
> - GPU reset debugfs register dumping support

(this time keeping cc).

^ this seems to conflict with the removal of reset_sem or something in
that area.

Can you trial merge this to drm-next and send a fixup patch I should
apply with it?

Dave.

Re: [PATCH] drm/amdkfd: enable heavy-weight TLB flush on Arcturus

[Dave Airlie]

On Wed, 19 Jan 2022 at 06:14, Eric Huang  wrote:
>
> I understand Alex's concern. I think usually we only check the version
> when a feature is only available in a specific version, and other
> version or newer version doesn't have.
>
> In case of FW fix, we assume the driver and FWs have to be synchronous.
> If we have driver backward compatibility for FWs, there must be a lot of
> redundant codes for FW version check. So this patch and SDMA fix will be
> pushed into ROCm 5.1 release branch at the same time.
>

Please remove that assumption from everwhere.

If you have released a fw into linux-firmware then you need to support
it going forward, even if it means printing something in dmesg
recommending people upgrade for features.

Dave.

Re: [pull] amdgpu drm-fixes-5.16

[Dave Airlie]

On Thu, 30 Dec 2021 at 01:51, Alex Deucher  wrote:
>
> Hi Dave, Daniel,

Just FYI on merging this into tip I got a conflict I'm not sure what
answer is right.

fixes has:
ee2698cf79cc759a397c61086c758d4cc85938bf
Author: Angus Wang 
Date:   Thu Dec 9 17:27:01 2021 -0500

drm/amd/display: Changed pipe split policy to allow for
multi-display pipe split

next has:
1edf5ae1fdaffb67c1b93e98df670cbe535d13cf
Author: Zhan Liu 
Date:   Mon Nov 8 19:31:00 2021 -0500

drm/amd/display: enable seamless boot for DCN301

-.pipe_split_policy = MPC_SPLIT_AVOID_MULT_DISP,
fixes is +.pipe_split_policy = MPC_SPLIT_DYNAMIC,
next is +.pipe_split_policy = MPC_SPLIT_AVOID,

I've chosen the -fixes answer for now, but it would be good to have
someone review it before Linus merges.

Dave.

Re: [pull] amdgpu, amdkfd drm-next-5.17

[Dave Airlie]

Hey,

dim: 3be2709660dc ("drm/amdgpu: Call amdgpu_device_unmap_mmio() if
device is unplugged to prevent crash in GPU initialization failure"):
committer Signed-off-by missing.

is missing your sob as you committed it. Please fix it up.

Thanks,
Dave.

Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

[Dave Airlie]

On Thu, 2 Sept 2021 at 01:20, Alex Deucher  wrote:
>
> On Wed, Sep 1, 2021 at 6:19 AM Liu, Monk  wrote:
> >
> > [AMD Official Use Only]
> >
> > Daniel
> >
> > From the link you share it looks you(or someone else) have quite a bunch 
> > patches that changes DRM_SCHED or even amdgpu, by that case before they are 
> > merged to kernel tree I'm wondering if any AMD develop reviewed them ?
> >
> > They looks to me somehow conflicting with what we changed in our repo
> >
> > It is really a chaos for AMDer if someone else out side of AMD changes our 
> > kernel driver (or/and scheduler) without reviewed by AMDer, just like we 
> > are requiring your review if we tend to change scheduler's logic here 
> >
> > This one changes AMD's code: 
> > https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/
> > And I didn't see any reviewed-by from AMDers ...
> >
> > This one also touches AMD's code: 
> > https://lore.kernel.org/dri-devel/20200604081224.863494-12-daniel.vet...@ffwll.ch/
> > Which is conflicting with one patch we submitted (in our repo rightnow), 
> > and neither see AMDder gave a review-by on this one (let me know if I 
> > missed it)
> >
>
> Monk, this is not how upstream works.  You need to participate.
> That's how communities work.  There's a reason all these discussions
> happen on public mailing lists.  The patch author can't be expected to
> know every person on every vendor team to CC with a patch.  If you
> have concerns, you need to raise them when the patches are being
> discussed.
>

I'm not sure I can add much to help this along, I'm sure Alex has some
internal training,

Once your driver is upstream, it belongs to upstream, you can maintain
it, but you no longer control it 100%, it's a tradeoff, it's not one
companies always understand.

Usually people are fine developing away internally, but once
interaction with other parts of the kernel/subsystem is required they
have the realisation that they needed to work upstream 6 months
earlier.

The best time to interact with upstream was 6 months ago, the second
best time is now.

Dave.

Re: [PATCH 0/7] libdrm tests for hot-unplug feature

[Dave Airlie]

On Fri, 4 Jun 2021 at 07:20, Alex Deucher  wrote:
>
> Please open a gitlab MR for these.
>

I'd really prefer these tests all get migrated out of here into igt. I
don't think libdrm_amdgpu really should have tests that test the
kernel level infrastructure.

I know some people at AMD had issues in the past with igt because the
i might have stood for intel back in time, but at this point I think
we should be moving past that.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Nouveau] [PATCH v4 00/17] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

[Dave Airlie]

On Sat, 24 Apr 2021 at 04:43, Lyude Paul  wrote:
>
> Since it's been asked quite a few times on some of the various DP
> related patch series I've submitted to use the new DRM printk helpers,
> and it technically wasn't really trivial to do this before due to the
> lack of a consistent way to find a drm_device for an AUX channel, this
> patch series aims to address this. In this series we:
>
> * (NEW! starting from V3) Make sure drm_dbg_*() and friends can handle
>   NULL drm device pointers
> * Clean-up potentially erroneous usages of drm_dp_aux_init() and
>   drm_dp_aux_register() so that actual AUX registration doesn't happen
>   until we have an associated DRM device
> * Clean-up any obvious errors in drivers we find along the way
> * Add a backpointer to the respective drm_device for an AUX channel in
>   drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel
>   across the tree
> * Add a new ratelimited print helper we'll need for converting the DP
>   helpers over to using the new DRM printk helpers
> * Fix any inconsistencies with logging in drm_dp_helper.c so we always
>   have the aux channel name printed
> * Prepare the various DP helpers so they can find the correct drm_device
>   to use for logging
> * And finally, convert all of the DP helpers over to using drm_dbg_*()
>   and drm_err().
>
> Major changes in v4:
> * Don't move i2c aux init into drm_dp_aux_init(), since I think I've
>   found a much better solution to tegra's issues:
>   https://patchwork.freedesktop.org/series/89420/

I've given this a general once over, seems like a good plan and since
it's mostly mechanical.

for the series:
Reviewed-by: Dave Airlie 

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13

[Dave Airlie]

On Fri, 9 Apr 2021 at 19:07, Christian König
 wrote:
>
> Am 08.04.21 um 15:03 schrieb Alex Deucher:
> > On Thu, Apr 8, 2021 at 6:28 AM Christian König
> >  wrote:
> >> Am 08.04.21 um 09:13 schrieb Christian König:
> >>> Am 07.04.21 um 21:04 schrieb Alex Deucher:
> >>>> On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie  wrote:
> >>>>> On Wed, 7 Apr 2021 at 06:54, Alex Deucher 
> >>>>> wrote:
> >>>>>> On Fri, Apr 2, 2021 at 12:22 PM Christian König
> >>>>>>  wrote:
> >>>>>>> Hey Alex,
> >>>>>>>
> >>>>>>> the TTM and scheduler changes should already be in the drm-misc-next
> >>>>>>> branch (not 100% sure about the TTM patch, need to double check
> >>>>>>> next week).
> >>>>>>>
> >>>>>> The TTM change is not in drm-misc yet.
> >>>>>>
> >>>>>>> Could that cause problems when both are merged into drm-next?
> >>>>>> Dave, Daniel, how do you want to handle this?  The duplicated patch
> >>>>>> is this one:
> >>>>>> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac4eb83ab255de9c31184df51fd1534ba36fd212
> >>>>>>
> >>>>>> amdgpu has changes which depend on it.  The same patch is included
> >>>>>> in this PR.
> >>>>> Ouch not sure how best to sync up here, maybe get misc-next into my
> >>>>> tree then rebase your tree on top of it?
> >>>> I can do that.
> >>> Please let me double check later today that we have everything we need
> >>> in drm-misc-next.
> >> There where two patch for TTM (one from Felix and one from Oak) which
> >> still needed to be pushed to drm-misc-next. I've done that just a minute
> >> ago.
> >>
> > They were included in this PR.
> >
> >> Then we have this patch which fixes a bug in code removed on
> >> drm-misc-next. I think it should be dropped when amd-staging-drm-next is
> >> based on drm-next/drm-misc-next.
> >>
> >> Author: xinhui pan 
> >> Date:   Wed Feb 24 11:28:08 2021 +0800
> >>
> >>   drm/ttm: Do not add non-system domain BO into swap list
> >>
> > Ok.
> >
> >> I've also found the following patch which is problematic as well:
> >>
> >> commit c8a921d49443025e10794342d4433b3f29616409
> >> Author: Jack Zhang 
> >> Date:   Mon Mar 8 12:41:27 2021 +0800
> >>
> >>   drm/amd/amdgpu implement tdr advanced mode
> >>
> >>   [Why]
> >>   Previous tdr design treats the first job in job_timeout as the bad 
> >> job.
> >>   But sometimes a later bad compute job can block a good gfx job and
> >>   cause an unexpected gfx job timeout because gfx and compute ring 
> >> share
> >>   internal GC HW mutually.
> >>
> >>   [How]
> >>   This patch implements an advanced tdr mode.It involves an additinal
> >>   synchronous pre-resubmit step(Step0 Resubmit) before normal resubmit
> >>   step in order to find the real bad job.
> >>
> >>   1. At Step0 Resubmit stage, it synchronously submits and pends for 
> >> the
> >>   first job being signaled. If it gets timeout, we identify it as 
> >> guilty
> >>   and do hw reset. After that, we would do the normal resubmit step to
> >>   resubmit left jobs.
> >>
> >>   2. For whole gpu reset(vram lost), do resubmit as the old way.
> >>
> >>   Signed-off-by: Jack Zhang 
> >>   Reviewed-by: Andrey Grodzovsky 
> >>
> >> That one is modifying both amdgpu as well as the scheduler code. IIRC I
> >> actually requested that the patch is split into two, but that was
> >> somehow not done.
> >>
> >> How should we proceed here? Should I separate the patch, push the
> >> changes to drm-misc-next and then we merge with drm-next and rebase
> >> amd-staging-drm-next on top of that?
> >>
> >> That's most likely the cleanest option approach as far as I can see.
> > That's fine with me.  We could have included them in my PR.  Now we
> > have wait for drm-misc-next to be merged again before we can merge the
> > amdgpu code.
>
> Well I'm not sure, but the patches are identical on both branches.
>
> As far as I can see git then just ignores that it gets the patches from
> both sides of the merge.

No this is one of the biggest no-nos. Don't ever merge a patch via
multiple trees,
it ends badly. (you might get away with it once or twice depending, but longer
term bad things result, esp around merge conflicts with other trees).

If we have patches we need in multiple trees, we have to create a stable topic
branch and pull that into both trees.

drm-misc-next is backmerged into drm-next now.
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13

[Dave Airlie]

On Wed, 7 Apr 2021 at 06:54, Alex Deucher  wrote:
>
> On Fri, Apr 2, 2021 at 12:22 PM Christian König
>  wrote:
> >
> > Hey Alex,
> >
> > the TTM and scheduler changes should already be in the drm-misc-next
> > branch (not 100% sure about the TTM patch, need to double check next week).
> >
>
> The TTM change is not in drm-misc yet.
>
> > Could that cause problems when both are merged into drm-next?
>
> Dave, Daniel, how do you want to handle this?  The duplicated patch is this 
> one:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac4eb83ab255de9c31184df51fd1534ba36fd212
> amdgpu has changes which depend on it.  The same patch is included in this PR.

Ouch not sure how best to sync up here, maybe get misc-next into my
tree then rebase your tree on top of it?

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, radeon drm-next-5.12

[Dave Airlie]

I think this is due to this pull, on arm32.

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:
In function ‘dmub_srv_hw_init’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:519:44:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
  outbox0_rb_params.base_address = (void
*)((uint64_t)(tracebuff_fb->cpu_addr) + TRACE_BUFFER_ENTRY_OFFSET);
^
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:519:35:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
  outbox0_rb_params.base_address = (void
*)((uint64_t)(tracebuff_fb->cpu_addr) + TRACE_BUFFER_ENTRY_OFFSET);

Dave.

On Sat, 27 Mar 2021 at 05:16, Zhuo, Qingqing  wrote:
>
> [AMD Public Use]
>
> On Thu, Feb 18, 2021 at 11:15 PM Alex Deucher  wrote:
> >>
> >> Hi Dave, Daniel,
> >>
> >> Fixes for 5.12.
> >>
> >> The following changes since commit 
> >> 4c3a3292730c56591472717d8c5c0faf74f6c6bb:
> >>
> >>   drm/amd/display: fix unused variable warning (2021-02-05 09:49:44
> >> +1000)
> >>
> >> are available in the Git repository at:
> >>
> >>
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> >> ab.freedesktop.org%2Fagd5f%2Flinux.gitdata=04%7C01%7Cqingqing.zhu
> >> o%40amd.com%7Cce0d1ee6a18b4a95366008d8f082048e%7C3dd8961fe4884e608e11a
> >> 82d994e183d%7C0%7C0%7C637523789263486288%7CUnknown%7CTWFpbGZsb3d8eyJWI
> >> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> >> mp;sdata=Ig3OkPN0X8OtCOHDJqV%2FZSEOsL7gPs8OMh9sXDniR2w%3Dreserved
> >> =0 tags/amd-drm-next-5.12-2021-02-18
> >>
> >> for you to fetch changes up to 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371:
> >>
> >>   drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) (2021-02-18
> >> 16:43:09 -0500)
>
> > Pulled into drm-next, with some conflicts, please double-check.
>
> > I also spotted
>
> > commit ea3b4242bc9ca197762119382b37e125815bd67f
> > Author: Qingqing Zhuo 
> > Date:   Tue Feb 9 16:36:41 2021 -0500
>
> >   drm/amd/display: Fix system hang after multiple hotplugs (v3)
>
> > I think it would be good if that could use the drm_vblank_work stuff from 
> > Lyude instead of hand-rolling your own.
> > -Daniel
>
> Hi Daniel,
>
> Thank you for the suggestion! I need to look into further and will do so as 
> soon as I have bandwidth.
>
> Thanks,
> Lillian
>
> >>
> >> 
> >> amd-drm-next-5.12-2021-02-18:
> >>
> >> amdgpu:
> >> - Prefer Bhawan's unused variable fix
> >> - Fixes for high priority queues on gfx8,9
> >> - swSMU fixes for sienna cichlid
> >> - swSMU fixes for renoir
> >> - mmhub client id fixes for arcturus
> >> - SMUIO fixes for navi family
> >> - swSMU fixes for vangogh
> >> - GPU reset cleanup
> >> - Display fixes
> >> - GFX harvesting fix for sienna cichlid
> >> - Fix reference clock on Renoir
> >> - Misc fixes and cleanups
> >>
> >> amdkfd:
> >> - Fix for unique id query
> >> - Fix recursive lock warnings
> >>
> >> radeon:
> >> - Remove confusing VCE messages on Oland
> >>
> >> 
> >> Alex Deucher (16):
> >>   Revert "drm/amd/display: fix unused variable warning"
> >>   drm/amdgpu/smu12: fix power reporting on renoir
> >>   drm/amdgpu/gmc9: fix mmhub client mapping for arcturus
> >>   drm/amdgpu/si: minor clean up of reset code
> >>   drm/amdgpu/cik: minor clean up of reset code
> >>   drm/amdgpu/vi: minor clean up of reset code
> >>   drm/amdgpu: add generic pci reset as an option
> >>   drm/amdgpu/si: add PCI reset support
> >>   drm/amdgpu/soc15: add PCI reset support
> >>   drm/amdgpu/nv: add PCI reset support
> >>   drm/amdgpu: drop extra drm_kms_helper_poll_enable/disable calls
> >>   drm/amdgpu: use runpm flag rather than fbcon for kfd runtime suspend 
> >> (v2)
> >>   drm/amdgpu: reset runpm flag if device suspend fails
> >>   Revert "drm/amd/display: Update NV1x SR latency values"
> >>   drm/radeon: OLAND boards don't have VCE
> >>   drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2)
> >>
> >> Anthony Koo (1):
> >>   drm/amd/display: [FW Promotion] Release 0.0.51
> >>
> >> Aric Cyr (1):
> >>   drm/amd/display: 3.2.122
> >>
> >> Bhawanpreet Lakha (1):
> >>   drm/amd/display: Fix unused variable warning
> >>
> >> Dale Zhao (1):
> >>   drm/amd/display: fix type mismatch error for return variable
> >>
> >> Derek Lai (1):
> >>   drm/amd/display: Add DIG_CLOCK_PATTERN in the transmitter
> >> control
> >>
> >> Eric Yang (1):
> >>   drm/amd/display: move edp sink present detection to hw init
> >>
> >> Fangzhi Zuo (1):
> >>   drm/amd/display: Add return code instead of boolean for future
> >> use
> >>
> >> Felix Kuehling (1):
> >>   drm/amdkfd: Fix recursive lock warnings
> >>
> >> Gustavo A. 

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[Dave Airlie]

On Wed, 3 Mar 2021 at 08:45, Zeng, Oak  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Daniel, Thomas, Dan,
>
>
>
> Does below message mean the calling ioremap_cache failed intel’s driver 
> build? I can see both ioremap_cache and ioremap_wc are defined in 
> arch/x86/mm/ioremap.c – why ioremap_wc doesn’t break intel driver’s build?

Just to clear up confusion here, the linux kernel robot is hosted by
Intel it does not test intel driver builds exclusively, it tests a lot
of different builds across lots of different architectures,.

If the robot complains it's because your patch breaks in the
configuration it describes, take the time to read that configuration
info and realise it's nothing to do with Intel at all.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd drm-next-5.12

[Dave Airlie]

On Thu, 4 Feb 2021 at 14:57, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> More fixes for 5.12.  Same PR from last week with the issue Felix reported
> fixed and a few more additional fixes on top.
>
> The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0:
>
>   Merge tag 'amd-drm-next-5.12-2021-01-20' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-01-20 13:08:18 
> +0100)
>
This brought an arm32 warning with it, I've applied Arnd's patch to
drm-next to fix it.

https://patchwork.freedesktop.org/patch/msgid/20210125124849.102037-1-a...@kernel.org

However that function has an ifdef around an ifdef that probably could
do with cleaning up.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu drm-next-5.12

[Dave Airlie]

On Fri, 15 Jan 2021 at 07:22, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 5.12.
>
> The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
>
>   drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 
> 210921) (2021-01-08 15:18:57 -0500)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-5.12-2021-01-14
>
> for you to fetch changes up to df1f0560d28f4895e2d61af826728efb61976f9f:
>
>   drm/amd/display: Simplify bool comparison (2021-01-14 13:20:21 -0500)

arm 32/64 builds say no.

  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_get_smu_metrics_data’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
  boot_cpu_data.x86_max_cores * sizeof(uint16_t));
  ^
  bl_get_data
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10:
note: each undeclared identifier is reported only once for each
function it appears in
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_read_sensor’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1320:11:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
   *size = boot_cpu_data.x86_max_cores * sizeof(uint16_t);
   ^
   bl_get_data
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_od_edit_dpm_table’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1460:19:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
   if (input[0] >= boot_cpu_data.x86_max_cores) {
   ^
   bl_get_data
make[5]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:279:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.o] Error 1


Not sure using boot_cpu_data in a driver is that good an idea, maybe
there is a better interface to get that sort of information, but even
so it should build on arm.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: fix check order in radeon_bo_move

[Dave Airlie]

Oops sorry for delay LGTM

Reviewed-by: Dave Airlie 

On Fri, 27 Nov 2020 at 02:34, Daniel Vetter  wrote:
>
> On Wed, Nov 25, 2020 at 3:34 PM Christian König
>  wrote:
> >
> > Reorder the code to fix checking if blitting is available.
>
> Might be good to explain why blitting might not be available, e.g.
> suspend/resume and or chip death and stuff like that.
>
> > Signed-off-by: Christian König 
>
> Needs Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")
>
> Btw
>
> $ dim fixes [sha1]
>
> generates that for you plus nice cc list of offenders. With the Fixes
> line added:
>
> Reviewed-by: Daniel Vetter 
>
> At least I'm hanging onto the illusion that I understand what you did here :-)
> -Daniel
> > ---
> >  drivers/gpu/drm/radeon/radeon_ttm.c | 54 +
> >  1 file changed, 24 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 0ca381b95d3d..2b598141225f 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -216,27 +216,15 @@ static int radeon_bo_move(struct ttm_buffer_object 
> > *bo, bool evict,
> > struct ttm_resource *old_mem = >mem;
> > int r;
> >
> > -   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> > -new_mem->mem_type == TTM_PL_VRAM) ||
> > -   (old_mem->mem_type == TTM_PL_VRAM &&
> > -new_mem->mem_type == TTM_PL_SYSTEM)) {
> > -   hop->fpfn = 0;
> > -   hop->lpfn = 0;
> > -   hop->mem_type = TTM_PL_TT;
> > -   hop->flags = 0;
> > -   return -EMULTIHOP;
> > -   }
> > -
> > if (new_mem->mem_type == TTM_PL_TT) {
> > r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
> > if (r)
> > return r;
> > }
> > -   radeon_bo_move_notify(bo, evict, new_mem);
> >
> > r = ttm_bo_wait_ctx(bo, ctx);
> > if (r)
> > -   goto fail;
> > +   return r;
> >
> > /* Can't move a pinned BO */
> > rbo = container_of(bo, struct radeon_bo, tbo);
> > @@ -246,12 +234,12 @@ static int radeon_bo_move(struct ttm_buffer_object 
> > *bo, bool evict,
> > rdev = radeon_get_rdev(bo->bdev);
> > if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
> > ttm_bo_move_null(bo, new_mem);
> > -   return 0;
> > +   goto out;
> > }
> > if (old_mem->mem_type == TTM_PL_SYSTEM &&
> > new_mem->mem_type == TTM_PL_TT) {
> > ttm_bo_move_null(bo, new_mem);
> > -   return 0;
> > +   goto out;
> > }
> >
> > if (old_mem->mem_type == TTM_PL_TT &&
> > @@ -259,31 +247,37 @@ static int radeon_bo_move(struct ttm_buffer_object 
> > *bo, bool evict,
> > radeon_ttm_tt_unbind(bo->bdev, bo->ttm);
> > ttm_resource_free(bo, >mem);
> > ttm_bo_assign_mem(bo, new_mem);
> > -   return 0;
> > +   goto out;
> > }
> > -   if (!rdev->ring[radeon_copy_ring_index(rdev)].ready ||
> > -   rdev->asic->copy.copy == NULL) {
> > -   /* use memcpy */
> > -   goto memcpy;
> > +   if (rdev->ring[radeon_copy_ring_index(rdev)].ready &&
> > +   rdev->asic->copy.copy != NULL) {
> > +   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> > +new_mem->mem_type == TTM_PL_VRAM) ||
> > +   (old_mem->mem_type == TTM_PL_VRAM &&
> > +new_mem->mem_type == TTM_PL_SYSTEM)) {
> > +   hop->fpfn = 0;
> > +   hop->lpfn = 0;
> > +   hop->mem_type = TTM_PL_TT;
> > +   hop->flags = 0;
> > +   return -EMULTIHOP;
> > +   }
> > +
> > +   r = radeon_move_blit(bo, evict, new_mem, old_mem);
> > +   } else {
> > +   r = -ENODEV;
> > }
> >
> > -   r = radeon_move_blit(bo, evict, new_mem, old_mem);
> > if (r) {
> > -memcpy:
> > r

Re: [PATCH 01/11] drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2

[Dave Airlie]

On Tue, 22 Sep 2020 at 23:32, Christian König
 wrote:
>
> As an alternative to the placement flag add a
> pin count to the ttm buffer object.

These all look good to me, nice cleanup.

For the series:
Reviewed-by: Dave Airlie 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: General protection fault: RIP: 0010:free_block+0xdc/0x1f0

[Dave Airlie]

cc'ing some more people.

On Tue, 15 Sep 2020 at 23:07, Paul Menzel  wrote:
>
> Dear Andrew folks, dear Linux folks,
>
>
> With Linux 5.9-rc4 on a Dell OptiPlex 5080 with Intel Core i7-10700 CPU
> @ 2.90GHz, and external
>
>  01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611] (rev 87)
>
> running graphical demanding applications glmark2 [1] and the Phoronix
> Test Suite [2] benchmark *pts/desktop-graphics* [3]
>
>  $ git describe --tags
>  v10.0.0m1-13-g0b5ddc3c0
>
> I got three general protection faults, and it restarted or froze (no
> input devices working, screen froze and even network card (no ping)).
>
> Here the system restarted itself:
>
> > kernel: general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > kernel: CPU: 2 PID: 9702 Comm: glmark2 Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020
> > kernel: RIP: 0010:free_block+0xdc/0x1f0
>
> Here it froze:
>
> > [14639.665745] general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 
> > 08/17/2020
> > [14639.691823] RIP: 0010:free_block+0xdc/0x1f0
>
> Here it froze:
>
> > kernel: general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > kernel: CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020
> > kernel: RIP: 0010:free_block+0xdc/0x1f0
>
> Running `scripts/decode_stacktrace.sh`:
>
> > linux-5.9_rc4-343.x86_64/source$ scripts/decode_stacktrace.sh vmlinux < 
> > optiplex-5080-linux-5.9-rc4-gp-pvpython.txt
> > [14528.718656] cgroup: fork rejected by pids controller in 
> > /user.slice/user-5272.slice/session-c6.scope
> > [14639.665745] general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 
> > 08/17/2020
> > [14639.691823] RIP: 0010:free_block (./include/linux/list.h:112 
> > ./include/linux/list.h:135 ./include/linux/list.h:146 mm/slab.c:3336)
> > [14639.696006] Code: 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 4c 01 e8 48 8b 50 
> > 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 48 8b 48 08 48 8b 50 10 4c 8d 78 08 
> > <48> 89 51 08 48 89 0a 4c 89 da 48 2b 50 28 4c 89 60 08 48 89 68 10
> > All code
> > 
> >0: 00 48 01add%cl,0x1(%rax)
> >3: d0 48 c1rorb   -0x3f(%rax)
> >6: e8 0c 48 c1 e0  callq  0xe0c14817
> >b: 06  (bad)
> >c: 4c 01 e8add%r13,%rax
> >f: 48 8b 50 08 mov0x8(%rax),%rdx
> >   13: 48 8d 4a ff lea-0x1(%rdx),%rcx
> >   17: 83 e2 01and$0x1,%edx
> >   1a: 48 0f 45 c1 cmovne %rcx,%rax
> >   1e: 48 8b 48 08 mov0x8(%rax),%rcx
> >   22: 48 8b 50 10 mov0x10(%rax),%rdx
> >   26: 4c 8d 78 08 lea0x8(%rax),%r15
> >   2a:*48 89 51 08 mov%rdx,0x8(%rcx)   <-- 
> > trapping instruction
> >   2e: 48 89 0amov%rcx,(%rdx)
> >   31: 4c 89 damov%r11,%rdx
> >   34: 48 2b 50 28 sub0x28(%rax),%rdx
> >   38: 4c 89 60 08 mov%r12,0x8(%rax)
> >   3c: 48 89 68 10 mov%rbp,0x10(%rax)
> >
> > Code starting with the faulting instruction
> > ===
> >0: 48 89 51 08 mov%rdx,0x8(%rcx)
> >4: 48 89 0amov%rcx,(%rdx)
> >7: 4c 89 damov%r11,%rdx
> >a: 48 2b 50 28 sub0x28(%rax),%rdx
> >e: 4c 89 60 08 mov%r12,0x8(%rax)
> >   12: 48 89 68 10 mov%rbp,0x10(%rax)
> > [14639.714747] RSP: 0018:c9001c26fab8 EFLAGS: 00010046
> > [14639.719970] RAX: ea000d193600 RBX: 8000 RCX: 
> > dead0100
> > [14639.727099] RDX: dead0122 RSI: 88842d5f3ef0 RDI: 
> > 88842b440300
> > [14639.734225] RBP: dead0122 R08: c9001c26fb30 R09: 
> > 88842b441280
> > [14639.741351] R10: 000f R11: 8883464d80c0 R12: 
> > dead0100
> > [14639.748477] R13: ea00 R14: 88842d5f3ff0 R15: 
> > ea000d193608
> > [14639.755604] FS:  7fd3b7e8f040() GS:88842d5c() 
> > knlGS:
> > [14639.763692] CS:  0010 DS:  ES:  CR0: 80050033
> > 

Re: [PATCH] radeon: Use only a single work queue thread for crt

[Dave Airlie]

On Sun, 6 Sep 2020 at 18:54, Christian König
 wrote:
>
> Am 03.08.19 um 02:09 schrieb Andi Kleen:
> > From: Andi Kleen 
> >
> > I got tired of seeing a lot of radeon-crt kernel threads in ps on my
> > workstation, one for each CPU and one for each display, which never use any 
> > CPU time.
> > Surely a single kernel thread is enough to handle the display.
>
> NAK, radeon blocks inside the kernel thread and those need to run in
> parallel or otherwise the hardware can hang.

Do we need one per cpu? or is one per crtc enough?

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/ttm: fix broken merge between drm-next and drm-misc-next

[Dave Airlie]

On Wed, 19 Aug 2020 at 23:44, Christian König
 wrote:
>
> drm-next reverted the changes to ttm_tt_create() to do the
> NULL check inside the function, but drm-misc-next adds new
> users of this approach.
>
> Re-apply the NULL check change inside the function to fix this.

Where is this problem now? only in drm-tip or have we baked the broken
mere already?

If it's baked then 'Reviewed-by: Dave Airlie `

If it's not baked, then please use the dim howto to put a fixup in the
right place.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: Embed drm_device into amdgpu_device

[Dave Airlie]

On Wed, 19 Aug 2020 at 04:23, Alex Deucher  wrote:
>
> On Fri, Aug 14, 2020 at 9:25 PM Luben Tuikov  wrote:
> >
> > Embed struct drm_device into struct amdgpu_device.
> > Modify the macro DRM_TO_ADEV()
> > accordingly. Introduce a new macro to yield the
> > DRM device from amdgpu_device, ADEV_TO_DRM().

Please don't use a macro, use an inline something like adev_to_drm().

Dave.

> > Eliminate the use of drm_device.dev_private,
> > in amdgpu.
> > Add a DRM driver relase function, which frees
> > the amdgpu_device after all krefs on the DRM
> > device have been released.
>
> You might want to also mention that this switches from using
> drm_dev_alloc() to drm_dev_init().  It might also be more helpful to
> introduce the ADEV_TO_DRM() macro in a new prior patch so that the
> diff for this change is smaller and easier to follow. That makes it
> more obvious what the functional change is here.  A few comments
> below, I think there is some component stuff leftover from debugging.
> Other than that, it looks pretty good to me overall.
>
> Alex
>
> >
> > Signed-off-by: Luben Tuikov 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   9 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |  10 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|   6 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c  |   6 +-
> >  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   | 178 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  41 ++--
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  37 ++--
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c   |   6 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  51 +++--
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  20 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |   6 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c   |  18 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  20 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 194 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c   |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c   |   4 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c   |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   6 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c  |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c  |   2 +-
> >  .../gpu/drm/amd/amdgpu/atombios_encoders.c|   2 +-
> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  46 ++---
> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  46 ++---
> >  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  46 ++---
> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  46 ++---
> >  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  36 ++--
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  78 +++
> >  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |   4 +-
> >  .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c |   4 +-
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |   4 +-
> >  35 files changed, 475 insertions(+), 467 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 0268bb1da82b..5581ba958fca 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -724,8 +724,8 @@ struct amd_powerplay {
> >  #define AMDGPU_MAX_DF_PERFMONS 4
> >  struct amdgpu_device {
> > struct device   *dev;
> > -   struct drm_device   *ddev;
> > struct pci_dev  *pdev;
> > +   struct drm_device   ddev;
> >
> >  #ifdef CONFIG_DRM_AMD_ACP
> > struct amdgpu_acp   acp;
> > @@ -988,7 +988,8 @@ struct amdgpu_device {
> > struct ratelimit_state  throttling_logging_rs;
> >  };
> >
> > -#define DRM_TO_ADEV(_drmdevp)  ((struct amdgpu_device 
> > *)(_drmdevp)->dev_private)
> > +#define DRM_TO_ADEV(_drmdevp) container_of(_drmdevp, struct amdgpu_device, 
> > ddev)
> > +#define ADEV_TO_DRM(_amddevp) ((struct drm_device *)(&((_amddevp)->ddev)))
> >
> >  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> > *bdev)
> >  {
> > @@ -996,8 +997,6 @@ static inline struct amdgpu_device 
> > *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
> >  }
> >
> >  int amdgpu_device_init(struct amdgpu_device *adev,
> > -  struct drm_device *ddev,
> > -  struct pci_dev *pdev,
> >uint32_t flags);
> >  void amdgpu_device_fini(struct amdgpu_device *adev);
> >  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
> > @@ -1187,7 +1186,7 @@ static inline void *amdgpu_atpx_get_dhandle(void) { 
> > return NULL; }
> >  extern const 

Re: [PATCH 3/3] drm/radeon: drop superflous AGP handling

[Dave Airlie]

On Thu, 6 Aug 2020 at 23:51, Christian König
 wrote:
>
> The object flags created in radeon_ttm_placement_from_domain take care that
> we use the correct caching for AGP, this is just superflous.
>
> Signed-off-by: Christian König 

Reviewed-by: Dave Airlie 

> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++---
>  1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 31f4cf211b6a..290c8b479853 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -76,26 +76,9 @@ static int radeon_ttm_init_vram(struct radeon_device *rdev)
>
>  static int radeon_ttm_init_gtt(struct radeon_device *rdev)
>  {
> -   uint32_t available_caching, default_caching;
> -
> -   available_caching = TTM_PL_MASK_CACHING;
> -   default_caching = TTM_PL_FLAG_CACHED;
> -
> -#if IS_ENABLED(CONFIG_AGP)
> -   if (rdev->flags & RADEON_IS_AGP) {
> -   if (!rdev->ddev->agp) {
> -   DRM_ERROR("AGP is not enabled\n");
> -   return -EINVAL;
> -   }
> -   available_caching = TTM_PL_FLAG_UNCACHED |
> -   TTM_PL_FLAG_WC;
> -   default_caching = TTM_PL_FLAG_WC;
> -   }
> -#endif
> -
> return ttm_range_man_init(>mman.bdev, TTM_PL_TT,
> - available_caching,
> - default_caching, true,
> + TTM_PL_MASK_CACHING,
> + TTM_PL_FLAG_CACHED, true,
>   rdev->mc.gtt_size >> PAGE_SHIFT);
>  }
>
> --
> 2.17.1
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/3] drm/ttm: give resource functions their own [ch] files

[Dave Airlie]

On Thu, 6 Aug 2020 at 23:51, Christian König
 wrote:
>
> This is a separate object we work within TTM.

Reviewed-by: Dave Airlie 
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c   |   4 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c|   4 +-
>  drivers/gpu/drm/ttm/Makefile   |   3 +-
>  drivers/gpu/drm/ttm/ttm_bo.c   | 124 +-
>  drivers/gpu/drm/ttm/ttm_bo_util.c  |   4 +-
>  drivers/gpu/drm/ttm/ttm_resource.c | 151 
>  include/drm/ttm/ttm_bo_api.h   |  70 +-
>  include/drm/ttm/ttm_bo_driver.h| 189 ---
>  include/drm/ttm/ttm_resource.h | 263 +
>  11 files changed, 446 insertions(+), 376 deletions(-)
>  create mode 100644 drivers/gpu/drm/ttm/ttm_resource.c
>  create mode 100644 include/drm/ttm/ttm_resource.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 43f4966331dd..b36d94f57d42 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -381,7 +381,7 @@ int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev,
> if (cpu_addr)
> amdgpu_bo_kunmap(*bo_ptr);
>
> -   ttm_bo_mem_put(&(*bo_ptr)->tbo, &(*bo_ptr)->tbo.mem);
> +   ttm_resource_free(&(*bo_ptr)->tbo, &(*bo_ptr)->tbo.mem);
>
> for (i = 0; i < (*bo_ptr)->placement.num_placement; ++i) {
> (*bo_ptr)->placements[i].fpfn = offset >> PAGE_SHIFT;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 67d2eef2f9eb..462402fcd1a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -578,7 +578,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object 
> *bo, bool evict,
> /* move BO (in tmp_mem) to new_mem */
> r = ttm_bo_move_ttm(bo, ctx, new_mem);
>  out_cleanup:
> -   ttm_bo_mem_put(bo, _mem);
> +   ttm_resource_free(bo, _mem);
> return r;
>  }
>
> @@ -625,7 +625,7 @@ static int amdgpu_move_ram_vram(struct ttm_buffer_object 
> *bo, bool evict,
> goto out_cleanup;
> }
>  out_cleanup:
> -   ttm_bo_mem_put(bo, _mem);
> +   ttm_resource_free(bo, _mem);
> return r;
>  }
>
> @@ -1203,11 +1203,11 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object 
> *bo)
> gtt->offset = (u64)tmp.start << PAGE_SHIFT;
> r = amdgpu_ttm_gart_bind(adev, bo, flags);
> if (unlikely(r)) {
> -   ttm_bo_mem_put(bo, );
> +   ttm_resource_free(bo, );
> return r;
> }
>
> -   ttm_bo_mem_put(bo, >mem);
> +   ttm_resource_free(bo, >mem);
> bo->mem = tmp;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 604a74323696..29d7d7e100f7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1191,7 +1191,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, 
> bool evict, bool intr,
>
> ret = ttm_bo_move_ttm(bo, , new_reg);
>  out:
> -   ttm_bo_mem_put(bo, _reg);
> +   ttm_resource_free(bo, _reg);
> return ret;
>  }
>
> @@ -1227,7 +1227,7 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, 
> bool evict, bool intr,
> goto out;
>
>  out:
> -   ttm_bo_mem_put(bo, _reg);
> +   ttm_resource_free(bo, _reg);
> return ret;
>  }
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 3355b69b13d1..31f4cf211b6a 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -271,7 +271,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
> *bo,
> }
> r = ttm_bo_move_ttm(bo, , new_mem);
>  out_cleanup:
> -   ttm_bo_mem_put(bo, _mem);
> +   ttm_resource_free(bo, _mem);
> return r;
>  }
>
> @@ -309,7 +309,7 @@ static int radeon_move_ram_vram(struct ttm_buffer_object 
> *bo,
> goto out_cleanup;
> }
>  out_cleanup:
> -   ttm_bo_mem_put(bo, _mem);
> +   ttm_resource_free(bo, _mem);
> return r;
>  }
>
> diff --git a/drivers/gpu/drm/ttm/Makefile b/dri

Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

[Dave Airlie]

On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
 wrote:
>
>
> On 7/21/20 9:45 AM, Christian König wrote:
> > Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 7/9/20 2:33 PM, Daniel Vetter wrote:
>  Comes up every few years, gets somewhat tedious to discuss, let's
>  write this down once and for all.
> 
>  What I'm not sure about is whether the text should be more explicit in
>  flat out mandating the amdkfd eviction fences for long running compute
>  workloads or workloads where userspace fencing is allowed.
> >>> Although (in my humble opinion) it might be possible to completely
> >>> untangle
> >>> kernel-introduced fences for resource management and dma-fences used
> >>> for
> >>> completion- and dependency tracking and lift a lot of restrictions
> >>> for the
> >>> dma-fences, including prohibiting infinite ones, I think this makes
> >>> sense
> >>> describing the current state.
> >> Yeah I think a future patch needs to type up how we want to make that
> >> happen (for some cross driver consistency) and what needs to be
> >> considered. Some of the necessary parts are already there (with like the
> >> preemption fences amdkfd has as an example), but I think some clear docs
> >> on what's required from both hw, drivers and userspace would be really
> >> good.
> >
> > I'm currently writing that up, but probably still need a few days for
> > this.
>
> Great! I put down some (very) initial thoughts a couple of weeks ago
> building on eviction fences for various hardware complexity levels here:
>
> https://gitlab.freedesktop.org/thomash/docs/-/blob/master/Untangling%20dma-fence%20and%20memory%20allocation.odt

We are seeing HW that has recoverable GPU page faults but only for
compute tasks, and scheduler without semaphores hw for graphics.

So a single driver may have to expose both models to userspace and
also introduces the problem of how to interoperate between the two
models on one card.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

[Dave Airlie]

>
> >> That's also why I'm not positive on the "no hw preemption, only
> >> scheduler" case: You still have a dma_fence for the batch itself,
> >> which means still no userspace controlled synchronization or other
> >> form of indefinite batches allowed. So not getting us any closer to
> >> enabling the compute use cases people want.
>
> What compute use case are you talking about? I'm only aware about the
> wait before signal case from Vulkan, the page fault case and the KFD
> preemption fence case.

So slight aside, but it does appear as if Intel's Level 0 API exposes
some of the same problems as vulkan.

They have fences:
"A fence cannot be shared across processes."

They have events (userspace fences) like Vulkan but specify:
"Signaled from the host, and waited upon from within a device’s command list."

"There are no protections against events causing deadlocks, such as
circular waits scenarios.

These problems are left to the application to avoid."

https://spec.oneapi.com/level-zero/latest/core/PROG.html#synchronization-primitives

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/1] drm/amdkfd: Add IPC API

[Dave Airlie]

On Tue, 14 Jul 2020 at 14:09, Felix Kuehling  wrote:
>
> Am 2020-07-13 um 11:28 p.m. schrieb Dave Airlie:
> > On Tue, 14 Jul 2020 at 13:14, Felix Kuehling  wrote:
> >> This allows exporting and importing buffers. The API generates handles
> >> that can be used with the HIP IPC API, i.e. big numbers rather than
> >> file descriptors.
> > First up why? I get the how.
>
> The "why" is compatibility with HIP code ported from CUDA. The
> equivalent CUDA IPC API works with handles that can be communicated
> through e.g. a pipe or shared memory. You can't do that with file
> descriptors.

Okay that sort of useful information should definitely be in the patch
description.

>
> https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1g8a37f7dfafaca652391d0758b3667539
>
> https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1g01050a29fefde385b1042081ada4cde9
>
> >
> >> + * @share_handle is a 128 bit random number generated with
> >> + * @get_random_bytes. This number should be very hard to guess.
> >> + * Knowledge of the @share_handle implies authorization to access
> >> + * the shared memory. User mode should treat it like a secret key.
> >> + * It can be used to import this BO in a different process context
> >> + * for IPC buffer sharing. The handle will be valid as long as the
> >> + * underlying BO exists. If the same BO is exported multiple times,
> > Do we have any examples of any APIs in the kernel that operate like
> > this? That don't at least layer some sort of file permissions  and
> > access control on top?
>
> SystemV shared memory APIs (shmget, shmat) work similarly. There are
> some permissions that can be specified by the exporter in shmget.
> However, the handles are just numbers and much easier to guess (they are
> 32-bit integers). The most restrictive permissions would allow only the
> exporting UID to attach to the shared memory segment.
>
> I think DRM flink works similarly as well, with a global name IDR used
> for looking up GEM objects using global object names.

flink is why I asked, because flink was a mistake and not one I'd care
to make again.
shm is horrible also, but at least has some permissions on what users
can attack it.

> > The reason fd's are good is that combined with unix sockets, you can't
> > sniff it, you can't ptrace a process and find it, you can't write it
> > out in a coredump and have someone access it later.
>
> Arguably ptrace and core dumps give you access to all the memory
> contents already. So you don't need the shared memory handle to access
> memory in that case.

core dumps might not dump this memory though, but yeah ptrace would
likely already mean you have access.

> > Maybe someone who knows security can ack merging this sort of uAPI
> > design, I'm not confident in what it's doing is in any ways a good
> > idea. I might have to ask some people to take a closer look.
>
> Please do. We have tried to make this API as secure as possible within
> the constraints of the user mode API we needed to implement.

I'll see if I hear back, but also if danvet has any input like I
suppose it's UUID based buffer access, so maybe 128-bit is enough and
you have enough entropy not to create anything insanely predictable.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/1] drm/amdkfd: Add IPC API

[Dave Airlie]

On Tue, 14 Jul 2020 at 13:14, Felix Kuehling  wrote:
>
> This allows exporting and importing buffers. The API generates handles
> that can be used with the HIP IPC API, i.e. big numbers rather than
> file descriptors.

First up why? I get the how.

> + * @share_handle is a 128 bit random number generated with
> + * @get_random_bytes. This number should be very hard to guess.
> + * Knowledge of the @share_handle implies authorization to access
> + * the shared memory. User mode should treat it like a secret key.
> + * It can be used to import this BO in a different process context
> + * for IPC buffer sharing. The handle will be valid as long as the
> + * underlying BO exists. If the same BO is exported multiple times,

Do we have any examples of any APIs in the kernel that operate like
this? That don't at least layer some sort of file permissions  and
access control on top?

The reason fd's are good is that combined with unix sockets, you can't
sniff it, you can't ptrace a process and find it, you can't write it
out in a coredump and have someone access it later.

To me this isn't secure design, it's obscure design, now I get to find
you've likely shipped this in "downstream" ROCm already, and have
customers running it.

Maybe someone who knows security can ack merging this sort of uAPI
design, I'm not confident in what it's doing is in any ways a good
idea. I might have to ask some people to take a closer look.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 01/25] dma-fence: basic lockdep annotations

[Dave Airlie]

On Tue, 14 Jul 2020 at 02:39, Christian König  wrote:
>
> Am 13.07.20 um 18:26 schrieb Daniel Vetter:
> > Hi Christian,
> >
> > On Wed, Jul 08, 2020 at 04:57:21PM +0200, Christian König wrote:
> >> Could we merge this controlled by a separate config option?
> >>
> >> This way we could have the checks upstream without having to fix all the
> >> stuff before we do this?
> > Discussions died out a bit, do you consider this a blocker for the first
> > two patches, or good for an ack on these?
>
> Yes, I think the first two can be merged without causing any pain. Feel
> free to add my ab on them.
>
> And the third one can go in immediately as well.

Acked-by: Dave Airlie  for the first 2 +
indefinite explains.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, radeon drm-next-5.9

[Dave Airlie]

commit 5fa689e66bf406ef3a1afe03d0139d90b0b13773
Author: Likun Gao 
Commit: Alex Deucher 

drm/amdgpu/powerplay: add smu block for sienna_cichlid

Add SMU block for sienna_cichlid with psp load type.

Signed-off-by: Likun Gao 
Reviewed-by: Jack Xiao 


Spot the missing signed-off-by. (hint dim warns about these generating
pull requests :-)

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

[Dave Airlie]

On Thu, 11 Jun 2020 at 18:01, Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2020-06-04 09:12:09)
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> >   this explicit annotation can be more liberally sprinkled around.
> >   With read locks lockdep isn't going to complain if the read-side
> >   isn't nested the same way under all circumstances, so ABBA deadlocks
> >   are ok. Which they are, since this is an annotation only.
> >
> > - We're using non-recursive lockdep read lock mode, since in recursive
> >   read lock mode lockdep does not catch read side hazards. And we
> >   _very_ much want read side hazards to be caught. For full details of
> >   this limitation see
> >
> >   commit e91498589746065e3ae95d9a00b068e525eec34f
> >   Author: Peter Zijlstra 
> >   Date:   Wed Aug 23 13:13:11 2017 +0200
> >
> >   locking/lockdep/selftests: Add mixed read-write ABBA tests
> >
> > - To allow nesting of the read-side explicit annotations we explicitly
> >   keep track of the nesting. lock_is_held() allows us to do that.
> >
> > - The wait-side annotation is a write lock, and entirely done within
> >   dma_fence_wait() for everyone by default.
> >
> > - To be able to freely annotate helper functions I want to make it ok
> >   to call dma_fence_begin/end_signalling from soft/hardirq context.
> >   First attempt was using the hardirq locking context for the write
> >   side in lockdep, but this forces all normal spinlocks nested within
> >   dma_fence_begin/end_signalling to be spinlocks. That bollocks.
> >
> >   The approach now is to simple check in_atomic(), and for these cases
> >   entirely rely on the might_sleep() check in dma_fence_wait(). That
> >   will catch any wrong nesting against spinlocks from soft/hardirq
> >   contexts.
> >
> > The idea here is that every code path that's critical for eventually
> > signalling a dma_fence should be annotated with
> > dma_fence_begin/end_signalling. The annotation ideally starts right
> > after a dma_fence is published (added to a dma_resv, exposed as a
> > sync_file fd, attached to a drm_syncobj fd, or anything else that
> > makes the dma_fence visible to other kernel threads), up to and
> > including the dma_fence_wait(). Examples are irq handlers, the
> > scheduler rt threads, the tail of execbuf (after the corresponding
> > fences are visible), any workers that end up signalling dma_fences and
> > really anything else. Not annotated should be code paths that only
> > complete fences opportunistically as the gpu progresses, like e.g.
> > shrinker/eviction code.
> >
> > The main class of deadlocks this is supposed to catch are:
> >
> > Thread A:
> >
> > mutex_lock(A);
> > mutex_unlock(A);
> >
> > dma_fence_signal();
> >
> > Thread B:
> >
> > mutex_lock(A);
> > dma_fence_wait();
> > mutex_unlock(A);
> >
> > Thread B is blocked on A signalling the fence, but A never gets around
> > to that because it cannot acquire the lock A.
> >
> > Note that dma_fence_wait() is allowed to be nested within
> > dma_fence_begin/end_signalling sections. To allow this to happen the
> > read lock needs to be upgraded to a write lock, which means that any
> > other lock is acquired between the dma_fence_begin_signalling() call and
> > the call to dma_fence_wait(), and still held, this will result in an
> > immediate lockdep complaint. The only other option would be to not
> > annotate such calls, defeating the point. Therefore these annotations
> > cannot be sprinkled over the code entirely mindless to avoid false
> > positives.
> >
> > v2: handle soft/hardirq ctx better against write side and dont forget
> > EXPORT_SYMBOL, drivers can't use this otherwise.
> >
> > v3: Kerneldoc.
> >
> > v4: Some spelling fixes from Mika
> >
> > Cc: Mika Kuoppala 
> > Cc: Thomas Hellstrom 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-gfx@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Christian König 
> > Signed-off-by: Daniel Vetter 
>
> Introducing a global lockmap that cannot capture the rules correctly,

Can you document the rules all drivers should be following then,
because from here it looks to get refactored every version of i915,
and it would be nice if we could all aim for the same set of things
roughly. We've already had enough problems with amdgpu vs i915 vs
everyone else with fences, if this stops that in the future then I'd
rather we have that than just some unwritten rules per driver and
untestable.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

[Dave Airlie]

On Tue, 12 May 2020 at 06:28, Alex Deucher  wrote:
>
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  wrote:
> >
> > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > Hi guys,
> >
> > > Well let's face it AGP is a total headache to maintain and dead for at 
> > > least 10+ years.
> >
> > > We have a lot of x86 specific stuff in the architecture independent
> > > graphics memory management to get the caching right, abusing the DMA
> > > API on multiple occasions, need to distinct between AGP and driver 
> > > specific page tables etc etc...
> >
> > > So the idea here is to just go ahead and remove the support from
> > > Radeon and Nouveau and then drop the necessary code from TTM.
> >
> > > For Radeon this means that we just switch over to the driver
> > > specific page tables and everything should more or less continue to work.
> >
> > > For Nouveau I'm not 100% sure, but from the code it of hand looks
> > > like we can do it similar to Radeon.
> >
> > > Please comment what you think about this.
> >
> > > Regards,
> > > Christian.
> >
> > Christian,
> >
> > I would respectfully ask that this change be rejected.
> >
> > I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
> > (Macs, IBM Power - BE and LE).
> >
> > Linux is not just used for modern hardware. There is also a subset of
> > the user base that uses it for what is often termed retro-computing.
> > No it's not commercial usage, but no one can seriously claim that that
> > Linux is for business only.
> >
> > Often the old hardware is built far batter than the modern junk, and
> > will continue to run for years to come. This group of folks either has
> > existing hardware they wish to continue to use, or are acquiring the
> > same because they are tired of generic locked-down hardware.
> >
> > A significant percentage of the video hardware that falls in the retro
> > category uses the AGP video bus. Removing that support for those cases
> > where it works would severely limit performance and in some cases
> > functionality. This can mean the difference between being able to run
> > an application, or having it fail.
> >
>
> Note there is no loss of functionality here, at least on radeon
> hardware.  It just comes down to which MMU gets used for access to
> system memory, the AGP MMU on the chipset or the MMU built into the
> GPU.  On powerpc hardware, AGP has been particularly unstable, and AGP
> has been disabled by default on radeon on powerpc for years now.  In
> fact, this will probably make older hardware more reliable as it takes
> AGP out of the equation.
>

From memory there is quite a loss in speed though, like pretty severe.

The radeon PCI GART has a single slot TLB, if memory serves.

I think this is going to be a hard sell at this stage, I'm guessing
users will crawl out of the woodwork, I'm sure with 2 hours after I'm
able to access the office, I can boot the 865 AGP box with an rv350 in
it on a modern distro.

Maybe we can find some way to compartmentalise AGP further?

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Sat, 29 Feb 2020 at 05:34, Eric Anholt  wrote:
>
> On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie  wrote:
> >
> > On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
> > >
> > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > > > b) we probably need to take a large step back here.
> > > >
> > > > Look at this from a sponsor POV, why would I give X.org/fd.o
> > > > sponsorship money that they are just giving straight to google to pay
> > > > for hosting credits? Google are profiting in some minor way from these
> > > > hosting credits being bought by us, and I assume we aren't getting any
> > > > sort of discounts here. Having google sponsor the credits costs google
> > > > substantially less than having any other company give us money to do
> > > > it.
> > >
> > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > > comparable in terms of what you get and what you pay for them.
> > > Obviously providers like Packet and Digital Ocean who offer bare-metal
> > > services are cheaper, but then you need to find someone who is going
> > > to properly administer the various machines, install decent
> > > monitoring, make sure that more storage is provisioned when we need
> > > more storage (which is basically all the time), make sure that the
> > > hardware is maintained in decent shape (pretty sure one of the fd.o
> > > machines has had a drive in imminent-failure state for the last few
> > > months), etc.
> > >
> > > Given the size of our service, that's a much better plan (IMO) than
> > > relying on someone who a) isn't an admin by trade, b) has a million
> > > other things to do, and c) hasn't wanted to do it for the past several
> > > years. But as long as that's the resources we have, then we're paying
> > > the cloud tradeoff, where we pay more money in exchange for fewer
> > > problems.
> >
> > Admin for gitlab and CI is a full time role anyways. The system is
> > definitely not self sustaining without time being put in by you and
> > anholt still. If we have $75k to burn on credits, and it was diverted
> > to just pay an admin to admin the real hw + gitlab/CI would that not
> > be a better use of the money? I didn't know if we can afford $75k for
> > an admin, but suddenly we can afford it for gitlab credits?
>
> As I think about the time that I've spent at google in less than a
> year on trying to keep the lights on for CI and optimize our
> infrastructure in the current cloud environment, that's more than the
> entire yearly budget you're talking about here.  Saying "let's just
> pay for people to do more work instead of paying for full-service
> cloud" is not a cost optimization.
>
>
> > > Yes, we could federate everything back out so everyone runs their own
> > > builds and executes those. Tinderbox did something really similar to
> > > that IIRC; not sure if Buildbot does as well. Probably rules out
> > > pre-merge testing, mind.
> >
> > Why? does gitlab not support the model? having builds done in parallel
> > on runners closer to the test runners seems like it should be a thing.
> > I guess artifact transfer would cost less then as a result.
>
> Let's do some napkin math.  The biggest artifacts cost we have in Mesa
> is probably meson-arm64/meson-arm (60MB zipped from meson-arm64,
> downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day,
> makes ~1.8TB/month ($180 or so).  We could build a local storage next
> to the lava dispatcher so that the artifacts didn't have to contain
> the rootfs that came from the container (~2/3 of the insides of the
> zip file), but that's another service to build and maintain.  Building
> the drivers once locally and storing it would save downloading the
> other ~1/3 of the inside of the zip file, but that requires a big
> enough system to do builds in time.
>
> I'm planning on doing a local filestore for google's lava lab, since I
> need to be able to move our xml files off of the lava DUTs to get the
> xml results we've become accustomed to, but this would not bubble up
> to being a priority for my time if I wasn't doing it anyway.  If it
> takes me a single day to set all this up (I estimate a couple of
> weeks), that costs my employer a lot more than sponsoring the costs of
> the inefficiencies of the system that has accumulated.

I'm not trying to knock the engineering works the CI contributors have
done at all, but I've never seen a real discussion about costs until
now. Engineers aren't accountants.

The thing we seem to 

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
>
> On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > b) we probably need to take a large step back here.
> >
> > Look at this from a sponsor POV, why would I give X.org/fd.o
> > sponsorship money that they are just giving straight to google to pay
> > for hosting credits? Google are profiting in some minor way from these
> > hosting credits being bought by us, and I assume we aren't getting any
> > sort of discounts here. Having google sponsor the credits costs google
> > substantially less than having any other company give us money to do
> > it.
>
> The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> comparable in terms of what you get and what you pay for them.
> Obviously providers like Packet and Digital Ocean who offer bare-metal
> services are cheaper, but then you need to find someone who is going
> to properly administer the various machines, install decent
> monitoring, make sure that more storage is provisioned when we need
> more storage (which is basically all the time), make sure that the
> hardware is maintained in decent shape (pretty sure one of the fd.o
> machines has had a drive in imminent-failure state for the last few
> months), etc.
>
> Given the size of our service, that's a much better plan (IMO) than
> relying on someone who a) isn't an admin by trade, b) has a million
> other things to do, and c) hasn't wanted to do it for the past several
> years. But as long as that's the resources we have, then we're paying
> the cloud tradeoff, where we pay more money in exchange for fewer
> problems.

Admin for gitlab and CI is a full time role anyways. The system is
definitely not self sustaining without time being put in by you and
anholt still. If we have $75k to burn on credits, and it was diverted
to just pay an admin to admin the real hw + gitlab/CI would that not
be a better use of the money? I didn't know if we can afford $75k for
an admin, but suddenly we can afford it for gitlab credits?

> Yes, we could federate everything back out so everyone runs their own
> builds and executes those. Tinderbox did something really similar to
> that IIRC; not sure if Buildbot does as well. Probably rules out
> pre-merge testing, mind.

Why? does gitlab not support the model? having builds done in parallel
on runners closer to the test runners seems like it should be a thing.
I guess artifact transfer would cost less then as a result.

> The reason we hadn't worked everything out in advance of deploying is
> because Mesa has had 3993 MRs in the not long over a year since
> moving, and a similar number in GStreamer, just taking the two biggest
> users. At the start it was 'maybe let's use MRs if you want to but
> make sure everything still goes through the list', and now it's
> something different. Similarly the CI architecture hasn't been
> 'designed', so much as that people want to run dEQP and Piglit on
> their hardware pre-merge in an open fashion that's actually accessible
> to people, and have just done it.
>
> Again, if you want everything to be centrally
> designed/approved/monitored/controlled, that's a fine enough idea, and
> I'd be happy to support whoever it was who was doing that for all of
> fd.o.

I don't think we have any choice but to have someone centrally
controlling it, You can't have a system in place that lets CI users
burn largs sums of money without authorisation, and that is what we
have now.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Fri, 28 Feb 2020 at 07:27, Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

a) Ouch.

b) we probably need to take a large step back here.

Look at this from a sponsor POV, why would I give X.org/fd.o
sponsorship money that they are just giving straight to google to pay
for hosting credits? Google are profiting in some minor way from these
hosting credits being bought by us, and I assume we aren't getting any
sort of discounts here. Having google sponsor the credits costs google
substantially less than having any other company give us money to do
it.

If our current CI architecture is going to burn this amount of money a
year and we hadn't worked this out in advance of deploying it then I
suggest the system should be taken offline until we work out what a
sustainable system would look like within the budget we have, whether
that be never transferring containers and build artifacts from the
google network, just having local runner/build combos etc.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu/display: use msleep rather than udelay for HDCP

[Dave Airlie]

Hey,

I've pulled in these two patches to drm-next directly because my arm
test build was broken.

Dave.

On Wed, 18 Dec 2019 at 06:47, Alex Deucher  wrote:
>
> ARM has a 2000us limit for udelay.  Switch to msleep.  This code
> executes in a worker thread so shouldn't be an atomic context.
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c 
> b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
> index bcbc0b8a9aa0..f730b94ac3c0 100644
> --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
> +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
> @@ -153,7 +153,7 @@ static enum mod_hdcp_status poll_l_prime_available(struct 
> mod_hdcp *hdcp)
>  {
> enum mod_hdcp_status status;
> uint8_t size;
> -   uint16_t max_wait = 2; // units of us
> +   uint16_t max_wait = 20; // units of ms
> uint16_t num_polls = 5;
> uint16_t wait_time = max_wait / num_polls;
>
> @@ -161,7 +161,7 @@ static enum mod_hdcp_status poll_l_prime_available(struct 
> mod_hdcp *hdcp)
> status = MOD_HDCP_STATUS_INVALID_OPERATION;
> else
> for (; num_polls; num_polls--) {
> -   udelay(wait_time);
> +   msleep(wait_time);
>
> status = mod_hdcp_read_rxstatus(hdcp);
> if (status != MOD_HDCP_STATUS_SUCCESS)
> @@ -474,7 +474,7 @@ static enum mod_hdcp_status locality_check(struct 
> mod_hdcp *hdcp,
>  hdcp, "lc_init_write"))
> goto out;
> if (is_dp_hdcp(hdcp))
> -   udelay(16000);
> +   msleep(16);
> else
> if (!mod_hdcp_execute_and_set(poll_l_prime_available,
> >l_prime_available_poll, ,
> --
> 2.23.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: GART write flush error on SI w/ amdgpu

[Dave Airlie]

On Wed, 21 Jun 2017 at 00:03, Marek Olšák  wrote:
>
> On Tue, Jun 20, 2017 at 1:46 PM, Christian König
>  wrote:
> > Am 20.06.2017 um 12:34 schrieb Marek Olšák:
> >>
> >> BTW, I noticed the flush sequence in the kernel is wrong. The correct
> >> flush sequence should be:
> >>
> >> 1) EVENT_WRITE_EOP - CACHE_FLUSH_AND_INV_TS - write a dword to memory,
> >> but no fence/interrupt.
> >> 2) WAIT_REG_MEM on the dword to wait for idle before SURFACE_SYNC.
> >> 3) SURFACE_SYNC (TC, K$, I$)
> >> 4) Write CP_COHER_CNTL2.
> >> 5) EVENT_WRITE_EOP - BOTTOM_OF_PIPE_TS - write the fence with the
> >> interrupt.
> >>
> >> WAIT_REG_MEM wouldn't be needed if we were able to merge
> >> CACHE_FLUSH_AND_INV, SURFACE_SYNC, and CP_COHER_CNTL2 into one EOP
> >> event.
> >>
> >> The main issue with the current flush sequence in radeon and amdgpu is
> >> that it doesn't wait for idle before writing CP_COHER_CNTL2 and
> >> SURFACE_SYNC. So far we've been able to avoid the bug by waiting for
> >> idle in userspace IBs.
> >
> >
> > Well not waiting for idle between IBs is an explicit requirement, because it
> > is rather bad for performance to do so.
> >
> > David Zhou, Monk and I worked quite a lot on this to avoid both possible
> > hazard and performance drop.
>
> I guess the requirement was ignored for SI. If you don't do the TC
> flush as part the EOP event, you have to wait for idle before
> SURFACE_SYNC, because SURFACE_SYNC doesn't wait for idle. It's kinda
> useless to flush TC when shaders are still in flight.

I've been chasing Verde wierdness, did this issue ever get resolved?

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: move pci handling out of pm ops

[Dave Airlie]

On Fri, 22 Nov 2019 at 06:05, Alex Deucher  wrote:
>
> On Thu, Nov 21, 2019 at 2:53 PM Dave Airlie  wrote:
> >
> > On Fri, 22 Nov 2019 at 02:55, Alex Deucher  wrote:
> > >
> > > The documentation says the that PCI core handles this
> > > for you unless you choose to implement it.  Just rely
> > > on the PCI core to handle the pci specific bits.
> > >
> > > Signed-off-by: Alex Deucher 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  4 +--
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 +-
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 16 +--
> > >  3 files changed, 24 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > index 97843462c2fb..2e9d0be05f2f 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > @@ -1191,8 +1191,8 @@ int amdgpu_driver_open_kms(struct drm_device *dev, 
> > > struct drm_file *file_priv);
> > >  void amdgpu_driver_postclose_kms(struct drm_device *dev,
> > >  struct drm_file *file_priv);
> > >  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
> > > -int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool 
> > > fbcon);
> > > -int amdgpu_device_resume(struct drm_device *dev, bool resume, bool 
> > > fbcon);
> > > +int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
> > > +int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
> > >  u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int 
> > > pipe);
> > >  int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> > >  void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int 
> > > pipe);
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index b1408c5e4640..d832bd22ba9d 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -1090,6 +1090,7 @@ static int amdgpu_device_check_arguments(struct 
> > > amdgpu_device *adev)
> > >  static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum 
> > > vga_switcheroo_state state)
> > >  {
> > > struct drm_device *dev = pci_get_drvdata(pdev);
> > > +   int r;
> > >
> > > if (amdgpu_device_supports_boco(dev) && state == 
> > > VGA_SWITCHEROO_OFF)
> > > return;
> > > @@ -1099,7 +1100,12 @@ static void amdgpu_switcheroo_set_state(struct 
> > > pci_dev *pdev, enum vga_switchero
> > > /* don't suspend or resume card normally */
> > > dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> > >
> > > -   amdgpu_device_resume(dev, true, true);
> > > +   pci_set_power_state(dev->pdev, PCI_D0);
> > > +   pci_restore_state(dev->pdev);
> > > +   r = pci_enable_device(dev->pdev);
> > > +   if (r)
> > > +   DRM_WARN("pci_enable_device failed (%d)\n", r);
> > > +   amdgpu_device_resume(dev, true);
> > >
> > > dev->switch_power_state = DRM_SWITCH_POWER_ON;
> > > drm_kms_helper_poll_enable(dev);
> > > @@ -1107,7 +1113,11 @@ static void amdgpu_switcheroo_set_state(struct 
> > > pci_dev *pdev, enum vga_switchero
> > > pr_info("amdgpu: switched off\n");
> > > drm_kms_helper_poll_disable(dev);
> > > dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> > > -   amdgpu_device_suspend(dev, true, true);
> > > +   amdgpu_device_suspend(dev, true);
> > > +   pci_save_state(dev->pdev);
> > > +   /* Shut down the device */
> > > +   pci_disable_device(dev->pdev);
> > > +   pci_set_power_state(dev->pdev, PCI_D3cold);
> >
> >
> > I think this will break D3 cold on ATPX systems (i.e. before PCIE d3
> > cold support).
> >
> > I'm not 100% sure but I'd really like to test it, as I don't think the
> > core will put the device into D3cold for us here.
>
> Should be the same as before, I just moved the pci funcs up from the
> callee into the caller, or are you talking about the switch from d3hot
> to d3cold?  I can make the hot/cold change a separate commit however.
> That said, it doesn't really matter what d3 state we choose here.  The
> APTX call cuts the power rail anyway (effectively d3cold).

It matters to the OS, as it has to bring the device out of cold for
certain operations that work in hot (like conifg space access).

But sorry I misread the patch I thought you were dropping the calls in
favour of the pci core doing them.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: move pci handling out of pm ops

[Dave Airlie]

On Fri, 22 Nov 2019 at 02:55, Alex Deucher  wrote:
>
> The documentation says the that PCI core handles this
> for you unless you choose to implement it.  Just rely
> on the PCI core to handle the pci specific bits.
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 16 +--
>  3 files changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 97843462c2fb..2e9d0be05f2f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1191,8 +1191,8 @@ int amdgpu_driver_open_kms(struct drm_device *dev, 
> struct drm_file *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>  struct drm_file *file_priv);
>  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
> -int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool fbcon);
> -int amdgpu_device_resume(struct drm_device *dev, bool resume, bool fbcon);
> +int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
> +int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
>  u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
>  int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
>  void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index b1408c5e4640..d832bd22ba9d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1090,6 +1090,7 @@ static int amdgpu_device_check_arguments(struct 
> amdgpu_device *adev)
>  static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum 
> vga_switcheroo_state state)
>  {
> struct drm_device *dev = pci_get_drvdata(pdev);
> +   int r;
>
> if (amdgpu_device_supports_boco(dev) && state == VGA_SWITCHEROO_OFF)
> return;
> @@ -1099,7 +1100,12 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
> /* don't suspend or resume card normally */
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>
> -   amdgpu_device_resume(dev, true, true);
> +   pci_set_power_state(dev->pdev, PCI_D0);
> +   pci_restore_state(dev->pdev);
> +   r = pci_enable_device(dev->pdev);
> +   if (r)
> +   DRM_WARN("pci_enable_device failed (%d)\n", r);
> +   amdgpu_device_resume(dev, true);
>
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> @@ -1107,7 +1113,11 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
> pr_info("amdgpu: switched off\n");
> drm_kms_helper_poll_disable(dev);
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> -   amdgpu_device_suspend(dev, true, true);
> +   amdgpu_device_suspend(dev, true);
> +   pci_save_state(dev->pdev);
> +   /* Shut down the device */
> +   pci_disable_device(dev->pdev);
> +   pci_set_power_state(dev->pdev, PCI_D3cold);


I think this will break D3 cold on ATPX systems (i.e. before PCIE d3
cold support).

I'm not 100% sure but I'd really like to test it, as I don't think the
core will put the device into D3cold for us here.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

radeon backtrace on fedora 31

[Dave Airlie]

5.3.4-300.fc31.x86_64

seems to be new.

https://retrace.fedoraproject.org/faf/reports/2726149/


Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: Add modeset module option

[Dave Airlie]

On Sat, 31 Mar 2018 at 06:45, Takashi Iwai  wrote:
>
> amdgpu driver lacks of modeset module option other drm drivers provide
> for enforcing or disabling the driver load.  Interestingly, the
> amdgpu_mode variable declaration is already found in the header file,
> but the actual implementation seems to have been forgotten.
>
> This patch adds the missing piece.

I'd like to land this patch, I realise people have NAKed it but for
consistency across drivers I'm going to ask we land it or something
like it.

The main use case for this is actually where you have amdgpu crashes
on load, and you want to debug them, people boot with nomodeset and
then modprobe amdgpu modeset=1 to get the crash in a running system.
This works for numerous other drivers, I'm not sure why amdgpu needs
to be the odd one out.

Reviewed-by: Dave Airlie 

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] radeon: add option so DVI always respect HPD over DDC

[Dave Airlie]

On Mon, 9 Sep 2019 at 08:52, Deucher, Alexander
 wrote:
>
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Dave Airlie
> > Sent: Sunday, September 1, 2019 11:09 PM
> > To: amd-gfx@lists.freedesktop.org
> > Subject: [PATCH] radeon: add option so DVI always respect HPD over DDC
> >
> > From: Dave Airlie 
> >
> > Purelink FX-D120 (DVI over fibre extendeders) drive the HPD line low on the
> > GPU side when the monitor side device is unplugged or loses the connection.
> > However the GPU side device seems to cache EDID in this case. Per DVI spec
> > the HPD line must be driven in order for EDID to be done, but we've met
> > enough broken devices (mainly
> > VGA->DVI convertors) that do the wrong thing with HPD that we ignore
> > it if a DDC probe succeeds.
> >
> > This patch adds an option to the radeon driver to always respect HPD on DVI
> > connectors such that if the HPD line isn't driven then EDID isn't probed.
>
> Probably cleaner to make this a connector property rather than a global 
> enable, but I'm not too pressed either way.

Just wanted a way to let them set it on the command line, rather than
run a script at bootup, but maybe it's cleaner, will look into it a
bit more.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 15/27] drm/dp_mst: Cleanup drm_dp_send_link_address() a bit

[Dave Airlie]

On Wed, 4 Sep 2019 at 06:48, Lyude Paul  wrote:
>
> Declare local pointer to the drm_dp_link_address_ack_reply struct
> instead of constantly dereferencing it through the union in
> txmsg->reply. Then, invert the order of conditionals so we don't have to
> do the bulk of the work inside them, and can wrap lines even less. Then
> finally, rearrange variable declarations a bit.
>
> Cc: Juston Li 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Signed-off-by: Lyude Paul 

Reviewed-by: Dave Airlie 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 11/27] drm/dp_mst: Constify guid in drm_dp_get_mst_branch_by_guid()

[Dave Airlie]

On Wed, 4 Sep 2019 at 06:48, Lyude Paul  wrote:
>
> And it's helper, we'll be using this in just a moment.
>

Reviewed-by: Dave Airlie 

> Cc: Juston Li 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 43452872efad..b44d3696c09a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2060,7 +2060,7 @@ static struct drm_dp_mst_branch 
> *drm_dp_get_mst_branch_device(struct drm_dp_mst_
>
>  static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper(
> struct drm_dp_mst_branch *mstb,
> -   uint8_t *guid)
> +   const uint8_t *guid)
>  {
> struct drm_dp_mst_branch *found_mstb;
> struct drm_dp_mst_port *port;
> @@ -2084,7 +2084,7 @@ static struct drm_dp_mst_branch 
> *get_mst_branch_device_by_guid_helper(
>
>  static struct drm_dp_mst_branch *
>  drm_dp_get_mst_branch_device_by_guid(struct drm_dp_mst_topology_mgr *mgr,
> -uint8_t *guid)
> +const uint8_t *guid)
>  {
> struct drm_dp_mst_branch *mstb;
> int ret;
> --
> 2.21.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 06/27] drm/dp_mst: Combine redundant cases in drm_dp_encode_sideband_req()

[Dave Airlie]

On Wed, 4 Sep 2019 at 06:48, Lyude Paul  wrote:
>
> Noticed this while working on adding a drm_dp_decode_sideband_req().
> DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct, so we can
> just combine their cases.

both use the same struct as enum path resources?

Since otherwise the patch doesn't make sense.

With that fixed:
Reviewed-by: Dave Airlie 

Re: [pull] amdgpu drm-next-5.4

[Dave Airlie]

On Sat, 31 Aug 2019 at 07:27, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> Mostly bug fixes.  The big addition is display support for renoir
> which is new for 5.4.  I realize it's a bit late to add it but the
> rest of the code for renoir is already in so it would be nice to
> get the display part in as well.  If not, let me know, and I'll
> respin without it.  Thanks!

dim: c072b0c24e6b ("drm/amdgpu: fix GFXOFF on Picasso and Raven2"):
Fixes: SHA1 in not pointing at an ancestor:
dim: 98f58ada2d37 ("drm/amdgpu/gfx9: update pg_flags after
determining if gfx off is possible")
dim: ERROR: issues in commits detected, aborting

b05f65d7720b172b6fde3abfa49ed66837071d45
 seems to be the correct ancestor in my tree.

No problems on the renoir code.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] radeon: add option so DVI always respect HPD over DDC

[Dave Airlie]

From: Dave Airlie 

Purelink FX-D120 (DVI over fibre extendeders) drive the HPD line
low on the GPU side when the monitor side device is unplugged
or loses the connection. However the GPU side device seems to cache
EDID in this case. Per DVI spec the HPD line must be driven in order
for EDID to be done, but we've met enough broken devices (mainly
VGA->DVI convertors) that do the wrong thing with HPD that we ignore
it if a DDC probe succeeds.

This patch adds an option to the radeon driver to always respect HPD
on DVI connectors such that if the HPD line isn't driven then EDID
isn't probed.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_connectors.c | 7 +++
 drivers/gpu/drm/radeon/radeon_drv.c| 4 
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 32808e50be12..d572e8ded9b9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -117,6 +117,7 @@ extern int radeon_uvd;
 extern int radeon_vce;
 extern int radeon_si_support;
 extern int radeon_cik_support;
+extern int radeon_respect_hpd;
 
 /*
  * Copy from radeon_drv.h so we don't have to include both and have conflicting
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c60d1a44d22a..e9b3924df06e 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1265,6 +1265,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
goto exit;
}
 
+   if (radeon_respect_hpd && radeon_connector->hpd.hpd != RADEON_HPD_NONE) 
{
+   if (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
+   ret = connector_status_disconnected;
+   goto exit;
+   }
+   }
+
if (radeon_connector->ddc_bus) {
dret = radeon_ddc_probe(radeon_connector, false);
 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index a6cbe11f79c6..556ae381ea86 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -207,6 +207,7 @@ int radeon_auxch = -1;
 int radeon_mst = 0;
 int radeon_uvd = 1;
 int radeon_vce = 1;
+int radeon_respect_hpd = 0;
 
 MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
 module_param_named(no_wb, radeon_no_wb, int, 0444);
@@ -312,6 +313,9 @@ int radeon_cik_support = 1;
 MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = 
disabled)");
 module_param_named(cik_support, radeon_cik_support, int, 0444);
 
+MODULE_PARM_DESC(respect_hpd, "For DVI always believe HPD");
+module_param_named(respect_hpd, radeon_respect_hpd, int, 0644);
+
 static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 14/17] drm/amd/display: Isolate DSC module from driver dependencies

[Dave Airlie]

On Thu, 29 Aug 2019 at 07:04, Bhawanpreet Lakha
 wrote:
>
> From: Bayan Zabihiyan 
>
> [Why]
> Edid Utility wishes to include DSC module from driver instead
> of doing it's own logic which will need to be updated every time
> someone modifies the driver logic.
>
> [How]
> Modify some functions such that we dont need to pass the entire
> DC structure as parameter.
> -Remove DC inclusion from module.
> -Filter out problematic types and inclusions

Do we really want the ifdef stuff upstream, the EDID utility isn't
shipped with the kernel is it.

Dave.

>
> Signed-off-by: Bayan Zabihiyan 
> Reviewed-by: Jun Lei 
> Acked-by: Bhawanpreet Lakha 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
>  drivers/gpu/drm/amd/display/dc/dc_dsc.h   | 14 +++-
>  drivers/gpu/drm/amd/display/dc/dc_hw_types.h  | 57 --
>  drivers/gpu/drm/amd/display/dc/dc_types.h |  9 +++
>  drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c   | 75 ---
>  drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h   | 12 ++-
>  6 files changed, 125 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 654679c4fded..82ea8cf8563e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3677,8 +3677,9 @@ create_stream_for_sink(struct amdgpu_dm_connector 
> *aconnector,
>  
> dc_link_get_link_cap(aconnector->dc_link));
>
> if (dsc_caps.is_dsc_supported)
> -   if 
> (dc_dsc_compute_config(aconnector->dc_link->ctx->dc,
> +   if 
> (dc_dsc_compute_config(aconnector->dc_link->ctx->dc->res_pool->dscs[0],
>   _caps,
> + 
> aconnector->dc_link->ctx->dc->debug.dsc_min_slice_height_override,
>   link_bandwidth_kbps,
>   >timing,
>   >timing.dsc_cfg))
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dsc.h 
> b/drivers/gpu/drm/amd/display/dc/dc_dsc.h
> index 6e42209f0e20..0ed2962add5a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dsc.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dsc.h
> @@ -30,6 +30,7 @@
>  #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_0  0x0a0   /* DP 1.4a SCR */
>  #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
>  #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2
> +#include "dc_types.h"
>
>  struct dc_dsc_bw_range {
> uint32_t min_kbps; /* Bandwidth if min_target_bpp_x16 is used */
> @@ -39,13 +40,21 @@ struct dc_dsc_bw_range {
> uint32_t stream_kbps; /* Uncompressed stream bandwidth */
>  };
>
> +struct display_stream_compressor {
> +   const struct dsc_funcs *funcs;
> +#ifndef AMD_EDID_UTILITY
> +   struct dc_context *ctx;
> +   int inst;
> +#endif
> +};
>
>  bool dc_dsc_parse_dsc_dpcd(const uint8_t *dpcd_dsc_basic_data,
> const uint8_t *dpcd_dsc_ext_data,
> struct dsc_dec_dpcd_caps *dsc_sink_caps);
>
>  bool dc_dsc_compute_bandwidth_range(
> -   const struct dc *dc,
> +   const struct display_stream_compressor *dsc,
> +   const uint32_t dsc_min_slice_height_override,
> const uint32_t min_kbps,
> const uint32_t max_kbps,
> const struct dsc_dec_dpcd_caps *dsc_sink_caps,
> @@ -53,8 +62,9 @@ bool dc_dsc_compute_bandwidth_range(
> struct dc_dsc_bw_range *range);
>
>  bool dc_dsc_compute_config(
> -   const struct dc *dc,
> +   const struct display_stream_compressor *dsc,
> const struct dsc_dec_dpcd_caps *dsc_sink_caps,
> +   const uint32_t dsc_min_slice_height_override,
> uint32_t target_bandwidth_kbps,
> const struct dc_crtc_timing *timing,
> struct dc_dsc_config *dsc_cfg);
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h 
> b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
> index dafc19a7b699..2869b26d966a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
> @@ -26,6 +26,8 @@
>  #ifndef DC_HW_TYPES_H
>  #define DC_HW_TYPES_H
>
> +#ifndef AMD_EDID_UTILITY
> +
>  #include "os_types.h"
>  #include "fixed31_32.h"
>  #include "signal_types.h"
> @@ -587,6 +589,8 @@ struct scaling_taps {
> bool integer_scaling;
>  };
>
> +#endif /* AMD_EDID_UTILITY */
> +
>  enum dc_timing_standard {
> DC_TIMING_STANDARD_UNDEFINED,
> DC_TIMING_STANDARD_DMT,
> @@ -708,30 +712,6 @@ enum dc_timing_3d_format {
> TIMING_3D_FORMAT_MAX,
>  };
>
> -enum trigger_delay {
> -   TRIGGER_DELAY_NEXT_PIXEL = 0,
> -   TRIGGER_DELAY_NEXT_LINE,
> -};
> -
> -enum 

Re: [pull] amdgpu, amdkfd, radeon, ttm drm-next-5.4

[Dave Airlie]

On Wed, 7 Aug 2019 at 06:03, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> The big updates here are support for new asics (navi14, navi12, arcturus).

Thanks Alex, but due to the readq/writeq this break my local
validation builds which means we need to land a fix for that somehow
first.

Also this is pretty conflict happy, so if you want to backmerge
5.3-rc3 before sending it I wouldn't object :-) (But I think I figured
them all out).

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: between commits d7d170a8e357 and 22051d9c4a57 begins issue page allocation failure in gnome-shell process

[Dave Airlie]

On Wed, 31 Jul 2019 at 05:34, Mikhail Gavrilov
 wrote:
>
> Is anyone here? Is everyone so busy what is wrong?
> RC2 is still affected by this issue and unusable for every day because
> opening a video in totem player cause DE a hang with a lot of
> messages:
>

This looks like dc_state got a size increase, Harry looks like your area.

Let's make dc_state not be so large. a 4 order allocation isn't
trivial for an object that we constantly alloc/destroy.

Dave.
> [ 1072.283518] amdgpu :0b:00.0: [gfxhub] retry page fault
> (src_id:0 ring:0 vmid:3 pasid:32769, for process gnome-shell pid 1948
> thread gnome-shel:cs0 pid 1983)
> [ 1072.283530] amdgpu :0b:00.0:   in page starting at address
> 0x0001c3385000 from 27
> [ 1072.283533] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
> [ 1072.283539] amdgpu :0b:00.0: [gfxhub] retry page fault
> (src_id:0 ring:0 vmid:3 pasid:32769, for process gnome-shell pid 1948
> thread gnome-shel:cs0 pid 1983)
> [ 1072.283541] amdgpu :0b:00.0:   in page starting at address
> 0x0001c3389000 from 27
> [ 1072.283543] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
> [ 1072.283548] amdgpu :0b:00.0: [gfxhub] retry page fault
> (src_id:0 ring:0 vmid:3 pasid:32769, for process gnome-shell pid 1948
> thread gnome-shel:cs0 pid 1983)
> [ 1072.283551] amdgpu :0b:00.0:   in page starting at address
> 0x0001c3387000 from 27
> [ 1072.283552] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
> [ 1072.283557] amdgpu :0b:00.0: [gfxhub] retry page fault
> (src_id:0 ring:0 vmid:3 pasid:32769, for process gnome-shell pid 1948
> thread gnome-shel:cs0 pid 1983)
> [ 1072.283559] amdgpu :0b:00.0:   in page starting at address
> 0x0001c3388000 from 27
> [ 1072.283560] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
> [ 1072.283565] amdgpu :0b:00.0: [gfxhub] retry page fault
> (src_id:0 ring:0 vmid:3 pasid:32769, for process gnome-shell pid 1948
> thread gnome-shel:cs0 pid 1983)
> [ 1072.283566] amdgpu :0b:00.0:   in page starting at address
> 0x0001c338c000 from 27
> [ 1072.283568] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
>
> All Vega GPU is affected: Vega 56, Vega 64, Radeon VII
>
> --
> Best Regards,
> Mike Gavrilov.
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: The issue with page allocation 5.3 rc1-rc2 (seems drm culprit here)

[Dave Airlie]

On Mon, 5 Aug 2019 at 08:23, Mikhail Gavrilov
 wrote:
>
> Hi folks,
> Two weeks ago when commit 22051d9c4a57 coming to my system.
> Started happen randomly errors:
> "gnome-shell: page allocation failure: order:4,
> mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> nodemask=(null),cpuset=/,mems_allowed=0"
> Symptoms:
> The screen goes out as in energy saving.
> And it is impossible to wake the computer in a few minutes.
>
> I am making bisect and looks like the first bad commit is 476e955dd679.
> Here full bisect logs: https://mega.nz/#F!kgYFxAIb!v1tcHANPy2ns1lh4LQLeIg
>
> I wrote about my find to the amd-gfx mailing list, but no one answer me.
> Until yesterday, I thought it was a bug in the amdgpu driver.
> But yesterday, after the next occurrence of an error, the system hangs
> completely already with another error.

Does it happen if you disable CONFIG_DRM_AMD_DC_DCN2_0, I'm assuming
you don't have a navi gpu.

I think some struct grew too large in the navi merge, hopefully amd
care, else we have to disable navi before release.

I've directed this at the main AMD devs who might be helpful.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, radeon, amdkfd drm-next-5.3

[Dave Airlie]

On Thu, 27 Jun 2019 at 13:07, Dave Airlie  wrote:
>
> Thanks,
>
> I've pulled this, but it introduced one warning
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c: In 
> function ‘vcn_v2_0_start_dpg_mode’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1013:15:
>  warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
> (uint32_t)((uint64_t)adev->vcn.dpg_sram_curr_addr -
>^
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1014:4:
>  warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
> (uint64_t)adev->vcn.dpg_sram_cpu_addr));
> ^
>

on arm32 buiild.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 08/24] drm/amd/display: add audio related regs

[Dave Airlie]

On Fri, 7 Jun 2019 at 06:55, Bhawanpreet Lakha
 wrote:
>
> From: Charlene Liu 
>
> Signed-off-by: Charlene Liu 
> Reviewed-by: Chris Park 
> Acked-by: Bhawanpreet Lakha 
> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 4 +---
>  drivers/gpu/drm/amd/display/dc/dce/dce_audio.h | 7 +++
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> index 7f6d724686f1..d43d5d924c19 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> @@ -22,7 +22,7 @@
>   * Authors: AMD
>   *
>   */
> -
> +#include "../dc.h"

Is this include needed? just seems wierd to have added it with no mention.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: arm32 build failure after abe882a39a9c ("drm/amd/display: fix issue with eDP not detected on driver load")

[Dave Airlie]

Hi Alex,

please resolve this ASAP, I cannot pull your tree without this fixed
as it breaks my arm builds here.

an 8 second delay there seems pointless and arbitary, an 8 sec delay
there without a comment, seems like a lack of review.

Dave.

On Tue, 18 Jun 2019 at 11:12, Nathan Chancellor
 wrote:
>
> Hi all,
>
> After commit abe882a39a9c ("drm/amd/display: fix issue with eDP not
> detected on driver load") in -next, arm32 allyesconfig builds start
> failing at link time:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/amd/display/dc/core/dc_link.o: in
> function `dc_link_detect':
> dc_link.c:(.text+0x260c): undefined reference to `__bad_udelay'
>
> arm32 only allows a udelay value of up to 2000, see
> arch/arm/include/asm/delay.h for more info.
>
> Please look into this when you have a chance!
> Nathan

Re: [pull] amdgpu, ttm drm-next-5.3

[Dave Airlie]

On Thu, 6 Jun 2019 at 05:12, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 5.3:
>
> amdgpu:
> - Revert timeline support until KHR is ready
> - Various driver reload fixes
> - Refactor clock handling in DC
> - Aux fixes for DC
> - Bandwidth calculation updates for DC
> - Fix documentation due to file rename
> - RAS fix
> - Fix race in late_init
>
> ttm:
> - Allow for better forward progress when there is heavy memory contention

dim: 137a7da92557 ("Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to
amdgpu""): mandatory review missing.
dim: cf25b6444376 ("gpu: amdgpu: fix broken amdgpu_dma_buf.c
references"): SHA1 in fixes line not found:
dim: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
amdgpu_dma_buf.[ch]")

The first I'm not worried about, but the fixes line should be fixed
before I can pull this.
2fbd6f94accdbb223acccada68940b50b0c668d9 is the upstream commit in my tree.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS

[Dave Airlie]

On Sat, 1 Jun 2019 at 06:04, Kuehling, Felix  wrote:
>
> On 2019-05-30 11:13 p.m., Dave Airlie wrote:
> > On Sat, 25 May 2019 at 05:48, Kuehling, Felix  
> > wrote:
> >> On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
> >>> Add a new kfd ioctl to allocate queue GWS. Queue
> >>> GWS is released on queue destroy.
> >>>
> >>> Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
> >>> Signed-off-by: Oak Zeng 
> >> Reviewed-by: Felix Kuehling 
> >>
> > btw just noticed in passing we are adding new features to kfd, is
> > there an open source developed userspace to go along with this, there
> > needs to a dev branch in public before new ioctls/uapi surfaces should
> > be added to the kernel.
> >
> > The commits should probably have pointers to that branch.
>
> Ah, a chicken and egg problem. I think this is the first time we're
> adding a new ioctl to upstream KFD rather than upstreaming one that's
> been developed internally first. Maybe not the right way to do it.

There is no chicken/egg problem here. You develop kernel and userspace
in parallel in the open, once you are happy and both sides are
reviewed you merge kernel then userspace.

Dave.

>
> I should be able to publish the user mode code in libhsakmt next week.
> Then we'll work on a kfdtest to validate the firmware functionality.
> Finally we'll use GWS further up the software stack for synchronization
> of concurrent compute workgroups.
>
> Regards,
>Felix
>
>
> >
> > Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS

[Dave Airlie]

On Sat, 25 May 2019 at 05:48, Kuehling, Felix  wrote:
>
> On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
> > Add a new kfd ioctl to allocate queue GWS. Queue
> > GWS is released on queue destroy.
> >
> > Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
> > Signed-off-by: Oak Zeng 
>
> Reviewed-by: Felix Kuehling 
>

btw just noticed in passing we are adding new features to kfd, is
there an open source developed userspace to go along with this, there
needs to a dev branch in public before new ioctls/uapi surfaces should
be added to the kernel.

The commits should probably have pointers to that branch.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

[Dave Airlie]

On Wed, 29 May 2019 at 02:47, Emil Velikov  wrote:
>
> On 2019/05/28, Koenig, Christian wrote:
> > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > On 2019/05/28, Daniel Vetter wrote:
> > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > >>  wrote:
> > >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> >  [SNIP]
> > > Might be a good idea looking into reverting it partially, so that at
> > > least command submission and buffer allocation is still blocked.
> >  I thought the issue is a lot more than vainfo, it's pretty much every
> >  hacked up compositor under the sun getting this wrong one way or
> >  another. Thinking about this some more, I also have no idea how you'd
> >  want to deprecate rendering on primary nodes in general. Apparently
> >  that breaks -modesetting already, and probably lots more compositors.
> >  And it looks like we're finally achieve the goal kms set out to 10
> >  years ago, and new compositors are sprouting up all the time. I guess
> >  we could just break them all (on new hardware) and tell them to all
> >  suck it up. But I don't think that's a great option. And just
> >  deprecating this on amdgpu is going to be even harder, since then
> >  everywhere else it'll keep working, and it's just amdgpu.ko that looks
> >  broken.
> > 
> >  Aside: I'm not supporting Emil's idea here because it fixes any issues
> >  Intel has - Intel doesn't care. I support it because reality sucks,
> >  people get this render vs. primary vs. multi-gpu prime wrong all the
> >  time (that's also why we have hardcoded display+gpu pairs in mesa for
> >  the various soc combinations out there), and this looks like a
> >  pragmatic solution. It'd be nice if every compositor and everything
> >  else would perfectly support multi gpu and only use render nodes for
> >  rendering, and only primary nodes for display. But reality is that
> >  people hack on stuff until gears on screen and then move on to more
> >  interesting things (to them). So I don't think we'll ever win this :-/
> > >>> Yeah, but this is a classic case of working around user space issues by
> > >>> making kernel changes instead of fixing user space.
> > >>>
> > >>> Having privileged (output control) and unprivileged (rendering control)
> > >>> functionality behind the same node is a mistake we have made a long time
> > >>> ago and render nodes finally seemed to be a way to fix that.
> > >>>
> > >>> I mean why are compositors using the primary node in the first place?
> > >>> Because they want to have access to privileged resources I think and in
> > >>> this case it is perfectly ok to do so.
> > >>>
> > >>> Now extending unprivileged access to the primary node actually sounds
> > >>> like a step into the wrong direction to me.
> > >>>
> > >>> I rather think that we should go down the route of completely dropping
> > >>> command submission and buffer allocation through the primary node for
> > >>> non master clients. And then as next step at some point drop support for
> > >>> authentication/flink.
> > >>>
> > >>> I mean we have done this with UMS as well and I don't see much other way
> > >>> to move forward and get rid of those ancient interface in the long term.
> > >> Well kms had some really good benefits that drove quick adoption, like
> > >> "suspend/resume actually has a chance of working" or "comes with
> > >> buffer management so you can run multiple gears".
> > >>
> > >> The render node thing is a lot more niche use case (prime, better priv
> > >> separation), plus "it's cleaner design". And the "cleaner design" part
> > >> is something that empirically doesn't seem to matter :-/ Just two
> > >> examples:
> > >> - KHR_display/leases just iterated display resources on the fd needed
> > >> for rendering (and iirc there was even a patch to expose that for
> > >> render nodes too so it works with DRI3), because implementing
> > >> protocols is too hard. Barely managed to stop that one before it
> > >> happened.
> > >> - Various video players use the vblank ioctl on directly to schedule
> > >> frames, without telling the compositor. I discovered that when I
> > >> wanted to limite the vblank ioctl to master clients only. Again,
> > >> apparently too hard to use the existing extensions, or fix the bugs in
> > >> there, or whatever. One userspace got fixed last year, but it'll
> > >> probably get copypasted around forever :-/
> > >>
> > >> So I don't think we'll ever manage to roll a clean split out, and best
> > >> we can do is give in and just hand userspace what it wants. As much as
> > >> that's misguided and unclean and all that. Maybe it'll result in a
> > >> least fewer stuff getting run as root to hack around this, because
> > >> fixing properly seems not to be on the table.
> > >>
> > >> The beauty of kms is that we've achieved the mission, everyone's
> > >> writing their own thing. Which is also terrible, and I don't 

Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

[Dave Airlie]

Daniel, drm-misc-next-fixes?

Dave.

On Fri, 26 Apr 2019 at 12:25,  wrote:
>
> Hi Dave,
>
> > -Original Message-
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Friday, April 26, 2019 11:19 AM
> > To: Yamada, Masahiro/山田 真弘 
> > Cc: David Airlie ; Daniel Vetter ;
> > dri-devel ; nouveau
> > ; Sam Ravnborg ; David
> > (ChunMing) Zhou ; amd-gfx mailing list
> > ; James (Qian) Wang
> > ; Ben Skeggs ;
> > linux-arm-msm ; Intel Graphics
> > Development ;
> > intel-gvt-...@lists.freedesktop.org; Linux Kernel Mailing List
> > ; Christian König
> > ; Alex Deucher ;
> > freedr...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with
> > $(srctree)/
> >
> > On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
> >  wrote:
> > >
> > > Hi.
> > >
> > >
> > > On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> > >  wrote:
> > > >
> > > > Currently, the Kbuild core manipulates header search paths in a crazy
> > > > way [1].
> > > >
> > > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > > > the search paths in the srctree. Some Makefiles are already written
> > in
> > > > that way, but not all. The goal of this work is to make the notation
> > > > consistent, and finally get rid of the gross hacks.
> > > >
> > > > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > > > ("kbuild: do not drop -I without parameter").
> > > >
> > > > [1]: https://patchwork.kernel.org/patch/9632347/
> > > >
> > > > Signed-off-by: Masahiro Yamada 
> > > > Reviewed-by: Sam Ravnborg 
> > > > ---
> > > >
> > > > I put all gpu/drm changes into a single patch because
> > > > they are trivial conversion.
> > > >
> > > > If you are interested in the big picture of this work,
> > > > the full patch set is available at the following URL.
> > > >
> > > >
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.g
> > it build-test
> > >
> > >
> > > Is somebody taking care of this?
> > >
> >
> > Are you expecting this to be merged in the drm tree? if so please
> > indicate that when posting.
>
>
> Sorry for unclearness.
>
> Could you apply this to your drm tree?
>
> Thanks.
>
>
>
>
> > I'd assumed this would go via kbuild tree.
> >
> > If the later,
> > Acked-by: Dave Airlie 
> > Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

[Dave Airlie]

On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
 wrote:
>
> Hi.
>
>
> On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
>  wrote:
> >
> > Currently, the Kbuild core manipulates header search paths in a crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > the search paths in the srctree. Some Makefiles are already written in
> > that way, but not all. The goal of this work is to make the notation
> > consistent, and finally get rid of the gross hacks.
> >
> > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > ("kbuild: do not drop -I without parameter").
> >
> > [1]: https://patchwork.kernel.org/patch/9632347/
> >
> > Signed-off-by: Masahiro Yamada 
> > Reviewed-by: Sam Ravnborg 
> > ---
> >
> > I put all gpu/drm changes into a single patch because
> > they are trivial conversion.
> >
> > If you are interested in the big picture of this work,
> > the full patch set is available at the following URL.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git 
> > build-test
>
>
> Is somebody taking care of this?
>

Are you expecting this to be merged in the drm tree? if so please
indicate that when posting.

I'd assumed this would go via kbuild tree.

If the later,
Acked-by: Dave Airlie 
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

[Dave Airlie]

> Well, I've got commit rights as well.
>
> Going to remove the warning, add your rb and push everything if nobody
> objects in the next hour or so.

So this got committed and is in my -next tree, but where is the
userspace and igt tests?

There needs to be a functional mesa userspace and a set of IGTs for
this, maybe I've overlooked them if I haven't we can't ship this.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, ttm drm-next-5.2

[Dave Airlie]

On Fri, 29 Mar 2019 at 03:44, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.2:

32-bit arm build:

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:
In function ‘smu_v11_0_notify_memory_pool_location’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:530:12:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]

Please fix and resend.

Thanks,
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

[Dave Airlie]

On Tue, 5 Feb 2019 at 04:35, Alex Deucher  wrote:
>
> On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie  wrote:
> >
> > On Mon, 4 Feb 2019 at 13:27, Dave Airlie  wrote:
> > >
> > > On Sat, 26 Jan 2019 at 09:15, Alex Deucher  wrote:
> > > >
> > > > Hi Dave, Daniel,
> > > >
> > > > New stuff for 5.1.
> > > > amdgpu:
> > > > - DC bandwidth formula updates
> > > > - Support for DCC on scanout surfaces
> > > > - Support for multiple IH rings on soc15 asics
> > > > - Fix xgmi locking
> > > > - Add sysfs interface to get pcie usage stats
> > > > - Simplify DC i2c/aux code
> > > > - Initial support for BACO on vega10/20
> > > > - New runtime SMU feature debug interface
> > > > - Expand existing sysfs power interfaces to new clock domains
> > > > - Handle kexec properly
> > > > - Simplify IH programming
> > > > - Rework doorbell handling across asics
> > > > - Drop old CI DPM implementation
> > > > - DC page flipping fixes
> > > > - Misc SR-IOV fixes
> > > >
> > >
> > > Hi Alex,
> > >
> > > I pulled this, but it introduced a warning, so I dropped it for now
> > > and the fix is on the list, please add it and resend,
> > >
> >
> > Just realised the warning was already there, so I pulled this again,
> > please send another next with the warning fix when you can.
>
> I was planning to send it via -fixes since the original patch was in
> 5.0, but I can include it in both -fixes and -next if you'd prefer.

Oh wow, I'm not sure how I missed it, please send via -fixes and I'll backmerge.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

[Dave Airlie]

On Mon, 4 Feb 2019 at 13:27, Dave Airlie  wrote:
>
> On Sat, 26 Jan 2019 at 09:15, Alex Deucher  wrote:
> >
> > Hi Dave, Daniel,
> >
> > New stuff for 5.1.
> > amdgpu:
> > - DC bandwidth formula updates
> > - Support for DCC on scanout surfaces
> > - Support for multiple IH rings on soc15 asics
> > - Fix xgmi locking
> > - Add sysfs interface to get pcie usage stats
> > - Simplify DC i2c/aux code
> > - Initial support for BACO on vega10/20
> > - New runtime SMU feature debug interface
> > - Expand existing sysfs power interfaces to new clock domains
> > - Handle kexec properly
> > - Simplify IH programming
> > - Rework doorbell handling across asics
> > - Drop old CI DPM implementation
> > - DC page flipping fixes
> > - Misc SR-IOV fixes
> >
>
> Hi Alex,
>
> I pulled this, but it introduced a warning, so I dropped it for now
> and the fix is on the list, please add it and resend,
>

Just realised the warning was already there, so I pulled this again,
please send another next with the warning fix when you can.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

[Dave Airlie]

On Sat, 26 Jan 2019 at 09:15, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.1.
> amdgpu:
> - DC bandwidth formula updates
> - Support for DCC on scanout surfaces
> - Support for multiple IH rings on soc15 asics
> - Fix xgmi locking
> - Add sysfs interface to get pcie usage stats
> - Simplify DC i2c/aux code
> - Initial support for BACO on vega10/20
> - New runtime SMU feature debug interface
> - Expand existing sysfs power interfaces to new clock domains
> - Handle kexec properly
> - Simplify IH programming
> - Rework doorbell handling across asics
> - Drop old CI DPM implementation
> - DC page flipping fixes
> - Misc SR-IOV fixes
>

Hi Alex,

I pulled this, but it introduced a warning, so I dropped it for now
and the fix is on the list, please add it and resend,

Thanks.
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu

[Dave Airlie]

Alex,

can you get this into next and resend the pull?

I don't like adding warnings.

Dave.

On Fri, 1 Feb 2019 at 06:10, Kuehling, Felix  wrote:
>
> Thank you, Nathan. I applied your patch to amd-staging-drm-next.
>
> Sorry for the late response. I'm catching up with my email backlog after
> a vacation.
>
> Regards,
>Felix
>
> On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: warning:
> > 'CONFIG_X86_64' is not defined, evaluates to 0 [-Wundef]
> > #if CONFIG_X86_64
> >  ^
> > 1 warning generated.
> >
> > Fixes: d1c234e2cd10 ("drm/amdkfd: Allow building KFD on ARM64 (v2)")
> > Signed-off-by: Nathan Chancellor 
> > ---
> >
> > Resending as I forgot to add the lists...
> >
> >   drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > index 5d85ff341385..2e7c44955f43 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > @@ -863,7 +863,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, 
> > int *avail_size,
> >   return 0;
> >   }
> >
> > -#if CONFIG_X86_64
> > +#ifdef CONFIG_X86_64
> >   static int kfd_fill_iolink_info_for_cpu(int numa_node_id, int *avail_size,
> >   uint32_t *num_entries,
> >   struct crat_subtype_iolink *sub_type_hdr)
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu drm-next-4.21

[Dave Airlie]

On Thu, 13 Dec 2018 at 07:13, Alex Deucher  wrote:
>
> Hi Dave,
>
> Updates for 4.21:
> - Powerplay updates for newer polaris variants
> - Add cursor plane update fast path
> - Enable gpu reset by default on CI parts
> - Fix config with KFD/HSA not enabled
> - Misc bug fixes
>

Either this or the previous one broke the etnaviv build, I see two
reports on the list of this breakage from the kbuild robot but no
mention of it, can you guys either stick some arm cross compiles in
your build paths or keep an eye on the kbuild robot emails for your
branches.

I created my own fix and pushed it in the merge commit.

Dave.

> The following changes since commit 22666cc1481ae3814d9c7718418cc4a3aa7d90c3:
>
>   drm/amdgpu: move IV prescreening into the GMC code (2018-12-07 18:14:26 
> -0500)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-next-4.21
>
> for you to fetch changes up to 674e78acae0dfb4beb56132e41cbae5b60f7d662:
>
>   drm/amd/display: Add fast path for cursor plane updates (2018-12-12 
> 15:32:10 -0500)
>
> 
> Alex Deucher (1):
>   drm/amdgpu/powerplay: Add special avfs cases for some polaris asics (v3)
>
> Andrey Grodzovsky (1):
>   drm/amdgpu: Enable GPU recovery by default for CI
>
> Kuehling, Felix (1):
>   drm/amdgpu: Fix stub function name
>
> Nicholas Kazlauskas (4):
>   Revert "drm/amd/display: Set RMX_ASPECT as default"
>   drm/amd/display: Fix unintialized max_bpc state values
>   drm/amd/display: Fix duplicating scaling/underscan connector state
>   drm/amd/display: Add fast path for cursor plane updates
>
> Rex Zhu (1):
>   drm/amdgpu: Limit vm max ctx number to 4096
>
> Tiecheng Zhou (1):
>   drm/amdgpu: bypass RLC init under sriov for Tonga (v2)
>
> YueHaibing (1):
>   drm/amdgpu: remove set but not used variable 'grbm_soft_reset'
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 79 
> --
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  8 +++
>  .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 54 +++
>  8 files changed, 147 insertions(+), 12 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

[Dave Airlie]

On Fri, 19 Oct 2018 at 18:51, Daniel Vetter  wrote:
>
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there's lots of value in having them: A
> cross-vendor interface isn't useful if every driver implements it
> slightly differently.
>
> I think there's 2 questions here:
>
> - Do we want to make such testcases mandatory?

Yes I think if at all practical it probably makes sense to have some
mandatory test cases for all cross-vendor features, or features that
might become cross vendor in the future.

>
> - If yes, are we there yet, or is there something crucially missing
>   still?

I think the does igt build in all the places needed is the main one,
I've no idea what a baseline IGT test run looks like on non-intel hw,
how useful is it?

Acked-by: Dave Airlie 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu/kfd, radeon, ttm, scheduler drm-next-4.20

[Dave Airlie]

On Thu, 20 Sep 2018 at 14:03, Dave Airlie  wrote:
>
> On my 32-bit arm build
>
> MODPOST 1797 modules
> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Somebody added a ul/ul without using the do_div stuff.
>
> I won't pull this until it's fixed.

It seems to be the mod in amdgpu_vm.c:amdgpu_vm_pt_descendant.

>
> Dave.
> On Sat, 15 Sep 2018 at 01:52, Alex Deucher  wrote:
> >
> > Hi Dave,
> >
> > First pull for 4.20 for amdgpu/kfd, radeon, ttm, and the GPU scheduler.
> > amdgpu/kfd:
> > - Picasso (new APU) support
> > - Raven2 (new APU) support
> > - Vega20 enablement
> > - ACP powergating improvements
> > - Add ABGR/XBGR display support
> > - VCN JPEG engine support
> > - Initial xGMI support
> > - Use load balancing for engine scheduling
> > - Lots of new documentation
> > - Rework and clean up i2c and aux handling in DC
> > - Add DP YCbCr 4:2:0 support in DC
> > - Add DMCU firmware loading for Raven (used for ABM and PSR)
> > - New debugfs features in DC
> > - LVDS support in DC
> > - Implement wave kill for gfx/compute (light weight reset for shaders)
> > - Use AGP aperture to avoid gart mappings when possible
> > - GPUVM performance improvements
> > - Bulk moves for more efficient GPUVM LRU handling
> > - Merge amdgpu and amdkfd into one module
> > - Enable gfxoff and stutter mode on Raven
> > - Misc cleanups
> >
> > Scheduler:
> > - Load balancing support
> > - Bug fixes
> >
> > ttm:
> > - Bulk move functionality
> > - Bug fixes
> >
> > radeon:
> > - Misc cleanups
> >
> > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> >
> >   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> >
> > are available in the git repository at:
> >
> >   git://people.freedesktop.org/~agd5f/linux drm-next-4.20
> >
> > for you to fetch changes up to 0957dc7097a3f462f6cedb45cf9b9785cc29e5bb:
> >
> >   drm/amdgpu: revert "stop using gart_start as offset for the GTT domain" 
> > (2018-09-14 10:05:42 -0500)
> >
> > 
> > Alex Deucher (22):
> >   drm/amdgpu/pp: endian fixes for process_pptables_v1_0.c
> >   drm/amdgpu/pp: endian fixes for processpptables.c
> >   drm/amdgpu/powerplay: check vrefresh when when changing displays
> >   drm/amdgpu: add AVFS control to PP_FEATURE_MASK
> >   drm/amdgpu/powerplay/smu7: enable AVFS control via ppfeaturemask
> >   drm/amdgpu/powerplay/vega10: enable AVFS control via ppfeaturemask
> >   Revert "drm/amdgpu: Add nbio support for vega20 (v2)"
> >   drm/amdgpu: remove experimental flag for vega20
> >   drm/amdgpu/display: add support for LVDS (v5)
> >   drm/amdgpu: add missing CHIP_HAINAN in amdgpu_ucode_get_load_type
> >   drm/amdgpu/gmc9: rework stolen vga memory handling
> >   drm/amdgpu/gmc9: don't keep stolen memory on Raven
> >   drm/amdgpu/gmc9: don't keep stolen memory on vega12
> >   drm/amdgpu/gmc9: don't keep stolen memory on vega20
> >   drm/amdgpu/gmc: add initial xgmi structure to amdgpu_gmc structure
> >   drm/amdgpu/gmc9: add a new gfxhub 1.1 helper for xgmi
> >   drm/amdgpu/gmc9: Adjust GART and AGP location with xgmi offset (v2)
> >   drm/amdgpu: use IP presence to free uvd and vce handles
> >   drm/amdgpu: set external rev id for raven2
> >   drm/amdgpu/soc15: clean up picasso support
> >   drm/amdgpu: simplify Raven, Raven2, and Picasso handling
> >   drm/amdgpu/display: return proper error codes in dm
> >
> > Alvin lee (2):
> >   drm/amd/display: Enable Stereo in Dal3
> >   drm/amd/display: Program vsc_infopacket in commit_planes_for_stream
> >
> > Amber Lin (4):
> >   drm/amdgpu: Merge amdkfd into amdgpu
> >   drm/amdgpu: Remove CONFIG_HSA_AMD_MODULE
> >   drm/amdgpu: Move KFD parameters to amdgpu (v3)
> >   drm/amdgpu: Relocate some definitions v2
> >
> > Andrey Grodzovsky (8):
> >   drm/amdgpu: Fix page fault and kasan warning on pci device remove.
> >   drm/scheduler: Add job dependency trace.
> >   drm/amdgpu: Add job pipe sync dependecy trace
> >   drm/scheduler: Add stopped flag to drm_sched_entity
> >   drm/amdgpu: Refine gmc9 VM fault print.
> >   drm/amdgpu: Use drm_dev_unplug in PCI .remove
> >   drm/amdgpu: Fix SDMA TO after GPU reset v3
> >   drm/amd/display: Fix pf

Re: [pull] amdgpu/kfd, radeon, ttm, scheduler drm-next-4.20

[Dave Airlie]

On my 32-bit arm build

MODPOST 1797 modules
ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

Somebody added a ul/ul without using the do_div stuff.

I won't pull this until it's fixed.

Dave.
On Sat, 15 Sep 2018 at 01:52, Alex Deucher  wrote:
>
> Hi Dave,
>
> First pull for 4.20 for amdgpu/kfd, radeon, ttm, and the GPU scheduler.
> amdgpu/kfd:
> - Picasso (new APU) support
> - Raven2 (new APU) support
> - Vega20 enablement
> - ACP powergating improvements
> - Add ABGR/XBGR display support
> - VCN JPEG engine support
> - Initial xGMI support
> - Use load balancing for engine scheduling
> - Lots of new documentation
> - Rework and clean up i2c and aux handling in DC
> - Add DP YCbCr 4:2:0 support in DC
> - Add DMCU firmware loading for Raven (used for ABM and PSR)
> - New debugfs features in DC
> - LVDS support in DC
> - Implement wave kill for gfx/compute (light weight reset for shaders)
> - Use AGP aperture to avoid gart mappings when possible
> - GPUVM performance improvements
> - Bulk moves for more efficient GPUVM LRU handling
> - Merge amdgpu and amdkfd into one module
> - Enable gfxoff and stutter mode on Raven
> - Misc cleanups
>
> Scheduler:
> - Load balancing support
> - Bug fixes
>
> ttm:
> - Bulk move functionality
> - Bug fixes
>
> radeon:
> - Misc cleanups
>
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
>
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-next-4.20
>
> for you to fetch changes up to 0957dc7097a3f462f6cedb45cf9b9785cc29e5bb:
>
>   drm/amdgpu: revert "stop using gart_start as offset for the GTT domain" 
> (2018-09-14 10:05:42 -0500)
>
> 
> Alex Deucher (22):
>   drm/amdgpu/pp: endian fixes for process_pptables_v1_0.c
>   drm/amdgpu/pp: endian fixes for processpptables.c
>   drm/amdgpu/powerplay: check vrefresh when when changing displays
>   drm/amdgpu: add AVFS control to PP_FEATURE_MASK
>   drm/amdgpu/powerplay/smu7: enable AVFS control via ppfeaturemask
>   drm/amdgpu/powerplay/vega10: enable AVFS control via ppfeaturemask
>   Revert "drm/amdgpu: Add nbio support for vega20 (v2)"
>   drm/amdgpu: remove experimental flag for vega20
>   drm/amdgpu/display: add support for LVDS (v5)
>   drm/amdgpu: add missing CHIP_HAINAN in amdgpu_ucode_get_load_type
>   drm/amdgpu/gmc9: rework stolen vga memory handling
>   drm/amdgpu/gmc9: don't keep stolen memory on Raven
>   drm/amdgpu/gmc9: don't keep stolen memory on vega12
>   drm/amdgpu/gmc9: don't keep stolen memory on vega20
>   drm/amdgpu/gmc: add initial xgmi structure to amdgpu_gmc structure
>   drm/amdgpu/gmc9: add a new gfxhub 1.1 helper for xgmi
>   drm/amdgpu/gmc9: Adjust GART and AGP location with xgmi offset (v2)
>   drm/amdgpu: use IP presence to free uvd and vce handles
>   drm/amdgpu: set external rev id for raven2
>   drm/amdgpu/soc15: clean up picasso support
>   drm/amdgpu: simplify Raven, Raven2, and Picasso handling
>   drm/amdgpu/display: return proper error codes in dm
>
> Alvin lee (2):
>   drm/amd/display: Enable Stereo in Dal3
>   drm/amd/display: Program vsc_infopacket in commit_planes_for_stream
>
> Amber Lin (4):
>   drm/amdgpu: Merge amdkfd into amdgpu
>   drm/amdgpu: Remove CONFIG_HSA_AMD_MODULE
>   drm/amdgpu: Move KFD parameters to amdgpu (v3)
>   drm/amdgpu: Relocate some definitions v2
>
> Andrey Grodzovsky (8):
>   drm/amdgpu: Fix page fault and kasan warning on pci device remove.
>   drm/scheduler: Add job dependency trace.
>   drm/amdgpu: Add job pipe sync dependecy trace
>   drm/scheduler: Add stopped flag to drm_sched_entity
>   drm/amdgpu: Refine gmc9 VM fault print.
>   drm/amdgpu: Use drm_dev_unplug in PCI .remove
>   drm/amdgpu: Fix SDMA TO after GPU reset v3
>   drm/amd/display: Fix pflip IRQ status after gpu reset.
>
> Anthony Koo (10):
>   drm/amd/display: Refactor FreeSync module
>   drm/amd/display: add method to check for supported range
>   drm/amd/display: Fix bug where refresh rate becomes fixed
>   drm/amd/display: Fix bug that causes black screen
>   drm/amd/display: Add back code to allow for rounding error
>   drm/amd/display: fix LFC tearing at top of screen
>   drm/amd/display: refactor vupdate interrupt registration
>   drm/amd/display: Correct rounding calcs in mod_freesync_is_valid_range
>   drm/amd/display: add config for sending VSIF
>   drm/amd/display: move edp fast boot optimization flag to stream
>
> Bhawanpreet Lakha (3):
>   drm/amd/display: Build stream update and plane updates in dm
>   drm/amd/display: Add Raven2 definitions in dc
>   drm/amd/display: Add DC config flag for Raven2 (v2)
>
> Boyuan Zhang (6):
>   drm/amdgpu: add emit reg write reg wait for 

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Dave Airlie]

On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom  wrote:
>
> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote:
> >>>> On 31 August 2018 at 15:38, Michel Dänzer  wrote:
> >>>>> [ Adding the amd-gfx list ]
> >>>>>
> >>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
> >>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote:
> >>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom 
> >>>>>>> wrote:
> >>>>>>>> To determine whether a device node is a drm device
> >>>>>>>> node or not, the code
> >>>>>>>> currently compares the node's major number to the static drm major
> >>>>>>>> device
> >>>>>>>> number.
> >>>>>>>>
> >>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients,
> >>>>>>>>
> >>>>>>> Any particular reason why the code doesn't use a fixed node there?
> >>>>>>> It will make the diff vs the in-kernel driver a bit smaller.
> >>>>>> Because then it won't be able to interoperate with other in-tree
> >>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers.
> >>>>>> There is no clean way to share the minor number allocation
> >>>>>> with in-tree
> >>>>>> drm, so standalone vmwgfx is using dynamic major allocation.
> >>>>> I wonder why I haven't heard of any of these issues with the standalone
> >>>>> version of amdgpu shipped in packaged AMD releases. Does that
> >>>>> also use a
> >>>>> different major number? If yes, maybe it's just that nobody has tried
> >>>>> Xwayland clients with that driver. If no, how does it avoid the other
> >>>>> issues described above?
> >>>>>
> >>>> AFAICT, the difference is that the standalone vmwgfx uses an internal
> >>>> copy of drm core.
> >>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor
> >>>> it can use.
> >>>>
> >>>> -Emil
> >>> Actually, standalone vmwgfx could perhaps also try to allocate minors
> >>> from 63 and downwards. That might work, but needs some verification.
> >>>
> >> So unfortuntately this doesn't work since the in-tree drm's file operations
> >> are registered with the DRM_MAJOR.
> >> So I still think the patch is the way to go. If people are concerned that
> >> also fbdev file descriptors are allowed, perhaps there are other sysfs
> >> traits we can look at?
> > Somewhat out of curiosity, but why do you have to overwrite all of drm?
> > amdgpu seems to be able to pull their stunt off without ...
> > -Daniel
>
> At the time we launched the standalone vmwgfx, the DRM <-> driver
> interface was moving considerably more rapidly than the DRM <-> kernel
> interface. I think that's still the case. Hence less work for us. Also
> meant we can install the full driver stack with latest features on
> fairly old VMs without backported DRM functionality.
>

I think this should be fine for 99% of drm usage, there may be corner
cases in wierd places, but I can't point to any that really matter
(maybe strace?)

Acked-by: Dave Airlie 

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm] Add basic CONTRIBUTING file

[Dave Airlie]

On Mon, 3 Sep 2018 at 18:47, Daniel Vetter  wrote:
>
> I picked up a bunch of the pieces from wayland's version:
>
> https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
>
> The weston one is fairly similar. Then I rather massively trimmed it
> down since in reality libdrm is a bit a dumping ground with very few
> real rules. The commit rights and CoC sections I've copied verbatim
> from igt respectively drm-misc. Weston/Wayland only differ in their
> pick of how many patches you need (10 instead of 5). I think for
> libdrm this is supremely relevant, since most everyone will get their
> commit rights by contributing already to the kernel or mesa and having
> commit rights there already.
>
> Anyway, I figured this is good to get the rules documented, even if
> there's mostly not many rules.
>
> Note: This references maintainers in a MAINTAINERS file, which needs
> to be created first.
>
> Note: With the gitlab migration the entire commit rights process is
> still a bit up in the air. But gitlab commit rights and roles are
> hierarchical, so we can do libdrm-only maintainer/commiter roles
> ("Owner" and "Developer" in gitlab-speak). This should avoid
> conflating libdrm roles with mesa roles, useful for those pushing to
> libdrm as primarily kernel contributors.

Fine with me,

Acked-by: Dave Airlie 

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 38/54] drm/amd/display: Expose bunch of functions from dcn10_hw_sequencer

[Dave Airlie]

This has some whitespace changes that don't seem to be related, please
get people to be a bit more careful.

(though I do realise this could be magic ifdef stuff that got ripped out :-)

Dave.


On 10 July 2018 at 10:37, Harry Wentland  wrote:
> From: Eric Bernstein 
>
> Signed-off-by: Eric Bernstein 
> Reviewed-by: Dmytro Laktyushkin 
> Acked-by: Harry Wentland 
> ---
>  .../gpu/drm/amd/display/dc/core/dc_resource.c |  1 -
>  drivers/gpu/drm/amd/display/dc/dc_stream.h|  1 +
>  .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 59 +++
>  .../amd/display/dc/dcn10/dcn10_hw_sequencer.h |  7 +++
>  .../gpu/drm/amd/display/dc/inc/hw_sequencer.h |  8 +++
>  5 files changed, 50 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index 41562ffa1c62..cacf59d0a1d6 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -1473,7 +1473,6 @@ bool dc_add_all_planes_for_stream(
> return add_all_planes_for_stream(dc, stream, , 1, context);
>  }
>
> -
>  static bool is_hdr_static_meta_changed(struct dc_stream_state *cur_stream,
> struct dc_stream_state *new_stream)
>  {
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h 
> b/drivers/gpu/drm/amd/display/dc/dc_stream.h
> index 532b2aff2227..65d08d594628 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
> @@ -131,6 +131,7 @@ struct dc_stream_update {
> struct dc_info_packet *vsc_infopacket;
>
> bool *dpms_off;
> +
>  };
>
>  bool dc_is_stream_unchanged(
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index 28dba6a324c1..06cf967b2431 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -849,7 +849,7 @@ static bool dcn10_hw_wa_force_recovery(struct dc *dc)
>  }
>
>
> -static void dcn10_verify_allow_pstate_change_high(struct dc *dc)
> +void dcn10_verify_allow_pstate_change_high(struct dc *dc)
>  {
> static bool should_log_hw_state; /* prevent hw state log by default */
>
> @@ -1863,8 +1863,7 @@ static void update_dpp(struct dpp *dpp, struct 
> dc_plane_state *plane_state)
> dpp->funcs->dpp_program_bias_and_scale(dpp, _params);
>  }
>
> -
> -static void update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
> +static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
>  {
> struct hubp *hubp = pipe_ctx->plane_res.hubp;
> struct mpcc_blnd_cfg blnd_cfg;
> @@ -2009,7 +2008,7 @@ static void update_dchubp_dpp(
>
> if (plane_state->update_flags.bits.full_update ||
> plane_state->update_flags.bits.per_pixel_alpha_change)
> -   update_mpcc(dc, pipe_ctx);
> +   dc->hwss.update_mpcc(dc, pipe_ctx);
>
> if (plane_state->update_flags.bits.full_update ||
> plane_state->update_flags.bits.per_pixel_alpha_change ||
> @@ -2119,6 +2118,33 @@ static void set_hdr_multiplier(struct pipe_ctx 
> *pipe_ctx)
> pipe_ctx->plane_res.dpp, hw_mult);
>  }
>
> +void dcn10_program_pipe(
> +   struct dc *dc,
> +   struct pipe_ctx *pipe_ctx,
> +   struct dc_state *context)
> +{
> +   if (pipe_ctx->plane_state->update_flags.bits.full_update)
> +   dcn10_enable_plane(dc, pipe_ctx, context);
> +
> +   update_dchubp_dpp(dc, pipe_ctx, context);
> +
> +   set_hdr_multiplier(pipe_ctx);
> +
> +   if (pipe_ctx->plane_state->update_flags.bits.full_update ||
> +   
> pipe_ctx->plane_state->update_flags.bits.in_transfer_func_change ||
> +   pipe_ctx->plane_state->update_flags.bits.gamma_change)
> +   dc->hwss.set_input_transfer_func(pipe_ctx, 
> pipe_ctx->plane_state);
> +
> +   /* dcn10_translate_regamma_to_hw_format takes 750us to finish
> +* only do gamma programming for full update.
> +* TODO: This can be further optimized/cleaned up
> +* Always call this for now since it does memcmp inside before
> +* doing heavy calculation and programming
> +*/
> +   if (pipe_ctx->plane_state->update_flags.bits.full_update)
> +   dc->hwss.set_output_transfer_func(pipe_ctx, pipe_ctx->stream);
> +}
> +
>  static void program_all_pipe_in_tree(
> struct dc *dc,
> struct pipe_ctx *pipe_ctx,
> @@ -2140,26 +2166,7 @@ static void program_all_pipe_in_tree(
> }
>
> if (pipe_ctx->plane_state != NULL) {
> -   if (pipe_ctx->plane_state->update_flags.bits.full_update)
> -   dcn10_enable_plane(dc, pipe_ctx, context);
> -
> -   update_dchubp_dpp(dc, pipe_ctx, context);
> -
> -  

Re: [PATCH 1/2] drm/amdgpu: switch firmware path for CIK parts

[Dave Airlie]

On 3 July 2018 at 05:36, Alex Deucher  wrote:
> Use separate firmware path for amdgpu to avoid conflicts
> with radeon on CIK parts.
>

Won't that cause a chicken and egg problem, new kernel with old
firmware package will
suddenly start failing, or do we not really care since in theory we
don't suppose amdgpu
on those parts yet?

Seems like we'd want to fallback to the old paths if possible.

Dave.

> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 10 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 10 ++---
>  drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 10 ++---
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   | 24 +--
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 72 
> -
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |  6 +--
>  7 files changed, 70 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> index e950730f1933..693ec5ea4950 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> @@ -314,17 +314,17 @@ static int amdgpu_cgs_get_firmware_info(struct 
> cgs_device *cgs_device,
> (adev->pdev->revision == 0x81) ||
> (adev->pdev->device == 0x665f)) {
> info->is_kicker = true;
> -   strcpy(fw_name, 
> "radeon/bonaire_k_smc.bin");
> +   strcpy(fw_name, 
> "amdgpu/bonaire_k_smc.bin");
> } else {
> -   strcpy(fw_name, 
> "radeon/bonaire_smc.bin");
> +   strcpy(fw_name, 
> "amdgpu/bonaire_smc.bin");
> }
> break;
> case CHIP_HAWAII:
> if (adev->pdev->revision == 0x80) {
> info->is_kicker = true;
> -   strcpy(fw_name, 
> "radeon/hawaii_k_smc.bin");
> +   strcpy(fw_name, 
> "amdgpu/hawaii_k_smc.bin");
> } else {
> -   strcpy(fw_name, 
> "radeon/hawaii_smc.bin");
> +   strcpy(fw_name, 
> "amdgpu/hawaii_smc.bin");
> }
> break;
> case CHIP_TOPAZ:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 0b46ea1c6290..3e70eb61a960 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -53,11 +53,11 @@
>
>  /* Firmware Names */
>  #ifdef CONFIG_DRM_AMDGPU_CIK
> -#define FIRMWARE_BONAIRE   "radeon/bonaire_uvd.bin"
> -#define FIRMWARE_KABINI"radeon/kabini_uvd.bin"
> -#define FIRMWARE_KAVERI"radeon/kaveri_uvd.bin"
> -#define FIRMWARE_HAWAII"radeon/hawaii_uvd.bin"
> -#define FIRMWARE_MULLINS   "radeon/mullins_uvd.bin"
> +#define FIRMWARE_BONAIRE   "amdgpu/bonaire_uvd.bin"
> +#define FIRMWARE_KABINI"amdgpu/kabini_uvd.bin"
> +#define FIRMWARE_KAVERI"amdgpu/kaveri_uvd.bin"
> +#define FIRMWARE_HAWAII"amdgpu/hawaii_uvd.bin"
> +#define FIRMWARE_MULLINS   "amdgpu/mullins_uvd.bin"
>  #endif
>  #define FIRMWARE_TONGA "amdgpu/tonga_uvd.bin"
>  #define FIRMWARE_CARRIZO   "amdgpu/carrizo_uvd.bin"
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index b0dcdfd85f5b..6ae1ad7e83b3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -40,11 +40,11 @@
>
>  /* Firmware Names */
>  #ifdef CONFIG_DRM_AMDGPU_CIK
> -#define FIRMWARE_BONAIRE   "radeon/bonaire_vce.bin"
> -#define FIRMWARE_KABINI"radeon/kabini_vce.bin"
> -#define FIRMWARE_KAVERI"radeon/kaveri_vce.bin"
> -#define FIRMWARE_HAWAII"radeon/hawaii_vce.bin"
> -#define FIRMWARE_MULLINS   "radeon/mullins_vce.bin"
> +#define FIRMWARE_BONAIRE   "amdgpu/bonaire_vce.bin"
> +#define FIRMWARE_KABINI"amdgpu/kabini_vce.bin"
> +#define FIRMWARE_KAVERI"amdgpu/kaveri_vce.bin"
> +#define FIRMWARE_HAWAII"amdgpu/hawaii_vce.bin"
> +#define FIRMWARE_MULLINS   "amdgpu/mullins_vce.bin"
>  #endif
>  #define FIRMWARE_TONGA "amdgpu/tonga_vce.bin"
>  #define FIRMWARE_CARRIZO   "amdgpu/carrizo_vce.bin"
> diff --git a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c 
> b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
> index 079a5fc9b593..d2469453dca2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
> @@ -49,10 +49,10 @@
>  #include "gmc/gmc_7_1_d.h"
>  #include "gmc/gmc_7_1_sh_mask.h"

Re: [PATCH 5/5] drm: drop drm_pcie_get_speed_cap_mask and drm_pcie_get_max_link_width

[Dave Airlie]

On 26 June 2018 at 07:06, Alex Deucher  wrote:
> These functions duplicated functionality which was ultimately added
> to the pci core.
>
> All users of these functions have been ported to using the newly
> exposed pci functionality.  These functions are no longer used,
> so drop them.
>
> Signed-off-by: Alex Deucher 

Reviewed-by: Dave Airlie 

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: replace mutex with spin_lock (V2)

[Dave Airlie]

On 31 May 2018 at 20:02, Shirish S  wrote:
> mutex's lead to sleeps which should be avoided in
> atomic context.
> Hence this patch replaces it with the spin_locks.
>
> Below is the stack trace:

I'm not sure I really like this series of patches, going around
replacing ATOMIC and mutex with spinlocks
isn't something that should be done lightly,

In all the patches I haven't seen what spin lock or what causes us to
be in an atomic state in the first
place and why it is necessary that we are in an atomic state for such
long sequences of code.

Thanks,
Dave.

>
> BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:**
> in_atomic(): 1, irqs_disabled(): 1, pid: 89, name: kworker/u4:3
> CPU: 1 PID: 89 Comm: kworker/u4:3 Tainted: GW   4.14.43 #8
> Workqueue: events_unbound commit_work
> Call Trace:
>  dump_stack+0x4d/0x63
>  ___might_sleep+0x11f/0x12e
>  mutex_lock+0x20/0x42
>  amdgpu_atom_execute_table+0x26/0x72
>  enable_disp_power_gating_v2_1+0x85/0xae
>  dce110_enable_display_power_gating+0x83/0x1b1
>  dce110_power_down_fe+0x4a/0x6d
>  dc_post_update_surfaces_to_stream+0x59/0x87
>  amdgpu_dm_do_flip+0x239/0x298
>  amdgpu_dm_commit_planes.isra.23+0x379/0x54b
>  ? drm_calc_timestamping_constants+0x14b/0x15c
>  amdgpu_dm_atomic_commit_tail+0x4fc/0x5d2
>  ? wait_for_common+0x5b/0x69
>  commit_tail+0x42/0x64
>  process_one_work+0x1b0/0x314
>  worker_thread+0x1cb/0x2c1
>  ? create_worker+0x1da/0x1da
>  kthread+0x156/0x15e
>  ? kthread_flush_work+0xea/0xea
>  ret_from_fork+0x22/0x40
>
> V2: Added stack trace in commit message.
>
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/atom.c| 4 ++--
>  drivers/gpu/drm/amd/amdgpu/atom.h| 3 ++-
>  3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index bf872f6..ba3d4b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -2033,7 +2033,7 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
> return -ENOMEM;
> }
>
> -   mutex_init(>mode_info.atom_context->mutex);
> +   spin_lock_init(>mode_info.atom_context->lock);
> if (adev->is_atom_fw) {
> amdgpu_atomfirmware_scratch_regs_init(adev);
> amdgpu_atomfirmware_allocate_fb_scratch(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 69500a8..bfd98f0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -1261,7 +1261,7 @@ int amdgpu_atom_execute_table(struct atom_context *ctx, 
> int index, uint32_t * pa
>  {
> int r;
>
> -   mutex_lock(>mutex);
> +   spin_lock(>lock);
> /* reset data block */
> ctx->data_block = 0;
> /* reset reg block */
> @@ -1274,7 +1274,7 @@ int amdgpu_atom_execute_table(struct atom_context *ctx, 
> int index, uint32_t * pa
> ctx->divmul[0] = 0;
> ctx->divmul[1] = 0;
> r = amdgpu_atom_execute_table_locked(ctx, index, params);
> -   mutex_unlock(>mutex);
> +   spin_unlock(>lock);
> return r;
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.h 
> b/drivers/gpu/drm/amd/amdgpu/atom.h
> index a391709..54063e2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.h
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.h
> @@ -26,6 +26,7 @@
>  #define ATOM_H
>
>  #include 
> +#include 
>  #include 
>
>  #define ATOM_BIOS_MAGIC0xAA55
> @@ -125,7 +126,7 @@ struct card_info {
>
>  struct atom_context {
> struct card_info *card;
> -   struct mutex mutex;
> +   spinlock_t lock;
> void *bios;
> uint32_t cmd_table, data_table;
> uint16_t *iio;
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 04/21] drm/amdgpu: Add GFXv9 kfd2kgd interface functions

[Dave Airlie]

> +static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> +   uint32_t queue_id, uint32_t __user *wptr,
> +   uint32_t wptr_shift, uint32_t wptr_mask,
> +   struct mm_struct *mm)
> +{
> +   struct amdgpu_device *adev = get_amdgpu_device(kgd);
> +   struct v9_mqd *m;
> +   uint32_t *mqd_hqd;
> +   uint32_t reg, hqd_base, data;
> +
> +   m = get_mqd(mqd);
> +
> +   acquire_queue(kgd, pipe_id, queue_id);
> +
> +   /* HIQ is set during driver init period with vmid set to 0*/
> +   if (m->cp_hqd_vmid == 0) {
> +   uint32_t value, mec, pipe;
> +
> +   mec = (pipe_id / adev->gfx.mec.num_pipe_per_mec) + 1;
> +   pipe = (pipe_id % adev->gfx.mec.num_pipe_per_mec);
> +
> +   pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
> +   mec, pipe, queue_id);
> +   value = RREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS));
> +   value = REG_SET_FIELD(value, RLC_CP_SCHEDULERS, scheduler1,
> +   ((mec << 5) | (pipe << 3) | queue_id | 0x80));
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS), value);
> +   }
> +
> +   /* HQD registers extend from CP_MQD_BASE_ADDR to CP_HQD_EOP_WPTR_MEM. 
> */
> +   mqd_hqd = >cp_mqd_base_addr_lo;
> +   hqd_base = SOC15_REG_OFFSET(GC, 0, mmCP_MQD_BASE_ADDR);
> +
> +   for (reg = hqd_base;
> +reg <= SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI); reg++)
> +   WREG32(reg, mqd_hqd[reg - hqd_base]);
> +
> +
> +   /* Activate doorbell logic before triggering WPTR poll. */
> +   data = REG_SET_FIELD(m->cp_hqd_pq_doorbell_control,
> +CP_HQD_PQ_DOORBELL_CONTROL, DOORBELL_EN, 1);
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL), data);
> +
> +   if (wptr) {
> +   /* Don't read wptr with get_user because the user
> +* context may not be accessible (if this function
> +* runs in a work queue). Instead trigger a one-shot
> +* polling read from memory in the CP. This assumes
> +* that wptr is GPU-accessible in the queue's VMID via
> +* ATC or SVM. WPTR==RPTR before starting the poll so
> +* the CP starts fetching new commands from the right
> +* place.
> +*
> +* Guessing a 64-bit WPTR from a 32-bit RPTR is a bit
> +* tricky. Assume that the queue didn't overflow. The
> +* number of valid bits in the 32-bit RPTR depends on
> +* the queue size. The remaining bits are taken from
> +* the saved 64-bit WPTR. If the WPTR wrapped, add the
> +* queue size.
> +*/
> +   uint32_t queue_size =
> +   2 << REG_GET_FIELD(m->cp_hqd_pq_control,
> +  CP_HQD_PQ_CONTROL, QUEUE_SIZE);
> +   uint64_t guessed_wptr = m->cp_hqd_pq_rptr & (queue_size - 1);
> +
> +   if ((m->cp_hqd_pq_wptr_lo & (queue_size - 1)) < guessed_wptr)
> +   guessed_wptr += queue_size;
> +   guessed_wptr += m->cp_hqd_pq_wptr_lo & ~(queue_size - 1);
> +   guessed_wptr += (uint64_t)m->cp_hqd_pq_wptr_hi << 32;
> +
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_LO),
> +  lower_32_bits(guessed_wptr));
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI),
> +  upper_32_bits(guessed_wptr));
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR),
> +  lower_32_bits((uint64_t)wptr));
> +   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI),
> +  upper_32_bits((uint64_t)wptr));

 CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.o
In file included from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:30:0:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:
In function ‘kgd_hqd_load’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
  lower_32_bits((uint64_t)wptr));
^
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/amdgpu.h:1666:53:
note: in definition of macro ‘WREG32’
 #define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
 ^
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:10:
note: in expansion of macro ‘lower_32_bits’
  lower_32_bits((uint64_t)wptr));
  ^

4.17-rc3 oops and cpu blocked

[Dave Airlie]

I was running latest drm-next kernel + radv with sdma support + Vulkan CTS

dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_compute

caused the below explosion to happen,

Dave.

[ 2119.182156] [ cut here ]
[ 2119.182158] kernel BUG at
/home/airlied/devel/kernel/dim/src/drivers/dma-buf/reservation.c:234!
[ 2119.182166] invalid opcode:  [#1] SMP PTI
[ 2119.182168] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 ipt_REJECT nf_reject_ipv4 tun ip6t_REJECT
nf_reject_ipv6 xt_conntrack nfnetlink ebtable_nat ebtable_broute
bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_security iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_raw iptable_security ebtable_filter ebtables
ip6table_filter ip6_tables fuse vsock snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core snd_seq x86_pkg_temp_thermal coretemp
snd_seq_device snd_pcm kvm_intel kvm snd_timer snd wmi_bmof soundcore
iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap lpc_ich i2c_i801
irqbypass crc32_pclmul ghash_clmulni_intel
[ 2119.182209]  wmi amdgpu i915 mfd_core chash gpu_sched ttm video
iosf_mbi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops drm e1000e crc32c_intel i2c_dev i2c_core
[ 2119.18] CPU: 7 PID: 3590 Comm: deqp-vk Not tainted 4.17.0-rc3+ #353
[ 2119.182224] Hardware name: Hewlett-Packard HP Z220 CMT
Workstation/1790, BIOS K51 v01.65 09/03/2013
[ 2119.182230] RIP: 0010:reservation_object_add_shared_fence+0x2cc/0x2f0
[ 2119.182232] RSP: 0018:8805eedf7ae0 EFLAGS: 00010246
[ 2119.182234] RAX: 0004 RBX: 8805eedf7c08 RCX: dead0200
[ 2119.182235] RDX: 8805f9800218 RSI: 8805eec85560 RDI: 8805f9800218
[ 2119.182236] RBP: 88060b510740 R08: 8805eed04ce8 R09: 8806124eb118
[ 2119.182238] R10: 8805eedf7a08 R11: 8805f9800800 R12: 
[ 2119.182239] R13: 8805eec85560 R14: 88061214dd00 R15: 8805eec85560
[ 2119.182241] FS:  7f9927fff700() GS:88062ebc()
knlGS:
[ 2119.182243] CS:  0010 DS:  ES:  CR0: 80050033
[ 2119.182244] CR2: 7f994d761000 CR3: 0005fb6b6001 CR4: 001606e0
[ 2119.182245] Call Trace:
[ 2119.182255]  ttm_eu_fence_buffer_objects+0x4e/0x90 [ttm]
[ 2119.182292]  amdgpu_cs_ioctl+0x149f/0x1a70 [amdgpu]
[ 2119.182325]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
[ 2119.182337]  drm_ioctl_kernel+0x81/0xd0 [drm]
[ 2119.182346]  drm_ioctl+0x2f2/0x3a0 [drm]
[ 2119.182372]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
[ 2119.182375]  ? __do_fault+0x1e/0xe5
[ 2119.182404]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 2119.182407]  do_vfs_ioctl+0x90/0x5e0
[ 2119.182410]  ? security_file_ioctl+0x32/0x50
[ 2119.182412]  ksys_ioctl+0x70/0x80
[ 2119.182415]  __x64_sys_ioctl+0x16/0x20
[ 2119.182418]  do_syscall_64+0x48/0x100
[ 2119.182421]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2119.182424] RIP: 0033:0x7f994a67e8e7
[ 2119.182425] RSP: 002b:7f9927ffe158 EFLAGS: 0246 ORIG_RAX:
0010
[ 2119.182427] RAX: ffda RBX: 7f9927ffe460 RCX: 7f994a67e8e7
[ 2119.182429] RDX: 7f9927ffe1d0 RSI: c0186444 RDI: 0005
[ 2119.182430] RBP: 7f9927ffe1d0 R08: 7f9927ffe2b0 R09: 7f9927ffe1a0
[ 2119.182431] R10: 7f9927ffe2b0 R11: 0246 R12: c0186444
[ 2119.182433] R13: 0005 R14: 038a3a10 R15: 7f9927fff9c0
[ 2119.182434] Code: 89 e7 e9 45 ff ff ff 4c 89 ef e8 e0 e5 ff ff 48
8b 54 24 08 8b 0c 24 e9 a3 fd ff ff b8 18 00 00 00 b9 01 00 00 00 e9
17 fe ff ff <0f> 0b 4c 89 7d 18 c7 45 10 01 00 00 00 83 42 28 01 e9 32
ff ff
[ 2119.182462] RIP: reservation_object_add_shared_fence+0x2cc/0x2f0
RSP: 8805eedf7ae0
[ 2119.182465] ---[ end trace d7fff2a47575192e ]---
[ 2144.715111] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [deqp-vk:3585]
[ 2144.715114] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 ipt_REJECT nf_reject_ipv4 tun ip6t_REJECT
nf_reject_ipv6 xt_conntrack nfnetlink ebtable_nat ebtable_broute
bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_security iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_raw iptable_security ebtable_filter ebtables
ip6table_filter ip6_tables fuse vsock snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core snd_seq x86_pkg_temp_thermal coretemp
snd_seq_device snd_pcm kvm_intel kvm snd_timer snd wmi_bmof soundcore
iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap lpc_ich i2c_i801
irqbypass crc32_pclmul ghash_clmulni_intel
[ 2144.715158]  wmi amdgpu i915 mfd_core chash gpu_sched ttm video
iosf_mbi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

[Dave Airlie]

>
>
> Yes, I fixed the original false positive messages myself with the swiotlb
> maintainer and I was CCed in fixing the recent fallout from Chris changes as
> well.

So do we have a good summary of where this at now?

I'm getting reports on 4.16.4 still displaying these, what hammer do I
need to hit things with to get 4.16.x+1 to not do this?

Is there still outstanding issues upstream.

For future reference I think how this should have gone down is

a) AMD implement a public CI with igt tests for all of this
b) we get these patches pushed and debugged.

Though to be a bit more constructive, I think you should have said at
-rc6 or 7 this isn't working for this kernel cycle,
push a minimal patch to back it off, even if the bug is in swiotlb, we
don't just add stuff broken like this, even if it's not
your bug we should have backed off for a kernel or two until we had
the underlying infrastructure fixed. Otherwise we
get what we have now, which is bit of a crappile, because now I've no
idea if the swiotlb things people report are
the false positive, or some new thing.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New KFD ioctls: taking the skeletons out of the closet

[Dave Airlie]

On 7 March 2018 at 08:44, Felix Kuehling  wrote:
> Hi all,
>
> Christian raised two potential issues in a recent KFD upstreaming code
> review that are related to the KFD ioctl APIs:
>
>  1. behaviour of -ERESTARTSYS
>  2. transactional nature of KFD ioctl definitions, or lack thereof
>
> I appreciate constructive feedback, but I also want to encourage an
> open-minded rather than a dogmatic approach to API definitions. So let
> me take all the skeletons out of my closet and get these APIs reviewed
> in the appropriate forum before we commit to them upstream. See the end
> of this email for reference.
>
> The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If
> any of the other APIs raise concerns or questions, please ask.
>
> Because of the HSA programming model, KFD memory management APIs are
> synchronous. There is no pipelining. Command submission to GPUs through
> user mode queues does not involve KFD. This means KFD doesn't know what
> memory is used by the GPUs and when it's used. That means, when the
> map_memory_to_gpu ioctl returns to user mode, all memory mapping
> operations are complete and the memory can be used by the CPUs or GPUs
> immediately.

I've got a few opinions, but first up I still dislike user-mode queues
and everything
they entail. I still feel they are solving a Windows problem and not a
Linux problem,
and it would be nice if we had some Linux numbers on what they gain us over
a dispatch ioctl, because they sure bring a lot of memory management issues.

That said amdkfd is here.

The first question you should ask (which you haven't asked here at all) is
what should userspace do with the ioctl result.

>
> HSA also uses a shared virtual memory model, so typically memory gets
> mapped on multiple GPUs and CPUs at the same virtual address.
>
> The point of contention seems to be the ability to map memory to
> multiple GPUs in a single ioctl and the behaviour in failure cases. I'll
> discuss two main failure cases:
>
> 1: Failure after all mappings have been dispatched via SDMA, but a
> signal interrupts the wait for completion and we return -ERESTARTSYS.
> Documentation/kernel-hacking/hacking.rst only says "[...] you should be
> prepared to process the restart, e.g. if you're in the middle of
> manipulating some data structure." I think we do that by ensuring that
> memory that's already mapped won't be mapped again. So the restart will
> become a no-op and just end up waiting for all the previous mappings to
> complete.

-ERESTARTSYS at that late stage points to a badly synchronous API,
I'd have said you should have two ioctls, one that returns a fence after
starting the processes, and one that waits for the fence separately.

The overhead of ioctls isn't your enemy until you've measured it and
proven it's a problem.

>
> Christian has a stricter requirement, and I'd like to know where that
> comes from: "An interrupted IOCTL should never have a visible effect."

Christian might be taking things a bit further but synchronous gpu access
APIs are bad, but I don't think undoing a bunch of work is a good plan either
just because you got ERESTARTSYS. If you get ERESTARTSYS can you
handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 more?
will I wait for the original SDMAs if I reenter?

>
> 2: Failure to map on some but not all GPUs. This comes down to the
> question, do all ioctl APIs or system calls in general need to be
> transactional? As a counter example I'd give incomplete read or write
> system calls that return how much was actually read or written. Our
> current implementation of map_memory_to_gpu doesn't do this, but it
> could be modified to return to user mode how many of the mappings, or
> which mappings specifically failed or succeeded.

What should userspace do? if it only get mappings on 3 of the gpus instead
of say 4? Is there a sane resolution other than calling the ioctl again with
the single GPU? Would it drop the GPU from the working set from that point on?

Need more info to do what can come out of the API doing incomplete
operations.

> The alternative would be to break multi-GPU mappings, and the final wait
> for completion, into multiple ioctl calls. That would result in
> additional system call overhead. I'd argue that the end result is the
> same for user mode, so I don't see why I'd use multiple ioctls over a
> single one.

Again stop worrying about ioctl overhead, this isn't Windows. If you
can show the overhead as being a problem then address it, but I
think it's premature worrying about it at this stage.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 04/37] drm/amdgpu: Implement get_local_mem_info

[Dave Airlie]

On 9 December 2017 at 14:08, Felix Kuehling  wrote:
> From: Harish Kasiviswanathan 
>
> Implement new kgd-kfd interface function get_local_mem_info.
>
> Signed-off-by: Harish Kasiviswanathan 
> Signed-off-by: Ben Goz 
> Signed-off-by: Felix Kuehling 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 30 
> +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |  1 +
>  4 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> index cfb7827..56f6c12 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> @@ -252,6 +252,36 @@ uint64_t get_vmem_size(struct kgd_dev *kgd)
> return adev->mc.real_vram_size;
>  }
>
> +void get_local_mem_info(struct kgd_dev *kgd,
> +   struct kfd_local_mem_info *mem_info)
> +{
> +   struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
> +   uint64_t address_mask = adev->dev->dma_mask ? ~*adev->dev->dma_mask :
> +~((1ULL << 32) - 1);
> +   resource_size_t aper_limit = adev->mc.aper_base + adev->mc.aper_size;
> +
> +   memset(mem_info, 0, sizeof(*mem_info));
> +   if (!(adev->mc.aper_base & address_mask || aper_limit & 
> address_mask)) {
> +   mem_info->local_mem_size_public = adev->mc.visible_vram_size;
> +   mem_info->local_mem_size_private = adev->mc.real_vram_size -
> +   adev->mc.visible_vram_size;
> +   } else {
> +   mem_info->local_mem_size_public = 0;
> +   mem_info->local_mem_size_private = adev->mc.real_vram_size;
> +   }
> +   mem_info->vram_width = adev->mc.vram_width;
> +
> +   pr_debug("Address base: 0x%llx limit 0x%llx public 0x%llx private 
> 0x%llx\n",
> +   adev->mc.aper_base, aper_limit,
> +   
> mem_in/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.cfo->local_mem_size_public,
> +   mem_info->local_mem_size_private);

This patches introduces:

In file included from
/home/airlied/devel/kernel/drm-next/include/linux/kernel.h:14:0,
 from
/home/airlied/devel/kernel/drm-next/include/asm-generic/bug.h:18,
 from
/home/airlied/devel/kernel/drm-next/arch/arm/include/asm/bug.h:60,
 from /home/airlied/devel/kernel/drm-next/include/linux/bug.h:5,
 from
/home/airlied/devel/kernel/drm-next/include/linux/thread_info.h:12,
 from
/home/airlied/devel/kernel/drm-next/include/asm-generic/current.h:5,
 from ./arch/arm/include/generated/asm/current.h:1,
 from
/home/airlied/devel/kernel/drm-next/include/linux/sched.h:12,
 from
/home/airlied/devel/kernel/drm-next/arch/arm/include/asm/mmu_context.h:17,
 from
/home/airlied/devel/kernel/drm-next/include/linux/mmu_context.h:5,
 from
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29,
 from
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:
In function ‘get_local_mem_info’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:297:11:
warning: format ‘%llx’ expects argument of type ‘long long unsigned
int’, but argument 3 has type ‘resource_size_t {aka unsigned int}’
[-Wformat=]
  pr_debug("Address base: 0x%llx limit 0x%llx public 0x%llx private 0x%llx\n",
   ^
/home/airlied/devel/kernel/drm-next/include/linux/printk.h:285:21:
note: in definition of macro ‘pr_fmt’
 #define pr_fmt(fmt) fmt
 ^~~
/home/airlied/devel/kernel/drm-next/include/linux/printk.h:333:2:
note: in expansion of macro ‘dynamic_pr_debug’
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^~~~
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:297:2:
note: in expansion of macro ‘pr_debug’
  pr_debug("Address base: 0x%llx limit 0x%llx public 0x%llx private 0x%llx\n",
  ^~~~
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:297:11:
warning: format ‘%llx’ expects argument of type ‘long long unsigned
int’, but argument 4 has type ‘resource_size_t {aka unsigned int}’
[-Wformat=]
  pr_debug("Address base: 0x%llx limit 0x%llx public 0x%llx private 0x%llx\n",
   ^
/home/airlied/devel/kernel/drm-next/include/linux/printk.h:285:21:
note: in definition of macro ‘pr_fmt’
 #define pr_fmt(fmt) fmt
 ^~~

Re: Initial release of AMD Open Source Driver for Vulkan

[Dave Airlie]

On 22 December 2017 at 21:03, Mao, David  wrote:
> We are pleased to announce the initial release of AMD Open Source Driver for
> Vulkan.
>
>
>
> The AMD Open Source Driver for Vulkan is an open-source Vulkan driver for
> Radeon graphics adapters on Linux. It is built on top of AMD's Platform
> Abstraction Library (PAL), a shared component that is designed to
> encapsulate certain hardware and OS-specific programming details for many of
> AMD's 3D and compute drivers. Leveraging PAL can help provide a consistent
> experience across platforms, including support for recently released GPUs
> and compatibility with AMD developer tools.
>
>
>
> The driver uses the LLVM-Based Pipeline Compiler (LLPC) library to compile
> shaders that compose a particular VkPipeline object. LLPC builds on LLVM's
> existing shader compilation infrastructure for AMD GPUs to generate code
> objects compatible with PAL's pipeline ABI.
>
>
>
> The AMD Open Source Driver for Vulkan is designed to support the following
> features:
>
> - Vulkan 1.0
>
> - More than 30 extensions
>
> - Radeon GPUProfiler tracing
>
> - Built-in debug and profiling tools
>
> - Mid-command buffer preemption and SR-IOV virtualization
>
>
>
> The following features and improvements are planned in future releases:
>
> - Upcoming versions of the Vulkan API
>
> - Hardware performance counter collection through RenderDoc
>
> - LLPC optimizations to improve GPU-limited performance and compile time
>
> - Optimizations to improve CPU-limited performance
>
>
>
> Please refer to  the README file under
> https://github.com/GPUOpen-Drivers/AMDVLK   for more information.  Looking
> forward to hearing your feedback.

Excellent!

Before I spend much time digging into the code, I am wondering how
much thought on
development model and future development has been put into this from
AMD perspective.

How does AMD envisage development on this going forward, how will AMD
internal developement
team engage with community development efforts on this code base?

How will code come be integrated from the AMD internal codebase into
this codebase?
How will external contributions be taken into this code base and
merged internally?
How often will this codebase be updated? every day/week/month/hardware release?
Will llvm master eventually be shippable? Will new llvm features be
developed in the open?

At the moment radv and anv cooperate on developing new features under
Khronos, will
AMD be open to developing new features internally at Khronos while
they are still pre-ratification?

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] amdgpu/dc: fix indentation warning from smatch.

[Dave Airlie]

From: Dave Airlie <airl...@redhat.com>

This fixes all the current smatch:
warn: inconsistent indenting

Signed-off-by: Dave Airlie <airl...@redhat.com>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |  2 +-
 .../gpu/drm/amd/display/dc/bios/command_table2.c   | 18 ++---
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  4 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 26 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  | 16 ++--
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 30 +++---
 .../display/dc/dce120/dce120_timing_generator.c|  7 +++--
 .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c|  2 +-
 .../dc/i2caux/dce110/i2c_hw_engine_dce110.c| 30 +++---
 10 files changed, 68 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 43e9a99..1ee1717 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1373,7 +1373,7 @@ static enum bp_result get_firmware_info_v3_1(
bp->cmd_tbl.get_smu_clock_info(bp) * 10;
}
 
-return BP_RESULT_OK;
+   return BP_RESULT_OK;
 }
 
 static enum bp_result bios_parser_get_encoder_cap_info(
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c 
b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
index 64eab35..ba68693 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
@@ -373,15 +373,15 @@ static void init_set_crtc_timing(struct bios_parser *bp)
uint32_t dtd_version =
BIOS_CMD_TABLE_PARA_REVISION(setcrtc_usingdtdtiming);
 
-   switch (dtd_version) {
-   case 3:
-   bp->cmd_tbl.set_crtc_timing =
-   set_crtc_using_dtd_timing_v3;
-   break;
-   default:
-   bp->cmd_tbl.set_crtc_timing = NULL;
-   break;
-   }
+   switch (dtd_version) {
+   case 3:
+   bp->cmd_tbl.set_crtc_timing =
+   set_crtc_using_dtd_timing_v3;
+   break;
+   default:
+   bp->cmd_tbl.set_crtc_timing = NULL;
+   break;
+   }
 }
 
 static enum bp_result set_crtc_using_dtd_timing_v3(
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
index e151523..3dce35e 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
@@ -1155,7 +1155,7 @@ static unsigned int dcn_find_normalized_clock_vdd_Level(
unsigned factor = (ddr4_dram_factor_single_Channel * 
dc->dcn_soc->number_of_channels);
 
if (clocks_in_khz > 
dc->dcn_soc->fabric_and_dram_bandwidth_vmax0p9*100/factor) {
-   vdd_level = dcn_bw_v_max0p91;
+   vdd_level = dcn_bw_v_max0p91;
BREAK_TO_DEBUGGER();
} else if (clocks_in_khz > 
dc->dcn_soc->fabric_and_dram_bandwidth_vnom0p8*100/factor) {
vdd_level = dcn_bw_v_max0p9;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index 572b885..de04b95 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -182,11 +182,11 @@ bool dc_stream_set_cursor_attributes(
 
if (NULL == stream) {
dm_error("DC: dc_stream is NULL!\n");
-   return false;
+   return false;
}
if (NULL == attributes) {
dm_error("DC: attributes is NULL!\n");
-   return false;
+   return false;
}
 
if (attributes->address.quad_part == 0) {
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
index 526ec5c..d882adf 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
@@ -179,19 +179,19 @@ static void check_audio_bandwidth_hdmi(
/* Number of Audio Packets (multiplied by 10) per Line (for 8 ch number
 * of Audio samples per line multiplied by 10 - Layout 1)
 */
-samples /= 32;
-samples *= crtc_info->v_active;
-/*Number of samples multiplied by 10, per second */
-samples *= crtc_info->refresh_rate;
-/*Number of Audio samples per second */
-samples /= 10;
-
-/* @todo do i