Kernel 4.15

AmigaOne X1000 platform specific issues related to Linux only.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

Tom,

Many thanks for testing the alpha5 and the RC1!

Cheers,
Christian
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
TearsOfMe
Posts: 30
Joined: Sat Jul 07, 2012 5:34 pm
Location: Westerwald (Germany)

Re: Kernel 4.15

Post by TearsOfMe »

Hi.
The 4.15 works here also.
Testet with your PowerPCRemix 0.8 and RadeonHD6450.

P.S.: I have problems with the network. Must test a litte more.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

TearsOfMe wrote:Hi.
The 4.15 works here also.
Testet with your PowerPCRemix 0.8 and RadeonHD6450.

P.S.: I have problems with the network. Must test a litte more.
Thanks a lot for testing. :-) What kind of problems do you have with the network?

-- Christian
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

FYI:
Michel Dänzer wrote: On 2017-11-27 01:17 PM, Tom St Denis wrote:

>
>
> On 27/11/17 07:02 AM, Michel Dänzer wrote:
>
>
>>
>>
>> On 2017-11-27 12:50 PM, Christian König wrote:
>>
>>
>>>
>>>
>>> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>>>
>>>
>>>>
>>>>
>>>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I bisected today and the first bad commit is:
>>>>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper
>>>>>> functions
>>>>>> to populate/map in one call (v2)) [1]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> It can't really be that commit, since it just adds functions but
>>>>> doesn't
>>>>> hook them up anywhere. Presumably it's commit
>>>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>>>> populate/dma map helper functions") instead, which makes the radeon
>>>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor
>>>>> CONFIG_INTEL_IOMMU is
>>>>> enabled.
>>>>>
>>>>> I can see two possible solutions:
>>>>>
>>>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>>>> work without SWIOTLB / INTEL_IOMMU as well.
>>>>>
>>>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>>>> ttm_unmap_and_unpopulate_pages again in that case.
>>>>>
>>>>>
>>>>> Solution 1 would be preferable.
>>>>>
>>>>>
>>>>
>>>>
>>>> Which solution do you want to go for?
>>>>
>>>>
>>>
>>>
>>> well, can somebody please explain to me why those patches actually
>>> result in problems?
>>>
>>>
>>
>>
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
>>
>>
>>
>>
>
>
> I think the issue is why would you have both disabled [...]
>
>

Doesn't matter. The drivers worked with both disabled before, now they
don't. That's a regression.


--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Christian König wrote: Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to handle the config options.

Please take a look at the attached patch, it should fix the issue (going to send that one out separately once more).

Regards,
Christian.
Michel Dänzer wrote: > On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
>> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
>> enabled?
> I doubt SWIOTLB provides any benefit for you.
>
>
> Can you test if Christian's patch fixes the problem with SWIOTLB disabled?
>
0001-drm-ttm-fix-populate_and_map-functions-once-more.patch

Code: Select all

>From a53c4574a06ee5a46d8e5b8fb10623c76513fe5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Mon, 27 Nov 2017 13:12:35 +0100
Subject: [PATCH] drm/ttm: fix populate_and_map() functions once more
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts "drm/ttm: Fix configuration error around populate_and_map()
functions".

This fix has gone into the wrong direction. Those helpers should be
available even when neither CONFIG_INTEL_IOMMU nor CONFIG_SWIOTLB are
set.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  2 --
 include/drm/ttm/ttm_page_alloc.h     | 32 ++++++++++----------------------
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 1543532b8740..c82d94cbbabc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1096,7 +1096,6 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
 }
 EXPORT_SYMBOL(ttm_pool_unpopulate);
 
-#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
 	unsigned i, j;
@@ -1167,7 +1166,6 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
 	ttm_pool_unpopulate(&tt->ttm);
 }
 EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
-#endif
 
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 38a2b4770c35..593811362a91 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -59,11 +59,20 @@ int ttm_pool_populate(struct ttm_tt *ttm);
 void ttm_pool_unpopulate(struct ttm_tt *ttm);
 
 /**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
  * Output the state of pools to debugfs file
  */
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
 
-
 #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 /**
  * Initialize pool allocator.
@@ -83,17 +92,6 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
 int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 
-
-/**
- * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
- */
-int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
-
-/**
- * Unpopulates and DMA unmaps pages as part of a
- * ttm_dma_unpopulate() request */
-void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
-
 #else
 static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
 					  unsigned max_pages)
@@ -116,16 +114,6 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
 				      struct device *dev)
 {
 }
-
-static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-	return -ENOMEM;
-}
-
-static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-}
-
 #endif
 
 #endif
-- 
2.11.0

http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

Michel Dänzer wrote: > On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
>> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
>> enabled?
> I doubt SWIOTLB provides any benefit for you.
>
>
> Can you test if Christian's patch fixes the problem with SWIOTLB disabled?
>
0001-drm-ttm-fix-populate_and_map-functions-once-more.patch

Code: Select all

>From a53c4574a06ee5a46d8e5b8fb10623c76513fe5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Mon, 27 Nov 2017 13:12:35 +0100
Subject: [PATCH] drm/ttm: fix populate_and_map() functions once more
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts "drm/ttm: Fix configuration error around populate_and_map()
functions".

This fix has gone into the wrong direction. Those helpers should be
available even when neither CONFIG_INTEL_IOMMU nor CONFIG_SWIOTLB are
set.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  2 --
 include/drm/ttm/ttm_page_alloc.h     | 32 ++++++++++----------------------
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 1543532b8740..c82d94cbbabc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1096,7 +1096,6 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
 }
 EXPORT_SYMBOL(ttm_pool_unpopulate);
 
-#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
 	unsigned i, j;
@@ -1167,7 +1166,6 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
 	ttm_pool_unpopulate(&tt->ttm);
 }
 EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
-#endif
 
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 38a2b4770c35..593811362a91 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -59,11 +59,20 @@ int ttm_pool_populate(struct ttm_tt *ttm);
 void ttm_pool_unpopulate(struct ttm_tt *ttm);
 
 /**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
  * Output the state of pools to debugfs file
  */
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
 
-
 #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 /**
  * Initialize pool allocator.
@@ -83,17 +92,6 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
 int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 
-
-/**
- * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
- */
-int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
-
-/**
- * Unpopulates and DMA unmaps pages as part of a
- * ttm_dma_unpopulate() request */
-void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
-
 #else
 static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
 					  unsigned max_pages)
@@ -116,16 +114,6 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
 				      struct device *dev)
 {
 }
-
-static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-	return -ENOMEM;
-}
-
-static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-}
-
 #endif
 
 #endif
-- 
2.11.0

Hi All,

Hardware 3D acceleration works with Christian's patch! I don't need to enable SWIOTLB anymore.

Thanks,
Christian
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
TearsOfMe
Posts: 30
Joined: Sat Jul 07, 2012 5:34 pm
Location: Westerwald (Germany)

Re: Kernel 4.15

Post by TearsOfMe »

Hi.
I can not reproduce the network problems.
I think i run it with the initrd from 4.14 but dont now.
Works now okay.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

TearsOfMe wrote:Hi.
I can not reproduce the network problems.
I think i run it with the initrd from 4.14 but dont now.
Works now okay.
Thank you for the info!

-- Christian
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

Hi All,

I have recently released the RC1-2 for the X5000 and X1000.

New:
Download: vmlinux-4.15-rc1-2-AmigaOne_X1000_X5000.tar.gz

fedora 26 Server PPC64 with the RC1-2 of kernel 4.15:

Image

Please test it.

Thanks,
Christian
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
User avatar
xeno74
Posts: 9349
Joined: Fri Mar 23, 2012 7:58 am

Re: Kernel 4.15

Post by xeno74 »

FYI:
On Thu, Nov 30, 2017 at 12:39:36AM +0100, Christian Zigotzky wrote:
On 29 November 2017 at 11:34PM, Bjorn Helgaas wrote:
On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky
Thank you for your answer. I have tried to boot the kernel 4.15
RC1 (built without the patch above) with the boot argument
"pci=pcie_scan_all" but without any success.

Just for info:

The CPU is a PA Semi “PWRficient” PA6T-1682M. This device
combines dual 1.8GHz PowerPC cores with a 2MB L2 cache, dual
channel DDR2 memory controllers and 24 SerDes channels. The
PowerPC cores adhere to the Power ISA v2.04, and support 64-bit
extensions. They feature a double precision FPU and a VMX
(AltiVec) vector unit. They each have a 64kB I-cache and a 64kB
D-cache. The SerDes channels support PCI Express, XAUI and SGMII
protocols. The “ENVOI” I/O subsystem which drives them includes
caching, offload and DMA resources to maximise I/O performance.

Nemo uses the AMD/ATI SB600 South Bridge to provide various
integrated I/O functions including SATA/PATA ports, USB and
audio. The SB600 connects to the CPU via a PCIe x4 link. This is
termed an “A-link II Express” link by ATI/AMD. The design team
determined early in the development of Nemo that the link’s
behaviour as an endpoint does not comply fully with the PCI
Express specification. Specifically, it requires the root complex
to use non-zero device numbers in type 0 configuration cycles to
enumerate all the devices within the SB600. This is related to
the PC architecture and is used to allow SB600 devices appear on
logical bus 0.

More information about the Nemo board:

https://en.wikipedia.org/wiki/AmigaOne_X1000
http://www.a-eon.com/?page=x1000
http://www.amigaos.net/hardware/35/amigaone-x1000

It looks like the SB600 devices actually appear on bus 05 (not 00),
right? I see these devices (among others):

00:10.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
00:11.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
01:00.0 VGA compatible controller: [AMD/ATI] Barts XT [Radeon HD 6870]
05:12.0 SATA controller: [AMD/ATI] SB600 Non-Raid-5 SATA
05:14.4 PCI bridge: [AMD/ATI] SBx00 PCI to PCI Bridge
06:05.0 Ethernet controller: RTL-8100/8101L/8139

So 00:10.0 and 00:11.0 are bridges leading to buses 01 and 05-06.
Maybe 00:11.0 is the Downstream Port that leads to this magic "A-Link
II Express" thing?

But I don't think all those SB600 devices on bus 05 are PCIe devices.
It would certainly be unconventional to have a PCIe device (00:11.0)
at the upstream end of a link and conventional PCI devices (05:12.0,
05:13.0, 05:13.1, etc) at the downstream end, with no visible PCIe
port.

The usual thing would be that 00:11.0 would be a Root Port or a Switch
Downstream Port leading to a Link, and the other end of the Link would
terminate in either a Switch Upstream Port or an Upstream Port
embedded in an Endpoint.

We'll have to think about how to handle this. But the complete "lspci
-vv" output as root will have more useful information.

Thanks for your reply. Please find attached the complete "lspci -vv"
output as root.

00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
means there's a Link (presumably this A-Link II Express thing), and the
downstream end of the Link *should* be a PCIe Upstream Port on bus 05,
but no such device is visible. I suppose the SB600 does implement
some sort of PCIe Port there, but keeps it invisible to software, and
at the same time, contains an invisible bridge that connects the Link
to all the conventional PCI devices on bus 05.

When we scan bus 05, we do this:

pci_scan_child_bus_extend(bus=05)
for (devfn = 0; devfn < 0x100; devfn += 8)
pci_scan_slot(05, 00.0)
pci_scan_single_device
pci_scan_device(05, 00.0) # fails; no 05:00.0
pci_scan_slot(05, 01.0)
only_one_child(bus=05)
parent = 00:11.0
pci_pcie_type(00:11.0) == ROOT_PORT # returns true

Since only_one_child() sees that 00:11.0 is a Root Port, we give up
before we even get to the PCI_SCAN_ALL_PCIE_DEVS test.

I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?


commit 75eaf674066590e79b3e03d32488871fc881ab40
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Thu Nov 30 15:22:39 2017 -0600

PCI: Make PCI_SCAN_ALL_PCIE_DEVS work for Root Ports as well as Downstream

Previously PCI_SCAN_ALL_PCIE_DEVS (set by quirks or the "pci=pcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports.

Simplify and restructure only_one_child() so PCI_SCAN_ALL_PCIE_DEVS means
we scan for all possible devices below Root Ports as well as Switch
Downstream Ports.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 14e0ea1ff38b..9e57d4ef0c1f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2217,20 +2217,28 @@ static int only_one_child(struct pci_bus *bus)
{
struct pci_dev *parent = bus->self;

- if (!parent || !pci_is_pcie(parent))
+ if (!parent)
+ return 0;
+
+ /*
+ * Systems with unusual topologies set PCI_SCAN_ALL_PCIE_DEVS so
+ * we scan for all possible devices, not just Device 0.
+ */
+ if (pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
return 0;
- if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT)
- return 1;

/*
- * PCIe downstream ports are bridges that normally lead to only a
- * device 0, but if PCI_SCAN_ALL_PCIE_DEVS is set, scan all
- * possible devices, not just device 0. See PCIe spec r3.0,
- * sec 7.3.1.
+ * A PCIe Downstream Port normally leads to a Link with only Device
+ * 0 on it (PCIe spec r3.1, sec 7.3.1). As an optimization, scan
+ * only for Device 0 in that situation.
+ *
+ * Checking has_secondary_link is a hack to identify Downstream
+ * Ports because sometimes Switches are configured such that the
+ * PCIe Port Type labels are backwards.
*/
- if (parent->has_secondary_link &&
- !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
+ if (pci_is_pcie(parent) && parent->has_secondary_link)
return 1;
+
return 0;
}
http://www.amigalinux.org
http://www.supertuxkart-amiga.de

Running Linux on AmigaONEs can require some tinkering.
Post Reply