* Re: 3.10-rc ppc64 corrupts usermem when swapping
From: Aneesh Kumar K.V @ 2013-05-30 16:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Hugh Dickins
Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras, David Gibson
In-Reply-To: <87vc60na89.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> Benjamin Herrenschmidt <benh@au1.ibm.com> writes:
>
>> On Wed, 2013-05-29 at 22:47 -0700, Hugh Dickins wrote:
>>> Running my favourite swapping load (repeated make -j20 kernel builds
>>> in tmpfs in parallel with repeated make -j20 kernel builds in ext4 on
>>> loop on tmpfs file, all limited by mem=700M and swap 1.5G) on 3.10-rc
>>> on PowerMac G5, the test dies with corrupted usermem after a few hours.
>>>
>>> Variously, segmentation fault or Binutils assertion fail or gcc Internal
>>> error in either or both builds: usually signs of swapping or TLB flushing
>>> gone wrong. Sometimes the tmpfs build breaks first, sometimes the ext4 on
>>> loop on tmpfs, so at least it looks unrelated to loop. No problem on x86.
>>>
>>> This is 64-bit kernel but 4k pages and old SuSE 11.1 32-bit userspace.
>>>
>>> I've just finished a manual bisection on arch/powerpc/mm (which might
>>> have been a wrong guess, but has paid off): the first bad commit is
>>> 7e74c3921ad9610c0b49f28b8fc69f7480505841
>>> "powerpc: Fix hpte_decode to use the correct decoding for page sizes".
>>
>> Ok, I have other reasons to think is wrong. I debugged a case last week
>> where after kexec we still had stale TLB entries, due to the TLB cleanup
>> not working.
>>
>> Thanks for doing that bisection ! I'll investigate ASAP (though it will
>> probably have to wait for tomorrow unless Paul beats me to it)
>>
>>> I don't know if it's actually swapping to swap that's triggering the
>>> problem, or a more general page reclaim or TLB flush problem. I hit
>>> it originally when trying to test Mel Gorman's pagevec series on top
>>> of 3.10-rc; and though I then reproduced it without that series, it
>>> did seem to take much longer: so I have been applying Mel's series to
>>> speed up each step of the bisection. But if I went back again, might
>>> find it was just chance that I hit it sooner with Mel's series than
>>> without. So, you're probably safe to ignore that detail, but I
>>> mention it just in case it turns out to have some relevance.
>>>
>>> Something else peculiar that I've been doing in these runs, may or may
>>> not be relevant: I've been running swapon and swapoff repeatedly in the
>>> background, so that we're doing swapoff even while busy building.
>>>
>>> I probably can't go into much more detail on the test (it's hard
>>> to get the balance right, to be swapping rather than OOMing or just
>>> running without reclaim), but can test any patches you'd like me to
>>> try (though it may take 24 hours for me to report back usefully).
>>
>> I think it's just failing to invalidate the TLB properly. At least one
>> bug I can spot just looking at it:
>>
>> static void native_hpte_invalidate(unsigned long slot, unsigned long vpn,
>> int psize, int ssize, int local)
>>
>> .../...
>>
>> native_lock_hpte(hptep);
>> hpte_v = hptep->v;
>>
>> actual_psize = hpte_actual_psize(hptep, psize);
>> if (actual_psize < 0) {
>> native_unlock_hpte(hptep);
>> local_irq_restore(flags);
>> return;
>> }
>>
>> That's wrong. We must still perform the TLB invalidation even if the
>> hash PTE is empty.
>>
>> In fact, Aneesh, this is a problem with MPSS for your THP work, I just
>> thought about it.
>>
>> The reason is that if a hash bucket gets full, we "evict" a more/less
>> random entry from it. When we do that we don't invalidate the TLB
>> (hpte_remove) because we assume the old translation is still technically
>> "valid".
>>
>
> Hmm that is correct, I missed that. But to do a tlb invalidate we need
> both base and actual page size. One of the reason i didn't update the
> hpte_invalidate callback to take both the page sizes was because, PAPR
> didn't need that for invalidate (H_REMOVE). hpte_remove did result in a
> tlb invalidate there.
>
>
>> However that means that an hpte_invalidate *must* invalidate the TLB
>> later on even if it's not hitting the right entry in the hash.
>>
>> However, I can see why that cannot work with THP/MPSS since you have no
>> way to know the page size from the PTE anymore....
>>
>> So my question is, apart from hpte_decode used by kexec, which I will
>> fix by just blowing the whole TLB when not running phyp, why do you need
>> the "actual" size in invalidate and updatepp ? You really can't rely on
>> the size passed by the upper layers ?
>
> So for upstream I have below which should address the
> above. Meanwhile I will see what the impact would be to do a tlb
> invalidate in hpte_remove, so that we can keep both lpar and native
> changes similar.
>
How about the below ?
commit 9f70fd8cfeb7fca33ef8453197b76df46c860b52
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Thu May 30 20:09:58 2013 +0530
powerpc/mm: Always invalidate tlb on hpte invalidate and update
If a hash bucket gets full, we "evict" a more/less random entry from it.
When we do that we don't invalidate the TLB (hpte_remove) because we assume
the old translation is still technically "valid". This implies that when
we are invalidating or updating pte, even if HPTE entry is not valid
we should do a tlb invalidate.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 92386fc..801e3c6 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -36,13 +36,13 @@ struct machdep_calls {
#ifdef CONFIG_PPC64
void (*hpte_invalidate)(unsigned long slot,
unsigned long vpn,
- int psize, int ssize,
- int local);
+ int bpsize, int apsize,
+ int ssize, int local);
long (*hpte_updatepp)(unsigned long slot,
unsigned long newpp,
unsigned long vpn,
- int psize, int ssize,
- int local);
+ int bpsize, int apsize,
+ int ssize, int local);
void (*hpte_updateboltedpp)(unsigned long newpp,
unsigned long ea,
int psize, int ssize);
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 3a9a1ac..176d3fd 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -34,7 +34,7 @@
void kvmppc_mmu_invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
{
ppc_md.hpte_invalidate(pte->slot, pte->host_vpn,
- MMU_PAGE_4K, MMU_SEGSIZE_256M,
+ MMU_PAGE_4K, MMU_PAGE_4K, MMU_SEGSIZE_256M,
false);
}
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index 0e980ac..d3cbda6 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -289,9 +289,10 @@ htab_modify_pte:
/* Call ppc_md.hpte_updatepp */
mr r5,r29 /* vpn */
- li r6,MMU_PAGE_4K /* page size */
- ld r7,STK_PARAM(R9)(r1) /* segment size */
- ld r8,STK_PARAM(R8)(r1) /* get "local" param */
+ li r6,MMU_PAGE_4K /* base page size */
+ li r7,MMU_PAGE_4K /* actual page size */
+ ld r8,STK_PARAM(R9)(r1) /* segment size */
+ ld r9,STK_PARAM(R8)(r1) /* get "local" param */
_GLOBAL(htab_call_hpte_updatepp)
bl . /* Patched by htab_finish_init() */
@@ -649,9 +650,10 @@ htab_modify_pte:
/* Call ppc_md.hpte_updatepp */
mr r5,r29 /* vpn */
- li r6,MMU_PAGE_4K /* page size */
- ld r7,STK_PARAM(R9)(r1) /* segment size */
- ld r8,STK_PARAM(R8)(r1) /* get "local" param */
+ li r6,MMU_PAGE_4K /* base page size */
+ li r7,MMU_PAGE_4K /* actual page size */
+ ld r8,STK_PARAM(R9)(r1) /* segment size */
+ ld r9,STK_PARAM(R8)(r1) /* get "local" param */
_GLOBAL(htab_call_hpte_updatepp)
bl . /* patched by htab_finish_init() */
@@ -937,9 +939,10 @@ ht64_modify_pte:
/* Call ppc_md.hpte_updatepp */
mr r5,r29 /* vpn */
- li r6,MMU_PAGE_64K
- ld r7,STK_PARAM(R9)(r1) /* segment size */
- ld r8,STK_PARAM(R8)(r1) /* get "local" param */
+ li r6,MMU_PAGE_64K /* base page size */
+ li r7,MMU_PAGE_64K /* actual page size */
+ ld r8,STK_PARAM(R9)(r1) /* segment size */
+ ld r9,STK_PARAM(R8)(r1) /* get "local" param */
_GLOBAL(ht64_call_hpte_updatepp)
bl . /* patched by htab_finish_init() */
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 6a2aead..121c8ef 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -273,61 +273,15 @@ static long native_hpte_remove(unsigned long hpte_group)
return i;
}
-static inline int __hpte_actual_psize(unsigned int lp, int psize)
-{
- int i, shift;
- unsigned int mask;
-
- /* start from 1 ignoring MMU_PAGE_4K */
- for (i = 1; i < MMU_PAGE_COUNT; i++) {
-
- /* invalid penc */
- if (mmu_psize_defs[psize].penc[i] == -1)
- continue;
- /*
- * encoding bits per actual page size
- * PTE LP actual page size
- * rrrr rrrz >=8KB
- * rrrr rrzz >=16KB
- * rrrr rzzz >=32KB
- * rrrr zzzz >=64KB
- * .......
- */
- shift = mmu_psize_defs[i].shift - LP_SHIFT;
- if (shift > LP_BITS)
- shift = LP_BITS;
- mask = (1 << shift) - 1;
- if ((lp & mask) == mmu_psize_defs[psize].penc[i])
- return i;
- }
- return -1;
-}
-
-static inline int hpte_actual_psize(struct hash_pte *hptep, int psize)
-{
- /* Look at the 8 bit LP value */
- unsigned int lp = (hptep->r >> LP_SHIFT) & ((1 << LP_BITS) - 1);
-
- if (!(hptep->v & HPTE_V_VALID))
- return -1;
-
- /* First check if it is large page */
- if (!(hptep->v & HPTE_V_LARGE))
- return MMU_PAGE_4K;
-
- return __hpte_actual_psize(lp, psize);
-}
-
static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
- unsigned long vpn, int psize, int ssize,
- int local)
+ unsigned long vpn, int bpsize,
+ int apsize, int ssize, int local)
{
struct hash_pte *hptep = htab_address + slot;
unsigned long hpte_v, want_v;
int ret = 0;
- int actual_psize;
- want_v = hpte_encode_avpn(vpn, psize, ssize);
+ want_v = hpte_encode_avpn(vpn, bpsize, ssize);
DBG_LOW(" update(vpn=%016lx, avpnv=%016lx, group=%lx, newpp=%lx)",
vpn, want_v & HPTE_V_AVPN, slot, newpp);
@@ -335,13 +289,14 @@ static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
native_lock_hpte(hptep);
hpte_v = hptep->v;
- actual_psize = hpte_actual_psize(hptep, psize);
- if (actual_psize < 0) {
- native_unlock_hpte(hptep);
- return -1;
- }
- /* Even if we miss, we need to invalidate the TLB */
- if (!HPTE_V_COMPARE(hpte_v, want_v)) {
+ /*
+ * We need to invalidate the TLB always because hpte_remove doesn't do
+ * a tlb invalidate. If a hash bucket gets full, we "evict" a more/less
+ * random entry from it. When we do that we don't invalidate the TLB
+ * (hpte_remove) because we assume the old translation is still technically
+ * "valid".
+ */
+ if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID)) {
DBG_LOW(" -> miss\n");
ret = -1;
} else {
@@ -353,7 +308,7 @@ static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
native_unlock_hpte(hptep);
/* Ensure it is out of the tlb too. */
- tlbie(vpn, psize, actual_psize, ssize, local);
+ tlbie(vpn, bpsize, apsize, ssize, local);
return ret;
}
@@ -394,7 +349,6 @@ static long native_hpte_find(unsigned long vpn, int psize, int ssize)
static void native_hpte_updateboltedpp(unsigned long newpp, unsigned long ea,
int psize, int ssize)
{
- int actual_psize;
unsigned long vpn;
unsigned long vsid;
long slot;
@@ -407,54 +361,82 @@ static void native_hpte_updateboltedpp(unsigned long newpp, unsigned long ea,
if (slot == -1)
panic("could not find page to bolt\n");
hptep = htab_address + slot;
- actual_psize = hpte_actual_psize(hptep, psize);
- if (actual_psize < 0)
- return;
/* Update the HPTE */
hptep->r = (hptep->r & ~(HPTE_R_PP | HPTE_R_N)) |
(newpp & (HPTE_R_PP | HPTE_R_N));
-
- /* Ensure it is out of the tlb too. */
- tlbie(vpn, psize, actual_psize, ssize, 0);
+ /*
+ * Ensure it is out of the tlb too. Bolted entries base and
+ * actual page size will be same.
+ */
+ tlbie(vpn, psize, psize, ssize, 0);
}
static void native_hpte_invalidate(unsigned long slot, unsigned long vpn,
- int psize, int ssize, int local)
+ int bpsize, int apsize, int ssize, int local)
{
struct hash_pte *hptep = htab_address + slot;
unsigned long hpte_v;
unsigned long want_v;
unsigned long flags;
- int actual_psize;
local_irq_save(flags);
DBG_LOW(" invalidate(vpn=%016lx, hash: %lx)\n", vpn, slot);
- want_v = hpte_encode_avpn(vpn, psize, ssize);
+ want_v = hpte_encode_avpn(vpn, bpsize, ssize);
native_lock_hpte(hptep);
hpte_v = hptep->v;
- actual_psize = hpte_actual_psize(hptep, psize);
- if (actual_psize < 0) {
- native_unlock_hpte(hptep);
- local_irq_restore(flags);
- return;
- }
- /* Even if we miss, we need to invalidate the TLB */
- if (!HPTE_V_COMPARE(hpte_v, want_v))
+ /*
+ * We need to invalidate the TLB always because hpte_remove doesn't do
+ * a tlb invalidate. If a hash bucket gets full, we "evict" a more/less
+ * random entry from it. When we do that we don't invalidate the TLB
+ * (hpte_remove) because we assume the old translation is still technically
+ * "valid".
+ */
+ if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID))
native_unlock_hpte(hptep);
else
/* Invalidate the hpte. NOTE: this also unlocks it */
hptep->v = 0;
/* Invalidate the TLB */
- tlbie(vpn, psize, actual_psize, ssize, local);
+ tlbie(vpn, bpsize, apsize, ssize, local);
local_irq_restore(flags);
}
+static inline int __hpte_actual_psize(unsigned int lp, int psize)
+{
+ int i, shift;
+ unsigned int mask;
+
+ /* start from 1 ignoring MMU_PAGE_4K */
+ for (i = 1; i < MMU_PAGE_COUNT; i++) {
+
+ /* invalid penc */
+ if (mmu_psize_defs[psize].penc[i] == -1)
+ continue;
+ /*
+ * encoding bits per actual page size
+ * PTE LP actual page size
+ * rrrr rrrz >=8KB
+ * rrrr rrzz >=16KB
+ * rrrr rzzz >=32KB
+ * rrrr zzzz >=64KB
+ * .......
+ */
+ shift = mmu_psize_defs[i].shift - LP_SHIFT;
+ if (shift > LP_BITS)
+ shift = LP_BITS;
+ mask = (1 << shift) - 1;
+ if ((lp & mask) == mmu_psize_defs[psize].penc[i])
+ return i;
+ }
+ return -1;
+}
+
static void hpte_decode(struct hash_pte *hpte, unsigned long slot,
int *psize, int *apsize, int *ssize, unsigned long *vpn)
{
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index e303a6d..2f47080 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1232,7 +1232,11 @@ void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize, int ssize,
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot += hidx & _PTEIDX_GROUP_IX;
DBG_LOW(" sub %ld: hash=%lx, hidx=%lx\n", index, slot, hidx);
- ppc_md.hpte_invalidate(slot, vpn, psize, ssize, local);
+ /*
+ * We use same base page size and actual psize, because we don't
+ * use these functions for hugepage
+ */
+ ppc_md.hpte_invalidate(slot, vpn, psize, psize, ssize, local);
} pte_iterate_hashed_end();
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
@@ -1365,7 +1369,8 @@ static void kernel_unmap_linear_page(unsigned long vaddr, unsigned long lmi)
hash = ~hash;
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot += hidx & _PTEIDX_GROUP_IX;
- ppc_md.hpte_invalidate(slot, vpn, mmu_linear_psize, mmu_kernel_ssize, 0);
+ ppc_md.hpte_invalidate(slot, vpn, mmu_linear_psize, mmu_linear_psize,
+ mmu_kernel_ssize, 0);
}
void kernel_map_pages(struct page *page, int numpages, int enable)
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
index 0f1d94a..0b7fb67 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -81,7 +81,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
slot += (old_pte & _PAGE_F_GIX) >> 12;
if (ppc_md.hpte_updatepp(slot, rflags, vpn, mmu_psize,
- ssize, local) == -1)
+ mmu_psize, ssize, local) == -1)
old_pte &= ~_PAGE_HPTEFLAGS;
}
diff --git a/arch/powerpc/platforms/cell/beat_htab.c b/arch/powerpc/platforms/cell/beat_htab.c
index 246e1d8..c34ee4e 100644
--- a/arch/powerpc/platforms/cell/beat_htab.c
+++ b/arch/powerpc/platforms/cell/beat_htab.c
@@ -185,7 +185,8 @@ static void beat_lpar_hptab_clear(void)
static long beat_lpar_hpte_updatepp(unsigned long slot,
unsigned long newpp,
unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long lpar_rc;
u64 dummy0, dummy1;
@@ -274,7 +275,8 @@ static void beat_lpar_hpte_updateboltedpp(unsigned long newpp,
}
static void beat_lpar_hpte_invalidate(unsigned long slot, unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long want_v;
unsigned long lpar_rc;
@@ -364,9 +366,10 @@ static long beat_lpar_hpte_insert_v3(unsigned long hpte_group,
* already zero. For now I am paranoid.
*/
static long beat_lpar_hpte_updatepp_v3(unsigned long slot,
- unsigned long newpp,
- unsigned long vpn,
- int psize, int ssize, int local)
+ unsigned long newpp,
+ unsigned long vpn,
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long lpar_rc;
unsigned long want_v;
@@ -394,7 +397,8 @@ static long beat_lpar_hpte_updatepp_v3(unsigned long slot,
}
static void beat_lpar_hpte_invalidate_v3(unsigned long slot, unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long want_v;
unsigned long lpar_rc;
diff --git a/arch/powerpc/platforms/ps3/htab.c b/arch/powerpc/platforms/ps3/htab.c
index 177a2f7..3e270e3 100644
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -109,7 +109,8 @@ static long ps3_hpte_remove(unsigned long hpte_group)
}
static long ps3_hpte_updatepp(unsigned long slot, unsigned long newpp,
- unsigned long vpn, int psize, int ssize, int local)
+ unsigned long vpn, int psize, int apsize,
+ int ssize, int local)
{
int result;
u64 hpte_v, want_v, hpte_rs;
@@ -162,7 +163,7 @@ static void ps3_hpte_updateboltedpp(unsigned long newpp, unsigned long ea,
}
static void ps3_hpte_invalidate(unsigned long slot, unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize, int ssize, int local)
{
unsigned long flags;
int result;
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 6d62072..ca45c8f 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -240,7 +240,8 @@ static void pSeries_lpar_hptab_clear(void)
static long pSeries_lpar_hpte_updatepp(unsigned long slot,
unsigned long newpp,
unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long lpar_rc;
unsigned long flags = (newpp & 7) | H_AVPN;
@@ -328,7 +329,8 @@ static void pSeries_lpar_hpte_updateboltedpp(unsigned long newpp,
}
static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long vpn,
- int psize, int ssize, int local)
+ int psize, int apsize,
+ int ssize, int local)
{
unsigned long want_v;
unsigned long lpar_rc;
@@ -356,8 +358,10 @@ static void pSeries_lpar_hpte_removebolted(unsigned long ea,
slot = pSeries_lpar_hpte_find(vpn, psize, ssize);
BUG_ON(slot == -1);
-
- pSeries_lpar_hpte_invalidate(slot, vpn, psize, ssize, 0);
+ /*
+ * lpar doesn't use the passed actual page size
+ */
+ pSeries_lpar_hpte_invalidate(slot, vpn, psize, 0, ssize, 0);
}
/* Flag bits for H_BULK_REMOVE */
@@ -400,8 +404,11 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot += hidx & _PTEIDX_GROUP_IX;
if (!firmware_has_feature(FW_FEATURE_BULK_REMOVE)) {
+ /*
+ * lpar doesn't use the passed actual page size
+ */
pSeries_lpar_hpte_invalidate(slot, vpn, psize,
- ssize, local);
+ 0, ssize, local);
} else {
param[pix] = HBR_REQUEST | HBR_AVPN | slot;
param[pix+1] = hpte_encode_avpn(vpn, psize,
^ permalink raw reply related
* Re: can't access PCIe card under sbc8548
From: Scott Wood @ 2013-05-30 16:24 UTC (permalink / raw)
To: wolfking; +Cc: linuxppc-dev
In-Reply-To: <1369918188379-71827.post@n7.nabble.com>
On 05/30/2013 07:49:48 AM, wolfking wrote:
> tiejun.chen wrote
> > On 05/30/2013 03:32 PM, wolfking wrote:
> >> (continued)
> >> I traced the 8139too.c when it uses pci_iomap, the pci_iomap =20
> called
> >> the
> >> ioport_map. The difference between 8139 and my PCIe card lies in =20
> the
> >> "port" value :
> >> void __iomem *ioport_map(unsigned long port, unsigned int len)
> >> {
> >> return (void __iomem *) (port + _IO_BASE);
> >
> > _IO_BASE is equal to isa_io_base. So if this is not zero, I think =20
> there's
> > a isa
> > bridge in your platform. So you can access these I/O ports based on =20
> that
> > isa
> > bridge/bus with ioreadx/iowritex.
> >
> > I tried ioread8/iowriet8 after ioremap, it doesn't work
> >
> >> }
> >> in 8139too.c, the "port" value is 0x1000; for my PCIe card, the =20
> "port"
> >> value
> >> is 0xfefff000. And the value is got from pci_resource_start. So =20
> you see,
> >> the
> >
> > But this means the port is as memory-mapped
Are you sure? It could mean that it's on a non-primary bus and I/O for =20
this bus is mapped at a lower address than the primary. Just because =20
the addition is wrapping around doesn't mean it's wrong.
> > so ioremap() should be workable in this case. Then out_bex/in_bex =20
> should be fine.
ioremap() and out_bex/in_bex are not appropriate for PCI I/O regions =20
(and presumably that's what it is, if pci_iomap is calling =20
ioport_map). Big-endian is not appropriate for PCI in any case.
The whole point of pci_iomap() appears to be that the driver doesn't =20
need to care whether it's MMIO or PIO, and can use ioread/writeX on the =20
resulting cookie. If PPC is messing this up it's not the driver's =20
fault.
-Scott=
^ permalink raw reply
* Re: can't access PCIe card under sbc8548
From: Scott Wood @ 2013-05-30 16:29 UTC (permalink / raw)
To: wolfking; +Cc: linuxppc-dev
In-Reply-To: <1369885321567-71775.post@n7.nabble.com>
On 05/29/2013 10:42:01 PM, wolfking wrote:
> hi, all
> I'm doing some developing on the windriver's sbc8548 board. The =20
> kernel I
> use
> is 3.6.10 and the u-boot version is 2012-10. I changed the board's
> configuration:
> the board now boot from the 64MB SODIMM Flash (not the default 8MB =20
> on-board
> Flash
> memory), and the PCI clock rate is changed to 33MHZ.
> Now the trouble I am in is that: the PCI card (a NIC card rtl8139) =20
> can be
> accessed OK, while the PCIe card can't work, that is, the kernel can't
> access
> its internal register. The kernel can correctly probe the PCIe card. =20
> its
> BAR0
> is a I/O mapped register, I use ioport_map to map the BAR0 to kernel's
> address
> space, then use ioread8/iowrite8 to access its internal register, it =20
> doesn't
> work.
In what specific way does it not work?
> I analyse the ioport_map function and find it just add the input =20
> parameter
> to
> a fixed _IO_BASE value, below is the function:
> void __iomem *ioport_map(unsigned long port, unsigned int len)
> {
> return (void __iomem *) (port + _IO_BASE);
> }
> the _IO_BASE value under sbc8548 is 0xfd7fd000, the value of =20
> ioport_map
> paramenter
> "port" is 0xfefff000. Obviously the add overflows, so the follow-up
> operations
> can't succeed.
Why can't it succeed? Is there nothing mapped at 0xfc7fc000?
> The value of "port" is got from the function
> pci_resource_start.
> So I guess the kernel allocate a bad address to this PCIe card. How =20
> can I
> fix this?
> I also plug this PCIe card into a freescale's board mpc8641-hpcn, =20
> try the
> same driver,
> I noticed ioport_map also meet overflow, but it does work fine.
So don't focus on the overflow, but rather on the actual breakage.
-Scott=
^ permalink raw reply
* Re: [PATCH 00/12] dma: various minor clean ups for slave drivers
From: Vinod Koul @ 2013-05-30 17:47 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Shawn Guo, Stephen Warren, linux-kernel, Zhang Wei, Dan Williams,
linux-tegra, linuxppc-dev
In-Reply-To: <1369656882-25241-1-git-send-email-andriy.shevchenko@linux.intel.com>
On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote:
> Here is a set of small independent patches that clean up or fix minor things
> across DMA slave drivers.
The series looks fine. I am going to wait a day more and apply, pls speak up if
you disagree and ack if you agree
--
~Vinod
>
> Andy Shevchenko (12):
> imx-sdma: remove useless variable
> mxs-dma: remove useless variable
> edma: no need to assign residue to 0 explicitly
> ep93xx_dma: remove useless use of lock
> fsldma: remove useless use of lock
> mmp_pdma: remove useless use of lock
> mpc512x_dma: remove useless use of lock
> pch_dma: remove useless use of lock
> tegra20-apb-dma: remove useless use of lock
> ipu_idmac: re-use dma_cookie_status()
> mmp_tdma: set cookies as well when asked for tx status
> txx9dmac: return DMA_SUCCESS immediately from device_tx_status()
>
> drivers/dma/edma.c | 2 --
> drivers/dma/ep93xx_dma.c | 10 +---------
> drivers/dma/fsldma.c | 10 +---------
> drivers/dma/imx-sdma.c | 9 +++------
> drivers/dma/ipu/ipu_idmac.c | 5 +----
> drivers/dma/mmp_pdma.c | 10 +---------
> drivers/dma/mmp_tdma.c | 3 ++-
> drivers/dma/mpc512x_dma.c | 10 +---------
> drivers/dma/mxs-dma.c | 4 +---
> drivers/dma/pch_dma.c | 9 +--------
> drivers/dma/tegra20-apb-dma.c | 8 +++-----
> drivers/dma/txx9dmac.c | 13 ++++++-------
> 12 files changed, 21 insertions(+), 72 deletions(-)
>
> --
> 1.8.2.rc0.22.gb3600c3
>
--
^ permalink raw reply
* Re: [PATCH 00/12] dma: various minor clean ups for slave drivers
From: Andy Shevchenko @ 2013-05-30 18:32 UTC (permalink / raw)
To: Vinod Koul
Cc: Shawn Guo, Stephen Warren, linux-kernel@vger.kernel.org,
Andy Shevchenko, Zhang Wei, Dan Williams, linux-tegra,
linuxppc-dev
In-Reply-To: <20130530174727.GE3767@intel.com>
On Thu, May 30, 2013 at 8:47 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote:
>> Here is a set of small independent patches that clean up or fix minor things
>> across DMA slave drivers.
> The series looks fine. I am going to wait a day more and apply, pls speak up if
> you disagree and ack if you agree
I'm not in hurry with it. Please, take your time and do whatever it requires.
Thank you!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
From: Scott Wood @ 2013-05-30 18:54 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130530102034.GB18702@pek-khao-d1.corp.ad.wrs.com>
On 05/30/2013 05:20:34 AM, Kevin Hao wrote:
> On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
> > On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
> > >It also seems that we don't support ISA on all the current corenet =20
> ds
> > >boards. So picking a primary bus seems useless, remove that =20
> function
> > >too.
> >
> > IIRC that was due to some bugs in the PPC PCI code in the absence of
> > any primary bus.
>=20
> Do you know more about these bugs?
Not off the top of my head -- either search the archives or ask Ben.
> > fsl_pci_assign_primary() will arbitrarily pick one
> > to be primary if there's no ISA. Have the bugs been fixed?
>=20
> I know there should be some reason that we put the =20
> fsl_pci_assign_primary()
> here. But frankly I am not sure what bugs this workaround try to fix. =20
> For these
> corenet boards picking one to be primary has no effect to the 64bit =20
> kernel.
> And for 32bit kernel, the only effect of this is that isa_io_base is =20
> set to the
> io virtual base of the primary bus. But the isa_io_base only make =20
> sense when
> we do have a isa bus, so that we can access some well-known io ports =20
> directly
> by using outx/inx. But if we don't have isa bus on the board, the =20
> value of
> isa_io_base should make no sense at all. So we really don't need to =20
> pick a
> fake primary bus. Of course I may miss something, correct me if I am =20
> wrong. :-)
outx/inx can also be used for PCI I/O BARs.
-Scott=
^ permalink raw reply
* Re: [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
From: Scott Wood @ 2013-05-30 18:57 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130530032525.GA18702@pek-khao-d1.corp.ad.wrs.com>
On 05/29/2013 10:25:25 PM, Kevin Hao wrote:
> On Tue, May 28, 2013 at 05:45:56PM -0500, Scott Wood wrote:
> > On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
> > >All these boards use the same configuration file p1_p2_rdb_pc.h in
> > >u-boot. So they have the same pci bus address set by the u-boot.
> > >But in some of these boards the bus address set in dtb don't match
> > >the one used by u-boot. And this will trigger a kernel bug in 32bit
> > >kernel and cause the pci device malfunction. For example, on a
> > >p2020rdb-pc board the u-boot use the 0xa0000000 as both bus address
> > >and cpu address for one pci controller and then assign bus address
> > >such as 0xa00004000 to some pci device. But in the kernel, the dtb
> > >set the bus address to 0xe0000000 and the cpu address to =20
> 0xa0000000.
> > >The kernel assumes mistakenly the assigned bus address 0xa0004000
> > >in pci device is correct and keep it unchanged. This will =20
> definitely
> > >cause the pci device malfunction. I have made two patches to fix
> > >this in the pci subsystem.
> > >http://patchwork.ozlabs.org/patch/243702/
> > >http://patchwork.ozlabs.org/patch/243703/
> > >
> > >But I still think it makes sense to set these bus address to match
> > >with the u-boot. This issue can't be reproduced on 36bit kernel.
> > >But I also tweak the 36bit dtb for the above reason.
> >
> > IIRC the reason for using 0xe0000000 on all PCIe roots is to
> > maximize the memory that is DMA-addressable without involving
> > swiotlb.
>=20
> OK, this sounds reasonable. I can drop the changes for the 36bit dts. =20
> But for
> the 32bit dts, it does cause the kernel hang on my p2020rdb-pca board =20
> when the
> SiI3132 driver probe the on-board pcie to sata controller. I think =20
> this issue
> should apply to all these boards if it has a pci device plugged. So =20
> we should
> fix them ASAP.
Is this what your 3.11 patch fixes, or does it hang even with that?
> > Maybe U-Boot should be fixed?
>=20
> Maybe. I have created patch for kernel to detect this kind of =20
> mismatch between
> kernel and bootloader and then try to reassign the bus address =20
> automatically.
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=3D=
next&id=3Dcf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855
>=20
> So with this patch the kernel should just work even without this =20
> patch and
> the fix for u-boot. But this patch is just queued for 3.11. So I wish =20
> we can
> tweak the 32bit dts to accommodate to the u-boot now so that we can =20
> make sure
> that these boards are at least bootable for 3.10 or previous kernel. =20
> Then we
> can revert this patch for more DMA address space once the pci patch =20
> are
> merged into mainline.
Is this a regression, or has it been broken for a while?
-Scott=
^ permalink raw reply
* Re: [PATCH] clk/mpc85xx: Update the compatible string
From: Mike Turquette @ 2013-05-30 18:57 UTC (permalink / raw)
To: Yuantian.Tang; +Cc: Tang Yuantian, devicetree-discuss, linuxppc-dev
In-Reply-To: <1369210939-25087-1-git-send-email-Yuantian.Tang@freescale.com>
Quoting Yuantian.Tang@freescale.com (2013-05-22 01:22:19)
> From: Tang Yuantian <yuantian.tang@freescale.com>
> =
> The compatible string of clock is changed from *-2 to *-2.0
> on chassis 2. So updated it accordingly.
> =
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Taken into clk-next.
Regards,
Mike
> ---
> drivers/clk/clk-ppc-corenet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> =
> diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
> index a2d483f..e958707 100644
> --- a/drivers/clk/clk-ppc-corenet.c
> +++ b/drivers/clk/clk-ppc-corenet.c
> @@ -260,7 +260,7 @@ static int __init ppc_corenet_clk_probe(struct platfo=
rm_device *pdev)
> =
> static const struct of_device_id ppc_clk_ids[] __initconst =3D {
> { .compatible =3D "fsl,qoriq-clockgen-1.0", },
> - { .compatible =3D "fsl,qoriq-clockgen-2", },
> + { .compatible =3D "fsl,qoriq-clockgen-2.0", },
> {}
> };
> =
> -- =
> 1.8.0
^ permalink raw reply
* Re: [PATCH] clk/mpc85xx: Update the compatible string
From: Mike Turquette @ 2013-05-30 19:21 UTC (permalink / raw)
To: Mike Turquette, Yuantian.Tang
Cc: Tang Yuantian, devicetree-discuss, linuxppc-dev
In-Reply-To: <20130530185732.4470.91176@quantum>
Quoting Mike Turquette (2013-05-30 11:57:32)
> Quoting Yuantian.Tang@freescale.com (2013-05-22 01:22:19)
> > From: Tang Yuantian <yuantian.tang@freescale.com>
> > =
> > The compatible string of clock is changed from *-2 to *-2.0
> > on chassis 2. So updated it accordingly.
> > =
> > Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> =
> Taken into clk-next.
> =
One small nitpick. I updated the $SUBJECT to:
clk: mpc85xx: Update the compatible string
The difference being "clk: mpc85xx:" versus "clk/mpc85xx:". Please use
the former format in the future.
Thanks,
Mike
> Regards,
> Mike
> =
> > ---
> > drivers/clk/clk-ppc-corenet.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > =
> > diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corene=
t.c
> > index a2d483f..e958707 100644
> > --- a/drivers/clk/clk-ppc-corenet.c
> > +++ b/drivers/clk/clk-ppc-corenet.c
> > @@ -260,7 +260,7 @@ static int __init ppc_corenet_clk_probe(struct plat=
form_device *pdev)
> > =
> > static const struct of_device_id ppc_clk_ids[] __initconst =3D {
> > { .compatible =3D "fsl,qoriq-clockgen-1.0", },
> > - { .compatible =3D "fsl,qoriq-clockgen-2", },
> > + { .compatible =3D "fsl,qoriq-clockgen-2.0", },
> > {}
> > };
> > =
> > -- =
> > 1.8.0
^ permalink raw reply
* Re: [PATCH] clk/mpc85xx: Update the compatible string
From: Kumar Gala @ 2013-05-30 19:26 UTC (permalink / raw)
To: Mike Turquette; +Cc: Yuantian.Tang, devicetree-discuss, linuxppc-dev
In-Reply-To: <20130530192143.4470.23214@quantum>
On May 30, 2013, at 2:21 PM, Mike Turquette wrote:
> Quoting Mike Turquette (2013-05-30 11:57:32)
>> Quoting Yuantian.Tang@freescale.com (2013-05-22 01:22:19)
>>> From: Tang Yuantian <yuantian.tang@freescale.com>
>>>=20
>>> The compatible string of clock is changed from *-2 to *-2.0
>>> on chassis 2. So updated it accordingly.
>>>=20
>>> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
>>=20
>> Taken into clk-next.
>>=20
>=20
> One small nitpick. I updated the $SUBJECT to:
>=20
> clk: mpc85xx: Update the compatible string
>=20
> The difference being "clk: mpc85xx:" versus "clk/mpc85xx:". Please =
use
> the former format in the future.
>=20
> Thanks,
> Mike
Mike,
If clk-ppc-corenet.c went into v3.10, than I think this fix is needed =
there and shouldn't wait til v3.11
- k=
^ permalink raw reply
* Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files
From: Jason Cooper @ 2013-05-30 19:37 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Thomas Petazzoni, Andrew Lunn, linux-kernel, linux-arm-kernel,
netdev, linuxppc-dev, David Miller, Lennert Buytenhek,
Sebastian Hesselbarth
In-Reply-To: <8738t4q1kv.fsf@natisbad.org>
On Thu, May 30, 2013 at 11:06:08AM +0200, Arnaud Ebalard wrote:
> Hi Jason and Sebastian,
>
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> writes:
>
> > With DT support for mv643xx_eth board specific init for some boards now
> > is unneccessary. Remove those board files, Kconfig entries, and
> > corresponding entries in kirkwood_defconfig.
> >
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> > ---
> > Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
> > the lock-up is not caused by accessing clock gating registers but rather
> > non-existent device registers. This will be addressed by dtsi separation
> > for kirkwood and bobcat SoC variants.
> >
> > Changelog:
> > v3->v4:
> > - remove more boards that don't require board specific setup
> >
> > Cc: David Miller <davem@davemloft.net>
> > Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: netdev@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > arch/arm/configs/kirkwood_defconfig | 16 ----
> > arch/arm/mach-kirkwood/Kconfig | 117 -------------------------
> > arch/arm/mach-kirkwood/Makefile | 16 ----
> > arch/arm/mach-kirkwood/board-dnskw.c | 7 --
> > arch/arm/mach-kirkwood/board-dockstar.c | 32 -------
> > arch/arm/mach-kirkwood/board-dreamplug.c | 35 --------
> > arch/arm/mach-kirkwood/board-dt.c | 62 +------------
> > arch/arm/mach-kirkwood/board-goflexnet.c | 34 -------
> > arch/arm/mach-kirkwood/board-guruplug.c | 33 -------
> > arch/arm/mach-kirkwood/board-ib62x0.c | 29 ------
> > arch/arm/mach-kirkwood/board-iconnect.c | 10 ---
> > arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 34 -------
> > arch/arm/mach-kirkwood/board-km_kirkwood.c | 44 ----------
> > arch/arm/mach-kirkwood/board-lsxl.c | 16 ----
> > arch/arm/mach-kirkwood/board-mplcec4.c | 14 ---
> > arch/arm/mach-kirkwood/board-ns2.c | 35 --------
> > arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 ------
> > arch/arm/mach-kirkwood/board-readynas.c | 6 --
>
> Just a stupid note: With Thomas ongoing work to get mvebu-pcie driver in
> place and enabled for kirkwood, some boards setup files will also lose
> their pcie init routines, which may allow you to kill those additonal
> files soon.
Yes, we're very excited about this ;-)
> For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
> PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
> the PCIE init routine in board-readynas.c, and yours remove ge00
> init. With both applied, the whole file can go away.
>
> AFAICT, this may be the case soon for:
>
> arch/arm/mach-kirkwood/board-iconnect.c (36e5722089)
> arch/arm/mach-kirkwood/board-mplcec4.c (9470fbfb8d)
> arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
> arch/arm/mach-kirkwood/board-readynas.c (6bd98481ab)
> arch/arm/mach-kirkwood/board-ts219.c (259e234608)
Would you mind putting a patch together (for after v3.10 drops) to do
this? If you applied Sebastian's series on top of mvebu/pcie_kirkwood,
that should get you almost there. The last half of his series is going
in after v3.10...
You may want to try merging in mvebu/boards and mvebu/soc. Those have
the changes to use dt for the restart and power-off drivers. That'll
allow us to empty out a few more board files. mvebu/dt also has a patch
from Valentin allowing us to remove the keymile board as well.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH] clk/mpc85xx: Update the compatible string
From: Mike Turquette @ 2013-05-30 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Yuantian.Tang, devicetree-discuss, linuxppc-dev
In-Reply-To: <17C23704-7017-427C-A00F-CEFA6247D65D@kernel.crashing.org>
Quoting Kumar Gala (2013-05-30 12:26:38)
> On May 30, 2013, at 2:21 PM, Mike Turquette wrote:
> =
> > Quoting Mike Turquette (2013-05-30 11:57:32)
> >> Quoting Yuantian.Tang@freescale.com (2013-05-22 01:22:19)
> >>> From: Tang Yuantian <yuantian.tang@freescale.com>
> >>> =
> >>> The compatible string of clock is changed from *-2 to *-2.0
> >>> on chassis 2. So updated it accordingly.
> >>> =
> >>> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> >> =
> >> Taken into clk-next.
> >> =
> > =
> > One small nitpick. I updated the $SUBJECT to:
> > =
> > clk: mpc85xx: Update the compatible string
> > =
> > The difference being "clk: mpc85xx:" versus "clk/mpc85xx:". Please use
> > the former format in the future.
> > =
> > Thanks,
> > Mike
> =
> Mike,
> =
> If clk-ppc-corenet.c went into v3.10, than I think this fix is needed the=
re and shouldn't wait til v3.11
> =
clk-ppc-corenet.c is first introduced in the current clk-next branch.
It is not merged into Linus' tree yet.
Regards,
Mike
> - k
^ permalink raw reply
* Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files
From: Arnaud Ebalard @ 2013-05-30 22:28 UTC (permalink / raw)
To: Jason Cooper
Cc: Thomas Petazzoni, Andrew Lunn, netdev, linux-kernel,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20130530193708.GC31290@titan.lakedaemon.net>
Hi,
Jason Cooper <jason@lakedaemon.net> writes:
>> For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
>> PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
>> the PCIE init routine in board-readynas.c, and yours remove ge00
>> init. With both applied, the whole file can go away.
>>
>> AFAICT, this may be the case soon for:
>>
>> arch/arm/mach-kirkwood/board-iconnect.c (36e5722089)
>> arch/arm/mach-kirkwood/board-mplcec4.c (9470fbfb8d)
>> arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
>> arch/arm/mach-kirkwood/board-readynas.c (6bd98481ab)
>> arch/arm/mach-kirkwood/board-ts219.c (259e234608)
>
> Would you mind putting a patch together (for after v3.10 drops) to do
> this? If you applied Sebastian's series on top of mvebu/pcie_kirkwood,
> that should get you almost there. The last half of his series is going
> in after v3.10...
Something like the quick quilt-generated patch at the end of this email
(done after a dummy merge of Sebastian's set in mvebu/pcie_kirkwood)? I
will take a look at what remains after Sebastian's set hit one of your
branch but I guess he will have included most of what is in the patch to
help you with the merge.
Anyway, at the end here is what DT board files would remain:
$ ls -1 arch/arm/mach-kirkwood/board-*.c
arch/arm/mach-kirkwood/board-dnskw.c
arch/arm/mach-kirkwood/board-dt.c
arch/arm/mach-kirkwood/board-lsxl.c
arch/arm/mach-kirkwood/board-ts219.c
Just one question though: the removal of MACH_*_DT in Kconfig removes
the automatic selection of useful board specific options like
ARM_APPENDED_DTB, ARM_ATAG_DTB_COMPAT, POWER_RESET_RESTART,
POWER_RESET_QNAP. Is that expected?
> You may want to try merging in mvebu/boards and mvebu/soc. Those have
> the changes to use dt for the restart and power-off drivers. That'll
> allow us to empty out a few more board files. mvebu/dt also has a patch
> from Valentin allowing us to remove the keymile board as well.
yes. After a merge w/ mvebu/boards to get restart and poweroff would
allow to get rid of board-ts219.c and board-lsxl.c, leaving mainly
board-dnskw.c.
Cheers,
a+
Index: linux/arch/arm/mach-kirkwood/board-iconnect.c
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/board-iconnect.c 2013-05-30 23:38:53.652311676 +0200
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,15 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iconnect.c
- *
- * Iomega i-connect Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include "common.h"
-
Index: linux/arch/arm/mach-kirkwood/Makefile
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/Makefile 2013-05-30 23:38:53.652311676 +0200
+++ linux/arch/arm/mach-kirkwood/Makefile 2013-05-30 23:38:53.644311636 +0200
@@ -19,9 +19,6 @@
obj-$(CONFIG_MACH_TS41X) += ts41x-setup.o tsx1x-common.o
obj-$(CONFIG_ARCH_KIRKWOOD_DT) += board-dt.o
-obj-$(CONFIG_MACH_DB88F628X_BP_DT) += board-db88f628x-bp.o
obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
-obj-$(CONFIG_MACH_MPLCEC4_DT) += board-mplcec4.o
-obj-$(CONFIG_MACH_READYNAS_DT) += board-readynas.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
Index: linux/arch/arm/mach-kirkwood/board-db88f628x-bp.c
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/board-db88f628x-bp.c 2013-05-30 23:38:53.652311676 +0200
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,24 +0,0 @@
-/*
- * Saeed Bishara <saeed@marvell.com>
- *
- * Marvell DB-88F628{1,2}-BP Development Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data db88f628x_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init db88f628x_init(void)
-{
- kirkwood_ge00_init(&db88f628x_ge00_data);
-}
Index: linux/arch/arm/mach-kirkwood/board-mplcec4.c
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/board-mplcec4.c 2013-05-30 23:38:53.652311676 +0200
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,21 +0,0 @@
-/*
- * Copyright (C) 2012 MPL AG, Switzerland
- * Stefan Peter <s.peter@mpl.ch>
- *
- * arch/arm/mach-kirkwood/board-mplcec4.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include "common.h"
-
-void __init mplcec4_init(void)
-{
-}
-
-
-
Index: linux/arch/arm/mach-kirkwood/board-readynas.c
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/board-readynas.c 2013-05-30 23:38:53.652311676 +0200
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,21 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD <arno@natisbad.org>
- *
- * 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/init.h>
-#include <linux/platform_device.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-void __init netgear_readynas_init(void)
-{
-}
Index: linux/arch/arm/mach-kirkwood/common.h
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/common.h 2013-05-30 23:38:53.652311676 +0200
+++ linux/arch/arm/mach-kirkwood/common.h 2013-05-30 23:38:53.648311656 +0200
@@ -55,16 +55,6 @@
void kirkwood_clk_init(void);
/* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
#ifdef CONFIG_MACH_TS219_DT
void qnap_dt_ts219_init(void);
#else
@@ -77,94 +67,12 @@
static inline void dnskw_init(void) {};
#endif
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
#ifdef CONFIG_MACH_LSXL_DT
void lsxl_init(void);
#else
static inline void lsxl_init(void) {};
#endif
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
Index: linux/arch/arm/mach-kirkwood/Kconfig
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/Kconfig 2013-05-30 23:38:53.652311676 +0200
+++ linux/arch/arm/mach-kirkwood/Kconfig 2013-05-30 23:38:53.648311656 +0200
@@ -140,13 +140,6 @@
Say 'Y' here if you want your kernel to support the
Marvell Kirkwood using flattened device tree.
-config MACH_DB88F628X_BP_DT
- bool "Marvell DB-88F628x-BP Development Board (Flattened Device Tree)"
- help
- Say 'Y' here if you want your kernel to support the Marvell
- DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
- Device Tree).
-
config MACH_DLINK_KIRKWOOD_DT
bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
select ARCH_KIRKWOOD_DT
@@ -163,22 +156,6 @@
Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
Flattened Device Tree.
-config MACH_MPLCEC4_DT
- bool "MPL CEC4 (Flattened Device Tree)"
- select ARCH_KIRKWOOD_DT
- help
- Say 'Y' here if you want your kernel to support the
- MPL CEC4 (Flattened Device Tree).
-
-config MACH_READYNAS_DT
- bool "NETGEAR ReadyNAS Duo v2 (Flattened Device Tree)"
- select ARCH_KIRKWOOD_DT
- select ARM_APPENDED_DTB
- select ARM_ATAG_DTB_COMPAT
- help
- Say 'Y' here if you want your kernel to support the
- NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
-
config MACH_TS219_DT
bool "Device Tree for QNAP TS-11X, TS-21X NAS"
select ARCH_KIRKWOOD_DT
Index: linux/arch/arm/configs/kirkwood_defconfig
===================================================================
--- linux.orig/arch/arm/configs/kirkwood_defconfig 2013-05-30 23:38:53.596311398 +0200
+++ linux/arch/arm/configs/kirkwood_defconfig 2013-05-30 23:41:42.293147920 +0200
@@ -32,9 +32,6 @@
CONFIG_MACH_TS41X=y
CONFIG_MACH_DLINK_KIRKWOOD_DT=y
CONFIG_MACH_LSXL_DT=y
-CONFIG_MACH_MPLCEC4_DT=y
-CONFIG_MACH_NSA310_DT=y
-CONFIG_MACH_READYNAS_DT=y
CONFIG_MACH_TS219_DT=y
# CONFIG_CPU_FEROCEON_OLD_ID is not set
CONFIG_PREEMPT=y
Index: linux/arch/arm/mach-kirkwood/board-dt.c
===================================================================
--- linux.orig/arch/arm/mach-kirkwood/board-dt.c 2013-05-30 23:38:53.616311497 +0200
+++ linux/arch/arm/mach-kirkwood/board-dt.c 2013-05-30 23:45:41.782335483 +0200
@@ -113,16 +113,6 @@
if (of_machine_is_compatible("buffalo,lsxl"))
lsxl_init();
- if (of_machine_is_compatible("marvell,db-88f6281-bp") ||
- of_machine_is_compatible("marvell,db-88f6282-bp"))
- db88f628x_init();
-
- if (of_machine_is_compatible("mpl,cec4"))
- mplcec4_init();
-
- if (of_machine_is_compatible("netgear,readynas-duo-v2"))
- netgear_readynas_init();
-
of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
}
^ permalink raw reply
* Re: can't access PCIe card under sbc8548
From: wolfking @ 2013-05-31 0:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1369931365.14679.7@snotra>
hi, scott:
Thanks for replying!
> In what specific way does it not work?
when I use iowrite8 to write, things seem OK, the codes continue running,
when I use ioread8 to read, the console I use freezes. The console stops
responding.
> Why can't it succeed? Is there nothing mapped at 0xfc7fc000?
My PCIe card's local bus register is at BAR0+0xC7, so the driver should
access 0xfc7fc027 and the following 7 bytes. But When I access the areas:
ioread8 just freezes.
--
View this message in context: http://linuxppc.10917.n7.nabble.com/can-t-access-PCIe-card-under-sbc8548-tp71775p71847.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
From: David Miller @ 2013-05-31 0:55 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: andrew, jason, netdev, linux-kernel, buytenh, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1369855975-21489-1-git-send-email-sebastian.hesselbarth@gmail.com>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Wed, 29 May 2013 21:32:42 +0200
> For the patches above I suggest to take Patches 1-6 through David
> Miller's branch, and Patches 7-12 through Jason Cooper's when the
> former have appeared on mainline linux. The patch set has been based
> on v3.10-rc3.
Patches 1-6 applied to net-next, and patch #1 queued up for -stable.
Thanks!
^ permalink raw reply
* Re: can't access PCIe card under sbc8548
From: tiejun.chen @ 2013-05-31 1:34 UTC (permalink / raw)
To: Scott Wood; +Cc: wolfking, linuxppc-dev
In-Reply-To: <1369931094.14679.6@snotra>
On 05/31/2013 12:24 AM, Scott Wood wrote:
> On 05/30/2013 07:49:48 AM, wolfking wrote:
>> tiejun.chen wrote
>> > On 05/30/2013 03:32 PM, wolfking wrote:
>> >> (continued)
>> >> I traced the 8139too.c when it uses pci_iomap, the pci_iomap called
>> >> the
>> >> ioport_map. The difference between 8139 and my PCIe card lies in the
>> >> "port" value :
>> >> void __iomem *ioport_map(unsigned long port, unsigned int len)
>> >> {
>> >> return (void __iomem *) (port + _IO_BASE);
>> >
>> > _IO_BASE is equal to isa_io_base. So if this is not zero, I think there's
>> > a isa
>> > bridge in your platform. So you can access these I/O ports based on that
>> > isa
>> > bridge/bus with ioreadx/iowritex.
>> >
>> > I tried ioread8/iowriet8 after ioremap, it doesn't work
>> >
>> >> }
>> >> in 8139too.c, the "port" value is 0x1000; for my PCIe card, the "port"
>> >> value
>> >> is 0xfefff000. And the value is got from pci_resource_start. So you see,
>> >> the
>> >
>> > But this means the port is as memory-mapped
>
> Are you sure? It could mean that it's on a non-primary bus and I/O for this bus
We can take a further look at '/proc/ioports', '/proc/iomem' and other message.
> is mapped at a lower address than the primary. Just because the addition is
> wrapping around doesn't mean it's wrong.
>
>> > so ioremap() should be workable in this case. Then out_bex/in_bex should be
>> fine.
>
> ioremap() and out_bex/in_bex are not appropriate for PCI I/O regions (and
> presumably that's what it is, if pci_iomap is calling ioport_map). Big-endian
> is not appropriate for PCI in any case.
Yes, I should correct that PCI interprets all accesses as little-endian.
Tiejun
^ permalink raw reply
* Re: can't access PCIe card under sbc8548
From: wolfking @ 2013-05-31 2:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <51A7FE17.2040803@windriver.com>
hi, tiejun:
When I don't compile my pcie card driver(in kernel or as a driver), the
kernel
auto allocate the resoures to my pcie card, here is the output:
root@generic-powerpc-e500v2:~# cat /proc/ioports
00000000-007fffff : /pci@e0008000
00000000-00000fff : Legacy IO
00001000-000010ff : 0000:00:11.0
00001000-000010ff : 8139too
feffe000-ffffdfff : /pcie@e000a000
feffe000-ffffdfff : PCI Bus 0001:02
fefff000-fefff0ff : 0001:02:00.0
fefff100-fefff103 : 0001:02:00.0
the "feffe000-ffffdfff " is the resources that the kernel allocates to my
card.
--
View this message in context: http://linuxppc.10917.n7.nabble.com/can-t-access-PCIe-card-under-sbc8548-tp71775p71850.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 3.10-rc ppc64 corrupts usermem when swapping
From: Hugh Dickins @ 2013-05-31 5:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras, Aneesh Kumar K.V,
David Gibson
In-Reply-To: <alpine.LNX.2.00.1305300643150.10009@eggly.anvils>
On Thu, 30 May 2013, Hugh Dickins wrote:
> On Thu, 30 May 2013, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-05-30 at 13:57 +0530, Aneesh Kumar K.V wrote:
> > > + /* FIXME!!, will fail with when we enable hugepage
> > > support */
> >
> > Just fix that to say "Transparent huge pages" as normal huge pages
> > should work fine unless I'm missing something.
> >
> > Hugh, any chance you can give that a spin ?
>
> Sure, it's now under way. If all goes well, I'll give you a
> progress report in about 15 hours time; but given the variance in
> how long it took to hit, I won't feel fully confident until this
> time tomorrow, when I'll update you again.
Still running fine. I'll leave it running a few more hours to make
sure, and then try switching to the patch Aneesh sent afterwards -
or say if you'd prefer me to switch over to that one immediately.
Hugh
^ permalink raw reply
* Re: [PATCH] powerpc/pci: Improve device hotplug initialization
From: Guenter Roeck @ 2013-05-31 5:14 UTC (permalink / raw)
To: Chen Yuanquan-B41889
Cc: Yuanquan Chen, Hiroo Matsumoto, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <51A5CAC1.6030800@freescale.com>
On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
> On 05/29/2013 01:35 AM, Guenter Roeck wrote:
> >bios_add_device(). Drop explicit calls to pcibios_setup_device();
> >this makes pcibios_setup_bus_devices() a noop function which could
> >eve
>
> Yeah, it's more reasonable to do the irq and DMA related initialization
> in one code path for all devices.
>
Any comments / feedback on the code itself ?
Thanks,
Guenter
^ permalink raw reply
* Re: 3.10-rc ppc64 corrupts usermem when swapping
From: Benjamin Herrenschmidt @ 2013-05-31 5:31 UTC (permalink / raw)
To: Hugh Dickins
Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras, Aneesh Kumar K.V,
David Gibson
In-Reply-To: <alpine.LNX.2.00.1305302201200.12852@eggly.anvils>
On Thu, 2013-05-30 at 22:05 -0700, Hugh Dickins wrote:
> > Sure, it's now under way. If all goes well, I'll give you a
> > progress report in about 15 hours time; but given the variance in
> > how long it took to hit, I won't feel fully confident until this
> > time tomorrow, when I'll update you again.
>
> Still running fine. I'll leave it running a few more hours to make
> sure, and then try switching to the patch Aneesh sent afterwards -
> or say if you'd prefer me to switch over to that one immediately.
The patch you are running on is what I'll send to Linus for 3.10 (+/-
cosmetics). Aneesh second patch is a much larger rework which will be
needed for THP but that will wait for 3.11. I'm happy for you to test it
but I first want to make sure it's solid with the 3.10 fix :-)
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/pci: Improve device hotplug initialization
From: Benjamin Herrenschmidt @ 2013-05-31 5:44 UTC (permalink / raw)
To: Guenter Roeck
Cc: Yuanquan Chen, Hiroo Matsumoto, linux-kernel, Paul Mackerras,
Chen Yuanquan-B41889, linuxppc-dev
In-Reply-To: <20130531051423.GA15505@roeck-us.net>
On Thu, 2013-05-30 at 22:14 -0700, Guenter Roeck wrote:
> On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
> > On 05/29/2013 01:35 AM, Guenter Roeck wrote:
> > >bios_add_device(). Drop explicit calls to pcibios_setup_device();
> > >this makes pcibios_setup_bus_devices() a noop function which could
> > >eve
> >
> > Yeah, it's more reasonable to do the irq and DMA related initialization
> > in one code path for all devices.
> >
> Any comments / feedback on the code itself ?
Sorry, I haven't had a chance to review it yet, I'm fairly bogged down
at the moment. I want to tread carefully because the previous iteration
of changing that stuff did break a few platforms in the end.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
From: Sebastian Hesselbarth @ 2013-05-31 6:28 UTC (permalink / raw)
To: David Miller
Cc: andrew, jason, netdev, linux-kernel, buytenh, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20130530.175549.407800685811475192.davem@davemloft.net>
On 05/31/2013 02:55 AM, David Miller wrote:
> From: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> Date: Wed, 29 May 2013 21:32:42 +0200
>
>> For the patches above I suggest to take Patches 1-6 through David
>> Miller's branch, and Patches 7-12 through Jason Cooper's when the
>> former have appeared on mainline linux. The patch set has been based
>> on v3.10-rc3.
>
> Patches 1-6 applied to net-next, and patch #1 queued up for -stable.
David,
thanks for pulling these in. I finally found how to check if a patch
already went into -stable. As Jason already said, the mdio patch that
#1 fixes did not yet went into -stable. Can you unqueue it? Sorry for
the confusion.
Sebastian
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
From: Kevin Hao @ 2013-05-31 6:41 UTC (permalink / raw)
To: Scott Wood, Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1369940099.14679.14@snotra>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote:
> On 05/30/2013 05:20:34 AM, Kevin Hao wrote:
> >On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
> >> On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
> >> >It also seems that we don't support ISA on all the current
> >corenet ds
> >> >boards. So picking a primary bus seems useless, remove that
> >function
> >> >too.
> >>
> >> IIRC that was due to some bugs in the PPC PCI code in the absence of
> >> any primary bus.
> >
> >Do you know more about these bugs?
>
> Not off the top of my head -- either search the archives or ask Ben.
Hi Ben,
Could you shed some light on this issue? Do we really has the restriction
that we have to pick one bus controller as primary even there is no
ISA bus on the board? I did check the current code and found no code
has a requirement for this. I also searched the archives and but found
nothing useful. :-(
Thanks,
Kevin
>
> >> fsl_pci_assign_primary() will arbitrarily pick one
> >> to be primary if there's no ISA. Have the bugs been fixed?
> >
> >I know there should be some reason that we put the
> >fsl_pci_assign_primary()
> >here. But frankly I am not sure what bugs this workaround try to
> >fix. For these
> >corenet boards picking one to be primary has no effect to the
> >64bit kernel.
> >And for 32bit kernel, the only effect of this is that isa_io_base
> >is set to the
> >io virtual base of the primary bus. But the isa_io_base only make
> >sense when
> >we do have a isa bus, so that we can access some well-known io
> >ports directly
> >by using outx/inx. But if we don't have isa bus on the board, the
> >value of
> >isa_io_base should make no sense at all. So we really don't need
> >to pick a
> >fake primary bus. Of course I may miss something, correct me if I
> >am wrong. :-)
>
> outx/inx can also be used for PCI I/O BARs.
>
> -Scott
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
From: Kevin Hao @ 2013-05-31 6:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1369940099.14679.14@snotra>
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]
On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote:
> On 05/30/2013 05:20:34 AM, Kevin Hao wrote:
> >On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
> >> On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
> >> >It also seems that we don't support ISA on all the current
> >corenet ds
> >> >boards. So picking a primary bus seems useless, remove that
> >function
> >> >too.
> >>
> >> IIRC that was due to some bugs in the PPC PCI code in the absence of
> >> any primary bus.
> >
> >Do you know more about these bugs?
>
> Not off the top of my head -- either search the archives or ask Ben.
>
> >> fsl_pci_assign_primary() will arbitrarily pick one
> >> to be primary if there's no ISA. Have the bugs been fixed?
> >
> >I know there should be some reason that we put the
> >fsl_pci_assign_primary()
> >here. But frankly I am not sure what bugs this workaround try to
> >fix. For these
> >corenet boards picking one to be primary has no effect to the
> >64bit kernel.
> >And for 32bit kernel, the only effect of this is that isa_io_base
> >is set to the
> >io virtual base of the primary bus. But the isa_io_base only make
> >sense when
> >we do have a isa bus, so that we can access some well-known io
> >ports directly
> >by using outx/inx. But if we don't have isa bus on the board, the
> >value of
> >isa_io_base should make no sense at all. So we really don't need
> >to pick a
> >fake primary bus. Of course I may miss something, correct me if I
> >am wrong. :-)
>
> outx/inx can also be used for PCI I/O BARs.
Yes, I know there is also PIO. But the value of isa_io_base doesn't
have any effect for this.
Thanks,
Kevin
>
> -Scott
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc/mpc85xx: Update the clock device tree nodes
From: Yuantian.Tang @ 2013-05-31 7:30 UTC (permalink / raw)
To: galak; +Cc: Tang Yuantian, devicetree-discuss, linuxppc-dev
From: Tang Yuantian <yuantian.tang@freescale.com>
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 32 ++++++++-
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 32 ++++++++-
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 54 ++++++++++++++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 54 ++++++++++++++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 100 +++++++++++++++++++++++++++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 38 ++++++++++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 54 ++++++++++++++-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 77 ++++++++++++++++++++-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 ++++
16 files changed, 473 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 5a6615d..b69d6e5 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -85,7 +85,37 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
+ compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0",
+ "fixed-clock";
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux0";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 7b4426e..a11126b 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -62,11 +62,13 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index e5cf6c8..507a22d 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -129,7 +129,37 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2.0";
+ compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2.0",
+ "fixed-clock";
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux0";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index 5263fa4..185a231 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -62,21 +62,25 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index dc6cc5a..cdf1615 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -305,9 +305,61 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,p2041-clockgen", "fsl,qoriq-clockgen-1.0";
+ compatible = "fsl,p2041-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux2";
+ };
+ mux3: mux3@60 {
+ #clock-cells = <0>;
+ reg = <0x60>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux3";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
index 7a2697d..22f3b14 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
@@ -81,6 +81,7 @@
cpu0: PowerPC,e500mc@0 {
device_type = "cpu";
reg = <0>;
+ clocks = <&mux0>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
next-level-cache = <&cpc>;
@@ -89,6 +90,7 @@
cpu1: PowerPC,e500mc@1 {
device_type = "cpu";
reg = <1>;
+ clocks = <&mux1>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
next-level-cache = <&cpc>;
@@ -97,6 +99,7 @@
cpu2: PowerPC,e500mc@2 {
device_type = "cpu";
reg = <2>;
+ clocks = <&mux2>;
next-level-cache = <&L2_2>;
L2_2: l2-cache {
next-level-cache = <&cpc>;
@@ -105,6 +108,7 @@
cpu3: PowerPC,e500mc@3 {
device_type = "cpu";
reg = <3>;
+ clocks = <&mux3>;
next-level-cache = <&L2_3>;
L2_3: l2-cache {
next-level-cache = <&cpc>;
diff --git a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
index 3fa1e22..982cfae 100644
--- a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
@@ -332,9 +332,61 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,p3041-clockgen", "fsl,qoriq-clockgen-1.0";
+ compatible = "fsl,p3041-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux2";
+ };
+ mux3: mux3@60 {
+ #clock-cells = <0>;
+ reg = <0x60>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux3";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
index c9ca2c3..468e8be 100644
--- a/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
@@ -82,6 +82,7 @@
cpu0: PowerPC,e500mc@0 {
device_type = "cpu";
reg = <0>;
+ clocks = <&mux0>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
next-level-cache = <&cpc>;
@@ -90,6 +91,7 @@
cpu1: PowerPC,e500mc@1 {
device_type = "cpu";
reg = <1>;
+ clocks = <&mux1>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
next-level-cache = <&cpc>;
@@ -98,6 +100,7 @@
cpu2: PowerPC,e500mc@2 {
device_type = "cpu";
reg = <2>;
+ clocks = <&mux2>;
next-level-cache = <&L2_2>;
L2_2: l2-cache {
next-level-cache = <&cpc>;
@@ -106,6 +109,7 @@
cpu3: PowerPC,e500mc@3 {
device_type = "cpu";
reg = <3>;
+ clocks = <&mux3>;
next-level-cache = <&L2_3>;
L2_3: l2-cache {
next-level-cache = <&cpc>;
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
index 34769a7..cf2fc54 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
@@ -352,9 +352,107 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,p4080-clockgen", "fsl,qoriq-clockgen-1.0";
+ compatible = "fsl,p4080-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+ pll2: pll2@840 {
+ #clock-cells = <1>;
+ reg = <0x840>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll2", "pll2-div2";
+ };
+ pll3: pll2@860 {
+ #clock-cells = <1>;
+ reg = <0x860>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll3", "pll3-div2";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux2";
+ };
+ mux3: mux3@60 {
+ #clock-cells = <0>;
+ reg = <0x60>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux3";
+ };
+ mux4: mux4@80 {
+ #clock-cells = <0>;
+ reg = <0x80>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll2 0>, <&pll2 1>, <&pll3 0>, <&pll3 1>;
+ clock-names = "pll2_0", "pll2_1", "pll3_0", "pll3_1";
+ clock-output-names = "cmux4";
+ };
+ mux5: mux5@a0 {
+ #clock-cells = <0>;
+ reg = <0xa0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll2 0>, <&pll2 1>, <&pll3 0>, <&pll3 1>;
+ clock-names = "pll2_0", "pll2_1", "pll3_0", "pll3_1";
+ clock-output-names = "cmux5";
+ };
+ mux6: mux6@c0 {
+ #clock-cells = <0>;
+ reg = <0xc0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll2 0>, <&pll2 1>, <&pll3 0>, <&pll3 1>;
+ clock-names = "pll2_0", "pll2_1", "pll3_0", "pll3_1";
+ clock-output-names = "cmux6";
+ };
+ mux7: mux7@e0 {
+ #clock-cells = <0>;
+ reg = <0xe0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll2 0>, <&pll2 1>, <&pll3 0>, <&pll3 1>;
+ clock-names = "pll2_0", "pll2_1", "pll3_0", "pll3_1";
+ clock-output-names = "cmux7";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
index 493d9a0..0040b5a 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
@@ -81,6 +81,7 @@
cpu0: PowerPC,e500mc@0 {
device_type = "cpu";
reg = <0>;
+ clocks = <&mux0>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
next-level-cache = <&cpc>;
@@ -89,6 +90,7 @@
cpu1: PowerPC,e500mc@1 {
device_type = "cpu";
reg = <1>;
+ clocks = <&mux1>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
next-level-cache = <&cpc>;
@@ -97,6 +99,7 @@
cpu2: PowerPC,e500mc@2 {
device_type = "cpu";
reg = <2>;
+ clocks = <&mux2>;
next-level-cache = <&L2_2>;
L2_2: l2-cache {
next-level-cache = <&cpc>;
@@ -105,6 +108,7 @@
cpu3: PowerPC,e500mc@3 {
device_type = "cpu";
reg = <3>;
+ clocks = <&mux3>;
next-level-cache = <&L2_3>;
L2_3: l2-cache {
next-level-cache = <&cpc>;
@@ -113,6 +117,7 @@
cpu4: PowerPC,e500mc@4 {
device_type = "cpu";
reg = <4>;
+ clocks = <&mux4>;
next-level-cache = <&L2_4>;
L2_4: l2-cache {
next-level-cache = <&cpc>;
@@ -121,6 +126,7 @@
cpu5: PowerPC,e500mc@5 {
device_type = "cpu";
reg = <5>;
+ clocks = <&mux5>;
next-level-cache = <&L2_5>;
L2_5: l2-cache {
next-level-cache = <&cpc>;
@@ -129,6 +135,7 @@
cpu6: PowerPC,e500mc@6 {
device_type = "cpu";
reg = <6>;
+ clocks = <&mux6>;
next-level-cache = <&L2_6>;
L2_6: l2-cache {
next-level-cache = <&cpc>;
@@ -137,6 +144,7 @@
cpu7: PowerPC,e500mc@7 {
device_type = "cpu";
reg = <7>;
+ clocks = <&mux7>;
next-level-cache = <&L2_7>;
L2_7: l2-cache {
next-level-cache = <&cpc>;
diff --git a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
index bc3ae5a..bb98848 100644
--- a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
@@ -337,9 +337,45 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
index 8df47fc..fe1a2e6 100644
--- a/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
@@ -88,6 +88,7 @@
cpu0: PowerPC,e5500@0 {
device_type = "cpu";
reg = <0>;
+ clocks = <&mux0>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
next-level-cache = <&cpc>;
@@ -96,6 +97,7 @@
cpu1: PowerPC,e5500@1 {
device_type = "cpu";
reg = <1>;
+ clocks = <&mux1>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
next-level-cache = <&cpc>;
diff --git a/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi b/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
index a91897f..a22a889 100644
--- a/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
@@ -297,9 +297,61 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,p5040-clockgen", "fsl,qoriq-clockgen-1.0";
+ compatible = "fsl,p5040-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux2";
+ };
+ mux3: mux3@60 {
+ #clock-cells = <0>;
+ reg = <0x60>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux3";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi
index 40ca943..3674686 100644
--- a/arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi
@@ -81,6 +81,7 @@
cpu0: PowerPC,e5500@0 {
device_type = "cpu";
reg = <0>;
+ clocks = <&mux0>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
next-level-cache = <&cpc>;
@@ -89,6 +90,7 @@
cpu1: PowerPC,e5500@1 {
device_type = "cpu";
reg = <1>;
+ clocks = <&mux1>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
next-level-cache = <&cpc>;
@@ -97,6 +99,7 @@
cpu2: PowerPC,e5500@2 {
device_type = "cpu";
reg = <2>;
+ clocks = <&mux2>;
next-level-cache = <&L2_2>;
L2_2: l2-cache {
next-level-cache = <&cpc>;
@@ -105,6 +108,7 @@
cpu3: PowerPC,e5500@3 {
device_type = "cpu";
reg = <3>;
+ clocks = <&mux3>;
next-level-cache = <&L2_3>;
L2_3: l2-cache {
next-level-cache = <&cpc>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..fadff2c 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -368,8 +368,83 @@
};
clockgen: global-utilities@e1000 {
- compatible = "fsl,t4240-clockgen", "fsl,qoriq-clockgen-2.0";
+ compatible = "fsl,t4240-clockgen", "fsl,qoriq-clockgen-2.0",
+ "fixed-clock";
reg = <0xe1000 0x1000>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ };
+ pll2: pll2@840 {
+ #clock-cells = <1>;
+ reg = <0x840>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll2", "pll2-div2", "pll2-div4";
+ };
+ pll3: pll3@860 {
+ #clock-cells = <1>;
+ reg = <0x860>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll3", "pll3-div2", "pll3-div4";
+ };
+ pll4: pll4@880 {
+ #clock-cells = <1>;
+ reg = <0x880>;
+ compatible = "fsl,core-pll-clock";
+ clocks = <&clockgen>;
+ clock-output-names = "pll4", "pll4-div2", "pll4-div4";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>,
+ <&pll2 0>, <&pll2 1>, <&pll2 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2",
+ "pll2_0", "pll2_1", "pll2_2";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>,
+ <&pll2 0>, <&pll2 1>, <&pll2 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2",
+ "pll2_0", "pll2_1", "pll2_2";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll3 0>, <&pll3 1>, <&pll3 2>,
+ <&pll4 0>, <&pll4 1>, <&pll4 2>;
+ clock-names = "pll3_0", "pll3_1", "pll3_2",
+ "pll4_0", "pll4_1", "pll4_2";
+ clock-output-names = "cmux2";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
index a93c55a..0b8ccc5 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
@@ -67,61 +67,73 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
+ clocks = <&mux0>;
next-level-cache = <&L2_1>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
+ clocks = <&mux0>;
next-level-cache = <&L2_1>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
+ clocks = <&mux0>;
next-level-cache = <&L2_1>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
+ clocks = <&mux0>;
next-level-cache = <&L2_1>;
};
cpu4: PowerPC,e6500@8 {
device_type = "cpu";
reg = <8 9>;
+ clocks = <&mux1>;
next-level-cache = <&L2_2>;
};
cpu5: PowerPC,e6500@10 {
device_type = "cpu";
reg = <10 11>;
+ clocks = <&mux1>;
next-level-cache = <&L2_2>;
};
cpu6: PowerPC,e6500@12 {
device_type = "cpu";
reg = <12 13>;
+ clocks = <&mux1>;
next-level-cache = <&L2_2>;
};
cpu7: PowerPC,e6500@14 {
device_type = "cpu";
reg = <14 15>;
+ clocks = <&mux1>;
next-level-cache = <&L2_2>;
};
cpu8: PowerPC,e6500@16 {
device_type = "cpu";
reg = <16 17>;
+ clocks = <&mux2>;
next-level-cache = <&L2_3>;
};
cpu9: PowerPC,e6500@18 {
device_type = "cpu";
reg = <18 19>;
+ clocks = <&mux2>;
next-level-cache = <&L2_3>;
};
cpu10: PowerPC,e6500@20 {
device_type = "cpu";
reg = <20 21>;
+ clocks = <&mux2>;
next-level-cache = <&L2_3>;
};
cpu11: PowerPC,e6500@22 {
device_type = "cpu";
reg = <22 23>;
+ clocks = <&mux2>;
next-level-cache = <&L2_3>;
};
};
--
1.8.0
^ 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