Re: powerc: fix build failure when CONFIG_HUGETLB_PAGE is not set
Hello Michael, On 10/28/2014 05:31 AM, Michael Ellerman wrote: On Mon, 2014-27-10 at 14:30:06 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote: CC arch/powerpc/mm/slice.o In file included from ../arch/powerpc/mm/slice.c:33:0: ../include/linux/hugetlb.h:141:47: error: expected identifier or ‘(’ before numeric constant #define is_hugepage_only_range(mm, addr, len) 0 ^ ../arch/powerpc/mm/slice.c:704:5: note: in expansion of macro ‘is_hugepage_only_range’ int is_hugepage_only_range(struct mm_struct *mm, unsigned long addr, ^ Hi Cedric, I'm pretty sure this is fixed in my fixes branch: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=fixes Indeed. I just picked -rc2 without checking your branch. I will next time. Thanks, C. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] CXL: Refactor cxl_load_segment and find_free_sste
Ian Munsie imun...@au1.ibm.com writes:
From: Ian Munsie imun...@au1.ibm.com
This moves the segment table hash calculation from cxl_load_segment into
find_free_sste since that is the only place it is actually used.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
drivers/misc/cxl/fault.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/misc/cxl/fault.c b/drivers/misc/cxl/fault.c
index d0e97fd..cb4f323 100644
--- a/drivers/misc/cxl/fault.c
+++ b/drivers/misc/cxl/fault.c
@@ -21,20 +21,30 @@
#include cxl.h
-static struct cxl_sste* find_free_sste(struct cxl_sste *primary_group,
-unsigned int *lru)
+/* This finds a free SSTE for the given SLB */
+static struct cxl_sste* find_free_sste(struct cxl_context *ctx,
+struct copro_slb *slb)
{
+ struct cxl_sste *primary, *sste;
+ unsigned int mask = (ctx-sst_size 7) - 1; /* SSTP0[SegTableSize] */
unsigned int entry;
- struct cxl_sste *sste, *group = primary_group;
+ unsigned int hash;
+
+ if (slb-vsid SLB_VSID_B_1T)
+ hash = (slb-esid SID_SHIFT_1T) mask;
+ else /* 256M */
+ hash = (slb-esid SID_SHIFT) mask;
- for (entry = 0; entry 8; entry++) {
- sste = group + entry;
+ primary = ctx-sstp + (hash 3);
+
+ for (entry = 0, sste = primary; entry 8; entry++, sste++) {
if (!(be64_to_cpu(sste-esid_data) SLB_ESID_V))
return sste;
}
+
/* Nothing free, select an entry to cast out */
- sste = primary_group + *lru;
- *lru = (*lru + 1) 0x7;
+ sste = primary + ctx-sst_lru;
+ ctx-sst_lru = (ctx-sst_lru + 1) 0x7;
return sste;
}
@@ -42,19 +52,11 @@ static struct cxl_sste* find_free_sste(struct cxl_sste
*primary_group,
static void cxl_load_segment(struct cxl_context *ctx, struct copro_slb *slb)
{
/* mask is the group index, we search primary and secondary here. */
- unsigned int mask = (ctx-sst_size 7)-1; /* SSTP0[SegTableSize] */
struct cxl_sste *sste;
- unsigned int hash;
unsigned long flags;
-
- if (slb-vsid SLB_VSID_B_1T)
- hash = (slb-esid SID_SHIFT_1T) mask;
- else /* 256M */
- hash = (slb-esid SID_SHIFT) mask;
-
spin_lock_irqsave(ctx-sste_lock, flags);
- sste = find_free_sste(ctx-sstp + (hash 3), ctx-sst_lru);
+ sste = find_free_sste(ctx, slb);
pr_devel(CXL Populating SST[%li]: %#llx %#llx\n,
sste - ctx-sstp, slb-vsid, slb-esid);
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] powerpc/copro: Use appropriate ESID mask in copro_calculate_slb
Ian Munsie imun...@au1.ibm.com writes:
From: Ian Munsie imun...@au1.ibm.com
This patch makes copro_calculate_slb mask the ESID by the correct mask
for 1T vs 256M segments.
This has no effect by itself as the extra bits were ignored, but it
makes debugging the segment table entries easier and means that we can
directly compare the ESID values for duplicates without needing to worry
about masking in the comparison.
This will be used to simplify a comparison in the following patch.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/mm/copro_fault.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index 0f9939e..5a236f0 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -99,8 +99,6 @@ int copro_calculate_slb(struct mm_struct *mm, u64 ea,
struct copro_slb *slb)
u64 vsid;
int psize, ssize;
- slb-esid = (ea ESID_MASK) | SLB_ESID_V;
-
switch (REGION_ID(ea)) {
case USER_REGION_ID:
pr_devel(%s: 0x%llx -- USER_REGION_ID\n, __func__, ea);
@@ -133,6 +131,7 @@ int copro_calculate_slb(struct mm_struct *mm, u64 ea,
struct copro_slb *slb)
vsid |= mmu_psize_defs[psize].sllp |
((ssize == MMU_SEGSIZE_1T) ? SLB_VSID_B_1T : 0);
+ slb-esid = (ea (ssize == MMU_SEGSIZE_1T ? ESID_MASK_1T : ESID_MASK))
| SLB_ESID_V;
slb-vsid = vsid;
return 0;
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] CXL: Fix PSL error due to duplicate segment table entries
Ian Munsie imun...@au1.ibm.com writes:
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a
segment miss that the kernel has already handled. This can happen if
multiple translations for the same segment are queued in the PSL before
the kernel has restarted the first translation.
The CXL driver does not expect this situation and does not check if a
segment had already been handled. This could cause a duplicate segment
table entry which in turn caused a PSL error taking down the card.
This patch fixes the issue by checking for existing entries in the
segment table that match the segment it is trying to insert to avoid
inserting duplicate entries.
This patch requires powerpc/copro: Use appropriate ESID mask in
copro_calculate_slb for the sste_matches function to operate correctly.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
drivers/misc/cxl/fault.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/cxl/fault.c b/drivers/misc/cxl/fault.c
index cb4f323..c99e896 100644
--- a/drivers/misc/cxl/fault.c
+++ b/drivers/misc/cxl/fault.c
@@ -21,11 +21,20 @@
#include cxl.h
-/* This finds a free SSTE for the given SLB */
+static bool sste_matches(struct cxl_sste *sste, struct copro_slb
*slb)
inline ?
+{
+ return ((sste-vsid_data == cpu_to_be64(slb-vsid))
+ (sste-esid_data == cpu_to_be64(slb-esid)));
why comparing converting to big endian ? The natural way is to do it
other way right ?.
(be64_to_cpu(sste-vsid_data) == slb-vsid)
+}
+
+/*
+ * This finds a free SSTE for the given SLB, or returns NULL if it's already
in
+ * the segment table.
+ */
static struct cxl_sste* find_free_sste(struct cxl_context *ctx,
struct copro_slb *slb)
{
- struct cxl_sste *primary, *sste;
+ struct cxl_sste *primary, *sste, *ret = NULL;
unsigned int mask = (ctx-sst_size 7) - 1; /* SSTP0[SegTableSize] */
unsigned int entry;
unsigned int hash;
@@ -38,15 +47,19 @@ static struct cxl_sste* find_free_sste(struct cxl_context
*ctx,
primary = ctx-sstp + (hash 3);
for (entry = 0, sste = primary; entry 8; entry++, sste++) {
- if (!(be64_to_cpu(sste-esid_data) SLB_ESID_V))
- return sste;
+ if (!ret !(be64_to_cpu(sste-esid_data) SLB_ESID_V))
+ ret = sste;
+ if (sste_matches(sste, slb))
+ return NULL;
}
+ if (ret)
+ return ret;
/* Nothing free, select an entry to cast out */
- sste = primary + ctx-sst_lru;
+ ret = primary + ctx-sst_lru;
ctx-sst_lru = (ctx-sst_lru + 1) 0x7;
- return sste;
+ return ret;
}
static void cxl_load_segment(struct cxl_context *ctx, struct copro_slb *slb)
@@ -57,12 +70,15 @@ static void cxl_load_segment(struct cxl_context *ctx,
struct copro_slb *slb)
spin_lock_irqsave(ctx-sste_lock, flags);
sste = find_free_sste(ctx, slb);
+ if (!sste)
+ goto out_unlock;
pr_devel(CXL Populating SST[%li]: %#llx %#llx\n,
sste - ctx-sstp, slb-vsid, slb-esid);
sste-vsid_data = cpu_to_be64(slb-vsid);
sste-esid_data = cpu_to_be64(slb-esid);
+out_unlock:
spin_unlock_irqrestore(ctx-sste_lock, flags);
}
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791
On 10/15/2014 07:28 PM, Aneesh Kumar K.V wrote:
=
[ INFO: possible recursive locking detected ]
3.17.0+ #31 Not tainted
-
qemu-system-ppc/9112 is trying to acquire lock:
((vcpu-arch.tbacct_lock)-rlock){..}, at: [d00011591f84]
.vcore_stolen_time+0x44/0xb0 [kvm_hv]
but task is already holding lock:
((vcpu-arch.tbacct_lock)-rlock){..}, at: [d00011592524]
.kvmppc_remove_runnable.part.2+0x34/0xd0 [kvm_hv]
This must come from here:
while (vcpu-arch.state == KVMPPC_VCPU_RUNNABLE
(vc-vcore_state == VCORE_RUNNING ||
vc-vcore_state == VCORE_EXITING)) {
spin_unlock(vc-lock);
kvmppc_wait_for_exec(vcpu, TASK_UNINTERRUPTIBLE);
spin_lock(vc-lock);
}
if (vcpu-arch.state == KVMPPC_VCPU_RUNNABLE) {
kvmppc_remove_runnable(vc, vcpu);
vcpu-stat.signal_exits++;
kvm_run-exit_reason = KVM_EXIT_INTR;
vcpu-arch.ret = -EINTR;
}
if vc-vcore_state is VCORE_SLEEPING (I think it cannot be VCORE_STARTING)?
Paolo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/4] dt/bindings: Introduce the FSL B/QMan
v2: Incorporate feedback from Mark Rutland - Remove subject to change notes - Add/document the 'interrupts' properties - Make multiple windows 'reg' properties more readable - Improve portal description Emil Medve (4): dt/bindings: Introduce the FSL QorIQ DPAA BMan dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s) dt/bindings: Introduce the FSL QorIQ DPAA QMan dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s) .../bindings/powerpc/fsl/bman-portals.txt | 52 +++ .../devicetree/bindings/powerpc/fsl/bman.txt | 95 + .../bindings/powerpc/fsl/qman-portals.txt | 151 + .../devicetree/bindings/powerpc/fsl/qman.txt | 133 ++ 4 files changed, 431 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt -- 2.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 95 ++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
new file mode 100644
index 000..d3fd1e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
@@ -0,0 +1,95 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Node
+ - BMan Private Memory Node
+ - Example
+
+BMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,bman
+ May include fsl,SoC-bman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property. The error interrupt
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing store
+for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a node
+under the /reserved-memory node
+
+The BMan FBPR memory node must be named bman-fbpr
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: Must inclide fsl,bman-fbpr
+
+The following constraints are relevant to the FBPR private memory:
+ - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
+ 16 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FBPR must be chosen by observing the hardware features
configured
+via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
+pinned-out, number of offline/host command FMan ports, etc.). The size
configured
+in the DT must reflect the hardware capabilities and not the specific needs of
an
+application
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a BMan FBPR dynamic allocation memory node
+
+ reserved-memory {
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+
+ bman-fbpr {
+ compatible = fsl,bman-fbpr;
+ alloc-ranges = 0 0 0xf 0x;
+ size = 0 0x100;
+ alignment = 0 0x100;
+ };
+ };
+
+The example below shows a (P4080) BMan CCSR-space node
+
+ bman@31a000 {
+ compatible = fsl,bman;
+ reg = 0x31a000 0x1000;
+ interrupts = 16 2 1 2;
+ fsl,liodn = 0x17;
+ };
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
Portals are memory mapped interfaces to BMan that allow low-latency,
lock-less interaction by software running on processor cores, accelerators
and network interfaces with the BMan
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
---
.../bindings/powerpc/fsl/bman-portals.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
new file mode 100644
index 000..02e0231
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
@@ -0,0 +1,52 @@
+QorIQ DPAA Buffer Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Portal
+ - Example
+
+BMan Portal Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,bman-portal-hardware revision
+ May include fsl,SoC-bman-portal or fsl,bman-portal
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Two regions. The first is the cache-enabled region of
+ the portal. The second is the cache-inhibited region of
+ the portal
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ bman-portals@ff400 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges = 0 0xf 0xf400 0x20;
+
+ bman-portal@0 {
+ compatible = fsl,bman-portal-1.0.0, fsl,bman-portal;
+ reg = 0x0 0x4000, 0x10 0x1000;
+ interrupts = 105 2 0 0;
+ };
+ bman-portal@4000 {
+ compatible = fsl,bman-portal-1.0.0, fsl,bman-portal;
+ reg = 0x4000 0x4000, 0x101000 0x1000;
+ interrupts = 107 2 0 0;
+ };
+ };
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan
The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA).
QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces
and DPAA logic modules, maintains packet ordering within flows. Besides
providing flow-level queuing, is also responsible for congestion management
functions such as RED/WRED, congestion notifications and tail discards. This
binding covers the CCSR space programming model
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I3acb223893e42003d6c9dc061db568ec0b10d29b
---
.../devicetree/bindings/powerpc/fsl/qman.txt | 133 +
1 file changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
new file mode 100644
index 000..a21e097
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
@@ -0,0 +1,133 @@
+QorIQ DPAA Queue Manager Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - QMan Node
+ - QMan Private Memory Nodes
+ - Example
+
+QMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,qman
+ May include fsl,SoC-qman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property. The error interrupt
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- clocks
+ Usage: See clock-bindings.txt and qoriq-clock.txt
+ Value type: prop-encoded-array
+ Definition: Reference input clock. Its frequency is half of the
+ platform clock
+
+QMan Private Memory Nodes
+
+QMan requires two contiguous range of physical memory used for the backing
store
+for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. This memory
+is reserved/allocated as a nodes under the /reserved-memory node
+
+The QMan FQD memory node must be named qman-fqd
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: Must inclide fsl,qman-fqd
+
+The QMan PFDR memory node must be named qman-pfdr
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: Must inclide fsl,qman-pfdr
+
+The following constraints are relevant to the FQD and PFDR private memory:
+ - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
+ 1 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FQD and PFDP must be chosen by observing the hardware features
+configured via the RCW and that are relevant to a specific board (e.g. number
of
+MAC(s) pinned-out, number of offline/host command FMan ports, etc.). The size
+configured in the DT must reflect the hardware capabilities and not the
specific
+needs of an application
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes
+
+ reserved-memory {
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+
+ qman-fqd {
+ compatible = fsl,qman-fqd;
+ alloc-ranges = 0 0 0xf 0x;
+ size = 0 0x40;
+ alignment = 0 0x40;
+ };
+ qman-pfdr {
+ compatible = fsl,qman-pfdr;
+ alloc-ranges = 0 0 0xf 0x;
+ size = 0 0x200;
+ alignment = 0 0x200;
+ };
+ };
+
+The example below shows a (P4080) QMan CCSR-space node
+
+ clockgen: global-utilities@e1000 {
+ ...
+ sysclk: sysclk {
+ ...
+ };
+ ...
+ platform_pll: platform-pll@c00 {
+ #clock-cells = 1;
+ reg = 0xc00 0x4;
+ compatible = fsl,qoriq-platform-pll-1.0;
+ clocks = sysclk;
+ clock-output-names = platform-pll,
platform-pll-div2;
+ };
+ ...
+ };
+
+
[PATCH v2 4/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)
Portals are memory mapped interfaces to QMan that allow low-latency,
lock-less interaction by software running on processor cores,
accelerators and network interfaces with the QMan
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I29764fa8093b5ce65460abc879446795c50d7185
---
.../bindings/powerpc/fsl/qman-portals.txt | 151 +
1 file changed, 151 insertions(+)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
new file mode 100644
index 000..86b06d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
@@ -0,0 +1,151 @@
+QorIQ DPAA Queue Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - QMan Portal
+ - QMan Pool Channel
+ - Example
+
+QMan Portal Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,qman-portal-hardware revision
+ May include fsl,SoC-qman-portal or fsl,qman-portal
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Two regions. The first is the cache-enabled region of
+ the portal. The second is the cache-inhibited region of
+ the portal
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment. This is
+ an optional property. It is a valid configuration for
+ this phandle to be dangling
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- fsl,qman-channel-id
+ Usage: Required
+ Value type: u32
+ Definition: The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+In addition to these properties the qman-portals should have sub-nodes to
+represent the HW devices/portals that are connected to the software portal
+described here
+
+The currently support sub-nodes are:
+ * fman@0
+ * fman@1
+ * pme@0
+ * crypto@0
+
+These subnodes should have the following properties:
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+- dev-handle
+ Usage: Required
+ Value type: phandle
+ Definition: The phandle to the particular hardware device that this
+ portal is connected to.
+
+DPAA QMan Pool Channel Nodes
+
+Pool Channels are defined with the following properties.
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,qman-pool-channel
+ May include fsl,SoC-qman-pool-channel
+
+- fsl,qman-channel-id
+ Usage: Required
+ Value type: u32
+ Definition: The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ qman-portals@ff420 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges = 0 0xf 0xf420 0x20;
+
+ qman-portal@0 {
+ compatible = fsl,qman-portal-1.2.0, fsl,qman-portal;
+ reg = 0 0x4000, 0x10 0x1000;
+ interrupts = 104 2 0 0;
+ fsl,liodn = 1 2;
+ fsl,qman-channel-id = 0;
+
+ fman@0 {
+ fsl,liodn = 0x21;
+ dev-handle = fman0;
+ };
+ fman@1 {
+ fsl,liodn = 0xa1;
+ dev-handle = fman1;
+ };
+ crypto@0 {
+ fsl,liodn = 0x41 0x66;
+ dev-handle =
Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
On Sat, Oct 25, 2014 at 04:14:19PM +0530, Aneesh Kumar K.V wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Hi,
Apologies for not getting to this yesterday.
I have some comments below:
Changes from V3:
* Explain pgd_huge, also move the definition to linux/hugetlb.h.
Both pgd_huge and is_hugepd are related to hugepages and hugetlb.h
is the right header
arch/arm/include/asm/pgtable.h | 2 +
arch/arm64/include/asm/pgtable.h | 2 +
arch/powerpc/include/asm/page.h | 1 +
include/linux/hugetlb.h | 30 +++
include/linux/mm.h | 7 +++
mm/gup.c | 113
+++
6 files changed, 96 insertions(+), 59 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 3b30062..c52d261 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
/* to find an entry in a kernel page-table-directory */
#define pgd_offset_k(addr) pgd_offset(init_mm, addr)
+#define pgd_huge(pgd)(0)
+
Please remove this from the patch as it is no longer needed due to
some changes below.
#define pmd_none(pmd)(!pmd_val(pmd))
#define pmd_present(pmd) (pmd_val(pmd))
diff --git a/arch/arm64/include/asm/pgtable.h
b/arch/arm64/include/asm/pgtable.h
index 41a43bf..f532a14 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t
newprot)
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
+#define pgd_huge(pgd)(0)
+
This too can be removed (see below)...
/*
* Encode and decode a swap entry:
* bits 0-1: present (must be zero)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 26fe1ae..f973fce 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -380,6 +380,7 @@ static inline int hugepd_ok(hugepd_t hpd)
#endif
#define is_hugepd(pdep) (hugepd_ok(*((hugepd_t *)(pdep
+#define pgd_huge pgd_huge
int pgd_huge(pgd_t pgd);
#else /* CONFIG_HUGETLB_PAGE */
#define is_hugepd(pdep) 0
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6e6d338..de63dbc 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -175,6 +175,36 @@ static inline void __unmap_hugepage_range(struct
mmu_gather *tlb,
}
#endif /* !CONFIG_HUGETLB_PAGE */
+/*
+ * hugepages at page global directory. If arch support
+ * hugepages at pgd level, they need to define this.
+ */
+#ifndef pgd_huge
+#define pgd_huge(x) 0
+#endif
This sequence now means we no longer need per-arch non-trivial
definitions of pgd_huge. i.e. it makes the arch/arm and arch/arm64
changes above superfluous.
+
+#ifndef is_hugepd
+/*
+ * Some architectures requires a hugepage directory format that is
+ * required to support multiple hugepage sizes. For example
+ * a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced the same
+ * on powerpc. This allows for a more flexible hugepage pagetable
+ * layout.
+ */
+typedef struct { unsigned long pd; } hugepd_t;
+#define is_hugepd(hugepd) (0)
+#define __hugepd(x) ((hugepd_t) { (x) })
+static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ return 0;
+}
+#else
+extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+unsigned pdshift, unsigned long end,
+int write, struct page **pages, int *nr);
+#endif
#define HUGETLB_ANON_FILE anon_hugepage
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 02d11ee..31d7fac 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1219,6 +1219,13 @@ long get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
struct vm_area_struct **vmas);
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
+extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
+ unsigned long sz, unsigned long end, int write,
+ struct page **pages, int *nr);
+#endif
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index cd62c8c..30773f3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -786,65 +786,31 @@
Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote: On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote: On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: Update generic gup implementation with powerpc specific details. On powerpc at pmd level we can have hugepte, normal pmd pointer or a pointer to the hugepage directory. I grabbed these. It would be better if they were merged into the powerpc tree where they'll get more testing than in linux-next alone. Fine by me. Can I get an ack from you and/or someone else on CC? Only arm and arm64 use this code. Steve, could you please look it over and check that arm is still happy? Hi Andrew, I've tested it and posted some comments on it. If the arch/arm and arch/arm64 changes are removed and a comment about an assumption made by the new gup_huge_pte code is added then I'm happy. Cheers, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
On Mon, Oct 27, 2014 at 09:26:26PM -0700, Nicolin Chen wrote: On Tue, Oct 28, 2014 at 12:19:04AM +, Mark Brown wrote: It's not a bug, it's not reasonable to default allocations to atomic and we can't really tell what context we're in. Anything used inside a heavily locked path should either have a default provided or arrange for a prior write to set up the cache. I've a little trouble to understand the prior write over here. Inside my probe() there's a register_init() call which has a set of regmap_write(). And then the first regmap_write() results the dump. Does that mean this regmap_write() isn't prior write? If so, how should I do if not setting Oh, bother. We fixed things so that we're now always running with the spinlock held... never mind. default values here -- Some IPs may have default value 0 for registers. And this would make reg_defaults tedious since there's nothing special to assign. Write a small script then, or a little bit of code to create the defaults dynamically. And actually I remember I haven't seen any dump when I sent the initial patch for the whole ASRC driver but it manifested last month. I thought it might be a partially-merging issue and it would be fixed after merge window's done. Nothing has changed here for a while as far as I remember. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] PowerPC: boot: Parse chosen/cmdline-timeout parameter
A 5 second timeout during boot might be too long, so make it
configurable. Run the loop at least once to let the user stop the boot
by holding a key pressed. If the timeout is set to 0, don't wait for
input, which can be used as a workaround if the boot hangs on random
data coming in on the serial port.
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
I googled for it, and can't find v2 applied anywhere. I've made an
improvement to the patch: If the timeout is 0, don't wait for input. We
have a board where the serial port gives garbage when it's not
connected - this board would then hang in the bootloader.
If someone (Michael Ellerman?) has already applied it somewhere, I can
send a separate patch for that particular change.
ChangeLog:
v3:
- Don't wait for input if the timeout is 0
v2:
- Rename the property linux,cmdline-timeout (Grant Likely)
- Run the loop at least once to allow (Grant Likely)
arch/powerpc/boot/main.c | 13 +++--
arch/powerpc/boot/ops.h|2 +-
arch/powerpc/boot/serial.c |6 +++---
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f021..acd0414 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -144,13 +144,22 @@ static char cmdline[COMMAND_LINE_SIZE]
static void prep_cmdline(void *chosen)
{
+ unsigned int getline_timeout = 5000;
+ int v;
+ int n;
+
+ /* Wait-for-input time */
+ n = getprop(chosen, linux,cmdline-timeout, v, sizeof(v));
+ if (n == sizeof(v))
+ getline_timeout = v;
+
if (cmdline[0] == '\0')
getprop(chosen, bootargs, cmdline, COMMAND_LINE_SIZE-1);
printf(\n\rLinux/PowerPC load: %s, cmdline);
/* If possible, edit the command line */
- if (console_ops.edit_cmdline)
- console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
+ if (console_ops.edit_cmdline getline_timeout)
+ console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE,
getline_timeout);
printf(\n\r);
/* Put the command line back into the devtree for the kernel */
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..c42ea70 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -58,7 +58,7 @@ extern struct dt_ops dt_ops;
struct console_ops {
int (*open)(void);
void(*write)(const char *buf, int len);
- void(*edit_cmdline)(char *buf, int len);
+ void(*edit_cmdline)(char *buf, int len, unsigned int
getline_timeout);
void(*close)(void);
void*data;
};
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index f2156f0..167ee94 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -33,7 +33,7 @@ static void serial_write(const char *buf, int len)
scdp-putc(*buf++);
}
-static void serial_edit_cmdline(char *buf, int len)
+static void serial_edit_cmdline(char *buf, int len, unsigned int timeout)
{
int timer = 0, count;
char ch, *cp;
@@ -44,7 +44,7 @@ static void serial_edit_cmdline(char *buf, int len)
cp = buf[count];
count++;
- while (timer++ 5*1000) {
+ do {
if (scdp-tstc()) {
while (((ch = scdp-getc()) != '\n') (ch != '\r')) {
/* Test for backspace/delete */
@@ -70,7 +70,7 @@ static void serial_edit_cmdline(char *buf, int len)
break; /* Exit 'timer' loop */
}
udelay(1000); /* 1 msec */
- }
+ } while (timer++ timeout);
*cp = 0;
}
--
1.7.9.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.
On 2014-9-18 3:34, Mark Rutland wrote: On Wed, Sep 17, 2014 at 04:37:30PM +0100, Kumar Gala wrote: On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni ganapatrao.kulka...@caviumnetworks.com wrote: From: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com This patch adds property nid to memory node to provide the memory range to numa node id mapping. Signed-off-by: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com — Adding the PPC guys as they’ve been doing NUMA on IBM Power Servers for years with OF/DT. So we should really try and follow what they’ve done. Agreed. Documentation/devicetree/bindings/numa.txt | 58 ++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/numa.txt diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt new file mode 100644 index 000..c4a94f2 --- /dev/null +++ b/Documentation/devicetree/bindings/numa.txt @@ -0,0 +1,58 @@ +== +numa id binding description +== + +== +1 - Introduction +== +The device node property nid(numa node id) can be added to memory Why the quotes? +device node to map the range of memory addresses as defined in property reg. +The property nid maps the memory range to the numa node id, which is used to +find the local and remory pages on numa aware systems. What is a numa node id, exactly, and how is the OS intended to use it? I think Proximity Domain would be more suitably, processors and memory or IOs in the same domain will have better performance than crossing other domains. Thanks Hanjun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Handling of multiple MSI Vecotrs on Freescale P1022
Hi, I've a question regarding the handling of multiple MSI Vectors on a Freescale P1022. In arch_setup_msi_irqs (arch/powerpc/kernel/msi.c) there is a comment that PowerPC doesn't support multiple MSI yet. What is the reason for this comment and is there anything I can do to enable multiple MSI IRQs? Thanks, Johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote:
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on
ARM SoCs as well?
I can’t remember if the TI guys had a HW allocator as part of their similar HW.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
new file mode 100644
index 000..c30bdde
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
@@ -0,0 +1,98 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Node
+ - BMan Private Memory Node
+ - Example
+
+NOTE:The bindings described in this document are preliminary and
subject to
+ change
+
+BMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,bman
+ May include fsl,SoC-bman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
interrupts should be in this list.
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing
store
+for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a
node
+under the /reserved-memory node
+
+The BMan FBPR memory node must be named bman-fbpr
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: Must inclide fsl,bman-fbpr
+
+The following constraints are relevant to the FBPR private memory:
+ - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
+ 16 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FBPR must be chosen by observing the hardware features
configured
+via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
+pinned-out, number of offline/host command FMan ports, etc.). The size
configured
+in the DT must reflect the hardware capabilities and not the specific needs
of an
+application
RCW doesn’t have any context here
+
+If the memory reserved in the device tree proves to be larger then the needs
of
+the application a BMan driver may provide a method to release the extra
memory
+back to the OS
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a BMan FBPR dynamic allocation memory node
+
+ reserved-memory {
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+
+ bman-fbpr {
+ compatible = fsl,bman-fbpr;
+ alloc-ranges = 0 0 0xf 0x;
+ size = 0 0x100;
+ alignment = 0 0x100;
+ };
+
+ };
+
+The example below shows a (P4080) BMan CCSR-space node
+
+ bman@31a000 {
+ compatible = fsl,bman;
+ reg = 0x31a000 0x1000;
+ interrupts = 16 2 1 2;
+ fsl,liodn = 0x17;
no fsl,iommu-parent in the example?
+ };
Do you not need a phandle between the bman and the memory node?
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Oct 28, 2014, at 4:15 AM, Emil Medve emilian.me...@freescale.com wrote:
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 95 ++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on
ARM SoCs as well?
I can’t remember if the TI guys had a HW allocator as part of their similar HW.
If so, possibly worth while to see where they have their binding.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
new file mode 100644
index 000..d3fd1e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
@@ -0,0 +1,95 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Node
+ - BMan Private Memory Node
+ - Example
+
+BMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,bman
+ May include fsl,SoC-bman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property. The error interrupt
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing
store
+for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a
node
… Proxy Records (FBPR). This
[ so we get context for the acronym used later ]
+under the /reserved-memory node
+
+The BMan FBPR memory node must be named bman-fbpr
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: Must inclide fsl,bman-fbpr
+
+The following constraints are relevant to the FBPR private memory:
+ - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
+ 16 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FBPR must be chosen by observing the hardware features
configured
+via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
+pinned-out, number of offline/host command FMan ports, etc.). The size
configured
+in the DT must reflect the hardware capabilities and not the specific needs
of an
+application
RCW doesn’t have any context here
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a BMan FBPR dynamic allocation memory node
+
+ reserved-memory {
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+
+ bman-fbpr {
+ compatible = fsl,bman-fbpr;
+ alloc-ranges = 0 0 0xf 0x;
+ size = 0 0x100;
+ alignment = 0 0x100;
+ };
+ };
+
+The example below shows a (P4080) BMan CCSR-space node
+
+ bman@31a000 {
+ compatible = fsl,bman;
+ reg = 0x31a000 0x1000;
+ interrupts = 16 2 1 2;
+ fsl,liodn = 0x17;
no fsl,iommu-parent in the example?
+ };
Do you not need a phandle between the bman and the memory node?
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
On Oct 28, 2014, at 4:15 AM, Emil Medve emilian.me...@freescale.com wrote:
Portals are memory mapped interfaces to BMan that allow low-latency,
lock-less interaction by software running on processor cores, accelerators
and network interfaces with the BMan
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
---
.../bindings/powerpc/fsl/bman-portals.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
similar comment about location of binding not being PPC specific.
new file mode 100644
index 000..02e0231
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
@@ -0,0 +1,52 @@
+QorIQ DPAA Buffer Manager Portals Device Tree Binding
+
Probably worth putting the text from the commit message here as well.
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Portal
+ - Example
+
+BMan Portal Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,bman-portal-hardware revision
+ May include fsl,SoC-bman-portal or fsl,bman-portal
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Two regions. The first is the cache-enabled region of
+ the portal. The second is the cache-inhibited region of
+ the portal
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ bman-portals@ff400 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges = 0 0xf 0xf400 0x20;
+
+ bman-portal@0 {
+ compatible = fsl,bman-portal-1.0.0, fsl,bman-portal;
+ reg = 0x0 0x4000, 0x10 0x1000;
+ interrupts = 105 2 0 0;
+ };
+ bman-portal@4000 {
+ compatible = fsl,bman-portal-1.0.0, fsl,bman-portal;
+ reg = 0x4000 0x4000, 0x101000 0x1000;
+ interrupts = 107 2 0 0;
+ };
+ };
--
2.1.2
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl-asoc-card: Don't bypass settings if cpu-dai is Master
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote: When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations, set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if the set_bias_level() has already taken care of the codec-dai side. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
On Tue, Oct 28, 2014 at 10:47:42AM +, Mark Brown wrote: On Mon, Oct 27, 2014 at 09:26:26PM -0700, Nicolin Chen wrote: On Tue, Oct 28, 2014 at 12:19:04AM +, Mark Brown wrote: It's not a bug, it's not reasonable to default allocations to atomic and we can't really tell what context we're in. Anything used inside a heavily locked path should either have a default provided or arrange for a prior write to set up the cache. I've a little trouble to understand the prior write over here. Inside my probe() there's a register_init() call which has a set of regmap_write(). And then the first regmap_write() results the dump. Does that mean this regmap_write() isn't prior write? If so, how should I do if not setting Oh, bother. We fixed things so that we're now always running with the spinlock held... never mind. Okay...so only one choice left. default values here -- Some IPs may have default value 0 for registers. And this would make reg_defaults tedious since there's nothing special to assign. Write a small script then, or a little bit of code to create the defaults dynamically. It actually doesn't bother me at all. I just thought there might be a simpler way. :) Thank you Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FSL MSI Mapping
Hi, I got notified about your patch to support multiple MSI Vectors on Freescale PowerPC platforms. Is there any reason why it wasn't applied until now? I couldn't find anything about it in the list archives. I think it would be a real benefit for all to have multiple MSI vecotrs on PowerPCs. Thanks in advance, Johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/2] powerpc/numa: ensure per-cpu NUMA mappings are correct on topology update
Hi Michael, On 21.10.2014 [15:36:27 +1100], Michael Ellerman wrote: On Sat, 2014-18-10 at 00:50:40 UTC, Nishanth Aravamudan wrote: We received a report of warning in kernel/sched/core.c where the sched group was NULL on an LPAR after a topology update. This seems to occur because after the topology update has moved the CPUs, cpu_to_node is returning the old value still, which ends up breaking the consistency of the NUMA topology in the per-cpu maps. Ensure that we update the per-cpu fields when we re-map CPUs. This looks like a bug fix, I assume you want it to go in for 3.18 ? Yes, please! Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
On Wed, 2014-10-22 at 15:04 -0500, Emil Medve wrote:
Hello Mark,
Thanks for having a look at this
On 10/22/2014 09:29 AM, Mark Rutland wrote:
I'd feel rather uncomfortable accepting a
binding that we already believe to be insufficient to describe the
hardware.
What do you expect to change?
Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
covers incompletely a dynamic LIODN assignment/programming model. The
current driver uses a static assignment scheme that the binding needs to
include. I also suspect that once the driver starts supporting the
dynamic LIODN assignment/programming we might find some wrinkles
How is this different from any of the other QorIQ bindings that have
been merged without such a disclaimer? The static LIODN model is
already there, even if documentation is missing, and should continue to
be supported even if we eventually implement a dynamic LIODN model.
+
+ bman-portals@ff400 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges = 0 0xf 0xf400 0x20;
+
+ bman-portal@0 {
+ compatible = fsl,bman-portal-1.0.0, fsl,bman-portal;
+ reg = 0x0 0x4000 0x10 0x1000;
It would be easier to read is each entry had its own set of brackets.
Initially this looked to me like a single 64-bit address/size pair.
Something like , ? It doesn't seem widely used but I agree is more
readable. I can include it in the the next spin
The older PPC device trees haven't used it much but I think it's pretty
common in the newer ARM trees.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt new file mode 100644 index 000..c30bdde --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt @@ -0,0 +1,98 @@ +QorIQ DPAA Buffer Manager Device Tree Bindings + +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc. + +CONTENTS + + - BMan Node + - BMan Private Memory Node + - Example + +NOTE:The bindings described in this document are preliminary and subject to + change + +BMan Node + +PROPERTIES + +- compatible + Usage: Required + Value type: stringlist + Definition: Must include fsl,bman + May include fsl,SoC-bman + +- reg + Usage: Required + Value type: prop-encoded-array + Definition: Registers region within the CCSR address space Is there a version register in reg? It would be nice to point it out in the binding along with an example chip for each version, similar to Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt. This would make it clear that the compatible needs to be changed if the version register moves or no longer works the same way. +BMan Private Memory Node + +BMan requires a contiguous range of physical memory used for the backing store +for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a node +under the /reserved-memory node + +The BMan FBPR memory node must be named bman-fbpr + +PROPERTIES + +- compatible + Usage: required + Value type: stringlist + Definition: Must inclide fsl,bman-fbpr + +The following constraints are relevant to the FBPR private memory: + - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to + 16 GiB + - The alignment must be a muliptle of the memory size + +The size of the FBPR must be chosen by observing the hardware features configured +via the RCW and that are relevant to a specific board (e.g. number of MAC(s) +pinned-out, number of offline/host command FMan ports, etc.). The size configured +in the DT must reflect the hardware capabilities and not the specific needs of an +application What about accelerators? +If the memory reserved in the device tree proves to be larger then the needs of +the application a BMan driver may provide a method to release the extra memory +back to the OS What if the memory reserved in the device tree proves to be smaller than the needs of the application? I think we should document this size as being a sane default for the hardware, and add a way of describing that the size is tunable. Below is the reserved-memory extension that I suggested to you internally: resizable (optional) - empty property - Indicates that the size of the dynamic allocation is flexible. If resizeable is present, the size property is optional. If both resizable and size are present, the size property indicates a recommended default size for this hardware. pow2-aligned (optional) - empty property - Only valid if resizable is present. Indicates that the size must be a power of two, and the address must be aligned to its size. If both pow2-aligned and alignment properties are present, pow2-aligned is used if the region is resized, and the alignment property is used if the region is not resized. min-size (optional) - Only valid if resizable is present. Specifies a minimum acceptable size. max-size (optional) - Only valid if resizable is present. Specifies a maximum acceptable size. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)
On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote:
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
There are two LIODNs on these nodes; you need to specifiy here which is
which. Likewise on the crypto subnode.
+The currently support sub-nodes are:
+ * fman@0
+ * fman@1
+ * pme@0
+ * crypto@0
s/support/supported/
+These subnodes should have the following properties:
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ Definition: PAMU property used for dynamic LIODN assignment
+
+- dev-handle
+ Usage: Required
+ Value type: phandle
+ Definition: The phandle to the particular hardware device that this
+ portal is connected to.
+
+DPAA QMan Pool Channel Nodes
+
+Pool Channels are defined with the following properties.
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,qman-pool-channel
+ May include fsl,SoC-qman-pool-channel
+
+- fsl,qman-channel-id
+ Usage: Required
+ Value type: u32
+ Definition: The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ qman-portals@ff420 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ ranges = 0 0xf 0xf420 0x20;
+
+ qman-portal@0 {
+ cell-index = 0;
+ compatible = fsl,qman-portal-1.2.0, fsl,qman-portal;
+ reg = 0 0x4000 0x10 0x1000;
+ interrupts = 104 2 0 0;
+ fsl,liodn = 1 2;
+ fsl,qman-channel-id = 0;
+
+ fman@0 {
+ fsl,liodn = 0x21;
+ dev-handle = fman0;
+ };
+ fman@1 {
+ fsl,liodn = 0xa1;
+ dev-handle = fman1;
+ };
+ crypto@0 {
+ fsl,liodn = 0x41 0x66;
+ dev-handle = crypto;
+ };
Shouldn't have unit address without reg; use fman0/fman1/crypto instead.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL MSI Mapping
On Tue, 2014-10-28 at 18:06 +0100, Johannes Thumshirn wrote: Hi, I got notified about your patch to support multiple MSI Vectors on Freescale PowerPC platforms. Is there any reason why it wasn't applied until now? I couldn't find anything about it in the list archives. I think it would be a real benefit for all to have multiple MSI vecotrs on PowerPCs. Could you provide a patchwork link to the patch you're talking about? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On 10/27/14 06:13, Tomi Valkeinen wrote: On 27/10/14 13:59, Jani Nikula wrote: While doing 'depends on' instead of 'select' is an easy fix for this, I do dislike it quite a bit. It's a major pain to go around the kernel config, trying to find all the dependencies that a particular driver wants. If I need fb-foobar, I should just be able to enable it, instead of first searching and selecting its minor dependencies individually. Agreed, but I don't think that's specific to this patch. Well, no, the generic problem is not specific to this patch, but we can avoid the issue with proper use of 'select' (at least in some cases), which is specific to this patch. So, not a NACK, but a isn't there an another way to fix this?. I think the real answer would be to fix kconfig to also show menu items whose dependencies are not met, and then recursively enabling the dependencies when the item is enabled. Beyond my scope. Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a meta option, it only enables a Kconfig submenu. So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option. But if we do that, all the items in drivers/video/backlight/Kconfig with default 'y' or 'm' would get enabled by default, so I think we should remove the 'default's from that file. That makes sense in any case, as I don't see why HP Jornada 700 series LCD Driver should be default y. BACKLIGHT_CLASS_DEVICE doesn't depend on anything except BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should be safe to 'select' BACKLIGHT_CLASS_DEVICE. BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE could be made to select BACKLIGHT_CLASS_DEVICE instead. I think it should be possible to choose between y and m when it's If I'm not mistaken, if CONFIG_FOO is 'm', and it 'select's CONFIG_BAR, and CONFIG_BAR is tristate, then CONFIG_BAR will be set to 'm'. selected, and it should be possible to enable it when it's not selected by any drivers. I'm not sure a hidden option is good for that. Why would you want to enable it if no one uses it? Does BACKLIGHT_CLASS_DEVICE enable something even if no driver uses it? That doesn't exactly fix anything, but I think it makes sense as BACKLIGHT_CLASS_DEVICE is something that's selected from all around the kernel, so it should be a selectable library instead of a Kconfig menu option. At least for drm/i915 BACKLIGHT_CLASS_DEVICE is an option. We use it if it's enabled, but we are just fine if it's not. I've learned the way to express that is depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n but I don't think there's a way to express that in terms of select, is there? The dependency above guarantees there's no DRM_I915=y and BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where this whole patch got started, as select didn't handle that properly. If backlight support is considered an option for drm/i915, then I think there should be a Kconfig option for i915 to enable backlight support, which in turn selects BACKLIGHT_CLASS_DEVICE. And that select will force BACKLIGHT_CLASS_DEVICE to be built-in if drm/i915 is built-in. Oh, but it doesn't work optimally with modules. The new option needed for that would be boolean, so BACKLIGHT_CLASS_DEVICE would always be either y or n. Sigh... I didn't look at the ACPI_VIDEO side, so no idea how messy that is. Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only imagine trying to solve this problem with select is going to end up in recursive dependencies that spread out and need changing about as wide as this patch. If ACPI_VIDEO uses select to enable BACKLIGHT_CLASS_DEVICE, then, I think, selecting ACPI_VIDEO will also select BACKLIGHT_CLASS_DEVICE. So I don't right away see any recursive dependencies. Or what did you have in mind? In the end, I agree with the problem you have with this patch, but yet I think it's the right thing to do in terms of expressing the dependencies. Well, dri/i915 doesn't exactly depend on backlight, if I understood you correctly. Instead, backlight is an option for dri/i915, and you kind of hack it to be implemented with that 'depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n'. I guess it's debatable whether drivers should automatically use features in the kernel if they happen to be enabled in the Kconfig, or should they be individually enabled for that driver. I personally like the latter option, as it allows more precise control, but it probably also depends on the feature in question. I also think the 'depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds like a hack to me =). It does exactly what is needed and it is used in many places in kernel Kconfig files. -- ~Randy
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
On Fri, 2014-10-17 at 11:27 +0200, Valentin Longchamp wrote:
With fsl-i2c compatibility the i2c frequency is not set
correctly, because it sets no prescaler. According to the AN2919 from
Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
the platform clock. This implies that a prescaler of 2 must be used.
This changes the compatibility of the qoriq-i2c .dtsi files to pick the
mpc8543, which uses the same driver but sets the correct prescaler.
Signed-off-by: Rainer Boschung rainer.bosch...@keymile.com
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
index 5f9bf7d..aa6c366 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
@@ -36,7 +36,7 @@ i2c@118000 {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118000 0x100;
interrupts = 38 2 0 0;
dfsrr;
@@ -46,7 +46,7 @@ i2c@118100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118100 0x100;
interrupts = 38 2 0 0;
dfsrr;
Are all chips that use this dtsi 100% compatible with mpc8543's i2c, or
just in ways the Linux driver cares about?
What about fsl,mpc8544-i2c, which has additional special handling in the
driver, but is only used in socrates.dts (not mpc8544ds.dts)?
What about pq3-i2c-*.dtsi?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/dts: Factorize the clock control node
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I25ce24a25862b4ca460164159867abefe00ccdd1
Please remove gerrit stuff prior to submitting.
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
new file mode 100644
index 000..4871048
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
@@ -0,0 +1,78 @@
+/*
+ * QorIQ clock control device tree stub [ controller @ offset 0xe1000 ]
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
met:
+ * * Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *names of its contributors may be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+global-utilities@e1000 {
+ compatible = fsl,qoriq-clockgen-1.0;
+ ranges = 0x0 0xe1000 0x1000;
+ reg = 0xe1000 0x1000;
+ clock-frequency = 0;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ sysclk: sysclk {
+ #clock-cells = 0;
+ compatible = fsl,qoriq-sysclk-1.0, fixed-clock;
+ clock-output-names = sysclk;
+ };
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 0x4;
+ compatible = fsl,qoriq-core-pll-1.0;
+ clocks = sysclk;
+ clock-output-names = pll0, pll0-div2;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820 0x4;
+ compatible = fsl,qoriq-core-pll-1.0;
+ clocks = sysclk;
+ clock-output-names = pll1, pll1-div2;
+ };
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0 0x4;
+ compatible = fsl,qoriq-core-mux-1.0;
+ clocks = pll0 0, pll0 1, pll1 0, pll1 1;
+ clock-names = pll0, pll0-div2, pll1, pll1-div2;
+ clock-output-names = cmux0;
+ };
+ mux1: mux1@20 {
+ #clock-cells = 0;
+ reg = 0x20 0x4;
+ compatible = fsl,qoriq-core-mux-1.0;
+ clocks = pll0 0, pll0 1, pll1 0, pll1 1;
+ clock-names = pll0, pll0-div2, pll1, pll1-div2;
+ clock-output-names = cmux1;
+ };
+};
I don't think the mux stuff belongs here, given that clockgen2.dtsi
doesn't have it, and I saw at least one clockgen1 user needing to
supplement this with more muxes.
@@ -1068,7 +1043,6 @@
clocks = sysclk;
clock-output-names = pll2, pll2-div2, pll2-div4;
};
-
pll3: pll3@860 {
#clock-cells = 1;
reg = 0x860 0x4;
@@ -1076,7 +1050,6 @@
clocks = sysclk;
clock-output-names = pll3, pll3-div2, pll3-div4;
};
-
pll4: pll4@880 {
#clock-cells = 1;
reg = 0x880 0x4;
Why?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] dt/bindings: qoriq-clock: Add binding for the platform PLL
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I7950afa9650d15ec7ce2cca89bb2a1e38586d4a5
---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 17
+++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 5666812..407fb01 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -62,6 +62,8 @@ Required properties:
It takes parent's clock-frequency as its clock.
* fsl,qoriq-sysclk-2.0: for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
+ * fsl,qoriq-platform-pll-1.0 for the platform PLL clock (v1.0)
+ * fsl,qoriq-platform-pll-2.0 for the platform PLL clock (v2.0)
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
@@ -94,7 +96,6 @@ Example for clock block and clock provider:
compatible = fsl,qoriq-sysclk-1.0;
clock-output-names = sysclk;
};
-
pll0: pll0@800 {
#clock-cells = 1;
reg = 0x800 0x4;
@@ -102,7 +103,6 @@ Example for clock block and clock provider:
clocks = sysclk;
clock-output-names = pll0, pll0-div2;
};
-
pll1: pll1@820 {
#clock-cells = 1;
reg = 0x820 0x4;
@@ -110,7 +110,6 @@ Example for clock block and clock provider:
clocks = sysclk;
clock-output-names = pll1, pll1-div2;
};
-
mux0: mux0@0 {
#clock-cells = 0;
reg = 0x0 0x4;
Please don't make unrelated whitespace changes, especially when they're
changing something that's not obviously broken.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: On 10/27/14 06:13, Tomi Valkeinen wrote: I also think the 'depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds like a hack to me =). It does exactly what is needed and it is used in many places in kernel Kconfig files. Is there any reason you can't do: depends on BACKLIGHT_CLASS_DEVICE != m cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791
On Wed, Oct 15, 2014 at 10:58:45PM +0530, Aneesh Kumar K.V wrote:
=
[ INFO: possible recursive locking detected ]
3.17.0+ #31 Not tainted
-
qemu-system-ppc/9112 is trying to acquire lock:
((vcpu-arch.tbacct_lock)-rlock){..}, at: [d00011591f84]
.vcore_stolen_time+0x44/0xb0 [kvm_hv]
but task is already holding lock:
((vcpu-arch.tbacct_lock)-rlock){..}, at: [d00011592524]
.kvmppc_remove_runnable.part.2+0x34/0xd0 [kvm_hv]
This is actually harmless, because the lock taken in
vcore_stolen_time() is always a different lock from the one taken in
kvmppc_remove_runnable(). In vcore_stolen_time() we take the lock of
the runner vcpu if we are not the runner vcpu (if we are the runner,
we don't take any lock there). Nor is there any lock ordering
problem, because we always take the runner's lock last.
This is all a bit subtle, probably a bit too subtle. I have been
meaning to rework it but haven't had the time yet.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
On Tue, 2014-10-28 at 10:44 +, Steve Capper wrote: On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote: On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote: On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: Update generic gup implementation with powerpc specific details. On powerpc at pmd level we can have hugepte, normal pmd pointer or a pointer to the hugepage directory. I grabbed these. It would be better if they were merged into the powerpc tree where they'll get more testing than in linux-next alone. Fine by me. Can I get an ack from you and/or someone else on CC? Only arm and arm64 use this code. Steve, could you please look it over and check that arm is still happy? Hi Andrew, I've tested it and posted some comments on it. If the arch/arm and arch/arm64 changes are removed and a comment about an assumption made by the new gup_huge_pte code is added then I'm happy. OK thanks Steve. Aneesh can you do those changes and resend and I'll put it in powerpc next. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] PowerPC: boot: Parse chosen/cmdline-timeout parameter
On Tue, 2014-28-10 at 11:19:00 UTC, Simon Kagstrom wrote: A 5 second timeout during boot might be too long, so make it configurable. Run the loop at least once to let the user stop the boot by holding a key pressed. If the timeout is set to 0, don't wait for input, which can be used as a workaround if the boot hangs on random data coming in on the serial port. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- I googled for it, and can't find v2 applied anywhere. I've made an improvement to the patch: If the timeout is 0, don't wait for input. We have a board where the serial port gives garbage when it's not connected - this board would then hang in the bootloader. If someone (Michael Ellerman?) has already applied it somewhere, I can send a separate patch for that particular change. No I haven't applied it yet. I will put it in next in the next week or so for 3.19, you don't need to do anything. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
