Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

[Michel Dänzer]

On 13/10/16 04:20 PM, Michel Dänzer wrote:
> On 13/10/16 12:39 AM, StDenis, Tom wrote:
>> It comes from amdgpu_query_gpu_info_init()
>>
>>
>> for (i = 0; i < (int)dev->info.num_shader_engines; i++) {
>> unsigned instance = (i << AMDGPU_INFO_MMR_SE_INDEX_SHIFT) |
>> (*AMDGPU_INFO_MMR_SH_INDEX_MASK*<<
>>  AMDGPU_INFO_MMR_SH_INDEX_SHIFT);
>>
>> r = amdgpu_read_mm_registers(dev, 0x263d, 1, instance, 0,
>>  >info.backend_disable[i]);
>>
>> This effectively reads from 0/* where the kernel adds the instance of *
>> so it's 0/*/*.  That line was last changed  by Alex
>>
>> *0936139536380* (Alex Deucher  2015-04-20 12:04:22 -0400 174)  
>>   (AMDGPU_INFO_MMR_SH_INDEX_MASK <<
> 
> As a side note, following that to the end in the kernel code, I noticed
> an interesting minor difference between the AMDGPU_INFO_READ_MMR_REG
> functionality used by this code and the debugfs interface:
> 
> With AMDGPU_INFO_READ_MMR_REG, the effect is that
> amdgpu_asic_read_register() doesn't call amdgpu_gfx_select_se_sh() at
> all before reading the register, so the read is performed from whichever
> SH instance is currently selected.
> 
> Whereas with this patch, amdgpu_debugfs_regs_read() calls
> amdgpu_gfx_select_se_sh(adev, se_bank, 0x, instance_bank) before
> the register read, which translates to only the SH_BROADCAST_WRITES bit
> being set for the SH instance index.
> 
> The end result should be the same though, since
> amdgpu_gfx_select_se_sh(adev, 0x, 0x, 0x) is
> normally called after every register read.
> 
> 
>> I still don't get why this is a reason to hit pause on the patch(es)
>> though.
> 
> At the very least, it should be documented in an appropriate place
> (commit log and/or code, or any other place where the debugfs interface
> semantics are documented) what actually happens when passing all ones
> for the SE/SH index. Does the hardware ignore the *_BROADCAST_WRITES bit
> for reads, so they're performed from instance 0, or does it combine the
> values from all instances with logical and/or?

I'm not sure how to interpret the fact that this patch has landed
without any changes or followups.

FWIW, I'm still interested in (pointers to) information about what the
libdrm_amdgpu code above expects and what the hardware does for reads
with the broadcast bit enabled, from anyone.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH xf86-video-ati 1/2] Order unique chipsets according to first appearance in ati_pciids.csv

[Michel Dänzer]

From: Michel Dänzer 

Instead of lexically. This makes it more likely for similar generations
to be close to each other in the list of unique chipsets.

Signed-off-by: Michel Dänzer 
---
 src/pcidb/parse_pci_ids.pl |   9 +-
 src/radeon_chipset_gen.h   | 598 ++---
 2 files changed, 306 insertions(+), 301 deletions(-)

diff --git a/src/pcidb/parse_pci_ids.pl b/src/pcidb/parse_pci_ids.pl
index f78e207..222dcf8 100755
--- a/src/pcidb/parse_pci_ids.pl
+++ b/src/pcidb/parse_pci_ids.pl
@@ -17,6 +17,8 @@ my $radeonchipsetfile = 'radeon_chipset_gen.h';
 my $radeonchipinfofile  = 'radeon_chipinfo_gen.h';
 
 my %uniquechipsets;
+my @uniquearray;
+my $numunique = 0;
 
 my $csv = Text::CSV_XS->new();
 
@@ -50,7 +52,10 @@ while () {
print PCIDEVICEMATCH " ATI_DEVICE_MATCH( PCI_CHIP_$columns[1], 0 ),\n";
 
print RADEONCHIPSET "  { PCI_CHIP_$columns[1], \"$columns[8]\" },\n";
-   $uniquechipsets{$columns[8]} = 1;
+   if (!$uniquechipsets{$columns[8]}) {
+   $uniquearray[$numunique] = $columns[8];
+   $uniquechipsets{$columns[8]} = $numunique++;
+   }
 
print RADEONCHIPINFO " { $columns[0], CHIP_FAMILY_$columns[2], ";
 
@@ -95,7 +100,7 @@ while () {
 
 print RADEONCHIPINFO "};\n";
 print RADEONCHIPSET "  { -1, NULL }\n};\n\nSymTabRec 
RADEONUniqueChipsets[] = {\n";
-foreach (sort keys %uniquechipsets) {
+foreach (@uniquearray) {
print RADEONCHIPSET "  { 0, \"$_\" },\n";
 }
 print RADEONCHIPSET "  { -1, NULL }\n};\n";
diff --git a/src/radeon_chipset_gen.h b/src/radeon_chipset_gen.h
index ee810cb..f68c2ea 100644
--- a/src/radeon_chipset_gen.h
+++ b/src/radeon_chipset_gen.h
@@ -704,340 +704,340 @@ SymTabRec RADEONChipsets[] = {
 };
 
 SymTabRec RADEONUniqueChipsets[] = {
-  { 0, "AMD FireStream 9250" },
-  { 0, "AMD FireStream 9270" },
-  { 0, "AMD Firestream 9170" },
-  { 0, "AMD Firestream 9350" },
-  { 0, "AMD Firestream 9370" },
-  { 0, "AMD Radeon HD 6200 Series Graphics" },
-  { 0, "AMD Radeon HD 6250 Graphics" },
-  { 0, "AMD Radeon HD 6300 Series Graphics" },
-  { 0, "AMD Radeon HD 6310 Graphics" },
-  { 0, "AMD Radeon HD 6700 Series" },
-  { 0, "AMD Radeon HD 6800 Series" },
-  { 0, "AMD Radeon HD 6900 Series" },
-  { 0, "AMD Radeon HD 6900M Series" },
-  { 0, "ARUBA" },
-  { 0, "ATI AMD Stream Processor" },
-  { 0, "ATI ES1000 515E (PCI)" },
-  { 0, "ATI ES1000 5969 (PCI)" },
-  { 0, "ATI FireGL 8700/8800 QH (AGP)" },
-  { 0, "ATI FireGL M22 GL 5464 (PCIE)" },
+  { 0, "ATI Radeon Mobility X600 (M24) 3150 (PCIE)" },
+  { 0, "ATI FireMV 2400 (PCI)" },
+  { 0, "ATI Radeon Mobility X300 (M24) 3152 (PCIE)" },
   { 0, "ATI FireGL M24 GL 3154 (PCIE)" },
+  { 0, "ATI FireMV 2400 3155 (PCI)" },
+  { 0, "ATI Radeon X600 (RV380) 3E50 (PCIE)" },
+  { 0, "ATI FireGL V3200 (RV380) 3E54 (PCIE)" },
+  { 0, "ATI Radeon IGP320 (A3) 4136" },
+  { 0, "ATI Radeon IGP330/340/350 (A4) 4137" },
+  { 0, "ATI Radeon 9500 AD (AGP)" },
+  { 0, "ATI Radeon 9500 AE (AGP)" },
+  { 0, "ATI Radeon 9600TX AF (AGP)" },
+  { 0, "ATI FireGL Z1 AG (AGP)" },
+  { 0, "ATI Radeon 9800SE AH (AGP)" },
+  { 0, "ATI Radeon 9800 AI (AGP)" },
+  { 0, "ATI Radeon 9800 AJ (AGP)" },
+  { 0, "ATI FireGL X2 AK (AGP)" },
+  { 0, "ATI Radeon 9600 AP (AGP)" },
+  { 0, "ATI Radeon 9600SE AQ (AGP)" },
+  { 0, "ATI Radeon 9600XT AR (AGP)" },
+  { 0, "ATI Radeon 9600 AS (AGP)" },
+  { 0, "ATI FireGL T2 AT (AGP)" },
+  { 0, "ATI Radeon 9650" },
+  { 0, "ATI FireGL RV360 AV (AGP)" },
+  { 0, "ATI Radeon 7000 IGP (A4+) 4237" },
+  { 0, "ATI Radeon 8500 AIW BB (AGP)" },
+  { 0, "ATI Radeon IGP320M (U1) 4336" },
+  { 0, "ATI Radeon IGP330M/340M/350M (U2) 4337" },
+  { 0, "ATI Radeon Mobility 7000 IGP 4437" },
+  { 0, "ATI Radeon 9000/PRO If (AGP/PCI)" },
+  { 0, "ATI Radeon 9000 Ig (AGP/PCI)" },
+  { 0, "ATI Radeon X800 (R420) JH (AGP)" },
+  { 0, "ATI Radeon X800PRO (R420) JI (AGP)" },
+  { 0, "ATI Radeon X800SE (R420) JJ (AGP)" },
+  { 0, "ATI Radeon X800 (R420) JK (AGP)" },
+  { 0, "ATI Radeon X800 (R420) JL (AGP)" },
+  { 0, "ATI FireGL X3 (R420) JM (AGP)" },
+  { 0, "ATI Radeon Mobility 9800 (M18) JN (AGP)" },
+  { 0, "ATI Radeon X800 SE (R420) (AGP)" },
+  { 0, "ATI Radeon X800XT (R420) JP (AGP)" },
+  { 0, "ATI Radeon X800 VE (R420) JT (AGP)" },
+  { 0, "ATI Radeon X850 (R480) (AGP)" },
+  { 0, "ATI Radeon X850 XT (R480) (AGP)" },
+  { 0, "ATI Radeon X850 SE (R480) (AGP)" },
+  { 0, "ATI Radeon X850 PRO (R480) (AGP)" },
+  { 0, "ATI Radeon X850 XT PE (R480) (AGP)" },
+  { 0, "ATI Radeon Mobility M7 LW (AGP)" },
+  { 0, "ATI Mobility FireGL 7800 M7 LX (AGP)" },
+  { 0, "ATI Radeon Mobility M6 LY (AGP)" },
+  { 0, "ATI Radeon Mobility M6 LZ (AGP)" },
   { 0, "ATI FireGL Mobility 9000 (M9) Ld (AGP)" },
+  { 0, "ATI Radeon Mobility 9000 (M9) Lf (AGP)" },
+  { 0, "ATI Radeon Mobility 9000 (M9) Lg (AGP)" },
+  { 0, "ATI FireMV 2400 PCI" },
+  { 0, "ATI Radeon 9700 Pro ND (AGP)" },
+  { 0, "ATI Radeon 

Re: [PATCH] drm/amdgpu/st: move ATC CG golden init from gfx to mc

[Christian König]

Am 18.10.2016 um 06:34 schrieb Alex Deucher:

It's technically an MC register so make sure we initialize it
in the MC module rather than the gfx module.  Since other bits
in the same register are used to enable ATC CG features make
sure we apply the golden setting first.

Signed-off-by: Alex Deucher 


Reviewed-by: Christian König .


---
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 1 -
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 +
  2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 1c2544f..6ce44bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -640,7 +640,6 @@ static const u32 stoney_mgcg_cgcg_init[] =
mmCP_MEM_SLP_CNTL, 0x, 0x00020201,
mmRLC_MEM_SLP_CNTL, 0x, 0x00020201,
mmCGTS_SM_CTRL_REG, 0x, 0x96940200,
-   mmATC_MISC_CG, 0x, 0x000c0200,
  };
  
  static void gfx_v8_0_set_ring_funcs(struct amdgpu_device *adev);

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 74d7cc3..f7372d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -100,6 +100,7 @@ static const u32 cz_mgcg_cgcg_init[] =
  
  static const u32 stoney_mgcg_cgcg_init[] =

  {
+   mmATC_MISC_CG, 0x, 0x000c0200,
mmMC_MEM_POWER_LS, 0x, 0x0104
  };
  



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

Re: [PATCH 1/3] x86/pat: export io memory reserve/free api.

[Dave Airlie]

On 18 Oct. 2016 17:23, "Edward O'Callaghan" 
wrote:
>
> NACK,
>
> I think you want to use 'iomap_create_wc()' instead to avoid aliasing.

Please explain what can alias here?

Dave.

>
> Kind Regards,
> Edward.
>
> On 10/18/2016 05:13 PM, Dave Airlie wrote:
> > From: Dave Airlie 
> >
> > These functions are needed for gpu/ttm drivers to reserve the
> > VRAM area as write combined. In a lot of places we don't ioremap
> > but still need to insert pfn from it into a VMA using vm_insert_mixed,
> > but a recent change in mixed insertion means we need to reserve
> > VRAM as WC upfront, so we need these APIs exported.
> >
> > Signed-off-by: Dave Airlie 
> > ---
> >  arch/x86/mm/pat.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> > index 170cc4f..5ce2fbb 100644
> > --- a/arch/x86/mm/pat.c
> > +++ b/arch/x86/mm/pat.c
> > @@ -719,6 +719,7 @@ out_free:
> >  out_err:
> >   return ret;
> >  }
> > +EXPORT_SYMBOL(io_reserve_memtype);
> >
> >  /**
> >   * io_free_memtype - Release a memory type mapping for a region of
memory
> > @@ -729,6 +730,7 @@ void io_free_memtype(resource_size_t start,
resource_size_t end)
> >  {
> >   free_memtype(start, end);
> >  }
> > +EXPORT_SYMBOL(io_free_memtype);
> >
> >  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> >   unsigned long size, pgprot_t vma_prot)
> >
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Daniel Vetter]

On Tue, Oct 18, 2016 at 08:01:01AM +1000, Dave Airlie wrote:
> On 18 October 2016 at 07:25, Dan Williams  wrote:
> > On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie  wrote:
> >> On 17 October 2016 at 04:41, Marek Olšák  wrote:
> >>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer  wrote:
> 
>  [ Adding Dan Williams and dri-devel ]
> 
>  On 14/10/16 03:28 AM, Shawn Starr wrote:
> > Hello AMD folks,
> >
> > I have discovered a problem in Linus master that affects AMDGPU, nobody 
> > would
> > notice this in drm-next-4.9-wip since its not in this repo.
> 
>  [...]
> 
> > 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
> > commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
> > Author: Dan Williams 
> > Date:   Fri Oct 7 17:00:18 2016 -0700
> >
> > mm: fix cache mode tracking in vm_insert_mixed()
> >
> > vm_insert_mixed() unlike vm_insert_pfn_prot() and 
> > vmf_insert_pfn_pmd(),
> > fails to check the pgprot_t it uses for the mapping against the one
> > recorded in the memtype tracking tree.  Add the missing call to
> > track_pfn_insert() to preclude cases where incompatible aliased 
> > mappings
> > are established for a given physical address range.
> >
> > Link: http://lkml.kernel.org/r/
> > 147328717909.35069.14256589123570653697.stgit@dwillia2-
> > desk3.amr.corp.intel.com
> > Signed-off-by: Dan Williams 
> > Cc: David Airlie 
> > Cc: Matthew Wilcox 
> > Cc: Ross Zwisler 
> > Signed-off-by: Andrew Morton 
> > Signed-off-by: Linus Torvalds 
> >
> > :04 04 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
> > fd497a604a2af5995db2b8ed1e9c640bede6adf3 M  mm
> >
> >
> > Removal of this patch stops graphics stalls.
> 
>  Thanks for bisecting this Shawn.
> 
> 
> > A friend of mine mentions,
> >
> > "looks like a graphics thingy you depend on is requesting a mapping 
> > with a
> > not-allowed cache mode, and now you are (rightfully) getting errors?"
> 
>  It would be nice to get some more specific pointers what amdgpu (or
>  maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
>  doing wrong.
> >>
> >>/*
> >>  * We'd like to use VM_PFNMAP on shared mappings, where
> >>  * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> >>  * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> >>  * bad for performance. Until that has been sorted out, use
> >>  * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> >>  */
> >> vma->vm_flags |= VM_MIXEDMAP;
> >>
> >> We have that comment in the ttm code, which to me implies that mixed is
> >> doing the right thing now, but that is slow, as the interface we
> >> should be using.
> >>
> >
> > Aren't there only 2 possibilities for this regression?
> >
> > 1/ a memtype entry was never made so track_pfn_insert() returns an
> > uncached mapping
> >
> > 2/ a conflicting memtype entry exists and undefined behavior due to
> > mixed mapping types is avoided with the change.
> 
> 3/ The CPU usage through this path goes up, and slows things down,
> though I suspect you it's more an uncached mapping showing up
> when we don't expect it.

Sounds reasonable, at least we (=i915 folks) known pte caching type
tracking is ridiculously expensive. In 4.9 we have our own pte walker and
upfront (at driver load) caching type checking to avoid all that. It's in
i915_mm.c, but probably should be moved into core kernel code (next to the
io_mapping stuff, which we reused as the tracking structure).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/3] x86/pat: export io memory reserve/free api.

[Edward O'Callaghan]

On 10/18/2016 07:29 PM, Dave Airlie wrote:
> On 18 Oct. 2016 17:23, "Edward O'Callaghan"  > wrote:
>>
>> NACK,
>>
>> I think you want to use 'iomap_create_wc()' instead to avoid aliasing.
> 
> Please explain what can alias here?

Ah disregard the alias comment, I was remembering how it was introduced
and that referred to 'io_mapping_create_wc()' not hard coding WC.

Any way, I think 'iomap_create_wc()' is what your looking for so no need
to expose those symbols and hook them though.

Cheers,
Edward.

> 
> Dave.
> 
>>
>> Kind Regards,
>> Edward.
>>
>> On 10/18/2016 05:13 PM, Dave Airlie wrote:
>> > From: Dave Airlie >
>> >
>> > These functions are needed for gpu/ttm drivers to reserve the
>> > VRAM area as write combined. In a lot of places we don't ioremap
>> > but still need to insert pfn from it into a VMA using vm_insert_mixed,
>> > but a recent change in mixed insertion means we need to reserve
>> > VRAM as WC upfront, so we need these APIs exported.
>> >
>> > Signed-off-by: Dave Airlie  >
>> > ---
>> >  arch/x86/mm/pat.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> > index 170cc4f..5ce2fbb 100644
>> > --- a/arch/x86/mm/pat.c
>> > +++ b/arch/x86/mm/pat.c
>> > @@ -719,6 +719,7 @@ out_free:
>> >  out_err:
>> >   return ret;
>> >  }
>> > +EXPORT_SYMBOL(io_reserve_memtype);
>> >
>> >  /**
>> >   * io_free_memtype - Release a memory type mapping for a region of
> memory
>> > @@ -729,6 +730,7 @@ void io_free_memtype(resource_size_t start,
> resource_size_t end)
>> >  {
>> >   free_memtype(start, end);
>> >  }
>> > +EXPORT_SYMBOL(io_free_memtype);
>> >
>> >  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>> >   unsigned long size, pgprot_t vma_prot)
>> >
>>
> 



signature.asc
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH xf86-video-ati 2/2] Remove PCI IDs and bus type from ati_pciids.csv

[Michel Dänzer]

From: Michel Dänzer 

This cleans up the list of unique chipsets a little further.

Signed-off-by: Michel Dänzer 
---
 src/pcidb/ati_pciids.csv | 282 -
 src/radeon_chipset_gen.h | 526 ++-
 2 files changed, 388 insertions(+), 420 deletions(-)

diff --git a/src/pcidb/ati_pciids.csv b/src/pcidb/ati_pciids.csv
index 55d7b1d..59b370a 100644
--- a/src/pcidb/ati_pciids.csv
+++ b/src/pcidb/ati_pciids.csv
@@ -1,36 +1,36 @@
 
"#pciid","define","family","mobility","igp","nocrtc2","Nointtvout","singledac","name"
-"0x3150","RV380_3150","RV380",1,"ATI Radeon Mobility X600 (M24) 3150 
(PCIE)"
-"0x3151","RV380_3151","RV380",,"ATI FireMV 2400 (PCI)"
-"0x3152","RV380_3152","RV380",1,"ATI Radeon Mobility X300 (M24) 3152 
(PCIE)"
-"0x3154","RV380_3154","RV380",1,"ATI FireGL M24 GL 3154 (PCIE)"
-"0x3155","RV380_3155","RV380",1,"ATI FireMV 2400 3155 (PCI)"
-"0x3E50","RV380_3E50","RV380",,"ATI Radeon X600 (RV380) 3E50 (PCIE)"
-"0x3E54","RV380_3E54","RV380",,"ATI FireGL V3200 (RV380) 3E54 (PCIE)"
-"0x4136","RS100_4136","RS100",,1,,,1,"ATI Radeon IGP320 (A3) 4136"
-"0x4137","RS200_4137","RS200",,1,,,1,"ATI Radeon IGP330/340/350 (A4) 4137"
-"0x4144","R300_AD","R300",,"ATI Radeon 9500 AD (AGP)"
-"0x4145","R300_AE","R300",,"ATI Radeon 9500 AE (AGP)"
-"0x4146","R300_AF","R300",,"ATI Radeon 9600TX AF (AGP)"
-"0x4147","R300_AG","R300",,"ATI FireGL Z1 AG (AGP)"
-"0x4148","R350_AH","R350",,"ATI Radeon 9800SE AH (AGP)"
-"0x4149","R350_AI","R350",,"ATI Radeon 9800 AI (AGP)"
-"0x414A","R350_AJ","R350",,"ATI Radeon 9800 AJ (AGP)"
-"0x414B","R350_AK","R350",,"ATI FireGL X2 AK (AGP)"
-"0x4150","RV350_AP","RV350",,"ATI Radeon 9600 AP (AGP)"
-"0x4151","RV350_AQ","RV350",,"ATI Radeon 9600SE AQ (AGP)"
-"0x4152","RV360_AR","RV350",,"ATI Radeon 9600XT AR (AGP)"
-"0x4153","RV350_AS","RV350",,"ATI Radeon 9600 AS (AGP)"
-"0x4154","RV350_AT","RV350",,"ATI FireGL T2 AT (AGP)"
+"0x3150","RV380_3150","RV380",1,"ATI Radeon Mobility X600 (M24)"
+"0x3151","RV380_3151","RV380",,"ATI FireMV 2400"
+"0x3152","RV380_3152","RV380",1,"ATI Radeon Mobility X300 (M24)"
+"0x3154","RV380_3154","RV380",1,"ATI FireGL M24 GL"
+"0x3155","RV380_3155","RV380",1,"ATI FireMV 2400"
+"0x3E50","RV380_3E50","RV380",,"ATI Radeon X600 (RV380)"
+"0x3E54","RV380_3E54","RV380",,"ATI FireGL V3200 (RV380)"
+"0x4136","RS100_4136","RS100",,1,,,1,"ATI Radeon IGP320 (A3)"
+"0x4137","RS200_4137","RS200",,1,,,1,"ATI Radeon IGP330/340/350 (A4)"
+"0x4144","R300_AD","R300",,"ATI Radeon 9500"
+"0x4145","R300_AE","R300",,"ATI Radeon 9500"
+"0x4146","R300_AF","R300",,"ATI Radeon 9600TX"
+"0x4147","R300_AG","R300",,"ATI FireGL Z1"
+"0x4148","R350_AH","R350",,"ATI Radeon 9800SE"
+"0x4149","R350_AI","R350",,"ATI Radeon 9800"
+"0x414A","R350_AJ","R350",,"ATI Radeon 9800"
+"0x414B","R350_AK","R350",,"ATI FireGL X2"
+"0x4150","RV350_AP","RV350",,"ATI Radeon 9600"
+"0x4151","RV350_AQ","RV350",,"ATI Radeon 9600SE"
+"0x4152","RV360_AR","RV350",,"ATI Radeon 9600XT"
+"0x4153","RV350_AS","RV350",,"ATI Radeon 9600"
+"0x4154","RV350_AT","RV350",,"ATI FireGL T2"
 "0x4155","RV350_4155","RV350",,"ATI Radeon 9650"
-"0x4156","RV350_AV","RV350",,"ATI FireGL RV360 AV (AGP)"
+"0x4156","RV350_AV","RV350",,"ATI FireGL RV360"
 "0x4158","MACH32","MACH32",,
-"0x4237","RS250_4237","RS200",,1,,,1,"ATI Radeon 7000 IGP (A4+) 4237"
-"0x4242","R200_BB","R200"1,,"ATI Radeon 8500 AIW BB (AGP)"
-"0x4336","RS100_4336","RS100",1,1,,,1,"ATI Radeon IGP320M (U1) 4336"
-"0x4337","RS200_4337","RS200",1,1,,,1,"ATI Radeon IGP330M/340M/350M (U2) 4337"
+"0x4237","RS250_4237","RS200",,1,,,1,"ATI Radeon 7000 IGP (A4+)"
+"0x4242","R200_BB","R200"1,,"ATI Radeon 8500 AIW"
+"0x4336","RS100_4336","RS100",1,1,,,1,"ATI Radeon IGP320M (U1)"
+"0x4337","RS200_4337","RS200",1,1,,,1,"ATI Radeon IGP330M/340M/350M (U2)"
 "0x4354","MACH64CT","MACH64",,
 "0x4358","MACH64CX","MACH64",,
-"0x4437","RS250_4437","RS200",1,1,,,1,"ATI Radeon Mobility 7000 IGP 4437"
+"0x4437","RS250_4437","RS200",1,1,,,1,"ATI Radeon Mobility 7000 IGP"
 "0x4554","MACH64ET","MACH64",,
 "0x4742","MACH64GB","MACH64",,
 "0x4744","MACH64GD","MACH64",,
@@ -50,23 +50,23 @@
 "0x4758","MACH64GX","MACH64",,
 "0x4759","MACH64GY","MACH64",,
 "0x475A","MACH64GZ","MACH64",,
-"0x4966","RV250_If","RV250",,"ATI Radeon 9000/PRO If (AGP/PCI)"
-"0x4967","RV250_Ig","RV250",,"ATI Radeon 9000 Ig (AGP/PCI)"
-"0x4A48","R420_JH","R420",,"ATI Radeon X800 (R420) JH (AGP)"
-"0x4A49","R420_JI","R420",,"ATI Radeon X800PRO (R420) JI (AGP)"
-"0x4A4A","R420_JJ","R420",,"ATI Radeon X800SE (R420) JJ (AGP)"
-"0x4A4B","R420_JK","R420",,"ATI Radeon X800 (R420) JK (AGP)"
-"0x4A4C","R420_JL","R420",,"ATI Radeon X800 (R420) JL (AGP)"
-"0x4A4D","R420_JM","R420",,"ATI FireGL 

[PATCH 3/3] amdgpu: reserve VRAM ranges in PAT memtype tables.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 887483b..3142d70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -,6 +,8 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
+
+   ttm_io_reserve_memtype_wc(adev->mc.aper_base, adev->mc.aper_base + 
adev->mc.aper_size);
/* Change the size here instead of the init above so only lpfn is 
affected */
amdgpu_ttm_set_active_vram_size(adev, adev->mc.visible_vram_size);
 
@@ -1203,6 +1205,7 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
ttm_bo_clean_mm(>mman.bdev, AMDGPU_PL_GWS);
ttm_bo_clean_mm(>mman.bdev, AMDGPU_PL_OA);
ttm_bo_device_release(>mman.bdev);
+   ttm_io_free_memtype(adev->mc.aper_base, adev->mc.aper_base + 
adev->mc.aper_size);
amdgpu_gart_fini(adev);
amdgpu_ttm_global_fini(adev);
adev->mman.initialized = false;
-- 
2.5.5

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

[PATCH 2/3] drm/ttm: add API to reserve/free WC memory.

[Dave Airlie]

From: Dave Airlie 

These will be used by drivers to reserve/free WC memory in the
PAT tracking tables, for VRAM BARs.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 24 
 include/drm/ttm/ttm_bo_driver.h   |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bf6e216..192c003 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -39,6 +39,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86
+#include 
+#else
+#define io_reserve_memtype(start, end, pcm) (0)
+#define io_free_memtype(start, end)
+#endif
+
 void ttm_bo_free_old_node(struct ttm_buffer_object *bo)
 {
ttm_bo_mem_put(bo, >mem);
@@ -796,3 +803,20 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
return 0;
 }
 EXPORT_SYMBOL(ttm_bo_pipeline_move);
+
+int ttm_io_reserve_memtype_wc(resource_size_t start, resource_size_t end)
+{
+   enum page_cache_mode pcm = _PAGE_CACHE_MODE_WC;
+   int ret;
+   ret = io_reserve_memtype(start, end, );
+   if (ret)
+   return ret;
+   return 0;
+}
+EXPORT_SYMBOL(ttm_io_reserve_memtype_wc);
+
+void ttm_io_free_memtype(resource_size_t start, resource_size_t end)
+{
+   io_free_memtype(start, end);
+}
+EXPORT_SYMBOL(ttm_io_free_memtype);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 4f0a921..6b2d24e 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -1054,6 +1054,8 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
  */
 extern pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp);
 
+int ttm_io_reserve_memtype_wc(resource_size_t start, resource_size_t end);
+void ttm_io_free_memtype(resource_size_t start, resource_size_t end);
 extern const struct ttm_mem_type_manager_func ttm_bo_manager_func;
 
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.5.5

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

[rfc] fix for regression in pat memory tracking in 4.9-rc1

[Dave Airlie]

Okay I spent some time looking into it, and this is the result.

We have to manually insert the VRAM BAR into the pat memory tracking
table as WC. The only other way things get inserted are via ioremap,
which we never do for the whole VRAM BAR. We could in theory map
the VRAM BAR using the iomap stuff that i915 uses, but we don't
and this seems easier for now.

We have to fix up at least nouveau and radeon I think as well.

Dave.

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

[PATCH 1/3] x86/pat: export io memory reserve/free api.

[Dave Airlie]

From: Dave Airlie 

These functions are needed for gpu/ttm drivers to reserve the
VRAM area as write combined. In a lot of places we don't ioremap
but still need to insert pfn from it into a VMA using vm_insert_mixed,
but a recent change in mixed insertion means we need to reserve
VRAM as WC upfront, so we need these APIs exported.

Signed-off-by: Dave Airlie 
---
 arch/x86/mm/pat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 170cc4f..5ce2fbb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -719,6 +719,7 @@ out_free:
 out_err:
return ret;
 }
+EXPORT_SYMBOL(io_reserve_memtype);
 
 /**
  * io_free_memtype - Release a memory type mapping for a region of memory
@@ -729,6 +730,7 @@ void io_free_memtype(resource_size_t start, resource_size_t 
end)
 {
free_memtype(start, end);
 }
+EXPORT_SYMBOL(io_free_memtype);
 
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
-- 
2.5.5

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

Re: [PATCH 1/3] x86/pat: export io memory reserve/free api.

[Edward O'Callaghan]

NACK,

I think you want to use 'iomap_create_wc()' instead to avoid aliasing.

Kind Regards,
Edward.

On 10/18/2016 05:13 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> These functions are needed for gpu/ttm drivers to reserve the
> VRAM area as write combined. In a lot of places we don't ioremap
> but still need to insert pfn from it into a VMA using vm_insert_mixed,
> but a recent change in mixed insertion means we need to reserve
> VRAM as WC upfront, so we need these APIs exported.
> 
> Signed-off-by: Dave Airlie 
> ---
>  arch/x86/mm/pat.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 170cc4f..5ce2fbb 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -719,6 +719,7 @@ out_free:
>  out_err:
>   return ret;
>  }
> +EXPORT_SYMBOL(io_reserve_memtype);
>  
>  /**
>   * io_free_memtype - Release a memory type mapping for a region of memory
> @@ -729,6 +730,7 @@ void io_free_memtype(resource_size_t start, 
> resource_size_t end)
>  {
>   free_memtype(start, end);
>  }
> +EXPORT_SYMBOL(io_free_memtype);
>  
>  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>   unsigned long size, pgprot_t vma_prot)
> 



signature.asc
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH xf86-video-amdgpu] amdgpu_probe: Do not close server managed drm fds

[Michel Dänzer]

[ Moving to the amd-gfx mailing list, where xf86-video-amdgpu (and -ati)
patches are reviewed ]

On 18/10/16 11:48 PM, Hans de Goede wrote:
> This fixes the xserver only seeing AMD/ATI devices supported by the amdgpu
> driver, as by the time xf86-video-ati gets a chance to probe them, the
> fd has been closed.

That basically makes sense, but I have one question: Why does amdgpu get
probed in the first place in that case? I was under the impression that
this should only happen for GPUs bound to the amdgpu kernel driver, due
to Section "OutputClass" in /usr/share/X11/xorg.conf.d/10-amdgpu.conf .


> diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c
> index 213d245..5d17fe5 100644
> --- a/src/amdgpu_probe.c
> +++ b/src/amdgpu_probe.c
> @@ -142,6 +142,15 @@ static int amdgpu_kernel_open_fd(ScrnInfoPtr pScrn, char 
> *busid,
>   return fd;
>  }
>  
> +static void amdgpu_kernel_close_fd(AMDGPUEntPtr pAMDGPUEnt)
> +{
> +#ifdef XF86_PDEV_SERVER_FD
> + if (!(pAMDGPUEnt->platform_dev &&
> +   pAMDGPUEnt->platform_dev->flags & XF86_PDEV_SERVER_FD))
> +#endif
> + drmClose(pAMDGPUEnt->fd);
> +}

AMDGPUFreeRec could also be refactored to call this function.


> @@ -164,7 +173,7 @@ static Bool amdgpu_open_drm_master(ScrnInfoPtr pScrn, 
> AMDGPUEntPtr pAMDGPUEnt,
>   if (err != 0) {
>   xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
>  "[drm] failed to set drm interface version.\n");
> - drmClose(pAMDGPUEnt->fd);
> + amdgpu_kernel_close_fd(pAMDGPUEnt);
>   return FALSE;
>   }
> @@ -252,7 +261,7 @@ static Bool amdgpu_get_scrninfo(int entity_num, struct 
> pci_device *pci_dev)
>   return TRUE;
>  
>  error_amdgpu:
> - drmClose(pAMDGPUEnt->fd);
> + amdgpu_kernel_close_fd(pAMDGPUEnt);
>  error_fd:
>   free(pPriv->ptr);
>  error:

These two hunks aren't really necessary, right? These only get called
from amdgpu_pci_probe, in which case pAMDGPUEnt->platform_dev remains NULL.


> @@ -347,6 +356,7 @@ amdgpu_platform_probe(DriverPtr pDriver,
>  
>   pPriv->ptr = xnfcalloc(sizeof(AMDGPUEntRec), 1);
>   pAMDGPUEnt = pPriv->ptr;
> + pAMDGPUEnt->platform_dev = dev;
>   pAMDGPUEnt->fd = amdgpu_kernel_open_fd(pScrn, busid, dev);
>   if (pAMDGPUEnt->fd < 0)
>   goto error_fd;
> @@ -365,7 +375,6 @@ amdgpu_platform_probe(DriverPtr pDriver,
>   pAMDGPUEnt = pPriv->ptr;
>   pAMDGPUEnt->fd_ref++;
>   }
> - pAMDGPUEnt->platform_dev = dev;
>  
>   xf86SetEntityInstanceForScreen(pScrn, pEnt->index,
>  xf86GetNumEntityInstances(pEnt->

These two hunks aren't really necessary either, are they?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx