* Re: [PATCH] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Srivatsa S. Bhat @ 2014-04-03 8:50 UTC (permalink / raw)
To: Michael wang
Cc: sfr, Srikar Dronamraju, LKML, jlarrew, paulus, alistair, nfont,
Andrew Morton, rcj, linuxppc-dev
In-Reply-To: <533B8431.8090507@linux.vnet.ibm.com>
On 04/02/2014 08:59 AM, Michael wang wrote:
> During the testing, we encounter below WARN followed by Oops:
>
> WARNING: at kernel/sched/core.c:6218
> ...
> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
> PACATMSCRATCH [800000000000f032]
> Call Trace:
> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> PACATMSCRATCH [8000000000029032]
> Call Trace:
> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
>
> This was caused by that 'sd->groups == NULL' after building groups, which
> was caused by the empty 'sd->span'.
>
> The cpu's domain contain nothing because the cpu was assigned to wrong
> node inside arch_update_cpu_topology() by calling update_lookup_table()
> with the uninitialized param, in the case when there is nothing to be
> update.
>
I think we need to verify this theory. Here are my thoughts:
If we get a topology update notification from the hypervisor, and then the
update happens to be nothing new (as in, new_node == old_node for the given
cpu), then updated_cpus mask will not have any cpus set in it (like you noted
below). In that scenario, the following sequence will take place:
Inside arch_cpu_update_topology(), the 'updates' has been kzalloc()'ed.
So updates[0] will have all its fields set to 0, such as ->cpu, ->new_nid etc.
When we invoke stop_machine() the first time like this:
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
stop-machine will notice that updated_cpus mask does not have any cpus set
in it, so it will nominate cpumask_first(cpu_online_mask) to run the
update_cpu_topology() function, which means that CPU0 will run it.
So, when CPU0 runs update_cpu_topology(), it will find that cpu == update->cpu
since both are 0, and will invoke unmap_cpu_from_node() and then calls
map_cpu_to_node(), with update->new_nid == 0.
Now, the interesting thing to note here is that, if CPU0's node was already
set as node0, *nothing* should go wrong, since its just a redundant update.
However, if CPU0's original node mapping was something different, or if
node0 doesn't even exist in the machine, then the system can crash.
Have you verified that CPU0's node mapping is different from node 0?
That is, boot the kernel with "numa=debug" in the kernel command line and
it will print out the cpu-to-node associativity during boot. That way you
can figure out what was the original associativity that was set. This will
confirm the theory that the hypervisor sent a redundant update, but because
of the weird pre-allocation using kzalloc that we do inside
arch_update_cpu_topology(), we wrongly updated CPU0's mapping as CPU0 <-> Node0.
Regards,
Srivatsa S. Bhat
> Thus we should stop the updating in such cases, this patch will achieve
> this and fix the issue.
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> CC: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 30a42e2..6757690 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1591,6 +1591,14 @@ int arch_update_cpu_topology(void)
> cpu = cpu_last_thread_sibling(cpu);
> }
>
> + /*
> + * The 'cpu_associativity_changes_mask' could be cleared if
> + * all the cpus it indicates won't change their node, in
> + * which case the 'updated_cpus' will be empty.
> + */
> + if (!cpumask_weight(&updated_cpus))
> + goto out;
> +
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>
> /*
> @@ -1612,6 +1620,7 @@ int arch_update_cpu_topology(void)
> changed = 1;
> }
>
> +out:
> kfree(updates);
> return changed;
> }
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:11 UTC (permalink / raw)
To: sandeep.kumar, netdev, linux-kernel, Tao, Yue,
Yang, Zhangle (Eric), guang.yang, joe, festevam, linuxppc-dev,
richardcochran, clarocq, yongjun_wei, Claudiu Manoil, w, zhuyj
In-Reply-To: <53310F4E.4080104@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.
Based on kernel 2.6.x, gianfar nic driver can not work well. The root
cause is that tx vlan of gianfar can not handle VLAN tag 0. So on kernel
3.0+, this tx vlan feature is disabled. But on kernel 2.6.x, this
feature is still enabled. This patch will disable this feature of
gianfar nic driver. If this feature is enabled, gianfar nic can not
support vlan packets and non-vlan packets at the same time. The
following steps will reproduce this problem.
The steps are as below.
1. boot two freescale-p2020 boards with linux kernel 2.6.x, then
connected 2 gfar-enet nic cards with a direct network line;
2. On board 1, checked the driver of eth0
ethtool -i eth0
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
On board 2, I checked the driver of eth1
ethtool -i eth1
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
3. Then configure the ip address on the above 2 nic cards.
On board 1,
ifconfig eth0 192.168.1.13/24 up
On board 2,
ifconfig eth1 192.168.1.196/24 up
4. We can access the other board on one board.
For example, on board 1, we can ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
5. We configure vlan on these 2 boards. VLAN tag 0
On board 1,
modprobe 8021q
vconfig add eth0 4091
ifconfig eth0.4091 10.1.1.13/24 up
On board 2,
modprobe 8021q
vconfig add eth1 4091
ifconfig eth1.4091 10.1.1.196/24 up
6. We can access the other board on one board through vlan.
For example, on board 1, we can ping board 2 through vlan nic.
root@p2020rdb:/root> ping 10.1.1.196
PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
But we can not access the other board on one board through raw nic.
For example, on board, we can not ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
Best Regards!
Zhu Yanjun
On 03/25/2014 01:08 PM, zhuyj wrote:
> Hi, Sandeep Gopalpet
>
> I am a developer. Now I confronted an interesting phenomena. When I
> used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw
> and vlan packets on gfar-enet nic. But with e1000e nic, we can make
> vlan and raw packets work well. I looked into the source code and find
> that maybe it is related with hardware insert and remove vlan head.
> But I have no the specifications of gfar-enet nic. Would you like to
> give some document or some guides?
>
> Thanks a lot.
> Zhu Yanjun
>
> The steps are as below.
>
> 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then
> I connected 2 gfar-enet nic cards with a direct network line;
>
> 2. On board 1, I checked the driver of eth0
>
> ethtool -i eth0
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> On board 2, I checked the driver of eth1
>
> ethtool -i eth1
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> 3. Then I configure the ip address on the above 2 nic cards.
>
> On board 1,
>
> ifconfig eth0 192.168.1.13/24 up
>
> On board 2,
>
> ifconfig eth1 192.168.1.196/24 up
>
> 4. We can access the other board on one board.
> For example, on board 1, we can ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
> 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> 5. We configure vlan on these 2 boards. VLAN tag 0
> On board 1,
>
> modprobe 8021q
> vconfig add eth0 4091
> ifconfig eth0.4091 10.1.1.13/24 up
>
> On board 2,
>
> modprobe 8021q
> vconfig add eth1 4091
> ifconfig eth1.4091 10.1.1.196/24 up
>
> 6. We can access the other board on one board through vlan.
> For example, on board 1, we can ping board 2 through vlan nic.
>
> root@p2020rdb:/root> ping 10.1.1.196
> PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
> 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> But we can not access the other board on one board through raw nic.
> For example, on board, we can not ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
>
>
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]
>From afd48fa3ad5b15d519adeb19b2a9c00051327c68 Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
Since there is something wrong with tx vlan of gianfar nic driver,
on kernel(3.0+), tx vlan is disabled. But on kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 9:27 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D25D4.4000607@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
>
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
> a lot.
>
> Hi, Willy
>
> Please help to merge this patch to longterm: 2.6.32.61 since this
> problem also occurs on this kernel. Thanks a lot.
Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:57 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I reference the following 2 mainline commits. These 2 commits are based
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will
not be fixed yet.
Best Regards!
Zhu Yanjun
1. commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
Author: Jiri Pirko <jpirko@redhat.com>
Date: Wed Jul 20 04:54:19 2011 +0000
gianfar: do vlan cleanup
- unify vlan and nonvlan rx path
- kill priv->vlgrp and gfar_vlan_rx_register
- allow to turn on/off rx/tx vlan accel via ethtool
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 55
++++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 26 deletions(-)
2.commit b852b720877e6b8e12b95a7cb4e00ea351b8cbfc
Author: Sebastian Pöhn <sebastian.belden@googlemail.com>
Date: Tue Jul 26 00:03:13 2011 +0000
gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e "gianfar: do vlan
cleanup" has two issues:
# permutation of rx and tx flags
# enabling vlan tag insertion by default (this leads to unusable
connections on some configurations)
If VLAN insertion is requested (via ethtool) it will be set at an
other point ...
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:01 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D30A1.1060509@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will
> not be fixed yet.
OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.
I'll merge your patch and put these references there.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:15 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I made a new patch. In long commit message, I inserted the equivalent
mainline commit
about this feature. Maybe it is better. Now this patch is in the
attachment. Please check
and merge it into kernel 2.6.32.62.
Thanks a lot.
Zhu Yanjun
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1688 bytes --]
>From 3b74ad6134f8eccce9ee391fb02ff15863630c1b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
2.6.x kernels require a similar logic change as commit e1653c3e
[gianfar: do vlan cleanup] and commit 51b8cbfc
[gianfar: fix bug caused by e1653c3e] introduces for newer kernels.
Since there is something wrong with tx vlan of gianfar nic driver,
in kernel(3.1+), tx vlan is disabled. But in kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets at the same time.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:18 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403100128.GE16158@1wt.eu>
On 04/03/2014 06:01 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
>> I reference the following 2 mainline commits. These 2 commits are based
>> on the current kernel 3.x and ethtool.
>> If we only backport these 2 commits on kernel 2.6.x, this problem will
>> not be fixed yet.
> OK fine, I just wanted that we keep the reference of these equivalent
> patches in the commit message so that if later a newer patch changes
> anything they did, at least we have some indications that the commit
> might also have to be revisited.
>
> I'll merge your patch and put these references there.
>
> Thanks,
> Willy
OK. Thanks a lot.
Zhu Yanjun
> .
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:21 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D34BD.900@gmail.com>
On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
>
> I made a new patch. In long commit message, I inserted the equivalent
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the
> attachment. Please check
> and merge it into kernel 2.6.32.62.
Sure, it's much better this way.
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH RFC v10 0/6] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-04-03 10:59 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1395326878-25243-1-git-send-email-a13xp0p0v88@gmail.com>
Hello,
2014-03-20 18:47 GMT+04:00 Alexander Popov <a13xp0p0v88@gmail.com>:
> Changes in v10:
> Part 2/6:
> - don't use direction field of dma_slave_config in mpc_dma_device_control()
> but store settings in mpc_dma_chan for both DMA_DEV_TO_MEM and
> DMA_MEM_TO_DEV cases; then retrieve the needed values in
> mpc_dma_prep_slave_sg();
> - fix style issue and put 2014 instead of 2013;
> Part 3/6:
> - fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
> dispose IRQ mappings before devm_* takes care of other resources;
> Part 6/6:
> - change according the new part 3/6;
> - fix style issue;
Excuse me, could I have a feedback?
Thanks!
> Alexander Popov (5):
> dma: mpc512x: reorder mpc8308 specific instructions
> dma: mpc512x: add support for peripheral transfers
> dma: mpc512x: fix freeing resources in mpc_dma_probe() and
> mpc_dma_remove()
> dma: of: Add common xlate function for matching by channel id
> dma: mpc512x: register for device tree channel lookup
>
> Gerhard Sittig (1):
> dma: mpc512x: add device tree binding document
>
> .../devicetree/bindings/dma/mpc512x-dma.txt | 55 ++++
> arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
> drivers/dma/mpc512x_dma.c | 345 ++++++++++++++++++---
> drivers/dma/of-dma.c | 35 +++
> include/linux/of_dma.h | 4 +
> 5 files changed, 402 insertions(+), 38 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>
> --
> 1.8.4.2
Best regards,
Alexander
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:36 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <CAFgQCTs8LSXUi+AwxR9j+2-QRGw4EFZWx-JxktAnJ3VvwLJb9A@mail.gmail.com>
On 03.04.14 04:36, Liu ping fan wrote:
> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
> enable numa fault for powerpc.
What bad happens without this patch? We map a page even though it was
declared to get NUMA migrated? What happens next?
I'm trying to figure out whether I need to mark this with a stable tag
for 3.14.
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:38 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D47CD.906@suse.com>
On 03.04.14 13:36, Alexander Graf wrote:
>
> On 03.04.14 04:36, Liu ping fan wrote:
>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>> enable numa fault for powerpc.
>
> What bad happens without this patch? We map a page even though it was
> declared to get NUMA migrated? What happens next?
>
> I'm trying to figure out whether I need to mark this with a stable tag
> for 3.14.
Also, what about the other uses of pre_present()?
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:43 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D4834.7050306@suse.com>
On 03.04.14 13:38, Alexander Graf wrote:
>
> On 03.04.14 13:36, Alexander Graf wrote:
>>
>> On 03.04.14 04:36, Liu ping fan wrote:
>>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>>> enable numa fault for powerpc.
>>
>> What bad happens without this patch? We map a page even though it was
>> declared to get NUMA migrated? What happens next?
>>
>> I'm trying to figure out whether I need to mark this with a stable
>> tag for 3.14.
>
> Also, what about the other uses of pre_present()?
Oh how I love to reply to myself. The patch doesn't apply to the latest
code anymore either. Also please rework the wording of your patch
subject and patch description to explain the actual problem at hand.
Alex
^ permalink raw reply
* cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
From: Yann Droneaud @ 2014-04-03 13:16 UTC (permalink / raw)
To: Michael Ellerman, Anton Blanchard, Benjamin Herrenschmidt,
Hans-Bernhard Bröker, Hans-Bernhard Broeker, Neil Horman,
Neil Horman
Cc: cscope-devel, linuxppc-dev, linux-kernel
Hi,
I'm using cscope to browse kernel sources, but I'm facing warnings from
the tool since following commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b
commit 22d651dcef536c75f75537290bf3da5038e68b6b
Author: Michael Ellerman <mpe@ellerman.id.au>
Date: Tue Jan 21 15:22:17 2014 +1100
selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests
Turn Anton's memcpy / copy_tofrom_user test into something that can
live in tools/testing/selftests.
It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's
pretty harmless IMHO.
We are sailing very close to the wind with the feature macros. We
define them to nothing, which currently means we get a few extra
nops and include the unaligned calls.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
cscope reports error when generating the cross-reference database:
$ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
GEN cscope
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
And when calling cscope from ./obj-cscope/ directory, it reports errors
too.
Hopefully it doesn't stop it from working, so I'm still able to use
cscope to browse kernel sources.
It's a rather uncommon side effect of having (for the first time ?)
sources files as symlinks: looking for symlinks in the kernel sources
returns only:
$ find . -type l
./arch/mips/boot/dts/include/dt-bindings
./arch/microblaze/boot/dts/system.dts
./arch/powerpc/boot/dts/include/dt-bindings
./arch/metag/boot/dts/include/dt-bindings
./arch/arm/boot/dts/include/dt-bindings
./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
./tools/testing/selftests/powerpc/copyloops/memcpy_64.S
./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
./tools/testing/selftests/powerpc/copyloops/copyuser_64.S
./obj-cscope/source
./Documentation/DocBook/vidioc-g-sliced-vbi-cap.xml
./Documentation/DocBook/vidioc-decoder-cmd.xml
...
./Documentation/DocBook/media-func-ioctl.xml
./Documentation/DocBook/vidioc-enumoutput.xml
So one can wonder if having symlinked sources files is an expected
supported feature for kbuild and all the various kernel
tools/infrastructure ?
Regarding cscope specifically, it does not support symlink, and it's the
expected behavior according to the bug reports I was able to find:
#214 cscope ignores symlinks to files
http://sourceforge.net/p/cscope/bugs/214/
#229 -I options doesn't handle symbolic link
http://sourceforge.net/p/cscope/bugs/229/
#247 cscope: cannot find file
http://sourceforge.net/p/cscope/bugs/247/
#252 cscope: cannot find file ***
http://sourceforge.net/p/cscope/bugs/252/
#261 Regression - version 15.7a does not follow symbolic links
http://sourceforge.net/p/cscope/bugs/261/
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* Re: [RFC PATCH] hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Aneesh Kumar K.V @ 2014-04-03 16:19 UTC (permalink / raw)
To: Nishanth Aravamudan, linux-mm; +Cc: linuxppc-dev, paulus, anton, nyc
In-Reply-To: <20140326155815.GB15234@linux.vnet.ibm.com>
Nishanth Aravamudan <nacc@linux.vnet.ibm.com> writes:
> On 24.03.2014 [16:02:56 -0700], Nishanth Aravamudan wrote:
>> In KVM guests on Power, if the guest is not backed by hugepages, we see
>> the following in the guest:
>>
>> AnonHugePages: 0 kB
>> HugePages_Total: 0
>> HugePages_Free: 0
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 64 kB
>>
>> This seems like a configuration issue -- why is a hstate of 64k being
>> registered?
>>
>> I did some debugging and found that the following does trigger,
>> mm/hugetlb.c::hugetlb_init():
>>
>> /* Some platform decide whether they support huge pages at boot
>> * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
>> * there is no such support
>> */
>> if (HPAGE_SHIFT == 0)
>> return 0;
>>
>> That check is only during init-time. So we don't support hugepages, but
>> none of the hugetlb APIs actually check this condition (HPAGE_SHIFT ==
>> 0), so /proc/meminfo above falsely indicates there is a valid hstate (at
>> least one). But note that there is no /sys/kernel/mm/hugepages meaning
>> no hstate was actually registered.
>>
>> Further, it turns out that huge_page_order(default_hstate) is 0, so
>> hugetlb_report_meminfo is doing:
>>
>> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10)
>>
>> which ends up just doing 1 << (PAGE_SHIFT - 10) and since the base page
>> size is 64k, we report a hugepage size of 64k... And allow the user to
>> allocate hugepages via the sysctl, etc.
>>
>> What's the right thing to do here?
>>
>> 1) Should we add checks for HPAGE_SHIFT == 0 to all the hugetlb APIs? It
>> seems like HPAGE_SHIFT == 0 should be the equivalent, functionally, of
>> the config options being off. This seems like a lot of overhead, though,
>> to put everywhere, so maybe I can do it in an arch-specific macro, that
>> in asm-generic defaults to 0 (and so will hopefully be compiled out?).
>>
>> 2) What should hugetlbfs do when HPAGE_SHIFT == 0? Should it be
>> mountable? Obviously if it's mountable, we can't great files there
>> (since the fs will report insufficient space). [1]
>
> Here is my solution to this. Comments appreciated!
>
> In KVM guests on Power, in a guest not backed by hugepages, we see the
> following:
>
> AnonHugePages: 0 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 64 kB
>
> HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
> are not supported at boot-time, but this is only checked in
> hugetlb_init(). Extract the check to a helper function, and use it in a
> few relevant places.
>
> This does make hugetlbfs not supported in this environment. I believe
> this is fine, as there are no valid hugepages and that won't change at
> runtime.
>
> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Looks good. Can you resubmit it as a proper patch ? You may also want to
capture in commit message saying hugetlbfs file system also will not be
registered.
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index d19b30a..c7aa477 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
> int error;
> int i;
>
> + if (!hugepages_supported()) {
> + printk(KERN_ERR "hugetlbfs: Disabling because there are no supported page sizes\n");
> + return -ENOTSUPP;
> + }
> +
> error = bdi_init(&hugetlbfs_backing_dev_info);
> if (error)
> return error;
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 8c43cc4..0aea8de 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -450,4 +450,14 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
> return ptl;
> }
>
> +static inline bool hugepages_supported(void)
> +{
> + /*
> + * Some platform decide whether they support huge pages at boot
> + * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> + * there is no such support
> + */
> + return HPAGE_SHIFT != 0;
> +}
> +
> #endif /* _LINUX_HUGETLB_H */
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c01cb9f..1c99585 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1949,11 +1949,7 @@ module_exit(hugetlb_exit);
>
> static int __init hugetlb_init(void)
> {
> - /* Some platform decide whether they support huge pages at boot
> - * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> - * there is no such support
> - */
> - if (HPAGE_SHIFT == 0)
> + if (!hugepages_supported())
> return 0;
>
> if (!size_to_hstate(default_hstate_size)) {
> @@ -2069,6 +2065,9 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->max_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2122,6 +2121,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->nr_overcommit_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2147,6 +2149,8 @@ out:
> void hugetlb_report_meminfo(struct seq_file *m)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return;
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> @@ -2163,6 +2167,8 @@ void hugetlb_report_meminfo(struct seq_file *m)
> int hugetlb_report_node_meminfo(int nid, char *buf)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return 0;
> return sprintf(buf,
> "Node %d HugePages_Total: %5u\n"
> "Node %d HugePages_Free: %5u\n"
> @@ -2177,6 +2183,9 @@ void hugetlb_show_meminfo(void)
> struct hstate *h;
> int nid;
>
> + if (!hugepages_supported())
> + return;
> +
> for_each_node_state(nid, N_MEMORY)
> for_each_hstate(h)
> pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-04-03 16:41 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140401013346.GD5144@linux.vnet.ibm.com>
On Mon, 31 Mar 2014, Nishanth Aravamudan wrote:
> Yep. The node exists, it's just fully exhausted at boot (due to the
> presence of 16GB pages reserved at boot-time).
Well if you want us to support that then I guess you need to propose
patches to address this issue.
> I'd appreciate a bit more guidance? I'm suggesting that in this case the
> node functionally has no memory. So the page allocator should not allow
> allocations from it -- except (I need to investigate this still)
> userspace accessing the 16GB pages on that node, but that, I believe,
> doesn't go through the page allocator at all, it's all from hugetlb
> interfaces. It seems to me there is a bug in SLUB that we are noting
> that we have a useless per-node structure for a given nid, but not
> actually preventing requests to that node or reclaim because of those
> allocations.
Well if you can address that without impacting the fastpath then we could
do this. Otherwise we would need a fake structure here to avoid adding
checks to the fastpath
> I think there is a logical bug (even if it only occurs in this
> particular corner case) where if reclaim progresses for a THISNODE
> allocation, we don't check *where* the reclaim is progressing, and thus
> may falsely be indicating that we have done some progress when in fact
> the allocation that is causing reclaim will not possibly make any more
> progress.
Ok maybe we could address this corner case. How would you do this?
^ permalink raw reply
* [PATCH 00/20] FDT clean-ups and libfdt support
From: Rob Herring @ 2014-04-03 22:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, Aurelien Jacquiot, H. Peter Anvin, Max Filippov,
Paul Mackerras, linux, Jonas Bonn, Rob Herring, Russell King,
linux-c6x-dev, x86, Ingo Molnar, Mark Salter, Grant Likely,
linux-xtensa, James Hogan, Thomas Gleixner, linux-metag,
linux-arm-kernel, Chris Zankel, Michal Simek, Vineet Gupta,
Ralf Baechle, linuxppc-dev
From: Rob Herring <robh@kernel.org>
This is a series of clean-ups of architecture FDT code and converts the
core FDT code over to using libfdt functions. This is in preparation
to add FDT based address translation parsing functions for early
console support.
The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need
to be copied out of init section. Patches 2 and 3 should be applied to
3.15.
A branch is available here[1]. Please test! I've compiled on arm,
arm64, mips, microblaze, and powerpc and booted on arm and arm64.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt
Rob Herring (20):
mips: octeon: convert to use unflatten_and_copy_device_tree
mips: lantiq: copy built-in DTB out of init section
mips: xlp: copy built-in DTB out of init section
mips: ralink: convert to use unflatten_and_copy_device_tree
ARM: dt: use default early_init_dt_alloc_memory_arch
c6x: convert fdt pointers to opaque pointers
mips: convert fdt pointers to opaque pointers
of/fdt: consolidate built-in dtb section variables
of/fdt: create common debugfs
of/fdt: remove some unneeded includes
of/fdt: remove unused of_scan_flat_dt_by_path
of/fdt: update of_get_flat_dt_prop in prep for libfdt
of/fdt: Convert FDT functions to use libfdt
of/fdt: use libfdt accessors for header data
of/fdt: move memreserve and dtb memory reservations into core
build: add libfdt include path globally
powerpc: use libfdt accessors for header data
x86: use libfdt accessors for header data
of/fdt: convert initial_boot_params to opaque pointer
of: push struct boot_param_header and defines into powerpc
Makefile | 5 +
arch/arc/include/asm/sections.h | 1 -
arch/arc/kernel/devtree.c | 2 +-
arch/arm/include/asm/prom.h | 2 -
arch/arm/kernel/devtree.c | 34 +--
arch/arm/mach-exynos/exynos.c | 2 +-
arch/arm/mach-vexpress/platsmp.c | 2 +-
arch/arm/mm/init.c | 1 -
arch/arm/plat-samsung/s5p-dev-mfc.c | 4 +-
arch/arm64/mm/init.c | 21 --
arch/c6x/kernel/setup.c | 4 +-
arch/metag/kernel/setup.c | 4 -
arch/microblaze/kernel/prom.c | 37 +--
arch/mips/cavium-octeon/Makefile | 3 -
arch/mips/cavium-octeon/setup.c | 18 +-
arch/mips/include/asm/mips-boards/generic.h | 4 -
arch/mips/include/asm/prom.h | 6 +-
arch/mips/kernel/prom.c | 2 +-
arch/mips/lantiq/prom.c | 15 +-
arch/mips/lantiq/prom.h | 2 -
arch/mips/mti-sead3/Makefile | 2 -
arch/mips/mti-sead3/sead3-setup.c | 8 +-
arch/mips/netlogic/xlp/dt.c | 17 +-
arch/mips/ralink/of.c | 29 +--
arch/openrisc/kernel/vmlinux.h | 2 -
arch/powerpc/include/asm/prom.h | 39 +++
arch/powerpc/kernel/epapr_paravirt.c | 2 +-
arch/powerpc/kernel/fadump.c | 4 +-
arch/powerpc/kernel/prom.c | 77 ++----
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/mm/hash_utils_64.c | 22 +-
arch/powerpc/platforms/52xx/efika.c | 4 +-
arch/powerpc/platforms/chrp/setup.c | 4 +-
arch/powerpc/platforms/powernv/opal.c | 12 +-
arch/powerpc/platforms/pseries/setup.c | 4 +-
arch/x86/kernel/devicetree.c | 7 +-
arch/xtensa/kernel/setup.c | 3 +-
drivers/of/Kconfig | 1 +
drivers/of/fdt.c | 379 +++++++++-------------------
drivers/of/of_reserved_mem.c | 4 +-
include/linux/of_fdt.h | 64 +----
lib/Makefile | 2 -
42 files changed, 261 insertions(+), 596 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 09/20] of/fdt: create common debugfs
From: Rob Herring @ 2014-04-03 22:16 UTC (permalink / raw)
To: linux-kernel
Cc: Rob Herring, Michal Simek, Paul Mackerras, Grant Likely,
linuxppc-dev
In-Reply-To: <1396563423-30893-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat-device-tree" to
"device-tree/flat-device-tree".
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/microblaze/kernel/prom.c | 31 -------------------------------
arch/powerpc/kernel/prom.c | 21 ---------------------
drivers/of/fdt.c | 24 ++++++++++++++++++++++++
3 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index abdfb10..1312cd2 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -114,34 +114,3 @@ void __init early_init_devtree(void *params)
pr_debug(" <- early_init_devtree()\n");
}
-
-/*******
- *
- * New implementation of the OF "find" APIs, return a refcounted
- * object, call of_node_put() when done. The device tree and list
- * are protected by a rw_lock.
- *
- * Note that property management will need some locking as well,
- * this isn't dealt with yet.
- *
- *******/
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = initial_boot_params->totalsize;
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- of_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-device_initcall(export_flat_device_tree);
-#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index dd72beb..7c2f90c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -29,7 +29,6 @@
#include <linux/bitops.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/memblock.h>
#include <linux/of.h>
@@ -918,23 +917,3 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
{
return (int)phys_id == get_hard_smp_processor_id(cpu);
}
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- powerpc_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-__initcall(export_flat_device_tree);
-#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index fa16a91..2085d47 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -20,6 +20,7 @@
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/slab.h>
+#include <linux/debugfs.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -1084,4 +1085,27 @@ void __init unflatten_and_copy_device_tree(void)
unflatten_device_tree();
}
+#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
+static struct debugfs_blob_wrapper flat_dt_blob;
+
+static int __init of_flat_dt_debugfs_export_fdt(void)
+{
+ struct dentry *d = debugfs_create_dir("device-tree", NULL);
+
+ if (!d)
+ return -ENOENT;
+
+ flat_dt_blob.data = initial_boot_params;
+ flat_dt_blob.size = fdt_totalsize(initial_boot_params);
+
+ d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
+ d, &flat_dt_blob);
+ if (!d)
+ return -ENOENT;
+
+ return 0;
+}
+module_init(of_flat_dt_debugfs_export_fdt);
+#endif
+
#endif /* CONFIG_OF_EARLY_FLATTREE */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 20/20] of: push struct boot_param_header and defines into powerpc
From: Rob Herring @ 2014-04-03 22:17 UTC (permalink / raw)
To: linux-kernel; +Cc: Grant Likely, Rob Herring, Paul Mackerras, linuxppc-dev
In-Reply-To: <1396563423-30893-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/prom.h | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/of_fdt.h | 37 -------------------------------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index d977b9b..74b79f0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -26,6 +26,45 @@
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+ * content */
+#define OF_DT_NOP 0x4 /* nop */
+#define OF_DT_END 0x9
+
+#define OF_DT_VERSION 0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+ __be32 magic; /* magic word OF_DT_HEADER */
+ __be32 totalsize; /* total size of DT block */
+ __be32 off_dt_struct; /* offset to structure */
+ __be32 off_dt_strings; /* offset to strings */
+ __be32 off_mem_rsvmap; /* offset to memory reserve map */
+ __be32 version; /* format version */
+ __be32 last_comp_version; /* last compatible version */
+ /* version 2 fields below */
+ __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ __be32 dt_strings_size; /* size of the DT strings block */
+ /* version 17 fields below */
+ __be32 dt_struct_size; /* size of the DT structure block */
+};
+
/*
* OF address retreival & translation
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index aa7fb87..7f67790 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -17,47 +17,10 @@
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
-#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size,
- * content */
-#define OF_DT_NOP 0x4 /* nop */
-#define OF_DT_END 0x9
-
-#define OF_DT_VERSION 0x10
#ifndef __ASSEMBLY__
#include <linux/libfdt.h>
-/*
- * This is what gets passed to the kernel by prom_init or kexec
- *
- * The dt struct contains the device tree structure, full pathes and
- * property contents. The dt strings contain a separate block with just
- * the strings for the property names, and is fully page aligned and
- * self contained in a page, so that it can be kept around by the kernel,
- * each property name appears only once in this page (cheap compression)
- *
- * the mem_rsvmap contains a map of reserved ranges of physical memory,
- * passing it here instead of in the device-tree itself greatly simplifies
- * the job of everybody. It's just a list of u64 pairs (base/size) that
- * ends when size is 0
- */
-struct boot_param_header {
- __be32 magic; /* magic word OF_DT_HEADER */
- __be32 totalsize; /* total size of DT block */
- __be32 off_dt_struct; /* offset to structure */
- __be32 off_dt_strings; /* offset to strings */
- __be32 off_mem_rsvmap; /* offset to memory reserve map */
- __be32 version; /* format version */
- __be32 last_comp_version; /* last compatible version */
- /* version 2 fields below */
- __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
- /* version 3 fields below */
- __be32 dt_strings_size; /* size of the DT strings block */
- /* version 17 fields below */
- __be32 dt_struct_size; /* size of the DT structure block */
-};
#if defined(CONFIG_OF_FLATTREE)
--
1.8.3.2
^ permalink raw reply related
* Re: [RFC PATCH] hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Nishanth Aravamudan @ 2014-04-03 23:12 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linux-mm, paulus, linuxppc-dev, nyc, anton
In-Reply-To: <87ioqqo065.fsf@linux.vnet.ibm.com>
On 03.04.2014 [21:49:46 +0530], Aneesh Kumar K.V wrote:
> Nishanth Aravamudan <nacc@linux.vnet.ibm.com> writes:
>
> > On 24.03.2014 [16:02:56 -0700], Nishanth Aravamudan wrote:
> >> In KVM guests on Power, if the guest is not backed by hugepages, we see
> >> the following in the guest:
> >>
> >> AnonHugePages: 0 kB
> >> HugePages_Total: 0
> >> HugePages_Free: 0
> >> HugePages_Rsvd: 0
> >> HugePages_Surp: 0
> >> Hugepagesize: 64 kB
> >>
> >> This seems like a configuration issue -- why is a hstate of 64k being
> >> registered?
> >>
> >> I did some debugging and found that the following does trigger,
> >> mm/hugetlb.c::hugetlb_init():
> >>
> >> /* Some platform decide whether they support huge pages at boot
> >> * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> >> * there is no such support
> >> */
> >> if (HPAGE_SHIFT == 0)
> >> return 0;
> >>
> >> That check is only during init-time. So we don't support hugepages, but
> >> none of the hugetlb APIs actually check this condition (HPAGE_SHIFT ==
> >> 0), so /proc/meminfo above falsely indicates there is a valid hstate (at
> >> least one). But note that there is no /sys/kernel/mm/hugepages meaning
> >> no hstate was actually registered.
> >>
> >> Further, it turns out that huge_page_order(default_hstate) is 0, so
> >> hugetlb_report_meminfo is doing:
> >>
> >> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10)
> >>
> >> which ends up just doing 1 << (PAGE_SHIFT - 10) and since the base page
> >> size is 64k, we report a hugepage size of 64k... And allow the user to
> >> allocate hugepages via the sysctl, etc.
> >>
> >> What's the right thing to do here?
> >>
> >> 1) Should we add checks for HPAGE_SHIFT == 0 to all the hugetlb APIs? It
> >> seems like HPAGE_SHIFT == 0 should be the equivalent, functionally, of
> >> the config options being off. This seems like a lot of overhead, though,
> >> to put everywhere, so maybe I can do it in an arch-specific macro, that
> >> in asm-generic defaults to 0 (and so will hopefully be compiled out?).
> >>
> >> 2) What should hugetlbfs do when HPAGE_SHIFT == 0? Should it be
> >> mountable? Obviously if it's mountable, we can't great files there
> >> (since the fs will report insufficient space). [1]
> >
> > Here is my solution to this. Comments appreciated!
> >
> > In KVM guests on Power, in a guest not backed by hugepages, we see the
> > following:
> >
> > AnonHugePages: 0 kB
> > HugePages_Total: 0
> > HugePages_Free: 0
> > HugePages_Rsvd: 0
> > HugePages_Surp: 0
> > Hugepagesize: 64 kB
> >
> > HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
> > are not supported at boot-time, but this is only checked in
> > hugetlb_init(). Extract the check to a helper function, and use it in a
> > few relevant places.
> >
> > This does make hugetlbfs not supported in this environment. I believe
> > this is fine, as there are no valid hugepages and that won't change at
> > runtime.
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
>
>
> Looks good. Can you resubmit it as a proper patch ?
Will Cc you on that.
> You may also want to capture in commit message saying hugetlbfs file
> system also will not be registered.
I did that already:
> > This does make hugetlbfs not supported in this environment. I
> > believe this is fine, as there are no valid hugepages and that won't
> > change at runtime.
Thanks,
Nish
^ permalink raw reply
* hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Nishanth Aravamudan @ 2014-04-03 23:14 UTC (permalink / raw)
To: linux-mm; +Cc: paulus, anton, nyc, akpm, linuxppc-dev, aneesh.kumar
In KVM guests on Power, in a guest not backed by hugepages, we see the
following:
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 64 kB
HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
are not supported at boot-time, but this is only checked in
hugetlb_init(). Extract the check to a helper function, and use it in a
few relevant places.
This does make hugetlbfs not supported (not registered at all) in this
environment. I believe this is fine, as there are no valid hugepages and
that won't change at runtime.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index d19b30a..cc8fcc7 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
int error;
int i;
+ if (!hugepages_supported()) {
+ printk(KERN_ERR "hugetlbfs: Disabling because there are no supported hugepage sizes\n");
+ return -ENOTSUPP;
+ }
+
error = bdi_init(&hugetlbfs_backing_dev_info);
if (error)
return error;
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..0aea8de 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -450,4 +450,14 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
return ptl;
}
+static inline bool hugepages_supported(void)
+{
+ /*
+ * Some platform decide whether they support huge pages at boot
+ * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
+ * there is no such support
+ */
+ return HPAGE_SHIFT != 0;
+}
+
#endif /* _LINUX_HUGETLB_H */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c01cb9f..1c99585 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1949,11 +1949,7 @@ module_exit(hugetlb_exit);
static int __init hugetlb_init(void)
{
- /* Some platform decide whether they support huge pages at boot
- * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
- * there is no such support
- */
- if (HPAGE_SHIFT == 0)
+ if (!hugepages_supported())
return 0;
if (!size_to_hstate(default_hstate_size)) {
@@ -2069,6 +2065,9 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
unsigned long tmp;
int ret;
+ if (!hugepages_supported())
+ return -ENOTSUPP;
+
tmp = h->max_huge_pages;
if (write && h->order >= MAX_ORDER)
@@ -2122,6 +2121,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
unsigned long tmp;
int ret;
+ if (!hugepages_supported())
+ return -ENOTSUPP;
+
tmp = h->nr_overcommit_huge_pages;
if (write && h->order >= MAX_ORDER)
@@ -2147,6 +2149,8 @@ out:
void hugetlb_report_meminfo(struct seq_file *m)
{
struct hstate *h = &default_hstate;
+ if (!hugepages_supported())
+ return;
seq_printf(m,
"HugePages_Total: %5lu\n"
"HugePages_Free: %5lu\n"
@@ -2163,6 +2167,8 @@ void hugetlb_report_meminfo(struct seq_file *m)
int hugetlb_report_node_meminfo(int nid, char *buf)
{
struct hstate *h = &default_hstate;
+ if (!hugepages_supported())
+ return 0;
return sprintf(buf,
"Node %d HugePages_Total: %5u\n"
"Node %d HugePages_Free: %5u\n"
@@ -2177,6 +2183,9 @@ void hugetlb_show_meminfo(void)
struct hstate *h;
int nid;
+ if (!hugepages_supported())
+ return;
+
for_each_node_state(nid, N_MEMORY)
for_each_hstate(h)
pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",
^ permalink raw reply related
* Re: hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Aneesh Kumar K.V @ 2014-04-04 0:42 UTC (permalink / raw)
To: Nishanth Aravamudan, linux-mm; +Cc: paulus, anton, nyc, akpm, linuxppc-dev
In-Reply-To: <20140403231413.GB17412@linux.vnet.ibm.com>
Nishanth Aravamudan <nacc@linux.vnet.ibm.com> writes:
> In KVM guests on Power, in a guest not backed by hugepages, we see the
> following:
>
> AnonHugePages: 0 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 64 kB
>
> HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
> are not supported at boot-time, but this is only checked in
> hugetlb_init(). Extract the check to a helper function, and use it in a
> few relevant places.
>
> This does make hugetlbfs not supported (not registered at all) in this
> environment. I believe this is fine, as there are no valid hugepages and
> that won't change at runtime.
>
> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index d19b30a..cc8fcc7 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
> int error;
> int i;
>
> + if (!hugepages_supported()) {
> + printk(KERN_ERR "hugetlbfs: Disabling because there are no supported hugepage sizes\n");
> + return -ENOTSUPP;
> + }
> +
> error = bdi_init(&hugetlbfs_backing_dev_info);
> if (error)
> return error;
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 8c43cc4..0aea8de 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -450,4 +450,14 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
> return ptl;
> }
>
> +static inline bool hugepages_supported(void)
> +{
> + /*
> + * Some platform decide whether they support huge pages at boot
> + * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> + * there is no such support
> + */
> + return HPAGE_SHIFT != 0;
> +}
> +
> #endif /* _LINUX_HUGETLB_H */
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c01cb9f..1c99585 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1949,11 +1949,7 @@ module_exit(hugetlb_exit);
>
> static int __init hugetlb_init(void)
> {
> - /* Some platform decide whether they support huge pages at boot
> - * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> - * there is no such support
> - */
> - if (HPAGE_SHIFT == 0)
> + if (!hugepages_supported())
> return 0;
>
> if (!size_to_hstate(default_hstate_size)) {
> @@ -2069,6 +2065,9 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->max_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2122,6 +2121,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->nr_overcommit_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2147,6 +2149,8 @@ out:
> void hugetlb_report_meminfo(struct seq_file *m)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return;
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> @@ -2163,6 +2167,8 @@ void hugetlb_report_meminfo(struct seq_file *m)
> int hugetlb_report_node_meminfo(int nid, char *buf)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return 0;
> return sprintf(buf,
> "Node %d HugePages_Total: %5u\n"
> "Node %d HugePages_Free: %5u\n"
> @@ -2177,6 +2183,9 @@ void hugetlb_show_meminfo(void)
> struct hstate *h;
> int nid;
>
> + if (!hugepages_supported())
> + return;
> +
> for_each_node_state(nid, N_MEMORY)
> for_each_hstate(h)
> pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",
^ permalink raw reply
* [PATCH v2 1/8] DMA: Freescale: remove the unnecessary FSL_DMA_LD_DEBUG
From: hongbo.zhang @ 2014-04-04 3:27 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel
In-Reply-To: <1396582037-23065-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Some codes are calling chan_dbg with FSL_DMA_LD_DEBUG surrounded, it is really
unnecessary to use such a macro because chan_dbg is a wrapper of dev_dbg, we do
have corresponding DEBUG macro to switch on/off dev_dbg, and most of the other
codes are also calling chan_dbg directly without using FSL_DMA_LD_DEBUG.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/fsldma.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index f157c6f..ec50420 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -426,9 +426,7 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
desc->async_tx.tx_submit = fsl_dma_tx_submit;
desc->async_tx.phys = pdesc;
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p allocated\n", desc);
-#endif
return desc;
}
@@ -479,9 +477,7 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
list_for_each_entry_safe(desc, _desc, list, node) {
list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
}
}
@@ -493,9 +489,7 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
list_for_each_entry_safe_reverse(desc, _desc, list, node) {
list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
}
}
@@ -832,9 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
/* Run the link descriptor callback function */
if (txd->callback) {
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p callback\n", desc);
-#endif
txd->callback(txd->callback_param);
}
@@ -842,9 +834,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
dma_run_dependencies(txd);
dma_descriptor_unmap(txd);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, txd->phys);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/8] DMA: Freescale: unify register access methods
From: hongbo.zhang @ 2014-04-04 3:27 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel
In-Reply-To: <1396582037-23065-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Methods of accessing DMA contorller registers are inconsistent, some registers
are accessed by DMA_IN/OUT directly, while others are accessed by functions
get/set_* which are wrappers of DMA_IN/OUT, and even for the BCR register, it
is read by get_bcr but written by DMA_OUT.
This patch unifies the inconsistent methods, all registers are accessed by
get/set_* now.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/fsldma.c | 52 ++++++++++++++++++++++++++++++++------------------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index ec50420..5f32cb8 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -61,6 +61,16 @@ static u32 get_sr(struct fsldma_chan *chan)
return DMA_IN(chan, &chan->regs->sr, 32);
}
+static void set_mr(struct fsldma_chan *chan, u32 val)
+{
+ DMA_OUT(chan, &chan->regs->mr, val, 32);
+}
+
+static u32 get_mr(struct fsldma_chan *chan)
+{
+ return DMA_IN(chan, &chan->regs->mr, 32);
+}
+
static void set_cdar(struct fsldma_chan *chan, dma_addr_t addr)
{
DMA_OUT(chan, &chan->regs->cdar, addr | FSL_DMA_SNEN, 64);
@@ -71,6 +81,11 @@ static dma_addr_t get_cdar(struct fsldma_chan *chan)
return DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
}
+static void set_bcr(struct fsldma_chan *chan, u32 val)
+{
+ DMA_OUT(chan, &chan->regs->bcr, val, 32);
+}
+
static u32 get_bcr(struct fsldma_chan *chan)
{
return DMA_IN(chan, &chan->regs->bcr, 32);
@@ -135,7 +150,7 @@ static void set_ld_eol(struct fsldma_chan *chan, struct fsl_desc_sw *desc)
static void dma_init(struct fsldma_chan *chan)
{
/* Reset the channel */
- DMA_OUT(chan, &chan->regs->mr, 0, 32);
+ set_mr(chan, 0);
switch (chan->feature & FSL_DMA_IP_MASK) {
case FSL_DMA_IP_85XX:
@@ -144,16 +159,15 @@ static void dma_init(struct fsldma_chan *chan)
* EOLNIE - End of links interrupt enable
* BWC - Bandwidth sharing among channels
*/
- DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_BWC
- | FSL_DMA_MR_EIE | FSL_DMA_MR_EOLNIE, 32);
+ set_mr(chan, FSL_DMA_MR_BWC | FSL_DMA_MR_EIE
+ | FSL_DMA_MR_EOLNIE);
break;
case FSL_DMA_IP_83XX:
/* Set the channel to below modes:
* EOTIE - End-of-transfer interrupt enable
* PRC_RM - PCI read multiple
*/
- DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_EOTIE
- | FSL_DMA_MR_PRC_RM, 32);
+ set_mr(chan, FSL_DMA_MR_EOTIE | FSL_DMA_MR_PRC_RM);
break;
}
}
@@ -175,10 +189,10 @@ static void dma_start(struct fsldma_chan *chan)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
if (chan->feature & FSL_DMA_CHAN_PAUSE_EXT) {
- DMA_OUT(chan, &chan->regs->bcr, 0, 32);
+ set_bcr(chan, 0);
mode |= FSL_DMA_MR_EMP_EN;
} else {
mode &= ~FSL_DMA_MR_EMP_EN;
@@ -191,7 +205,7 @@ static void dma_start(struct fsldma_chan *chan)
mode |= FSL_DMA_MR_CS;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
static void dma_halt(struct fsldma_chan *chan)
@@ -200,7 +214,7 @@ static void dma_halt(struct fsldma_chan *chan)
int i;
/* read the mode register */
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
/*
* The 85xx controller supports channel abort, which will stop
@@ -209,14 +223,14 @@ static void dma_halt(struct fsldma_chan *chan)
*/
if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
mode |= FSL_DMA_MR_CA;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
mode &= ~FSL_DMA_MR_CA;
}
/* stop the DMA controller */
mode &= ~(FSL_DMA_MR_CS | FSL_DMA_MR_EMS_EN);
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
/* wait for the DMA controller to become idle */
for (i = 0; i < 100; i++) {
@@ -245,7 +259,7 @@ static void fsl_chan_set_src_loop_size(struct fsldma_chan *chan, int size)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
switch (size) {
case 0:
@@ -259,7 +273,7 @@ static void fsl_chan_set_src_loop_size(struct fsldma_chan *chan, int size)
break;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -277,7 +291,7 @@ static void fsl_chan_set_dst_loop_size(struct fsldma_chan *chan, int size)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
switch (size) {
case 0:
@@ -291,7 +305,7 @@ static void fsl_chan_set_dst_loop_size(struct fsldma_chan *chan, int size)
break;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -312,10 +326,10 @@ static void fsl_chan_set_request_count(struct fsldma_chan *chan, int size)
BUG_ON(size > 1024);
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
mode |= (__ilog2(size) << 24) & 0x0f000000;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -889,9 +903,9 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
mode &= ~FSL_DMA_MR_CS;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/8] DMA: Freescale: driver cleanups and enhancements
From: hongbo.zhang @ 2014-04-04 3:27 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Hi Vinod Koul,
Please have a look at the v2 patch set.
v1 -> v2 change:
The only one change is introducing a new patch[1/7] to remove the unnecessary
macro FSL_DMA_LD_DEBUG, thus the total patches number is 8 now (was 7)
Hongbo Zhang (8):
DMA: Freescale: remove the unnecessary FSL_DMA_LD_DEBUG
DMA: Freescale: unify register access methods
DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
DMA: Freescale: add fsl_dma_free_descriptor() to reduce code
duplication
DMA: Freescale: move functions to avoid forward declarations
DMA: Freescale: change descriptor release process for supporting
async_tx
DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
DMA: Freescale: add suspend resume functions for DMA driver
drivers/dma/fsldma.c | 590 ++++++++++++++++++++++++++++++++------------------
drivers/dma/fsldma.h | 33 ++-
2 files changed, 408 insertions(+), 215 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 3/8] DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
From: hongbo.zhang @ 2014-04-04 3:27 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel
In-Reply-To: <1396582037-23065-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Delete attribute DMA_INTERRUPT because fsldma doesn't support this function,
exception will be thrown if talitos is used to offload xor at the same time.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/dma/fsldma.c | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 5f32cb8..b71cc04 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -528,35 +528,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
}
static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
-{
- struct fsldma_chan *chan;
- struct fsl_desc_sw *new;
-
- if (!dchan)
- return NULL;
-
- chan = to_fsl_chan(dchan);
-
- new = fsl_dma_alloc_descriptor(chan);
- if (!new) {
- chan_err(chan, "%s\n", msg_ld_oom);
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list */
- set_ld_eol(chan, new);
-
- return &new->async_tx;
-}
-
-static struct dma_async_tx_descriptor *
fsl_dma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1308,12 +1279,10 @@ static int fsldma_of_probe(struct platform_device *op)
fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SG, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
fdev->common.device_tx_status = fsl_tx_status;
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox