On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Hmm range fault will succeed for any kind of device private memory,
even if it doesn't belong to the calling entity. While nouveau
has some crude checks for that, they are broken because they assume
nouveau is the only user of device private memory
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of the
HMM_PFN_DEVICE_PRIVATE flag in the pfns array with a simple
is_device_private_page check in nouveau.
Signed
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Add a new src_owner field to struct migrate_vma. If the field is set,
only device private pages with page->pgmap->owner equal to that field
are migrated. If the field is not set only "normal" pages are migrated.
Signed-off-by: Christoph Hellwig
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Add a new opaque owner field to struct dev_pagemap, which will allow
the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
and refuse to work on mappings not owned by the calling entity.
Signed-off-by: Christoph Hellwig
This look
On 3/16/20 1:09 PM, Jason Gunthorpe wrote:
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature.
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
> >
> > On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> >> No driver has actually used properly wire up and support this feature.
> >> There is various code related t
On Mon, Mar 16, 2020 at 08:32:15PM +0100, Christoph Hellwig wrote:
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 180e398170b0..cfad65f6a67b 100644
> +++ b/mm/hmm.c
> @@ -118,15 +118,6 @@ static inline void hmm_pte_need_fault(const struct
> hmm_vma_walk *hmm_vma_walk,
> /* We aren't ask to do an
On Mon, Mar 16, 2020 at 08:32:16PM +0100, Christoph Hellwig wrote:
> Hmm range fault will succeed for any kind of device private memory,
> even if it doesn't belong to the calling entity. While nouveau
> has some crude checks for that, they are broken because they assume
> nouveau is the only user
On 3/16/20 11:49 AM, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature.
There is various code related to it in nouveau, but as far as I c
Hmm range fault will succeed for any kind of device private memory,
even if it doesn't belong to the calling entity. While nouveau
has some crude checks for that, they are broken because they assume
nouveau is the only user of device private memory. Fix this by
passing in an expected pgmap owner
Add a new opaque owner field to struct dev_pagemap, which will allow
the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
and refuse to work on mappings not owned by the calling entity.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 2 ++
drivers/g
When acting on device private mappings a driver needs to know if the
device (or other entity in case of kvmppc) actually owns this private
mapping. This series adds an owner field and converts the migrate_vma
code over to check it. I looked into doing the same for
hmm_range_fault, but as far as I
Add a new src_owner field to struct migrate_vma. If the field is set,
only device private pages with page->pgmap->owner equal to that field
are migrated. If the field is not set only "normal" pages are migrated.
Signed-off-by: Christoph Hellwig
Fixes: df6ad69838fc ("mm/device-public-memory: dev
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of the
HMM_PFN_DEVICE_PRIVATE flag in the pfns array with a simple
is_device_private_page check in nouveau.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/a
On Mon, Mar 16, 2020 at 07:13:24PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 03:07:13PM -0300, Jason Gunthorpe wrote:
> > I chose this to be simple without having to goto unwind it.
> >
> > So, instead like this:
>
> As ѕaid, and per the previous discussion: I think just removing
On Mon, Mar 16, 2020 at 04:04:43PM -0300, Jason Gunthorpe wrote:
> > This is not actually true. OpenCL 2.x does support SVM with nouveau and
> > device private memory via clEnqueueSVMMigrateMem().
> > Also, Ben Skeggs has accepted a set of patches to map GPU memory after being
> > migrated and this
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
> >
> > On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> >> No driver has actually used properly wire up and support this feature.
> >> There is various code related t
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
>
> On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> > No driver has actually used properly wire up and support this feature.
> > There is various code related to it in nouveau, but as far as I can tell
> > it never actually got turned
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
>
> On 3/16/20 10:52 AM, Christoph Hellwig wrote:
>> No driver has actually used properly wire up and support this feature.
>> There is various code related to it in nouveau, but as far as I can tell
>> it never actually got turned on,
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature.
There is various code related to it in nouveau, but as far as I can tell
it never actually got turned on, and the only changes since the initial
commit are global cleanups.
Thi
On Wed, Mar 11, 2020 at 03:34:58PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The hmm_range_fault() flow is fairly complicated. The scheme allows the
> caller to specify if it needs a usable result for each page, or if it only
> needs the current page table status filled in. This m
On Mon, Mar 16, 2020 at 03:17:07PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 16, 2020 at 06:52:58PM +0100, Christoph Hellwig wrote:
> > Add a new opaque owner field to struct dev_pagemap, which will allow
> > the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
> > and refuse to
On Mon, Mar 16, 2020 at 06:52:58PM +0100, Christoph Hellwig wrote:
> Add a new opaque owner field to struct dev_pagemap, which will allow
> the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
> and refuse to work on mappings not owned by the calling entity.
Using a pointer seems
On Mon, Mar 16, 2020 at 03:07:13PM -0300, Jason Gunthorpe wrote:
> I chose this to be simple without having to goto unwind it.
>
> So, instead like this:
As ѕaid, and per the previous discussion: I think just removing the
pgmap lookup is the right thing to do here. Something like this patch:
d
On Mon, Mar 16, 2020 at 10:02:50AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:00PM -0300, Jason Gunthorpe wrote:
> > @@ -694,6 +672,15 @@ long hmm_range_fault(struct hmm_range *range, unsigned
> > int flags)
> > return -EBUSY;
> > ret = walk_pag
No driver has actually used properly wire up and support this feature.
There is various code related to it in nouveau, but as far as I can tell
it never actually got turned on, and the only changes since the initial
commit are global cleanups.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm
Add a new opaque owner field to struct dev_pagemap, which will allow
the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
and refuse to work on mappings not owned by the calling entity.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 4
drivers
When acting on device private mappings a driver needs to know if the
device (or other entity in case of kvmppc) actually owns this private
mapping. This series adds an owner field and converts the migrate_vma
code over to check it. I looked into doing the same for
hmm_range_fault, but as far as I
On Fri, Mar 13, 2020 at 11:05 PM Andrey Grodzovsky
wrote:
>
> Puts the i2c adapter in common place for sharing by RAS
> and upcoming data read from FRU EEPROM feature.
>
> v2:
> Move i2c adapter to amdgpu_pm and rename it.
>
> v3: Move i2c adapter init to ASIC specific code and get rid
> of the sw
Ping
Andrey
On 3/13/20 11:05 PM, Andrey Grodzovsky wrote:
Puts the i2c adapter in common place for sharing by RAS
and upcoming data read from FRU EEPROM feature.
v2:
Move i2c adapter to amdgpu_pm and rename it.
v3: Move i2c adapter init to ASIC specific code and get rid
of the switch case in
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* Updates on MST;
* Improvements in HMDI;
* Add fallback to DMCUB for PSR.
Charlene Liu (1):
drm/amd/display: guard DPPHY_Internal_ctrl
Dmytro Laktyushkin (2):
drm/amd/display: fix split threshold w/a to work
From: Dmytro Laktyushkin
Adds logic that will determine if pipes need merging during validation.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Chris Park
Acked-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/core/dc_resource.c | 7 ++-
.../drm/amd/display/dc/dcn20/dcn20_resource.c | 56
From: Nicholas Kazlauskas
[Why]
This is enabled by default on Renoir but there's userspace/API support
to actually make use of this.
Since we're not passing this down through surface updates, let's
explicitly disable this for now.
This fixes "dcn20_program_front_end_for_ctx" warnings associated
From: "Jerry (Fangzhi) Zuo"
[why]
When reprogram MSA with updated color space, the test color space shows
inconsistency. Linux has separate routine to set up test pattern color
space, but it fails to configure RGB.
[How]
Add RGB to test pattern.
Fixes: 282243fab ("dc: update MSA and VSC SDP on
From: Dmytro Laktyushkin
Right now only stream count is used to avoid split. This change updates
the W/A to check plane count instead.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Wesley Chalmers
Acked-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn20/dcn20_resource.c | 39 +++
From: Yongqiang Sun
[Why]
underflow happened when playing video on 1366x768 + 4K clone mode due to
incorrect handle watermark change flag and lower down clocks to early.
[How]
Check watermark change flag when decide doing optimized, and check
optimized required flag to do clock update.
Signed-o
From: Isabel Zhang
[Why]
Due to previous code changes displays which are in active state
immediately transition to the active and added state. This makes the two
states redundant and unnecessary.
[How]
Instead of updating the device state to active and added after
successful addition, change sta
From: Wenjing Liu
[why]
DP doesn't have message id as the first byte of an hdcp message,
current hdcp psp unifies HDMI and DP message so that it is required
when reading DP HDCP messages in hdcp_ddc, a message id needs to be
added as the first byte of the HDCP message.
The id is currently assigne
From: Roman Li
[Why]
The PSR enablement was dependent on swizzle as a workaround for
non-pageflipping fb console. It's no longer required.
[How]
Remove PSR-enable dependency on swizzle mode.
Signed-off-by: Roman Li
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueira
---
drivers/gpu/
From: Wyatt Wood
[Why]
The default value for disable_dmcu is true, even for asics that require
dmcu.
[How]
Set flag properly per asic.
Signed-off-by: Wyatt Wood
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 4 ++--
dr
From: Hersen Wu
[Why]
drm_connector->display_info is not passed to amdgpu_dm right way after
read edid.
[How]
display_info is parsed from edid and saved into drm_connector by
drm_connector_update_edid_proerty which is called within
amdgpu_dm_update_connector_after_detect. call this function afte
From: Nikola Cornij
[why]
Causes regression with MST DSC displays not lighting up after DPMS
[how]
Revert commit 3ee07fdc908c40f570f8ce25f12b5ad6463b87ad
"dc: Program DSC during timing programming"
Signed-off-by: Nikola Cornij
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
---
drivers/gpu
From: Yongqiang Sun
[Why]
before update dpp DTO, we check dppclks in context to determine it is
changed or not, but dppclks in context will be updated anyways after
flip is done, so compare dppclks in context will always get an equal
result.
[How]
Add pipe dpp clks in dccg and compare values bet
From: Nicholas Kazlauskas
[Why]
A "dcn20_program_front_end_for_ctx" warning is observed on Renoir.
Since the resource definition doesn't explicitly disable triplebuffer
flips like Navi10 DC actually attempts to go and setup triplebuffering
even when we pass in false to the plane state.
If we hi
From: Wyatt Wood
[Why]
We want to be able to enable/disable psr on dmcub and fallback to dmcu
when necessary.
[How]
Use dc config option to do so.
Signed-off-by: Wyatt Wood
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
From: Martin Tsai
[Why]
We should check MST BU support capability on output port before building
vsc info packet.
[How]
Add a new definition for port and sink capability check.
Signed-off-by: Martin Tsai
Reviewed-by: Wenjing Liu
Acked-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_
From: Yongqiang Sun
[Why]
When hotplug a HDMI monitor during entering S0i3 or DPMSOFF state due to
entering infinite loop when calling vbios to program pixel clocks. In
this scenario, pll is enabled but phy is not, and there is not a
programing guide for this case.
[How]
Before we having the pro
From: Wyatt Wood
[Why]
The scratch space can be used to pass data between x86 and DMCUB. DMCUB
will manage the actually mapping of CW7 internally, driver does not
program the window.
[How]
Allocate extra space within the DMUB service's framebuffer for this
scratch space and expose them from the
From: Sung Lee
[WHY]
In headless boot cases, self refresh control registers are not
programmed on boot. In certain hybrid graphics cases this may cause
cstate entering to get blocked causing a hang.
[HOW]
Program self refresh control register on boot.
Signed-off-by: Sung Lee
Reviewed-by: Antho
From: Charlene Liu
[why]
this register not exist in some asic, based on request remove this from
dc.
[how]
add guard for sanization.
Signed-off-by: Charlene Liu
Reviewed-by: Dmytro Laktyushkin
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.h | 2 +-
1
The problem is that we can't add the clear fence to the BO
when there is an exclusive fence on it since we can't
guarantee the the clear fence will complete after the
exclusive one.
To fix this refactor the function and wait for any potential
exclusive fence with a small timeout before adding the
On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote:
> > Ok. I had some cleanups like this based of older trees, but if you are
> > active in this area I think I'll let you handle it.
>
> You once said you wanted to loose the weird pfn flags scheme, so
> before putting hmm_range_fault
On Mon, Mar 16, 2020 at 09:10:53AM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> > > From: Jason Gunthorpe
> > >
> > > Currently if a special PTE is encountered hmm_range_fa
On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Currently if a special PTE is encountered hmm_range_fault() immediately
> > returns EFAULT and sets the HMM_PFN_SPECIAL error out
On Mon, Mar 16, 2020 at 10:05:03AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:01PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > This eventually calls into handle_mm_fault() which is a sleeping function.
> > Release the lock first.
> >
> > hmm_vma_walk_hole
On Wed, Mar 11, 2020 at 03:35:05PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_range_fault() should never return 0 if the caller requested a valid
> page, but the pfns output for that page would be HMM_PFN_ERROR.
>
> hmm_pte_need_fault() must always be called before setting HMM
On Wed, Mar 11, 2020 at 03:35:01PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This eventually calls into handle_mm_fault() which is a sleeping function.
> Release the lock first.
>
> hmm_vma_walk_hole() does not touch the contents of the PUD, so it does not
> need the lock.
So ho
On Wed, Mar 11, 2020 at 03:35:00PM -0300, Jason Gunthorpe wrote:
> @@ -694,6 +672,15 @@ long hmm_range_fault(struct hmm_range *range, unsigned
> int flags)
> return -EBUSY;
> ret = walk_page_range(mm, hmm_vma_walk.last, range->end,
>
Looks good:
Reviewed-by: Christoph Hellwig
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Wed, Mar 11, 2020 at 03:35:03PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> All return paths that do EFAULT must call hmm_range_need_fault() to
> determine if the user requires this page to be valid.
>
> If the page cannot be made valid if the user later requires it, due to vma
On Wed, Mar 11, 2020 at 03:35:02PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> All success exit paths from the walker functions must set the pfns array.
>
> A migration entry with no required fault is a HMM_PFN_NONE return, just
> like the pte case.
>
> Fixes: d08faca018c4 ("mm/hm
On Mon, Mar 16, 2020 at 01:49:53PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 09:10:53AM -0300, Jason Gunthorpe wrote:
> > On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> > > > From: Jason Gun
On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Currently if a special PTE is encountered hmm_range_fault() immediately
> returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing
> uses).
>
> EFAULT should only be returned after testing
On Wed, Mar 11, 2020 at 03:34:59PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Many of the direct returns of error skipped doing the pte_unmap(). All non
> zero exit paths must unmap the pte.
>
> The pte_unmap() is split unnaturally like this because some of the error
> exit paths
On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Currently if a special PTE is encountered hmm_range_fault() immediately
> returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing
> uses).
>
> EFAULT should only be returned after testing
On Thu, Mar 12, 2020 at 04:33:10PM -0300, Jason Gunthorpe wrote:
> pmd_to_hmm_pfn_flags() already checks it and makes the cpu flags 0. If no
> fault is requested then the pfns should be returned with the not valid
> flags.
>
> It should not unconditionally fault if faulting is not requested.
>
>
Am 16.03.20 um 13:04 schrieb xinhui pan:
Job fence on page table should be a shared one, so add it to the root
page talbe bo resv.
last_delayed field is not needed anymore. so remove it.
Cc: Christian König
Cc: Alex Deucher
Cc: Felix Kuehling
Suggested-by: Christian König
Signed-off-by: xinh
Am 16.03.20 um 11:08 schrieb Yintian Tao:
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
v2: add PRT condition for amdgpu_vm_bo_update_mapping, too
Good point, yes. Feel free to commit it like
Hi Xinhui,
well that is quite an impressive analyses of the problem.
should it be ok to sync it also in unmapping case?
Short answer no, but I think I need to get back to the drawing board
with the direct unmapping case anyway.
2) always add fence to resv after commit.
Yes, let's stick wit
Job fence on page table should be a shared one, so add it to the root
page talbe bo resv.
last_delayed field is not needed anymore. so remove it.
Cc: Christian König
Cc: Alex Deucher
Cc: Felix Kuehling
Suggested-by: Christian König
Signed-off-by: xinhui pan
---
change from v4:
remove last_del
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
v2: add PRT condition for amdgpu_vm_bo_update_mapping, too
v3: fix one typo error
Signed-off-by: Yintian Tao
Reviewed-by: Christian König
---
dri
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
v2: add PRT condition for amdgpu_vm_bo_update_mapping, too
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
1 fil
Hi Xinhui
Sure, can you submit one patch for it？ I want to test it on my local server.
Thanks in advance.
Best Regards
Yintian Tao
From: Pan, Xinhui
Sent: 2020年3月16日 17:51
To: Koenig, Christian ; Tao, Yintian
Cc: Deucher, Alexander ; Kuehling, Felix
; amd-gfx@lists.freedesktop.org
Subje
[AMD Official Use Only - Internal Distribution Only]
I still hit page fault with option 1 while running oclperf test.
Looks like we need sync fence after commit.
From: Tao, Yintian
Sent: Monday, March 16, 2020 4:15:01 PM
To: Pan, Xinhui ; Koenig, Christian
Cc: D
Hi Christian
Many thanks for your review
Best Regards
Yintian Tao
-Original Message-
From: Koenig, Christian
Sent: 2020年3月16日 17:38
To: Tao, Yintian ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: miss PRT case when bo update
Am 16.03.20 um 08
Hi, good news,
'modprobe amdgpu' is finally working with Athlon 200GE, on a motherboard
MSI B450M-A Pro Max,
with latest raven linux-firmware bundle for 19.50
Mauro
On Tue, Feb 11, 2020 at 7:20 PM Mauro Rossi wrote:
> Hi Felix,
>
> On Mon, Jan 27, 2020 at 10:34 AM Felix Kuehling
> wrote:
> >
Am 16.03.20 um 08:52 schrieb Yintian Tao:
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
Good catch, just one style nit pick below.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdg
On Fri, Mar 13, 2020 at 02:04:46PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 13, 2020 at 04:55:50PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 12, 2020 at 05:02:18PM +, Steven Price wrote:
> > > On 12/03/2020 16:37, Jason Gunthorpe wrote:
> > > > On Thu, Mar 12, 2020 at 04:16:33PM +, St
pci_platform_rom() returns an __iomem pointer which should not be
accessed directly. Change radeon_read_platform_bios() to use
memcpy_fromio() instead of calling kmemdup() on the __iomem pointer.
Signed-off-by: Mikel Rychliski
---
drivers/gpu/drm/radeon/radeon_bios.c | 11 +++
1 file cha
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the rad
This patch series fixes an oops when loading the radeon driver on old Macs
with a 32-bit EFI implementation.
Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel.
Changes in v2:
- Add iounmap() call in nouveau
- Update function comment for pci_platform_rom()
- Minor changes to
Hi Xinhui
I encounter the same problem(page fault) when test vk_example benchmark.
I use your first option which can fix the problem. Can you help submit one
patch?
- if (flags & AMDGPU_PTE_VALID) {
- struct amdgpu_bo *root = vm->root.base.bo;
- if (!dma_fence
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/driv
83 matches
Mail list logo
