* [PATCH -V2 00/26]T HP support for PPC64
From: Aneesh Kumar K.V @ 2013-03-06 6:10 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Hi,
This patchset adds transparent huge page support for PPC64.
TODO:
* ppc64 KVM related changes
* powernv still doesn't boot
* hash preload support in update_mmu_cache_pmd
Some numbers:
The latency measurements code from Anton found at
http://ozlabs.org/~anton/junkcode/latency2001.c
THP disabled 64K page size
------------------------
[root@llmp24l02 ~]# ./latency2001 8G
8589934592 731.73 cycles 205.77 ns
[root@llmp24l02 ~]# ./latency2001 8G
8589934592 743.39 cycles 209.05 ns
[root@llmp24l02 ~]#
THP disabled large page via hugetlbfs
-------------------------------------
[root@llmp24l02 ~]# ./latency2001 -l 8G
8589934592 416.09 cycles 117.01 ns
[root@llmp24l02 ~]# ./latency2001 -l 8G
8589934592 415.74 cycles 116.91 ns
THP enabled 64K page size.
----------------
[root@llmp24l02 ~]# ./latency2001 8G
8589934592 405.07 cycles 113.91 ns
[root@llmp24l02 ~]# ./latency2001 8G
8589934592 411.82 cycles 115.81 ns
[root@llmp24l02 ~]#
We are close to hugetlbfs in latency and we can achieve this with zero
config/page reservation. Most of the allocations above are fault allocated.
I haven't really measured the collapse alloc impact.
Another test that does 50000000 random access over 1GB area goes from
2.65 seconds to 1.07 seconds with this patchset.
Changes from V1
* Address review comments
* More patch split
* Add batch hpte invalidate for hugepages.
Changes from RFC V2:
* Address review comments
* More code cleanup and patch split
Changes from RFC V1:
* HugeTLB fs now works
* Compile issues fixed
* rebased to v3.8
* Patch series reorded so that ppc64 cleanups and MM THP changes are moved
early in the series. This should help in picking those patches early.
Thanks,
-aneesh
^ permalink raw reply
* 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
From: Philippe De Muyter @ 2013-03-06 6:00 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, linux-kernel
Hello Michael,
bisect tells me that since your commit 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
"powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers",
compiling linux fails with :
cc1: warnings being treated as errors
arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace':
arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used uninitialized in this function
arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here
could you look at that ?
Thanks
Philippe
^ permalink raw reply
* Re: [PATCH 5/6][v4]: perf: Create a sysfs entry for Power event format
From: Sukadev Bhattiprolu @ 2013-03-06 5:48 UTC (permalink / raw)
To: Michael Ellerman
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Anton Blanchard,
linux-kernel, Stephane Eranian, linuxppc-dev, Ingo Molnar,
Paul Mackerras, Arnaldo Carvalho de Melo, Jiri Olsa
In-Reply-To: <20130227011725.GA5819@concordia>
Michael Ellerman [michael@ellerman.id.au] wrote:
| I suspect Arnaldo was either waiting for an ACK from Ben, or was
| expecting Ben to take it?
Arnaldo, here is an updated patch. If it is acked by Paul Mackerras,
Michael Ellerman or Ben, will you add it to your tree so the whole
patchset comes from one place ?
Sukadev
---
>From 50c7a46f14083c0ed10d66b7aed66ba76e798550 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Tue, 5 Mar 2013 21:20:56 -0800
Subject: [PATCH] [PATCH 5/6][v4]: perf Create a sysfs format entry for Power7 events
Create a sysfs entry, '/sys/bus/event_source/devices/cpu/format/event'
which describes the format of the POWER7 PMU events.
This code is based on corresponding code in x86.
Changelog[v4]: [Michael Ellerman, Paul Mckerras] The event format is different
for other POWER cpus. So move the code to POWER7-specific,
power7-pmu.c Also, the POWER7 format uses bits 0-19 not 0-20.
Changelog[v2]: [Jiri Osla] Use PMU_FORMAT_ATTR rather than duplicating code.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/perf/power7-pmu.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index b554879..3c475d6 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -420,7 +420,20 @@ static struct attribute_group power7_pmu_events_group = {
.attrs = power7_events_attr,
};
+PMU_FORMAT_ATTR(event, "config:0-19");
+
+static struct attribute *power7_pmu_format_attr[] = {
+ &format_attr_event.attr,
+ NULL,
+};
+
+struct attribute_group power7_pmu_format_group = {
+ .name = "format",
+ .attrs = power7_pmu_format_attr,
+};
+
static const struct attribute_group *power7_pmu_attr_groups[] = {
+ &power7_pmu_format_group,
&power7_pmu_events_group,
NULL,
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
From: Michael Ellerman @ 2013-03-06 5:42 UTC (permalink / raw)
To: Mike Qiu; +Cc: tglx, linuxppc-dev, linux-kernel
In-Reply-To: <5136D582.80101@linux.vnet.ibm.com>
On Wed, Mar 06, 2013 at 01:34:58PM +0800, Mike Qiu wrote:
> 于 2013/3/6 11:54, Michael Ellerman 写道:
> >On Tue, Mar 05, 2013 at 03:19:57PM +0800, Mike Qiu wrote:
> >>于 2013/3/5 10:23, Michael Ellerman 写道:
> >>>On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
> >>>>diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> >>>>index 96f3a1d..38648e6 100644
> >>>>--- a/kernel/irq/irqdomain.c
> >>>>+++ b/kernel/irq/irqdomain.c
> >>>>@@ -636,6 +636,67 @@ int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
> >>>> }
> >>>> EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
> >>>>+/**
> >>>>+ * irq_create_mapping_many - Map a range of hw IRQs to a range of virtual IRQs
> >>>>+ * @domain: domain owning the interrupt range
> >>>>+ * @hwirq_base: beginning of continuous hardware IRQ range
> >>>>+ * @count: Number of interrupts to map
> >>>For multiple-MSI the allocated interrupt numbers must be a power-of-2,
> >>>and must be naturally aligned. I don't /think/ that's a requirement for
> >>>the virtual numbers, but it's probably best that we do it anyway.
> >>>
> >>>So this API needs to specify that it will give you back a power-of-2
> >>>block that is naturally aligned - otherwise you can't use it for MSI.
> >>rtas_call will return the numbers of hardware interrupt, and it
> >>should be power-of-2, as this I think do not need to specify
> >You're confusing hardware interrupt numbers and virtual interrupt
> >numbers. My comment is about irq_create_mapping_many(), which returns
> >virtual interrupt numbers.
> >
> >As I said I don't think there is a requirement that the virtual
> >interrupt numbers are also a power-of-2 naturally aligned block, but we
> >should allocate them as one anyway, to avoid any issues in future.
> But for virtual interrupt numbersit should be a power-of-2 naturally
> aligned block, because it must be continuous, as the MSI-HOWTO.txt says:
>
> 4.2.2 pci_enable_msi_block
> int pci_enable_msi_block(struct pci_dev *dev, int count)
> This variation on the above call allows a device driver to request
> multiple MSIs. The MSI specification only allows interrupts to be
> allocated in powers of two, up to a maximum of 2^5 (32).
> If this function returns 0, it has succeeded in allocating at least
> as many interrupts as the driver requested
> (it may have allocated more in order to satisfy the power-of-two
> requirement). In this case, the function enables MSI on this device
> and updates dev->irq to be the lowest of the new interrupts
> assigned to it. The other interrupts assigned to the device are in
> the range dev->irq to dev->irq + count - 1.
>
> See the last line, that means for the virtual interrupts must be a
> continuous block.
In practice I think things could work if we didn't, because we are not
using the mask routines that assume that layout.
But you're right, we must implement the API as it's specified, so the
virtual interrupt numbers must be a naturally aligned power-of-2.
cheers
^ permalink raw reply
* Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
From: Mike Qiu @ 2013-03-06 5:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: tglx, linuxppc-dev, linux-kernel
In-Reply-To: <20130306035443.GB3493@concordia>
[-- Attachment #1: Type: text/plain, Size: 5555 bytes --]
于 2013/3/6 11:54, Michael Ellerman 写道:
> On Tue, Mar 05, 2013 at 03:19:57PM +0800, Mike Qiu wrote:
>> 于 2013/3/5 10:23, Michael Ellerman 写道:
>>> On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
>>>> Adding a function irq_create_mapping_many() which can associate
>>>> multiple MSIs to a continous irq mapping.
>>>>
>>>> This is needed to enable multiple MSI support for pSeries.
>>>>
>>>> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
>>>> ---
>>>> include/linux/irq.h | 2 +
>>>> include/linux/irqdomain.h | 3 ++
>>>> kernel/irq/irqdomain.c | 61 +++++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 66 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/include/linux/irq.h b/include/linux/irq.h
>>>> index 60ef45b..e00a7ec 100644
>>>> --- a/include/linux/irq.h
>>>> +++ b/include/linux/irq.h
>>>> @@ -592,6 +592,8 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
>>>> #define irq_alloc_desc_from(from, node) \
>>>> irq_alloc_descs(-1, from, 1, node)
>>>> +#define irq_alloc_desc_n(nevc, node) \
>>>> + irq_alloc_descs(-1, 0, nevc, node)
>>> This has been superseeded by irq_alloc_descs_from(), which is the right
>>> way to do it.
>> Yes, but irq_alloc_descs_from() just for 1 irq
> No it's not, look again.
>
> #define irq_alloc_descs_from(from, cnt, node) \
> irq_alloc_descs(-1, from, cnt, node)
Sorry, I see as irq_alloc_desc_from(from, node)
you are right
>
>
>>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>>> index 96f3a1d..38648e6 100644
>>>> --- a/kernel/irq/irqdomain.c
>>>> +++ b/kernel/irq/irqdomain.c
>>>> @@ -636,6 +636,67 @@ int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
>>>> }
>>>> EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
>>>> +/**
>>>> + * irq_create_mapping_many - Map a range of hw IRQs to a range of virtual IRQs
>>>> + * @domain: domain owning the interrupt range
>>>> + * @hwirq_base: beginning of continuous hardware IRQ range
>>>> + * @count: Number of interrupts to map
>>> For multiple-MSI the allocated interrupt numbers must be a power-of-2,
>>> and must be naturally aligned. I don't /think/ that's a requirement for
>>> the virtual numbers, but it's probably best that we do it anyway.
>>>
>>> So this API needs to specify that it will give you back a power-of-2
>>> block that is naturally aligned - otherwise you can't use it for MSI.
>> rtas_call will return the numbers of hardware interrupt, and it
>> should be power-of-2, as this I think do not need to specify
> You're confusing hardware interrupt numbers and virtual interrupt
> numbers. My comment is about irq_create_mapping_many(), which returns
> virtual interrupt numbers.
>
> As I said I don't think there is a requirement that the virtual
> interrupt numbers are also a power-of-2 naturally aligned block, but we
> should allocate them as one anyway, to avoid any issues in future.
But for virtual interrupt numbersit should be a power-of-2 naturally
aligned block, because it must be continuous, as the MSI-HOWTO.txt says:
4.2.2 pci_enable_msi_block
int pci_enable_msi_block(struct pci_dev *dev, int count)
This variation on the above call allows a device driver to request
multiple MSIs. The MSI specification only allows interrupts to be
allocated in powers of two, up to a maximum of 2^5 (32).
If this function returns 0, it has succeeded in allocating at least
as many interrupts as the driver requested
(it may have allocated more in order to satisfy the power-of-two
requirement). In this case, the function enables MSI on this device
and updates dev->irq to be the lowest of the new interrupts
assigned to it. The other interrupts assigned to the device are in
the range dev->irq to dev->irq + count - 1.
See the last line, that means for the virtual interrupts must be a
continuous block.
> And so this API, which returns virtual interrupt numbers, must satisfy
> that specification.
>
>>>> + /* Look for default domain if nececssary */
>>>> + if (!domain)
>>>> + domain = irq_default_domain;
>>>> + if (!domain) {
>>>> + pr_warn("irq_create_mapping called for NULL domain, hwirq=%lx\n"
>>>> + , hwirq_base);
>>>> + WARN_ON(1);
>>>> + return 0;
>>>> + }
>>>> + pr_debug("-> using domain @%p\n", domain);
>>>> +
>>>> + /* For IRQ_DOMAIN_MAP_LEGACY, get the first virtual interrupt number */
>>>> + if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
>>>> + return irq_domain_legacy_revmap(domain, hwirq_base);
>>> The above doesn't work.
>> Why it doesn't work ?
> Because irq_domain_legacy_revmap() only allocates a single interrupt
> number.
OK, your right.
>>>> + /* Check if mapping already exists */
>>>> + for (i = 0; i < count; i++) {
>>>> + virq = irq_find_mapping(domain, hwirq_base+i);
>>>> + if (virq) {
>>>> + pr_debug("existing mapping on virq %d,"
>>>> + " now dispose it first\n", virq);
>>>> + irq_dispose_mapping(virq);
>>> You might have just disposed of someone elses mapping, we shouldn't do
>>> that. It should be an error to the caller.
>> It's a good question. If the interrupt used for someone elses, why I
>> can apply it from the system?
> I agree, that would be a bug. But disposing of someone elses mapping is
> not OK.
>
>> So it may someone else forget to dispose mapping, and it never be
>> used for others as I have got the interrupt I think.
> Perhaps, but that is a bug that needs to be fixed in the code that
> forgets to dispose of the mapping.
>
> cheers
>
[-- Attachment #2: Type: text/html, Size: 8453 bytes --]
^ permalink raw reply
* Re: [PATCH -V1 06/24] powerpc: Reduce PTE table memory wastage
From: Aneesh Kumar K.V @ 2013-03-06 5:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20130305021219.GC2888@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Mon, Mar 04, 2013 at 04:28:42PM +0530, Aneesh Kumar K.V wrote:
>> The last one that ends up doing atomic_xor_bits which cause the mapcount
>> to go zero, will take the page off the list and free the page.
>
> No, look at the example again. page_table_free_rcu() won't take it
> off the list because it uses the (mask & FRAG_MASK) == 0 test, which
> fails (one fragment is still in use). page_table_free() won't take it
> off the list because it uses the mask == 0 test, which also fails (one
> fragment is still waiting for the RCU grace period). Finally,
> __page_table_free_rcu() doesn't take it off the list, it just frees
> the page. Oops. :)
How about the below
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -425,7 +425,7 @@ void page_table_free(struct mm_struct *mm, unsigned long *table)
bit = 1 << ((__pa(table) & ~PAGE_MASK) / PTE_FRAG_SIZE);
spin_lock(&mm->page_table_lock);
mask = atomic_xor_bits(&page->_mapcount, bit);
- if (mask == 0)
+ if (!(mask & FRAG_MASK))
list_del(&page->lru);
else if (mask & FRAG_MASK) {
/*
@@ -446,7 +446,7 @@ void page_table_free(struct mm_struct *mm, unsigned long *table)
ie, we always remove the page from the list, when the lower half is
zero or lower half is FRAG_MASK. We free the page when _mapcount is 0.
-aneesh
^ permalink raw reply
* Re: [PATCH -V1 09/24] powerpc: Decode the pte-lp-encoding bits correctly.
From: Aneesh Kumar K.V @ 2013-03-06 4:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20130305020205.GB2888@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Mon, Mar 04, 2013 at 05:11:53PM +0530, Aneesh Kumar K.V wrote:
>> Paul Mackerras <paulus@samba.org> writes:
>> >> +static inline int hpte_actual_psize(struct hash_pte *hptep, int psiz=
e)
>> >> +{
>> >> + unsigned int mask;
>> >> + int i, penc, shift;
>> >> + /* Look at the 8 bit LP value */
>> >> + unsigned int lp =3D (hptep->r >> LP_SHIFT) & ((1 << LP_BITS) - 1);
>> >> +
>> >> + penc =3D 0;
>> >> + for (i =3D 0; i < MMU_PAGE_COUNT; i++) {
>> >> + /* valid entries have a shift value */
>> >> + if (!mmu_psize_defs[i].shift)
>> >> + continue;
>> >> +
>> >> + /* encoding bits per actual page size */
>> >> + shift =3D mmu_psize_defs[i].shift - 11;
>> >> + if (shift > 9)
>> >> + shift =3D 9;
>> >> + mask =3D (1 << shift) - 1;
>> >> + if ((lp & mask) =3D=3D mmu_psize_defs[psize].penc[i])
>> >> + return i;
>> >> + }
>> >> + return -1;
>> >> +}
>> >
>> > This doesn't look right to me. First, it's not clear what the 11 and
>> > 9 refer to, and I think the 9 should be LP_BITS (i.e. 8). Secondly,
>> > the mask for the comparison needs to depend on the actual page size
>> > not the base page size.
>>=20
>> That 11 should be 12.That depends on the fact that we have below mapping
>
> And the 12 should be LP_SHIFT, shouldn't it?
LP_SHIFT would indicate how many bit poisition need to be shifted to get
to the LP field in HPTE. I guess what we want here is shift value for 4K
page. How about=20
shift =3D mmu_psize_defs[i].shift - mmu_psize_defs[MMU_PAGE_4K].shift;
>
>> rrrr rrrz =E2=89=A58KB
>>=20
>> Yes, that 9 should be LP_BITs.=20
>>=20
>> We are generating mask based on actual page size above (variable i in
>> the for loop).
>
> OK, yes, you're right.
>
>> > I don't see where in this function you set the penc[] elements for
>> > invalid actual page sizes to -1.
>>=20
>> We do the below
>>=20
>> --- a/arch/powerpc/mm/hash_utils_64.c
>> +++ b/arch/powerpc/mm/hash_utils_64.c
>> @@ -125,7 +125,7 @@ static struct mmu_psize_def mmu_psize_defaults_old[]=
=3D {
>> [MMU_PAGE_4K] =3D {
>> .shift =3D 12,
>> .sllp =3D 0,
>> - .penc =3D 0,
>> + .penc =3D { [0 ... MMU_PAGE_COUNT - 1] =3D -1 },
>> .avpnm =3D 0,
>
> Yes, which sets them for the entries you initialize, but not for the
> others. For example, the entry for MMU_PAGE_64K will initially be all
> zeroes. Then we find an entry in the ibm,segment-page-sizes property
> for 64k pages, so we set mmu_psize_defs[MMU_PAGE_64K].shift to 16,
> making that entry valid, but we never set any of the .penc[] entries
> to -1, leading your other code to think that it can do (say) 1M pages
> in a 64k segment using an encoding of 0.
>
Noticed that earlier. This is what i currently have.
+static void mmu_psize_set_default_penc(struct mmu_psize_def *mmu_psize)
+{
+ int bpsize, apsize;
+ for (bpsize =3D 0; bpsize < MMU_PAGE_COUNT; bpsize++)
+ for (apsize =3D 0; apsize < MMU_PAGE_COUNT; apsize++)
+ mmu_psize[bpsize].penc[apsize] =3D -1;
+}
+
static void __init htab_init_page_sizes(void)
{
int rc;
=20
+ mmu_psize_set_default_penc(mmu_psize_defaults_old);
+
/* Default to 4K pages only */
memcpy(mmu_psize_defs, mmu_psize_defaults_old,
sizeof(mmu_psize_defaults_old));
@@ -411,6 +443,8 @@ static void __init htab_init_page_sizes(void)
if (rc !=3D 0) /* Found */
goto found;
=20
+ mmu_psize_set_default_penc(mmu_psize_defaults_gp);
+
/*
* Not in the device-tree, let's fallback on known size
* list for 16M capable GP & GR
Modified arch/powerpc/mm/hugetlbpage-hash64.c
> Also, I noticed that the code in the if (base_idx < 0) statement is
> wrong. It needs to advance prop (and decrease size) by 2 * lpnum,
> not just 2.
>
Ok. Fixed now.
-aneesh
^ permalink raw reply
* Re: [PATCH -V1 07/24] powerpc: Add size argument to pgtable_cache_add
From: Aneesh Kumar K.V @ 2013-03-06 4:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20130305015041.GA2888@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Mon, Mar 04, 2013 at 04:32:24PM +0530, Aneesh Kumar K.V wrote:
>>
>> Now with table_size argument, the first arg is no more the shift value,
>> rather it is index into the array. Hence i changed the variable name. I
>> will split that patch to make it easy for review.
>
> OK, so you're saying that the simple relation between index and the
> size of the objects in PGT_CACHE(index) no longer holds. That worries
> me, because now, what guarantees that two callers won't use the same
> index value with two different sizes? And what guarantees that we
> won't have two callers using different index values but the same size
> (which wouldn't be a disaster but would be a waste of space)?
>
> I think it would be preferable to keep the relation between shift and
> the size of the objects and just arrange to use a different shift
> value for the pmd objects when you need to.
Most of the places we get the cache pointer by doing something like.
PGT_CACHE(PMD_INDEX_SIZE). What we need is that kmem_cache to return an
object twice the size of PMD_TABLE_SIZE. The relevant diff in the later
patch is below.
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ /*
+ * we store the pgtable details in the second half of PMD
+ */
+ if (PGT_CACHE(PMD_INDEX_SIZE))
+ pr_err("PMD Page cache already initialized with different size\n");
+ __pgtable_cache_add(PMD_INDEX_SIZE, PMD_TABLE_SIZE * 2, pmd_ctor);
+#else
pgtable_cache_add(PMD_INDEX_SIZE, pmd_ctor);
+#endif
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix next available MSI IRQ
From: Gavin Shan @ 2013-03-06 4:09 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <20130306032454.GA3493@concordia>
On Wed, Mar 06, 2013 at 02:24:54PM +1100, Michael Ellerman wrote:
>On Tue, Mar 05, 2013 at 02:59:16PM +0800, Gavin Shan wrote:
>> The allocation of MSI is implemented based on bitmap and working
>> like the mechanism of strict round through the traced next available
>> cursor. However, the next available MSI is never updated in current
>> implementation. The patch fixes the issue.
>>
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/pci.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index 6f464dc..9cf18c4 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -66,6 +66,11 @@ static unsigned int pnv_get_one_msi(struct pnv_phb *phb)
>> rc = 0;
>> goto out;
>> }
>> +
>> + if (id >= phb->msi_count - 1)
>> + phb->msi_next = 0;
>> + else
>> + phb->msi_next = id + 1;
>> __set_bit(id, phb->msi_map);
>
>
>There is code in arch/powerpc/sysdev/msi_bitmap.c that implements a
>bitmap allocator for MSI. It may not do what you need but please take a
>look at it if you haven't already.
>
Thanks, Michael. I neve know that you've implemented bitmaps to manage
MSI interrupts. It seems arch/powerpc/sysdev/msi_bitmap.c meets our
requirment here except that needs device tree node. Fortunately, we
can set the corresponding device tree node to NULL and functions playing
with the device tree nodes (of_node_get/of_node_put) works well for NULL
device tree node.
I'll update powernv platform to use msi_bitmap.c to manage it MSI interrupts.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH] ppc32: Fix compile of sha1-powerpc-asm.S
From: Michael Ellerman @ 2013-03-06 4:09 UTC (permalink / raw)
To: Christian Kujau; +Cc: LinuxPPC-dev
In-Reply-To: <alpine.DEB.2.10.1303041656010.22410@trent.utfs.org>
On Mon, Mar 04, 2013 at 05:23:14PM -0800, Christian Kujau wrote:
> On Tue, 26 Feb 2013 at 13:20, Tony Breeds wrote:
> > When building with CRYPTO_SHA1_PPC enabled we fail with:
> > ---
> > powerpc/crypto/sha1-powerpc-asm.S: Assembler messages:
> > powerpc/crypto/sha1-powerpc-asm.S:116: Error: can't resolve `0' {*ABS* section} - `STACKFRAMESIZE' {*UND* section}
> > powerpc/crypto/sha1-powerpc-asm.S:116: Error: expression too complex
> > powerpc/crypto/sha1-powerpc-asm.S:178: Error: unsupported relocation against STACKFRAMESIZE
> > ---
> >
> > Use INT_FRAME_SIZE instead.
> >
> > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> Thanks for the fix! Ran into this as well, with your patch 3.9-rc1
> compiles again (and it even boots :-))
>
> Tested-by: Christian Kujau <lists@nerdbynature.de>
>
> $ grep -A10 sha1 /proc/crypto
> name : sha1
> driver : sha1-powerpc
> module : kernel
> priority : 0
> refcnt : 1
> selftest : passed
> type : shash
> blocksize : 64
> digestsize : 20
Thanks Christian. What hardware are you on?
cheers
^ permalink raw reply
* Re: [PATCH -V1 06/24] powerpc: Reduce PTE table memory wastage
From: Aneesh Kumar K.V @ 2013-03-06 4:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20130305021219.GC2888@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Mon, Mar 04, 2013 at 04:28:42PM +0530, Aneesh Kumar K.V wrote:
>> Paul Mackerras <paulus@samba.org> writes:
>>
>> > The other general comment I have is that it's not really clear when a
>> > page will be on the mm->context.pgtable_list and when it won't. I
>> > would like to see an invariant that says something like "the page is
>> > on the pgtable_list if and only if (page->_mapcount & FRAG_MASK) is
>> > neither 0 nor FRAG_MASK". But that doesn't seem to be the case
>> > exactly, and I can't see any consistent rule, which makes me think
>> > there are going to be bugs in corner cases.
>> >
>>
>>
>> I added the below comment when initializing the list.
>>
>> +#ifdef CONFIG_PPC_64K_PAGES
>> + /*
>> + * Used to support 4K PTE fragment. The pages are added to list,
>> + * when we have free framents in the page. We track the whether
>> + * a page frament is available using page._mapcount. A value of
>> + * zero indicate none of the fragments are used and page can be
>> + * freed. A value of FRAG_MASK indicate all the fragments are used
>> + * and hence the page will be removed from the below list.
>> + */
>> + INIT_LIST_HEAD(&init_mm.context.pgtable_list);
>> +#endif
>>
>> I am not sure about why you say there is no consistent rule. Can you
>> elaborate on that ?
>
> Well, sometimes you take things off the list when mask == 0, and
> sometimes when (mask & FRAG_MASK) == 0. So it's not clear whether the
> page is supposed to be on the list when (mask & FRAG_MASK) == 0 but
> mask != 0. If you stated in a comment what the rule was supposed to
> be then reviewers could check whether your code implemented that rule.
> Also, if you had a consistent rule you could more easily add debug
> code to check that the rule was being followed.
I guess you are looking at this in page_table_free_rcu ?
+ mask = atomic_xor_bits(&page->_mapcount, bit | (bit << FRAG_MASK_BITS));
+ if (!(mask & FRAG_MASK))
+ list_del(&page->lru);
+ else {
We want to remove the page from list looking at the lower half bits. If
all the bits are cleared, that indicate nobody is using that page. But
then we may have pending rcu, which is indicated by higher half. So if
the lower half is 0 we can remove from the list. _mapcount is 0 we can
free the page.
Now if all the bits in the lower half is set then also we remove the
page from the list, because we don't have any free fragments in the
page.
>
> Also, that comment above doesn't say anything about the upper bits and
> whether they have any influence on whether the page should be on the
> list or not.
will add more to the comment.
>
>> > Consider, for example, the case where a page has two fragments still
>> > in use, and one of them gets queued up by RCU for freeing via a call
>> > to page_table_free_rcu, and then the other one gets freed through
>> > page_table_free(). Neither the call to page_table_free_rcu nor the
>> > call to page_table_free will take the page off the list AFAICS, and
>> > then __page_table_free_rcu() will free the page while it's still on
>> > the pgtable_list.
>>
>> The last one that ends up doing atomic_xor_bits which cause the mapcount
>> to go zero, will take the page off the list and free the page.
>
> No, look at the example again. page_table_free_rcu() won't take it
> off the list because it uses the (mask & FRAG_MASK) == 0 test, which
> fails (one fragment is still in use). page_table_free() won't take it
> off the list because it uses the mask == 0 test, which also fails (one
> fragment is still waiting for the RCU grace period). Finally,
> __page_table_free_rcu() doesn't take it off the list, it just frees
> the page. Oops. :)
Got it, I will see how we can fix that.
-aneesh
^ permalink raw reply
* Re: [PATCH -V1 06/24] powerpc: Reduce PTE table memory wastage
From: Aneesh Kumar K.V @ 2013-03-06 4:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, linux-mm
In-Reply-To: <1362440204.21357.20.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2013-03-04 at 16:28 +0530, Aneesh Kumar K.V wrote:
>> I added the below comment when initializing the list.
>>
>> +#ifdef CONFIG_PPC_64K_PAGES
>> + /*
>> + * Used to support 4K PTE fragment. The pages are added to list,
>> + * when we have free framents in the page. We track the whether
>> + * a page frament is available using page._mapcount. A value of
>> + * zero indicate none of the fragments are used and page can be
>> + * freed. A value of FRAG_MASK indicate all the fragments are used
>> + * and hence the page will be removed from the below list.
>> + */
>> + INIT_LIST_HEAD(&init_mm.context.pgtable_list);
>> +#endif
>>
>> I am not sure about why you say there is no consistent rule. Can you
>> elaborate on that ?
>
> Do you really need that list ? I assume it's meant to allow you to find
> free frags when allocating but my worry is that you'll end up losing
> quite a bit of node locality of PTE pages....
>
> It may or may not work but can you investigate doing things differently
> here ? The idea I want you to consider is to always allocate a full
> page, but make the relationship of the fragments to PTE pages fixed. IE.
> the fragment in the page is a function of the VA.
>
> Basically, the algorithm for allocation is roughly:
>
> - Walk the tree down to the PMD ptr (* that can be improved with a
> generic change, see below)
>
> - Check if any of the neighbouring PMDs is populated. If yes, you have
> your page and pick the appropriate fragment based on the VA
>
> - If not, allocate and populate
>
> On free, similarly, you checked if all neighbouring PMDs have been
> cleared, in which case you can fire off the page for RCU freeing.
>
> (*) By changing pte_alloc_one to take the PMD ptr (which the call side
> has right at hand) you can avoid the tree lookup.
>
Will try this.
-aneesh
^ permalink raw reply
* Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
From: Michael Ellerman @ 2013-03-06 3:54 UTC (permalink / raw)
To: Mike Qiu; +Cc: tglx, linuxppc-dev, linux-kernel
In-Reply-To: <51359C9D.5030009@linux.vnet.ibm.com>
On Tue, Mar 05, 2013 at 03:19:57PM +0800, Mike Qiu wrote:
> 于 2013/3/5 10:23, Michael Ellerman 写道:
> >On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
> >>Adding a function irq_create_mapping_many() which can associate
> >>multiple MSIs to a continous irq mapping.
> >>
> >>This is needed to enable multiple MSI support for pSeries.
> >>
> >>Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
> >>---
> >> include/linux/irq.h | 2 +
> >> include/linux/irqdomain.h | 3 ++
> >> kernel/irq/irqdomain.c | 61 +++++++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 66 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/include/linux/irq.h b/include/linux/irq.h
> >>index 60ef45b..e00a7ec 100644
> >>--- a/include/linux/irq.h
> >>+++ b/include/linux/irq.h
> >>@@ -592,6 +592,8 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
> >> #define irq_alloc_desc_from(from, node) \
> >> irq_alloc_descs(-1, from, 1, node)
> >>+#define irq_alloc_desc_n(nevc, node) \
> >>+ irq_alloc_descs(-1, 0, nevc, node)
> >This has been superseeded by irq_alloc_descs_from(), which is the right
> >way to do it.
> Yes, but irq_alloc_descs_from() just for 1 irq
No it's not, look again.
#define irq_alloc_descs_from(from, cnt, node) \
irq_alloc_descs(-1, from, cnt, node)
> >>diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> >>index 96f3a1d..38648e6 100644
> >>--- a/kernel/irq/irqdomain.c
> >>+++ b/kernel/irq/irqdomain.c
> >>@@ -636,6 +636,67 @@ int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
> >> }
> >> EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
> >>+/**
> >>+ * irq_create_mapping_many - Map a range of hw IRQs to a range of virtual IRQs
> >>+ * @domain: domain owning the interrupt range
> >>+ * @hwirq_base: beginning of continuous hardware IRQ range
> >>+ * @count: Number of interrupts to map
> >For multiple-MSI the allocated interrupt numbers must be a power-of-2,
> >and must be naturally aligned. I don't /think/ that's a requirement for
> >the virtual numbers, but it's probably best that we do it anyway.
> >
> >So this API needs to specify that it will give you back a power-of-2
> >block that is naturally aligned - otherwise you can't use it for MSI.
> rtas_call will return the numbers of hardware interrupt, and it
> should be power-of-2, as this I think do not need to specify
You're confusing hardware interrupt numbers and virtual interrupt
numbers. My comment is about irq_create_mapping_many(), which returns
virtual interrupt numbers.
As I said I don't think there is a requirement that the virtual
interrupt numbers are also a power-of-2 naturally aligned block, but we
should allocate them as one anyway, to avoid any issues in future.
And so this API, which returns virtual interrupt numbers, must satisfy
that specification.
> >>+ /* Look for default domain if nececssary */
> >>+ if (!domain)
> >>+ domain = irq_default_domain;
> >>+ if (!domain) {
> >>+ pr_warn("irq_create_mapping called for NULL domain, hwirq=%lx\n"
> >>+ , hwirq_base);
> >>+ WARN_ON(1);
> >>+ return 0;
> >>+ }
> >>+ pr_debug("-> using domain @%p\n", domain);
> >>+
> >>+ /* For IRQ_DOMAIN_MAP_LEGACY, get the first virtual interrupt number */
> >>+ if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> >>+ return irq_domain_legacy_revmap(domain, hwirq_base);
> >The above doesn't work.
> Why it doesn't work ?
Because irq_domain_legacy_revmap() only allocates a single interrupt
number.
> >>+ /* Check if mapping already exists */
> >>+ for (i = 0; i < count; i++) {
> >>+ virq = irq_find_mapping(domain, hwirq_base+i);
> >>+ if (virq) {
> >>+ pr_debug("existing mapping on virq %d,"
> >>+ " now dispose it first\n", virq);
> >>+ irq_dispose_mapping(virq);
> >You might have just disposed of someone elses mapping, we shouldn't do
> >that. It should be an error to the caller.
> It's a good question. If the interrupt used for someone elses, why I
> can apply it from the system?
I agree, that would be a bug. But disposing of someone elses mapping is
not OK.
> So it may someone else forget to dispose mapping, and it never be
> used for others as I have got the interrupt I think.
Perhaps, but that is a bug that needs to be fixed in the code that
forgets to dispose of the mapping.
cheers
^ permalink raw reply
* [PATCH 2/2] powerpc: Setup in HFSCR for POWER8
From: Michael Neuling @ 2013-03-06 3:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <1362540924-15253-1-git-send-email-mikey@neuling.org>
Setup the HFSCR (Hypervisor Facility Status and Control Register) for POWER8
when running HV=1. The HFSCR is the same as the FSCR except it's for
hypervisors. It controls the available of various facilities in OS and
userspace levels. It also indicates the cause of a hypervisor facility
unavailable interrupt (although we are not using this here).
This patch sets the facilities Linux knows about incase the firmware doesn't.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/cpu_setup_power.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index ea847ab..2e6ad11 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -57,6 +57,7 @@ _GLOBAL(__setup_cpu_power8)
mfspr r3,SPRN_LPCR
oris r3, r3, LPCR_AIL_3@h
bl __init_LPCR
+ bl __init_HFSCR
bl __init_TLB
mtlr r11
blr
@@ -72,6 +73,7 @@ _GLOBAL(__restore_cpu_power8)
mfspr r3,SPRN_LPCR
oris r3, r3, LPCR_AIL_3@h
bl __init_LPCR
+ bl __init_HFSCR
bl __init_TLB
mtlr r11
blr
@@ -120,6 +122,12 @@ __init_FSCR:
mtspr SPRN_FSCR,r3
blr
+__init_HFSCR:
+ mfspr r3,SPRN_HFSCR
+ ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP
+ mtspr SPRN_HFSCR,r3
+ blr
+
__init_TLB:
/* Clear the TLB */
li r6,128
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] powerpc: Add HFSCR SPR definitions
From: Michael Neuling @ 2013-03-06 3:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <1362540924-15253-1-git-send-email-mikey@neuling.org>
Add SPR number and bit definitions for the HFSCR (Hypervisor Facility Status
and Control Register).
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/reg.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c9c67fc..4ae2d44 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -268,6 +268,12 @@
#define SPRN_FSCR 0x099 /* Facility Status & Control Register */
#define FSCR_TAR (1 << (63-55)) /* Enable Target Address Register */
#define FSCR_DSCR (1 << (63-61)) /* Enable Data Stream Control Register */
+#define SPRN_HFSCR 0xbe /* HV=1 Facility Status & Control Register */
+#define HFSCR_TAR (1 << (63-55)) /* Enable Target Address Register */
+#define HFSCR_TM (1 << (63-58)) /* Enable Transactional Memory */
+#define HFSCR_DSCR (1 << (63-61)) /* Enable Data Stream Control Register */
+#define HFSCR_VECVSX (1 << (63-62)) /* Enable VMX/VSX */
+#define HFSCR_FP (1 << (63-63)) /* Enable Floating Point */
#define SPRN_TAR 0x32f /* Target Address Register */
#define SPRN_LPCR 0x13E /* LPAR Control Register */
#define LPCR_VPM0 (1ul << (63-0))
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] powerpc: HFSCR enablement for POWER8
From: Michael Neuling @ 2013-03-06 3:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
Benh,
This small series adds support for the HFSCR (Hypervisor Facility Status &
Control Register) in POWER8. It just sets the bits we know about at this
stage. This is useful only when MSR HV=1.
The HFSCR is the same as the FSCR except it's for hypervisors. It controls the
available of various facilities in OS and userspace levels. It also indicates
the cause of a hypervisor facility unavailable interrupt (although we are not
using this here).
v2:
Make description of the HFSCR more verbose as suggested by benh.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix next available MSI IRQ
From: Michael Ellerman @ 2013-03-06 3:24 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1362466756-16113-1-git-send-email-shangw@linux.vnet.ibm.com>
On Tue, Mar 05, 2013 at 02:59:16PM +0800, Gavin Shan wrote:
> The allocation of MSI is implemented based on bitmap and working
> like the mechanism of strict round through the traced next available
> cursor. However, the next available MSI is never updated in current
> implementation. The patch fixes the issue.
>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index 6f464dc..9cf18c4 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -66,6 +66,11 @@ static unsigned int pnv_get_one_msi(struct pnv_phb *phb)
> rc = 0;
> goto out;
> }
> +
> + if (id >= phb->msi_count - 1)
> + phb->msi_next = 0;
> + else
> + phb->msi_next = id + 1;
> __set_bit(id, phb->msi_map);
There is code in arch/powerpc/sysdev/msi_bitmap.c that implements a
bitmap allocator for MSI. It may not do what you need but please take a
look at it if you haven't already.
cheers
^ permalink raw reply
* Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
From: Roy Zang @ 2013-03-06 11:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1362525360-23136-5-git-send-email-galak@kernel.crashing.org>
On 03/06/2013 07:15 AM, Kumar Gala wrote:
> * Thread support on e6500
> * Proper PAMU topology information
> * DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
> * Prefetch Manager
> * Thermal monitor unit
> * Interlaken
>
> Signed-off-by: Roy Zang<tie-fei.zang@freescale.com>
> Signed-off-by: Minghuan Lian<Minghuan.Lian@freescale.com>
> Signed-off-by: Haiying Wang<Haiying.Wang@freescale.com>
> Signed-off-by: Andy Fleming<afleming@freescale.com>
> Signed-off-by: Prabhakar Kushwaha<prabhakar@freescale.com>
> Signed-off-by: York Sun<yorksun@freescale.com>
> Signed-off-by: Vakul Garg<vakul@freescale.com>
> Signed-off-by: Tang Yuantian<Yuantian.Tang@freescale.com>
> Signed-off-by: Zhao Chenhui<chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang<leoli@freescale.com>
> Signed-off-by: Ramneek Mehresh<ramneek.mehresh@freescale.com>
> Signed-off-by: Haiying Wang<Haiying.Wang@freescale.com>
Haiying is doubled.
Roy
^ permalink raw reply
* [PATCH 2/2] powerpc: Setup in HFSCR for POWER8
From: Michael Neuling @ 2013-03-06 2:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <1362536114-9658-1-git-send-email-mikey@neuling.org>
Setup the HFSCR (Hypervisor Facility Status and Control Register) for POWER8
when running HV=1. The HFSCR is the same as the FSCR except but for
hypervisors.
This patch sets the facilities Linux knows about incase the firmware doesn't.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/cpu_setup_power.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index ea847ab..2e6ad11 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -57,6 +57,7 @@ _GLOBAL(__setup_cpu_power8)
mfspr r3,SPRN_LPCR
oris r3, r3, LPCR_AIL_3@h
bl __init_LPCR
+ bl __init_HFSCR
bl __init_TLB
mtlr r11
blr
@@ -72,6 +73,7 @@ _GLOBAL(__restore_cpu_power8)
mfspr r3,SPRN_LPCR
oris r3, r3, LPCR_AIL_3@h
bl __init_LPCR
+ bl __init_HFSCR
bl __init_TLB
mtlr r11
blr
@@ -120,6 +122,12 @@ __init_FSCR:
mtspr SPRN_FSCR,r3
blr
+__init_HFSCR:
+ mfspr r3,SPRN_HFSCR
+ ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP
+ mtspr SPRN_HFSCR,r3
+ blr
+
__init_TLB:
/* Clear the TLB */
li r6,128
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] powerpc: Add HFSCR SPR definitions
From: Michael Neuling @ 2013-03-06 2:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <1362536114-9658-1-git-send-email-mikey@neuling.org>
Add SPR number and bit definitions for the HFSCR (Hypervisor Facility Status
and Control Register).
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/reg.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c9c67fc..4ae2d44 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -268,6 +268,12 @@
#define SPRN_FSCR 0x099 /* Facility Status & Control Register */
#define FSCR_TAR (1 << (63-55)) /* Enable Target Address Register */
#define FSCR_DSCR (1 << (63-61)) /* Enable Data Stream Control Register */
+#define SPRN_HFSCR 0xbe /* HV=1 Facility Status & Control Register */
+#define HFSCR_TAR (1 << (63-55)) /* Enable Target Address Register */
+#define HFSCR_TM (1 << (63-58)) /* Enable Transactional Memory */
+#define HFSCR_DSCR (1 << (63-61)) /* Enable Data Stream Control Register */
+#define HFSCR_VECVSX (1 << (63-62)) /* Enable VMX/VSX */
+#define HFSCR_FP (1 << (63-63)) /* Enable Floating Point */
#define SPRN_TAR 0x32f /* Target Address Register */
#define SPRN_LPCR 0x13E /* LPAR Control Register */
#define LPCR_VPM0 (1ul << (63-0))
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] powerpc: HFSCR enablement for POWER8
From: Michael Neuling @ 2013-03-06 2:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev
Benh,
This small series adds support for the HFSCR (Hypervisor Facility Status &
Control Register) in POWER8. It just sets the bits we know about at this
stage. This is useful only when MSR HV=1.
Mikey
^ permalink raw reply
* Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
From: Scott Wood @ 2013-03-06 0:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1362525360-23136-5-git-send-email-galak@kernel.crashing.org>
On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
> Enable a baseline T4240 SoC to boot. There are several things missing
> from the device trees for T4240:
>=20
> * Thread support on e6500
Why did threads get removed from the device tree? It's supposed to =20
describe hardware, not what Linux currently supports.
> * Proper PAMU topology information
> * DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
> * Prefetch Manager
> * Thermal monitor unit
> * Interlaken
The dts should be marked preliminary somehow -- we really should get =20
out of the habit of letting device nodes trickle in as drivers get =20
added.
> +/* controller at 0x240000 */
> +&pci0 {
> + compatible =3D "fsl,t4240-pcie", "fsl,qoriq-pcie-v3.0";
We have a version register -- do we really need to keep sticking the =20
version number in the compatible? Note that we've had device trees =20
that specified the version incorrectly in the past.
> + device_type =3D "pci";
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + bus-range =3D <0x0 0xff>;
> + clock-frequency =3D <33333333>;
This clock-frequency is not correct (I doubt it's needed at all).
> + PowerPC,e6500@1 {
> + device_type =3D "cpu";
> + reg =3D <2>;
> + next-level-cache =3D <&L2_1>;
> + };
> + PowerPC,e6500@2 {
> + device_type =3D "cpu";
> + reg =3D <4>;
> + next-level-cache =3D <&L2_1>;
> + };
> + PowerPC,e6500@3 {
> + device_type =3D "cpu";
> + reg =3D <6>;
> + next-level-cache =3D <&L2_1>;
> + };
> +
> + PowerPC,e6500@4 {
> + device_type =3D "cpu";
> + reg =3D <8>;
> + next-level-cache =3D <&L2_2>;
> + };
Inconsistent whitespace.
As usual, the pre/post split is unnecessary. Everything in it can go =20
in post.
-Scott=
^ permalink raw reply
* [PATCH 8/8] powerpc/85xx: Update corenet64_smp_defconfig for T4240
From: Kumar Gala @ 2013-03-05 23:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1362525360-23136-7-git-send-email-galak@kernel.crashing.org>
* Add support for up to 24 cores on T4240 (includes threads)
* Enable AltiVec support (on T4240)
* Add T4240QDS board into build
* Other changes are due to general kernel update of defconfig
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/configs/corenet64_smp_defconfig | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 3d139fa..c3da860 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -1,14 +1,13 @@
CONFIG_PPC64=y
CONFIG_PPC_BOOK3E_64=y
-# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
+CONFIG_ALTIVEC=y
CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_EXPERIMENTAL=y
+CONFIG_NR_CPUS=24
CONFIG_SYSVIPC=y
-CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
@@ -24,6 +23,7 @@ CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_P5020_DS=y
CONFIG_P5040_DS=y
+CONFIG_T4240_QDS=y
# CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
CONFIG_BINFMT_MISC=m
CONFIG_PCIEPORTBUS=y
@@ -140,6 +140,5 @@ CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
-CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DEV_FSL_CAAM=y
--
1.7.9.7
^ permalink raw reply related
* [PATCH 7/8] powerpc/fsl-booke: Add initial T4240QDS board support
From: Kumar Gala @ 2013-03-05 23:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1362525360-23136-6-git-send-email-galak@kernel.crashing.org>
Some minor changes to the common corenet_ds.c code are needed to support
the T4240QDS:
* Add support for "fsl,qoriq-pcie-v3.0" controller
* Bump max # of IRQs to 512 (T4240 supports more interrupts than
previous SoCs).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/Kconfig | 17 ++++++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_ds.c | 5 +-
arch/powerpc/platforms/85xx/t4240_qds.c | 98 ++++++++++++++++++++++++++++++
4 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index a0dcd57..31dc066 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -305,6 +305,23 @@ config PPC_QEMU_E500
unset based on the emulated CPU (or actual host CPU in the case
of KVM).
+if PPC64
+
+config T4240_QDS
+ bool "Freescale T4240 QDS"
+ select DEFAULT_UIMAGE
+ select E500
+ select PPC_E500MC
+ select PHYS_64BIT
+ select SWIOTLB
+ select ARCH_REQUIRE_GPIOLIB
+ select GPIO_MPC8XXX
+ select HAS_RAPIDIO
+ select PPC_EPAPR_HV_PIC
+ help
+ This option enables support for the T4240 QDS board
+
+endif
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 07d0dbb..712e233 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS) += p5020_ds.o corenet_ds.o
obj-$(CONFIG_P5040_DS) += p5040_ds.o corenet_ds.o
+obj-$(CONFIG_T4240_QDS) += t4240_qds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c b/arch/powerpc/platforms/85xx/corenet_ds.c
index 6f355d8..c59c617 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -40,7 +40,7 @@ void __init corenet_ds_pic_init(void)
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
- mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC ");
+ mpic = mpic_alloc(NULL, 0, flags, 0, 512, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
@@ -83,6 +83,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qoriq-pcie-v2.4",
},
+ {
+ .compatible = "fsl,qoriq-pcie-v3.0",
+ },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
diff --git a/arch/powerpc/platforms/85xx/t4240_qds.c b/arch/powerpc/platforms/85xx/t4240_qds.c
new file mode 100644
index 0000000..5998e9f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/t4240_qds.c
@@ -0,0 +1,98 @@
+/*
+ * T4240 QDS Setup
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/phy.h>
+
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include <asm/ehv_pic.h>
+
+#include "corenet_ds.h"
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init t4240_qds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
+
+ if (of_flat_dt_is_compatible(root, "fsl,T4240QDS"))
+ return 1;
+
+ /* Check if we're running under the Freescale hypervisor */
+ if (of_flat_dt_is_compatible(root, "fsl,T4240QDS-hv")) {
+ ppc_md.init_IRQ = ehv_pic_init;
+ ppc_md.get_irq = ehv_pic_get_irq;
+ ppc_md.restart = fsl_hv_restart;
+ ppc_md.power_off = fsl_hv_halt;
+ ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
+ return 1;
+ }
+
+ return 0;
+}
+
+define_machine(t4240_qds) {
+ .name = "T4240 QDS",
+ .probe = t4240_qds_probe,
+ .setup_arch = corenet_ds_setup_arch,
+ .init_IRQ = corenet_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
+#ifdef CONFIG_PPC64
+ .get_irq = mpic_get_irq,
+#else
+ .get_irq = mpic_get_coreint_irq,
+#endif
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+#ifdef CONFIG_PPC64
+ .power_save = book3e_idle,
+#else
+ .power_save = e500_idle,
+#endif
+};
+
+machine_arch_initcall(t4240_qds, corenet_ds_publish_devices);
+
+#ifdef CONFIG_SWIOTLB
+machine_arch_initcall(t4240_qds, swiotlb_setup_bus_notifier);
+#endif
--
1.7.9.7
^ permalink raw reply related
* [PATCH 6/8] powerpc/fsl-booke: Add initial T4240QDS board device
From: Kumar Gala @ 2013-03-05 23:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1362525360-23136-5-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/t4240qds.dts | 220 ++++++++++++++++++++++++++++++++++++
1 file changed, 220 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t4240qds.dts
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
new file mode 100644
index 0000000..83b479f
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -0,0 +1,220 @@
+/*
+ * T4240QDS Device Tree Source
+ *
+ * Copyright 2012 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.
+ */
+
+/include/ "fsl/t4240si-pre.dtsi"
+
+/ {
+ model = "fsl,T4240QDS";
+ compatible = "fsl,T4240QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x00100000>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg = <0x00100000 0x00100000>;
+ label = "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 10MB for Linux Kernel Image */
+ reg = <0x00200000 0x00A00000>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@C00000 {
+ /* 500MB for Root file System Image */
+ reg = <0x00c00000 0x1F400000>;
+ label = "NAND RFS Image";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,t4240qds-fpga", "fsl,fpga-qixis";
+ reg = <3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "sst,sst25wf040";
+ reg = <0>;
+ spi-max-frequency = <40000000>; /* input clock */
+ };
+ };
+
+ i2c@118000 {
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@52 {
+ compatible = "at24,24c256";
+ reg = <0x52>;
+ };
+ eeprom@53 {
+ compatible = "at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@54 {
+ compatible = "at24,24c256";
+ reg = <0x54>;
+ };
+ eeprom@55 {
+ compatible = "at24,24c256";
+ reg = <0x55>;
+ };
+ eeprom@56 {
+ compatible = "at24,24c256";
+ reg = <0x56>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ interrupts = <0x1 0x1 0 0>;
+ };
+ };
+ };
+
+ pci0: pcie@ffe240000 {
+ reg = <0xf 0xfe240000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg = <0xf 0xfe250000 0 0x10000>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg = <0xf 0xfe260000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg = <0xf 0xfe270000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x60000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+ rio: rapidio@ffe0c0000 {
+ reg = <0xf 0xfe0c0000 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x20000000 0 0x10000000>;
+ };
+ port2 {
+ ranges = <0 0 0xc 0x30000000 0 0x10000000>;
+ };
+ };
+};
+
+/include/ "fsl/t4240si-post.dtsi"
--
1.7.9.7
^ 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