Re: Help needed with porting ether-net driver from ADS5121 to TWR-MPC5125
Hi, On Fri, 16 Dec 2011 08:38:58 +0800 G.H.Lee ligu...@live.com wrote: ... I am a new user of the board TWR-MPC5125 made by freescale. Now I am trying to porting the new kernel, i.e. the version 3.0.4, to this board. I have porting the serial driver and the nand flash driver successfully. And I can also mount the root file system. But I can not use the ether-net interface now. I have tried to port the ether-net driver based on the ether-net driver for ADS 5121, which is provided by the new kernel 3.0.4. The only thing I have to do in the porting is that I should change the MII mode in ADS5121 board to RMII mode in my board. And I find that I can send packages out if I use the ping command. But I can not receive any package for responding. And I also found that the interrupt routine for sending packages was running but the interrupt routine for receiving message was not called by the kernel. I don't know why. Can anyone help me? Should I change some other codes beyond the ether-net driver? Someone told me that I should regulate the kernel because of the differences among the different kerenl versions if the MAC was integrated inside the SOC, which was the fatto in my board. But I don't know how to regulate. Please try following patch for fs_enet driver: http://patchwork.ozlabs.org/patch/87320/ There are also other patches for TWR-MPC5125 support: http://patchwork.ozlabs.org/patch/87925/ http://patchwork.ozlabs.org/patch/87926/ http://patchwork.ozlabs.org/patch/87321/ Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood scottw...@freescale.com wrote: On 12/15/2011 08:44 PM, LiuShuo wrote: hi Artem, Could this patch be applied now and we make a independent patch for bad block information migration later? This patch is not safe to use without migration. Hi Scott, We agree it's not entirely safe without migrating the bad block flag. But let's consider two sides of the situation. Firstly, it's only unsafe when there is a need to re-built the Bad Block Table from scratch(old BBT broken). But currently there is no easy way to do that(re-build BBT on demand), which means it's not a common problem that we can easily address now. Secondly, even if the previous said problem happens(BBT broken). We can still recover all the data if we overrule the bad block flag. Only the card is not so good to be used again, however, it can be used if we take the risk of losing data from errors that ECC can't notice(low possibility too). Finally, I don't think this is a blocker issue but a better to have enhancement. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RapidIO Direct I/O Support?
On Monday, December 19, 2011 1:39 AM, Daniel Ng wrote: Is there RapidIO Direct Memory I/O Support in the latest kernel? I've seen these patches from Freescale, but it seems they were never integrated- http://kerneltrap.org/mailarchive/linux-netdev/2009/5/12/5686954 Does anyone know why these weren't integrated? What is the latest state of these patches? Do they work? I am in process of submitting set of patches that add DMA Engine support into RapidIO subsystem. One of these patches brings back an upper level interface for inbound memory mapping from referenced thread. It does not include HW specific mapping for fsl_rio though. I used an inbound mapping on 8548 based platform during my testing and that part did not take too much time to get it working. The v.2 set of my DMA patches will be published as soon as DMAengine maintainers release an update for dma_slave API. For outbound SRIO requests new patches rely on DMA capabilities of SRIO controller. These patches add DMA channel driver for Tsi721 PCIe-to-SRIO bridge. Alex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 04/14] KVM: PPC: Keep page physical addresses in per-slot arrays
On 12.12.2011, at 23:28, Paul Mackerras wrote:
This allocates an array for each memory slot that is added to store
the physical addresses of the pages in the slot. This array is
vmalloc'd and accessed in kvmppc_h_enter using real_vmalloc_addr().
This allows us to remove the ram_pginfo field from the kvm_arch
struct, and removes the 64GB guest RAM limit that we had.
We use the low-order bits of the array entries to store a flag
indicating that we have done get_page on the corresponding page,
and therefore need to call put_page when we are finished with the
page. Currently this is set for all pages except those in our
special RMO regions.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm_host.h |9 ++-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 18 +++---
arch/powerpc/kvm/book3s_hv.c| 114 +--
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 41 +++-
4 files changed, 107 insertions(+), 75 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 629df2e..7a17ab5 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -38,6 +38,7 @@
#define KVM_MEMORY_SLOTS 32
/* memory slots that does not exposed to userspace */
#define KVM_PRIVATE_MEM_SLOTS 4
+#define KVM_MEM_SLOTS_NUM (KVM_MEMORY_SLOTS + KVM_PRIVATE_MEM_SLOTS)
#ifdef CONFIG_KVM_MMIO
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -175,25 +176,27 @@ struct revmap_entry {
unsigned long guest_rpte;
};
+/* Low-order bits in kvm-arch.slot_phys[][] */
+#define KVMPPC_GOT_PAGE 0x80
+
struct kvm_arch {
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
struct revmap_entry *revmap;
- unsigned long ram_npages;
unsigned long ram_psize;
unsigned long ram_porder;
- struct kvmppc_pginfo *ram_pginfo;
unsigned int lpid;
unsigned int host_lpid;
unsigned long host_lpcr;
unsigned long sdr1;
unsigned long host_sdr1;
int tlbie_lock;
- int n_rma_pages;
unsigned long lpcr;
unsigned long rmor;
struct kvmppc_rma_info *rma;
struct list_head spapr_tce_tables;
+ unsigned long *slot_phys[KVM_MEM_SLOTS_NUM];
+ int slot_npages[KVM_MEM_SLOTS_NUM];
unsigned short last_vcpu[NR_CPUS];
struct kvmppc_vcore *vcores[KVM_MAX_VCORES];
#endif /* CONFIG_KVM_BOOK3S_64_HV */
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 80ece8d..e4c6069 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -98,16 +98,16 @@ void kvmppc_free_hpt(struct kvm *kvm)
void kvmppc_map_vrma(struct kvm *kvm, struct kvm_userspace_memory_region *mem)
{
unsigned long i;
- unsigned long npages = kvm-arch.ram_npages;
- unsigned long pfn;
+ unsigned long npages;
+ unsigned long pa;
unsigned long *hpte;
unsigned long hash;
unsigned long porder = kvm-arch.ram_porder;
struct revmap_entry *rev;
- struct kvmppc_pginfo *pginfo = kvm-arch.ram_pginfo;
+ unsigned long *physp;
- if (!pginfo)
- return;
+ physp = kvm-arch.slot_phys[mem-slot];
+ npages = kvm-arch.slot_npages[mem-slot];
/* VRMA can't be 1TB */
if (npages 1ul (40 - porder))
@@ -117,9 +117,10 @@ void kvmppc_map_vrma(struct kvm *kvm, struct
kvm_userspace_memory_region *mem)
npages = HPT_NPTEG;
for (i = 0; i npages; ++i) {
- pfn = pginfo[i].pfn;
- if (!pfn)
+ pa = physp[i];
+ if (!pa)
break;
+ pa = PAGE_MASK;
/* can't use hpt_hash since va 64 bits */
hash = (i ^ (VRMA_VSID ^ (VRMA_VSID 25))) HPT_HASH_MASK;
/*
@@ -131,8 +132,7 @@ void kvmppc_map_vrma(struct kvm *kvm, struct
kvm_userspace_memory_region *mem)
hash = (hash 3) + 7;
hpte = (unsigned long *) (kvm-arch.hpt_virt + (hash 4));
/* HPTE low word - RPN, protection, etc. */
- hpte[1] = (pfn PAGE_SHIFT) | HPTE_R_R | HPTE_R_C |
- HPTE_R_M | PP_RWXX;
+ hpte[1] = pa | HPTE_R_R | HPTE_R_C | HPTE_R_M | PP_RWXX;
smp_wmb();
hpte[0] = HPTE_V_1TB_SEG | (VRMA_VSID (40 - 16)) |
(i (VRMA_PAGE_ORDER - 16)) | HPTE_V_BOLTED |
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index da7db14..86d3e4b 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -50,14 +50,6 @@
#include linux/vmalloc.h
#include linux/highmem.h
-/*
- * For now, limit memory to 64GB and require it to be large pages.
- * This value is chosen because it makes the ram_pginfo array be
- * 64kB in size, which is about as large as we want to be trying
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 12/19/2011 05:05 AM, Li Yang wrote: On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood scottw...@freescale.com wrote: On 12/15/2011 08:44 PM, LiuShuo wrote: hi Artem, Could this patch be applied now and we make a independent patch for bad block information migration later? This patch is not safe to use without migration. Hi Scott, We agree it's not entirely safe without migrating the bad block flag. But let's consider two sides of the situation. Firstly, it's only unsafe when there is a need to re-built the Bad Block Table from scratch(old BBT broken). No, it's unsafe in the presence of bad blocks. The BBT erasure issue relates to how me mark the flash as migrated, not whether we migrate in the first place. But currently there is no easy way to do that(re-build BBT on demand), You scrub the blocks with U-Boot. It's not supposed to be *easy*, it's a developer recovery mechanism. Secondly, even if the previous said problem happens(BBT broken). We can still recover all the data if we overrule the bad block flag. How so? The bad block markers -- including ones legitimately written to the BBT after the fact -- are used for block skipping with certain types of writes. Without the knowledge of which blocks were marked bad, how do we know which blocks were skipped? Only the card is not so good to be used again, That's a pretty crappy thing to happen every time you hit a bug during development. But again, that's irrelevant to whether this patch should be applied as-is, because we currently don't have any bad block migration at all. however, it can be used if we take the risk of losing data from errors that ECC can't notice(low possibility too). Can you quantify low possibility here? Note that any block that *was* marked bad will have a multi-bit error from the marker itself, since it will be embedded in the main data area. Finally, I don't think this is a blocker issue but a better to have enhancement. No, it is not an enhancement. Processing bad block markers correctly is a fundamental requirement. And if anyone *does* start using it right away, then we'll have to deal with their complaints if we start checking for a migration marker later. Why is it so critical that it be merged now, and not in a few weeks (or next merge window) when I have a chance to do the migration code (assuming nobody else does it first) and add a suitable check for the migration marker in the Linux driver? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 12/14] KVM: Add barriers to allow mmu_notifier_retry to be used locklessly
On 12.12.2011, at 23:37, Paul Mackerras wrote: This adds an smp_wmb in kvm_mmu_notifier_invalidate_range_end() and an smp_rmb in mmu_notifier_retry() so that mmu_notifier_retry() will give the correct answer when called without kvm-mmu_lock being held. PowerPC Book3S HV KVM wants to use a bitlock per guest page rather than a single global spinlock in order to improve the scalability of updates to the guest MMU hashed page table, and so needs this. Signed-off-by: Paul Mackerras pau...@samba.org Avi, mind to ack? Alex --- include/linux/kvm_host.h | 14 +- virt/kvm/kvm_main.c |6 +++--- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 8c5c303..ec79a45 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -700,12 +700,16 @@ static inline int mmu_notifier_retry(struct kvm_vcpu *vcpu, unsigned long mmu_se if (unlikely(vcpu-kvm-mmu_notifier_count)) return 1; /* - * Both reads happen under the mmu_lock and both values are - * modified under mmu_lock, so there's no need of smb_rmb() - * here in between, otherwise mmu_notifier_count should be - * read before mmu_notifier_seq, see - * mmu_notifier_invalidate_range_end write side. + * Ensure the read of mmu_notifier_count happens before the read + * of mmu_notifier_seq. This interacts with the smp_wmb() in + * mmu_notifier_invalidate_range_end to make sure that the caller + * either sees the old (non-zero) value of mmu_notifier_count or + * the new (incremented) value of mmu_notifier_seq. + * PowerPC Book3s HV KVM calls this under a per-page lock + * rather than under kvm-mmu_lock, for scalability, so + * can't rely on kvm-mmu_lock to keep things ordered. */ + smp_rmb(); if (vcpu-kvm-mmu_notifier_seq != mmu_seq) return 1; return 0; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e289486..c144132 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -357,11 +357,11 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn, * been freed. */ kvm-mmu_notifier_seq++; + smp_wmb(); /* * The above sequence increase must be visible before the - * below count decrease but both values are read by the kvm - * page fault under mmu_lock spinlock so we don't need to add - * a smb_wmb() here in between the two. + * below count decrease, which is ensured by the smp_wmb above + * in conjunction with the smp_rmb in mmu_notifier_retry(). */ kvm-mmu_notifier_count--; spin_unlock(kvm-mmu_lock); -- 1.7.7.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 12/14] KVM: Add barriers to allow mmu_notifier_retry to be used locklessly
On 12/19/2011 07:18 PM, Alexander Graf wrote: On 12.12.2011, at 23:37, Paul Mackerras wrote: This adds an smp_wmb in kvm_mmu_notifier_invalidate_range_end() and an smp_rmb in mmu_notifier_retry() so that mmu_notifier_retry() will give the correct answer when called without kvm-mmu_lock being held. PowerPC Book3S HV KVM wants to use a bitlock per guest page rather than a single global spinlock in order to improve the scalability of updates to the guest MMU hashed page table, and so needs this. Signed-off-by: Paul Mackerras pau...@samba.org Avi, mind to ack? Acked-by: Avi Kivity a...@redhat.com -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/14] KVM: PPC: Update Book3S HV memory handling
On 12.12.2011, at 23:23, Paul Mackerras wrote: This series of patches updates the Book3S-HV KVM code that manages the guest hashed page table (HPT) to enable several things: * MMIO emulation and MMIO pass-through * Use of small pages (4kB or 64kB, depending on config) to back the guest memory * Pageable guest memory - i.e. backing pages can be removed from the guest and reinstated on demand, using the MMU notifier mechanism * Guests can be given read-only access to pages even though they think they have mapped them read/write. When they try to write to them their access is upgraded to read/write. This allows KSM to share pages between guests. On PPC970 we have no way to get DSIs and ISIs to come to the hypervisor, so we can't do MMIO emulation or pageable guest memory. On POWER7 we set the VPM1 bit in the LPCR to make all DSIs and ISIs come to the hypervisor (host) as HDSIs or HISIs. This code is working well in my tests. The sporadic crashes that I was seeing earlier are fixed by the second patch in the series. Somewhat to my surprise, when I implemented the last patch in the series I started to see KSM coalescing pages without any further effort on my part -- my tests were on a machine with Fedora 16 installed, and it has ksmtuned running by default. This series is on top of Alex Graf's kvm-ppc-next branch. The first patch in my series fixes a bug in one of the patches in that branch (KVM: PPC: booke: Improve timer register emulation). These patches only touch arch/powerpc except for patch 12, which adds a couple of barriers to allow mmu_notifier_retry() to be used outside of the kvm-mmu_lock. Thanks, applied all to kvm-ppc-next, awaiting the one follow-up patch though. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 12/17/2011 08:35 AM, Artem Bityutskiy wrote: On Mon, 2011-12-12 at 15:30 -0600, Scott Wood wrote: On 12/12/2011 03:19 PM, Artem Bityutskiy wrote: On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote: NAND chips come from the factory with bad blocks marked at a certain offset into each page. This offset is normally in the OOB area, but since we change the layout from 4k data, 128 byte oob to 2k data, 64 byte oob, 2k data, 64 byte oob the marker is no longer in the oob. On first use we need to migrate the markers so that they are still in the oob. Ah, I see, thanks. Are you planning to implement in-kernel migration or use a user-space tool? That's the kind of answer I was hoping to get from Shuo. :-) Most likely is a firmware-based tool, but I'd like there to be some way for the tool to mark that this has happened, so that the Linux driver can refuse to do non-raw accesses to a chip that isn't marked as having been migrated (or at least yell loudly in the log). Speaking of raw accesses, these are currently broken in the eLBC driver... we need some way for the generic layer to tell us what kind of access it is before the transaction starts, not once it wants to read out the buffer (unless we add more hacks to delay the start of a read transaction until first buffer access...). We'd be better off with a high-level read page/write page function that does the whole thing (not just buffer access, but command issuance as well). It looks like currently you can re-define chip-read_page, so I guess you should rework MTD and make chip-write_page re-definable? Unless something has changed very recently, there is no chip-read_page or chip-write_page. There is chip-ecc.read_page and chip-ecc.write_page, but they are too low-level. What we'd need to replace is a portion of nand_do_read_ops()/nand_do_write_ops(). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 12/19/2011 12:38 PM, Scott Wood wrote: On 12/17/2011 08:35 AM, Artem Bityutskiy wrote: It looks like currently you can re-define chip-read_page, so I guess you should rework MTD and make chip-write_page re-definable? Unless something has changed very recently, there is no chip-read_page or chip-write_page. There is chip-ecc.read_page and chip-ecc.write_page, but they are too low-level. What we'd need to replace is a portion of nand_do_read_ops()/nand_do_write_ops(). Sorry, chip-write_page does exist -- it's chip-read_page that would need to be made similarly redefinable. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the cputime tree with the powerpc tree
Hi Martin,
Today's linux-next merge of the cputime tree got a conflict in
arch/powerpc/include/asm/cputime.h between commit 9f5072d4f63f (powerpc:
Fix wrong divisor in usecs_to_cputime) from the powerpc tree and commit
648616343cdb ([S390] cputime: add sparse checking and cleanup) from the
cputime tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/powerpc/include/asm/cputime.h
index 33a3580,e94935c..000
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@@ -130,7 -114,7 +114,7 @@@ extern u64 __cputime_usec_factor
static inline unsigned long cputime_to_usecs(const cputime_t ct)
{
- return mulhdu(ct, __cputime_usec_factor);
- return mulhdu((__force u64) ct, __cputime_msec_factor) * USEC_PER_MSEC;
++ return mulhdu((__force u64) ct, __cputime_usec_factor);
}
static inline cputime_t usecs_to_cputime(const unsigned long us)
pgp9tnHPn2oIp.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
-Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Saturday, December 17, 2011 10:45 PM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; dw...@infradead.org; Gala Kumar-B11780; linux-...@lists.infradead.org Subject: Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller On Mon, 2011-12-12 at 17:40 +0800, Shengzhou Liu wrote: There was a bug for fmr initialization, which lead to fmr was always 0x100 in fsl_elbc_chip_init() and caused FCM command timeout before calling fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value and not relying on the setting of bootloader. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Pushed both to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy I noted it had been applied in linux-next.git tree. Does it still need to l2-mtd-2.6.git? Thanks. Best Regards, Shengzhou Liu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx: 32bit address support for p1022ds
From: Jerry Huang chang-ming.hu...@freescale.com All features for p1022ds are based on the 32bit address, 36bit only optional. We should make the PHYS_64BIT optional, remove the 'select PHYS_64BIT' from the Kconfig file in order to support 32bit address for P1022DS platform. Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com --- arch/powerpc/platforms/85xx/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 8f0543f..d58987f 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -80,7 +80,6 @@ config P1010_RDB config P1022_DS bool Freescale P1022 DS select DEFAULT_UIMAGE - select PHYS_64BIT # The DTS has 36-bit addresses select SWIOTLB help This option enables support for the Freescale P1022DS reference board. -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
