* [v1 PATCH 0/4] Add INT mode support for EDAC drivers on Maple
From: Harry Ciao @ 2009-05-18 10:04 UTC (permalink / raw)
To: benh, bluesmoke-devel; +Cc: linuxppc-dev, linux-kernel
Hi Ben,
This is the v2 patches that have integrated your suggestions to
remove the refcount for a hwriq2virq mapping as long as we don't
dispose it, the changes are mostly within the 1/4 patch where the
unnecessary refcount and irqmap structure are removed, and callings
to edac_put_mpic_irq() are also removed from the rest of patches.
Since there are 3 EDAC modules on Maple will use one same copy of
code to create hwirq2virq mappings, I perfer to preserve it in
edac_mpic_irq.c.
How do feel about the assumption that MPIC will latch INT 0 pin for
the NMI Reqeust Messages whose vector is == 0? This is the thing that
I have least confidence in, so far all I can get is the brief
introduction in CPC925 user manual that "This interrupt vector is used
to set a corresponding interrupt latch", P111, so I think it imples that
vector==0 will latch pin #0.
Many thanks for all your comments!
Best regards,
Harry
^ permalink raw reply
* Re: [PATCH] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Wolfram Sang @ 2009-05-18 11:04 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <d2b9ea600905150552u6951a92es5dd119dcc37e641d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]
> Could we go forward with my initial patch, and then continue the work
> on this repeated START approach for future releases?
Then could you please send another version of your patch with the CodingStyle
issue removed and an updated description what this patch fixes and what still
needs to be resolved?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v4] powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven @ 2009-05-18 12:10 UTC (permalink / raw)
To: Linux/PPC Development
If CONFIG_PPC_EMULATED_STATS is enabled, make available counters for the
various classes of emulated instructions under
/sys/kernel/debug/powerpc/emulated_instructions/ (assumed debugfs is mounted on
/sys/kernel/debug). Optionally (controlled by
/sys/kernel/debug/powerpc/emulated_instructions/do_warn), rate-limited warnings
can be printed to the console when instructions are emulated.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
Tested on ppc64 (ps3) and ppc32 (sequoia) using mfpvr.
v4:
- Introduce CONFIG_PPC_EMULATED_STATS
v3:
- Add generic unaligned
- Switch from sysfs + sysctl to debugfs. All virtual files now show up under
/sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs mounted on
/sys/kernel/debug)
- Enable the printing of rate-limited warnings by writing a non-zero value to
/sys/kernel/debug/powerpc/emulated_instructions/do_warn
- Switch from per-CPU to system-wide counters
- Always use 32-bit counters (was 64-bit on ppc64)
- Counters are writable, i.e. can be reset (by root)
v2:
- arch/powerpc/kernel/sysfs.c is now compiled on ppc32, so we can provide
counters in sysfs on ppc32, too,
- WARN_EMULATED() is a no-op if CONFIG_SYSCTL is disabled,
- Add warnings for altivec,
- Add warnings for recently introduced emulation of vsx and isel
instructions.
arch/powerpc/Kconfig.debug | 13 ++++
arch/powerpc/include/asm/emulated_ops.h | 73 +++++++++++++++++++++++
arch/powerpc/kernel/align.c | 20 +++++-
arch/powerpc/kernel/traps.c | 96 ++++++++++++++++++++++++++++++-
4 files changed, 196 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/include/asm/emulated_ops.h
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a1098e2..d79a902 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -41,6 +41,19 @@ config HCALL_STATS
This option will add a small amount of overhead to all hypervisor
calls.
+config PPC_EMULATED_STATS
+ bool "Emulated instructions tracking"
+ depends on DEBUG_FS
+ help
+ Adds code to keep track of the number of instructions that are
+ emulated by the in-kernel emulator. Counters for the various classes
+ of emulated instructions are available under
+ powerpc/emulated_instructions/ in the root of the debugfs file
+ system. Optionally (controlled by
+ powerpc/emulated_instructions/do_warn in debugfs), rate-limited
+ warnings can be printed to the console when instructions are
+ emulated.
+
config CODE_PATCHING_SELFTEST
bool "Run self-tests of the code-patching code."
depends on DEBUG_KERNEL
diff --git a/arch/powerpc/include/asm/emulated_ops.h b/arch/powerpc/include/asm/emulated_ops.h
new file mode 100644
index 0000000..9154e85
--- /dev/null
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2007 Sony Corporation
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ * If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _ASM_POWERPC_EMULATED_OPS_H
+#define _ASM_POWERPC_EMULATED_OPS_H
+
+#include <asm/atomic.h>
+
+
+#ifdef CONFIG_PPC_EMULATED_STATS
+
+struct ppc_emulated_entry {
+ const char *name;
+ atomic_t val;
+};
+
+extern struct ppc_emulated {
+#ifdef CONFIG_ALTIVEC
+ struct ppc_emulated_entry altivec;
+#endif
+ struct ppc_emulated_entry dcba;
+ struct ppc_emulated_entry dcbz;
+ struct ppc_emulated_entry fp_pair;
+ struct ppc_emulated_entry isel;
+ struct ppc_emulated_entry mcrxr;
+ struct ppc_emulated_entry mfpvr;
+ struct ppc_emulated_entry multiple;
+ struct ppc_emulated_entry popcntb;
+ struct ppc_emulated_entry spe;
+ struct ppc_emulated_entry string;
+ struct ppc_emulated_entry unaligned;
+#ifdef CONFIG_MATH_EMULATION
+ struct ppc_emulated_entry math;
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+ struct ppc_emulated_entry 8xx;
+#endif
+#ifdef CONFIG_VSX
+ struct ppc_emulated_entry vsx;
+#endif
+} ppc_emulated;
+
+extern u32 ppc_warn_emulated;
+
+extern void ppc_warn_emulated_print(const char *type);
+
+#define PPC_WARN_EMULATED(type) \
+ do { \
+ atomic_inc(&ppc_emulated.type.val); \
+ if (ppc_warn_emulated) \
+ ppc_warn_emulated_print(ppc_emulated.type.name); \
+ } while (0)
+
+#else /* !CONFIG_PPC_EMULATED_STATS */
+
+#define PPC_WARN_EMULATED(type) do { } while (0)
+
+#endif /* !CONFIG_PPC_EMULATED_STATS */
+
+#endif /* _ASM_POWERPC_EMULATED_OPS_H */
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 5ffcfaa..a5b632e 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -24,6 +24,7 @@
#include <asm/system.h>
#include <asm/cache.h>
#include <asm/cputable.h>
+#include <asm/emulated_ops.h>
struct aligninfo {
unsigned char len;
@@ -730,8 +731,10 @@ int fix_alignment(struct pt_regs *regs)
areg = dsisr & 0x1f; /* register to update */
#ifdef CONFIG_SPE
- if ((instr >> 26) == 0x4)
+ if ((instr >> 26) == 0x4) {
+ PPC_WARN_EMULATED(spe);
return emulate_spe(regs, reg, instr);
+ }
#endif
instr = (dsisr >> 10) & 0x7f;
@@ -783,23 +786,28 @@ int fix_alignment(struct pt_regs *regs)
flags |= SPLT;
nb = 8;
}
+ PPC_WARN_EMULATED(vsx);
return emulate_vsx(addr, reg, areg, regs, flags, nb);
}
#endif
/* A size of 0 indicates an instruction we don't support, with
* the exception of DCBZ which is handled as a special case here
*/
- if (instr == DCBZ)
+ if (instr == DCBZ) {
+ PPC_WARN_EMULATED(dcbz);
return emulate_dcbz(regs, addr);
+ }
if (unlikely(nb == 0))
return 0;
/* Load/Store Multiple instructions are handled in their own
* function
*/
- if (flags & M)
+ if (flags & M) {
+ PPC_WARN_EMULATED(multiple);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
+ }
/* Verify the address of the operand */
if (unlikely(user_mode(regs) &&
@@ -816,8 +824,12 @@ int fix_alignment(struct pt_regs *regs)
}
/* Special case for 16-byte FP loads and stores */
- if (nb == 16)
+ if (nb == 16) {
+ PPC_WARN_EMULATED(fp_pair);
return emulate_fp_pair(addr, reg, flags);
+ }
+
+ PPC_WARN_EMULATED(unaligned);
/* If we are loading, get the data from user space, else
* get it from register values
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 678fbff..6a5b2b7 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -33,7 +33,9 @@
#include <linux/backlight.h>
#include <linux/bug.h>
#include <linux/kdebug.h>
+#include <linux/debugfs.h>
+#include <asm/emulated_ops.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -757,36 +759,44 @@ static int emulate_instruction(struct pt_regs *regs)
/* Emulate the mfspr rD, PVR. */
if ((instword & PPC_INST_MFSPR_PVR_MASK) == PPC_INST_MFSPR_PVR) {
+ PPC_WARN_EMULATED(mfpvr);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
}
/* Emulating the dcba insn is just a no-op. */
- if ((instword & PPC_INST_DCBA_MASK) == PPC_INST_DCBA)
+ if ((instword & PPC_INST_DCBA_MASK) == PPC_INST_DCBA) {
+ PPC_WARN_EMULATED(dcba);
return 0;
+ }
/* Emulate the mcrxr insn. */
if ((instword & PPC_INST_MCRXR_MASK) == PPC_INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
+ PPC_WARN_EMULATED(mcrxr);
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
}
/* Emulate load/store string insn. */
- if ((instword & PPC_INST_STRING_GEN_MASK) == PPC_INST_STRING)
+ if ((instword & PPC_INST_STRING_GEN_MASK) == PPC_INST_STRING) {
+ PPC_WARN_EMULATED(string);
return emulate_string_inst(regs, instword);
+ }
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & PPC_INST_POPCNTB_MASK) == PPC_INST_POPCNTB) {
+ PPC_WARN_EMULATED(popcntb);
return emulate_popcntb_inst(regs, instword);
}
/* Emulate isel (Integer Select) instruction */
if ((instword & PPC_INST_ISEL_MASK) == PPC_INST_ISEL) {
+ PPC_WARN_EMULATED(isel);
return emulate_isel(regs, instword);
}
@@ -984,6 +994,8 @@ void SoftwareEmulation(struct pt_regs *regs)
#ifdef CONFIG_MATH_EMULATION
errcode = do_mathemu(regs);
+ if (errcode >= 0)
+ PPC_WARN_EMULATED(math);
switch (errcode) {
case 0:
@@ -1005,6 +1017,9 @@ void SoftwareEmulation(struct pt_regs *regs)
#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
errcode = Soft_emulate_8xx(regs);
+ if (errcode >= 0)
+ PPC_WARN_EMULATED(8xx);
+
switch (errcode) {
case 0:
emulate_single_step(regs);
@@ -1088,6 +1103,7 @@ void altivec_assist_exception(struct pt_regs *regs)
flush_altivec_to_thread(current);
+ PPC_WARN_EMULATED(altivec);
err = emulate_altivec(regs);
if (err == 0) {
regs->nip += 4; /* skip emulated instruction */
@@ -1286,3 +1302,79 @@ void kernel_bad_stack(struct pt_regs *regs)
void __init trap_init(void)
{
}
+
+
+#ifdef CONFIG_PPC_EMULATED_STATS
+
+#define WARN_EMULATED_SETUP(type) .type = { .name = #type }
+
+struct ppc_emulated ppc_emulated = {
+#ifdef CONFIG_ALTIVEC
+ WARN_EMULATED_SETUP(altivec),
+#endif
+ WARN_EMULATED_SETUP(dcba),
+ WARN_EMULATED_SETUP(dcbz),
+ WARN_EMULATED_SETUP(fp_pair),
+ WARN_EMULATED_SETUP(isel),
+ WARN_EMULATED_SETUP(mcrxr),
+ WARN_EMULATED_SETUP(mfpvr),
+ WARN_EMULATED_SETUP(multiple),
+ WARN_EMULATED_SETUP(popcntb),
+ WARN_EMULATED_SETUP(spe),
+ WARN_EMULATED_SETUP(string),
+ WARN_EMULATED_SETUP(unaligned),
+#ifdef CONFIG_MATH_EMULATION
+ WARN_EMULATED_SETUP(math),
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+ WARN_EMULATED_SETUP(8xx),
+#endif
+#ifdef CONFIG_VSX
+ WARN_EMULATED_SETUP(vsx),
+#endif
+};
+
+u32 ppc_warn_emulated;
+
+void ppc_warn_emulated_print(const char *type)
+{
+ if (printk_ratelimit())
+ pr_warning("%s used emulated %s instruction\n", current->comm,
+ type);
+}
+
+static int __init ppc_warn_emulated_init(void)
+{
+ struct dentry *dir, *d;
+ unsigned int i;
+ struct ppc_emulated_entry *entries = (void *)&ppc_emulated;
+
+ if (!powerpc_debugfs_root)
+ return -ENODEV;
+
+ dir = debugfs_create_dir("emulated_instructions",
+ powerpc_debugfs_root);
+ if (!dir)
+ return -ENOMEM;
+
+ d = debugfs_create_u32("do_warn", S_IRUGO | S_IWUSR, dir,
+ &ppc_warn_emulated);
+ if (!d)
+ goto fail;
+
+ for (i = 0; i < sizeof(ppc_emulated)/sizeof(*entries); i++) {
+ d = debugfs_create_u32(entries[i].name, S_IRUGO | S_IWUSR, dir,
+ (u32 *)&entries[i].val.counter);
+ if (!d)
+ goto fail;
+ }
+
+ return 0;
+
+fail:
+ debugfs_remove_recursive(dir);
+ return -ENOMEM;
+}
+
+device_initcall(ppc_warn_emulated_init);
+
+#endif /* CONFIG_PPC_EMULATED_STATS */
--
1.6.2.4
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply related
* [PATCH v3] powerpc/pci: clean up direct access to sysdata by iseries platform
From: Kumar Gala @ 2009-05-18 12:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell
We shouldn't directly access sysdata to get the device node. We should
be calling pci_device_to_OF_node().
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Fixed compile error (dev -> pdev)
arch/powerpc/platforms/iseries/iommu.c | 2 +-
arch/powerpc/platforms/iseries/pci.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/iommu.c b/arch/powerpc/platforms/iseries/iommu.c
index 4021982..6c1e101 100644
--- a/arch/powerpc/platforms/iseries/iommu.c
+++ b/arch/powerpc/platforms/iseries/iommu.c
@@ -177,7 +177,7 @@ static struct iommu_table *iommu_table_find(struct iommu_table * tbl)
static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
{
struct iommu_table *tbl;
- struct device_node *dn = pdev->sysdata;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
struct pci_dn *pdn = PCI_DN(dn);
const u32 *lsn = of_get_property(dn, "linux,logical-slot-number", NULL);
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index 21cddc3..175aac8 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -318,6 +318,7 @@ static void __init iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
{
struct resource *bar_res = &dev->resource[bar_num];
long bar_size = pci_resource_len(dev, bar_num);
+ struct device_node *dn = pci_device_to_OF_node(dev);
/*
* No space to allocate, quick exit, skip Allocation.
@@ -335,9 +336,9 @@ static void __init iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
* Allocate the number of table entries needed for BAR.
*/
while (bar_size > 0 ) {
- iomm_table[current_iomm_table_entry] = dev->sysdata;
+ iomm_table[current_iomm_table_entry] = dn;
ds_addr_table[current_iomm_table_entry] =
- iseries_ds_addr(dev->sysdata) | (bar_num << 24);
+ iseries_ds_addr(dn) | (bar_num << 24);
bar_size -= IOMM_TABLE_ENTRY_SIZE;
++current_iomm_table_entry;
}
@@ -410,7 +411,7 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev *pdev)
struct device_node *node;
int i;
- node = find_device_node(bus, pdev->devfn);
+ node = pci_device_to_OF_node(pdev);
pr_debug("PCI: iSeries %s, pdev %p, node %p\n",
pci_name(pdev), pdev, node);
if (!node) {
@@ -441,7 +442,6 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev *pdev)
}
}
- pdev->sysdata = node;
allocate_device_bars(pdev);
iseries_device_information(pdev, bus, *sub_bus);
}
--
1.6.0.6
^ permalink raw reply related
* Re: fs_enet build breakage
From: Kumar Gala @ 2009-05-18 13:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Kumar Gala, linuxppc-dev list
In-Reply-To: <1242630064.18075.48.camel@pasglop>
On May 18, 2009, at 2:01 AM, Benjamin Herrenschmidt wrote:
> Hi Kumar
>
> Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch
> breaks my 8xx test config with the following error:
>
> /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In =20=
> function =91setup_immap=92:
> /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:=20
> 947: error: =91IMAP_ADDR=92 undeclared (first use in this function)
> /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:=20
> 947: error: (Each undeclared identifier is reported only once
> /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:=20
> 947: error: for each function it appears in.)
>
> I'm still pushing it with a bunch of other stuff to "test" so people =20=
> get
> to find more breakage but it will need to be fixed for the actual =20
> "next"
> branch.
>
> Cheers,
> Ben.
>
I'm pretty sure the driver changes to address this are in dave's net-=20
next tree.
- k=
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-18 13:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <1242622141.18075.37.camel@pasglop>
On May 17, 2009, at 11:49 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-14 at 17:42 -0500, Becky Bruce wrote:
>> This patch includes the basic infrastructure to use swiotlb
>> bounce buffering on 32-bit powerpc. It is not yet enabled on
>> any platforms. Probably the most interesting bit is the
>> addition of addr_needs_map to dma_ops - we need this as
>> a dma_op because the decision of whether or not an addr
>> can be mapped by a device is device-specific.
>>
>> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
>
> Hi Becky !
>
> Finally I got to look at your patch :-)
>
> A few comments below...
>
>> #ifdef CONFIG_NOT_COHERENT_CACHE
>> /*
>> * DMA-consistent mapping functions for PowerPCs that don't support
>> @@ -76,6 +85,8 @@ struct dma_mapping_ops {
>> dma_addr_t dma_address, size_t size,
>> enum dma_data_direction direction,
>> struct dma_attrs *attrs);
>> + int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
>> + size_t size);
>
> What annoys me here is that we basically end up with two indirect
> function calls for pretty much any DMA map. One was bad enough on low
> end processors or very intensive networking, but this is getting real
> bad don't you think ?
>
> Granted, this is only used when swiotlb is used too, but still...
>
> So the problem is that the region that can pass-through is somewhat
> a mix of bus specific (incoming DMA window location & size) and
> device specific (device addressing limitations).
>
> Now, if we can always reduce it to a single range though, which I
> think is practically the case, can't we instead pre-calculate that
> range and stick -that- in the struct dev archdata or similar thus
> speeding up the decision for a given address as to whether it needs
> a swiotlb mapping or not ? Or does it gets too messy ?
Part of this is how the generic swiotlb code works and part of it was
our desire not to bloat dev archdata by adding such info that as you
say is either bus specific or conveyed in the dma addr mask.
- k
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Piotr Zięcik @ 2009-05-18 13:57 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <4A028182.3040107@grandegger.com>
> Right. Furthermore, the i2c-mpc.c should be extened to support bus speed
> setting for the MPC512x, which has been merged recently (see commit id
> f2bd5efe).
I have simple question about bus speed setting support. Existing=20
implementation uses default safe speed if there is no 'clock-frequency'=20
property in i2c node. Comments in code suggest that this behaviour is left=
=20
for backward compatibility only. Should I make the 'clock-frequency'
property mandatory for a new type of I2C controller (MPC5121) ?
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Grant Likely @ 2009-05-18 14:11 UTC (permalink / raw)
To: Piotr Zięcik; +Cc: linuxppc-dev, Detlev Zundel, Wolfgang Denk, linux-i2c
In-Reply-To: <200905181557.11766.kosmo@semihalf.com>
2009/5/18 Piotr Zi=EAcik <kosmo@semihalf.com>:
>> Right. Furthermore, the i2c-mpc.c should be extened to support bus speed
>> setting for the MPC512x, which has been merged recently (see commit id
>> f2bd5efe).
>
> I have simple question about bus speed setting support. Existing
> implementation uses default safe speed if there is no 'clock-frequency'
> property in i2c node. Comments in code suggest that this behaviour is lef=
t
> for backward compatibility only. Should I make the 'clock-frequency'
> property mandatory for a new type of I2C controller (MPC5121) ?
yes. At least in documentation, but I wouldn't do extra work to
disable that behaviour for 5121 boards.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Wolfgang Grandegger @ 2009-05-18 14:29 UTC (permalink / raw)
To: Piotr Zięcik; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <200905181557.11766.kosmo@semihalf.com>
Piotr Zięcik wrote:
>> Right. Furthermore, the i2c-mpc.c should be extened to support bus speed
>> setting for the MPC512x, which has been merged recently (see commit id
>> f2bd5efe).
>
> I have simple question about bus speed setting support. Existing
> implementation uses default safe speed if there is no 'clock-frequency'
> property in i2c node. Comments in code suggest that this behaviour is left
> for backward compatibility only. Should I make the 'clock-frequency'
> property mandatory for a new type of I2C controller (MPC5121) ?
I don't think so, for the same backward compatibility reason as for the
other boards. But the DTS file might be changed to use clock-frequency.
BTW, when I wrote the code I already had the MPC512x in mind. IIRC, the
FDR table and the function scanning it for the MPC52xx should work for
the MPC512x as well. It's mainly a matter of using the proper function
to get the source clock frequency and fiddling with multiple-arch support.
Wolfgang.
^ permalink raw reply
* Re: FEC & SDMA (bestcomm) interaction on the 5200
From: Dimiter Popoff @ 2009-05-18 15:59 UTC (permalink / raw)
To: linuxppc-dev
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Fri, 15 May 2009 08:52:19 -0600
> Subject: Re: FEC & SDMA (bestcomm) interaction on the 5200
> To: Dimiter Popoff <dp@tgi-sci.com>
> Cc: linuxppc-dev@ozlabs.org
>
> On Fri, May 15, 2009 at 2:36 AM, Dimiter Popoff <dp@tgi-sci.com> wrote:
> > Hi people,
> >
> > I am porting my (not linux) OS to the 5200. I went all the
> > way understanding how the SDMA works and programming what
> > I needed for it so things are now pretty stable in terms
> > of disk I/O and system memory -> PCI (offscreen window
> > buffers -> PCI display framebuffer).
> >
> > =A0And I wanted to make use of the Ethernet ("FEC", as they have
> > it), hoping it would take me a few days (not my first one).
> >
> > =A0I am out of luck - it is practically undocumented. There is some
> > talk of receive buffers which the FEC should see empty etc.,
> > how on earth is that supposed to happen when it has no bus
> > master capability at all? It relies on the SDMA for its bus
> > activity - but in what format does it expect to get these
> > buffer related data?
> > =A0Or (more likely, at least hopefully so) this talk in the
> > MPC5200BUM (and MPC5200UM, for that) is just nonsense and
> > the FEC simply puts in the FIFO incoming packets, writing as
> > a last .l the receive frame status word? If so, I could
> > easily handle that with the SDMA.
> > =A0Same question about transmitting. I can only hope/assume
> > that the FEC will just send what it is handed through the
> > FIFO by the SDMA, the very first .l being the frame control
> > word, and ending when the TFD from the data drd1a or whatever
> > makes it through?
>
> It's been a long time since I've been in the bowels of the FEC driver,
> but I believe you are correct.
>
> g.
>
> -- =
>
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
Thanks for the input, Grant. It matches the memories of a guy
at Frrecale who has had to deal with it ass well, so I guess
I am on the right path - It won't be without trying this or
that out but I am well enough positioned to start.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
^ permalink raw reply
* Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
From: K.Prasad @ 2009-05-18 16:10 UTC (permalink / raw)
To: Alan Stern
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Roland McGrath
In-Reply-To: <Pine.LNX.4.44L0.0905141614360.4344-100000@iolanthe.rowland.org>
On Thu, May 14, 2009 at 04:20:04PM -0400, Alan Stern wrote:
> On Fri, 15 May 2009, K.Prasad wrote:
>
> > I see that you're referring to this code in __switch_to() :
> > if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
> > set_dabr(new->thread.dabr);
> >
> > arch_install_thread_hw_breakpoint()<--switch_to_thread_hw_breakpoint()
> > <--__switch_to() implementation is also similar.
> >
> > In __switch_to(),
> > if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
> > switch_to_thread_hw_breakpoint(new);
> >
> > happens only when TIF_DEBUG flag is set. This flag is cleared when the
> > process unregisters any breakpoints it had requested earlier. So, the
> > set_dabr() call is avoided for processes not using the debug register.
>
> In the x86 code, shouldn't arch_update_user_hw_breakpoint set or clear
> TIF_DEBUG, depending on whether or not there are any user breakpoints
> remaining?
>
Yes. There's a bigger issue in setting TIF_DEBUG flag through ptrace
code. It should instead be done in register_user_hw_breakpoint() and
removed through unregister_user_hw_breakpoint() when the last breakpoint
request is being unregistered.
The unregister_user_hw_breakpoint() code should be like this:
void unregister_user_hw_breakpoint(struct task_struct *tsk,
struct hw_breakpoint *bp)
{
struct thread_struct *thread = &(tsk->thread);
int i, pos = -1, clear_tsk_debug_counter = 0;
spin_lock_bh(&hw_breakpoint_lock);
for (i = 0; i < hbp_kernel_pos; i++) {
if (thread->hbp[i])
clear_tsk_debug_counter++;
if (bp == thread->hbp[i]) {
clear_tsk_debug_counter--;
pos = i;
}
}
if (pos >= 0)
__unregister_user_hw_breakpoint(pos, tsk);
if (!clear_tsk_debug_counter)
clear_tsk_thread_flag(tsk, TIF_DEBUG);
spin_unlock_bh(&hw_breakpoint_lock);
}
It needs modification in the generic HW Breakpoint code. I'm planning to
submit this as a patch over the earlier patchset (after it is pulled
into -tip tree).
> > > > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > > > +{
> > > > + int rc = NOTIFY_STOP;
> > > > + struct hw_breakpoint *bp;
> > > > + struct pt_regs *regs = args->regs;
> > > > + unsigned long dar;
> > > > + int cpu, stepped, is_kernel;
> > > > +
> > > > + /* Disable breakpoints during exception handling */
> > > > + set_dabr(0);
> > > > +
> > > > + dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
> > > > + is_kernel = (dar >= TASK_SIZE) ? 1 : 0;
> > >
> > > is_kernel_addr() ?
> > >
> >
> > Ok.
>
> Shouldn't this test hbp_kernel_pos instead?
>
Testing hbp_kernel_pos should be sufficient for PPC64 with just one
breakpoint register. However the above code is more extensible to other
PowerPC implementations which have more than one breakpoint register.
> > > > + if (is_kernel)
> > > > + bp = hbp_kernel[0];
> > > > + else {
> > > > + bp = current->thread.hbp[0];
> > > > + /* Lazy debug register switching */
> > > > + if (!bp)
> > > > + return rc;
>
> Shouldn't this test be moved outside the "if" statement, as in the x86
> code?
>
Yes, I will do it. Another error here is the return code when exception
is raised from user-space address due to lazy debug register switching.
The return code should be NOTIFY_STOP (and not NOTIFY_DONE) since the
exception is a stray one and we don't want it to be propogated as a
signal to user-space. This change is required in both x86 and PPC64. I
will submit the x86 change as a separate patch.
> Alan Stern
>
Thanks,
K.Prasad
^ permalink raw reply
* Re: [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware breakpoint usage
From: K.Prasad @ 2009-05-18 16:11 UTC (permalink / raw)
To: Alan Stern
Cc: linuxppc-dev, Michael Neuling, Benjamin Herrenschmidt, paulus,
Roland McGrath
In-Reply-To: <Pine.LNX.4.44L0.0905141621040.4344-100000@iolanthe.rowland.org>
On Thu, May 14, 2009 at 04:21:48PM -0400, Alan Stern wrote:
> On Thu, 14 May 2009, K.Prasad wrote:
>
> > Index: linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
> > ===================================================================
> > --- linux-2.6-tip.hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c 2009-05-14 00:17:24.000000000 +0530
> > +++ linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c 2009-05-14 00:58:06.000000000 +0530
> > @@ -54,6 +54,10 @@
> > sample_hbp.info.type = HW_BREAKPOINT_WRITE;
> > sample_hbp.info.len = HW_BREAKPOINT_LEN_4;
> > #endif /* CONFIG_X86 */
> > +#ifdef CONFIG_PPC64
> > + sample_hbp.info.name = ksym_name;
> > + sample_hbp.info.type = DABR_DATA_WRITE;
>
> This should be HW_BREAKPOINT_WRITE, not DABR_DATA_WRITE.
>
> Alan Stern
>
Done. Thanks.
-- K.Prasad
^ permalink raw reply
* Re: [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
From: K.Prasad @ 2009-05-18 16:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Michael Neuling, Alan Stern, Roland McGrath, paulus
In-Reply-To: <1242617732.18075.29.camel@pasglop>
On Mon, May 18, 2009 at 01:35:32PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-14 at 19:13 +0530, K.Prasad wrote:
> > plain text document attachment (ppc64_prepare_code_01)
> > Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
> > relevant constant definitions and function declarations.
>
> Hi !
>
> Some comments below...
>
> > +#define HBP_NUM 1 /* Number of physical HW breakpoint registers */
>
> Can you use a more verbose constant ? reg.h is included everywhere so
> the risk of collision is high.
>
This constant is used by the generic HW Breakpoint code in
kernel/hw_breakpoint.c too and renaming it here will require changes
there too, while I don't see any existing name-space clashes.
Instead the definition can be moved into arch/powerpc/include/asm/hw_breakpoint.h
and in arch/power/include/asm/processor.h. What do you think?
> > #define DABR_TRANSLATION (1UL << 2)
> > #define DABR_DATA_WRITE (1UL << 1)
> > #define DABR_DATA_READ (1UL << 0)
> > +#define DABR_DATA_RW (3UL << 0)
>
> Do you really need that ? It's just DABR_DATA_WRITE | DABR_DATA_READ :-)
>
Yes, it looks silly. I will remove it. The HW_BREAKPOINT_RW defined in
arch/powerpc/include/asm/hw_breakpoint.h will instead be defined as:
#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)
> Cheers,
> Ben.
>
Thanks,
K.Prasad
^ permalink raw reply
* Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
From: Alan Stern @ 2009-05-18 16:30 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Roland McGrath
In-Reply-To: <20090518161055.GA27641@in.ibm.com>
On Mon, 18 May 2009, K.Prasad wrote:
> > > > > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > > > > +{
> > > > > + int rc = NOTIFY_STOP;
> > > > > + struct hw_breakpoint *bp;
> > > > > + struct pt_regs *regs = args->regs;
> > > > > + unsigned long dar;
> > > > > + int cpu, stepped, is_kernel;
> > > > > +
> > > > > + /* Disable breakpoints during exception handling */
> > > > > + set_dabr(0);
> > > > > +
> > > > > + dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
> > > > > + is_kernel = (dar >= TASK_SIZE) ? 1 : 0;
> > > >
> > > > is_kernel_addr() ?
> > > >
> > >
> > > Ok.
> >
> > Shouldn't this test hbp_kernel_pos instead?
> >
>
> Testing hbp_kernel_pos should be sufficient for PPC64 with just one
> breakpoint register. However the above code is more extensible to other
> PowerPC implementations which have more than one breakpoint register.
Then maybe you don't want to test this at all. Just compare the dar
value with each of the breakpoint addresses. That's more like what the
x86 code does.
Alan Stern
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Scott Wood @ 2009-05-18 17:10 UTC (permalink / raw)
To: Chris Plasun; +Cc: linuxppc-dev
In-Reply-To: <4A0FCEAA.5000606@yahoo.com>
On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
> Hi,
>
> (I haven't found any answers in the archives)
>
> How would I access a NTFS shared directory from a Freescale MPC8313?
>
> Will Samba run on a Freescale MPC8313?
It should (and if it doesn't, file a bug with them).
Userspace is pretty much the same at the source-code and user-interface
level -- the answer to "how do I do X on this PPC board" is generally the
same as the answer to "how do I do X on Linux", other than that you may
need to compile some packages manually if they don't come with whatever
distribution you're using.
-Scott
^ permalink raw reply
* Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
From: Mel Gorman @ 2009-05-18 17:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List, ebmunson
In-Reply-To: <1241128126.29501.48.camel@pasglop>
On Fri, May 01, 2009 at 07:48:46AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-04-30 at 21:59 +0100, Mel Gorman wrote:
>
> > This patch fixes the problem by not asseting the PTE is locked for VMAs
> > backed by huge pages.
>
> Thanks, will apply.
>
What's the story with this patch? I'm still hearing of failures with huge pages
that this patch fixes but I'm no seeing it upstream. Was the patch
rejected or did it just slip through the cracks?
To refresh, an assertion is being made on ppc64 that only makes sense for
base pages. Hugepages through a wobbly every time. For convenience, here is
the patch again.
Thanks.
==== CUT HERE ====
powerpc: Do not assert pte_locked for hugepage PTE entries
With DEBUG_VM enabled, an assertion is made when changing the protection
flags of a PTE that the PTE is locked. Huge pages use a different
pagetable format and the assertion is bogus and will always trigger with
a bug looking something like
Unable to handle kernel paging request for data at address 0xf1a00235800006f8
Faulting instruction address: 0xc000000000034a80
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA Maple
Modules linked in: dm_snapshot dm_mirror dm_region_hash
dm_log dm_mod loop evdev ext3 jbd mbcache sg sd_mod ide_pci_generic
pata_amd ata_generic ipr libata tg3 libphy scsi_mod windfarm_pid
windfarm_smu_sat windfarm_max6690_sensor windfarm_lm75_sensor
windfarm_cpufreq_clamp windfarm_core i2c_powermac
NIP: c000000000034a80 LR: c000000000034b18 CTR: 0000000000000003
REGS: c000000003037600 TRAP: 0300 Not tainted (2.6.30-rc3-autokern1)
MSR: 9000000000009032 <EE,ME,IR,DR> CR: 28002484 XER: 200fffff
DAR: f1a00235800006f8, DSISR: 0000000040010000
TASK = c0000002e54cc740[2960] 'map_high_trunca' THREAD: c000000003034000 CPU: 2
GPR00: 4000000000000000 c000000003037880 c000000000895d30 c0000002e5a2e500
GPR04: 00000000a0000000 c0000002edc40880 0000005700000393 0000000000000001
GPR08: f000000011ac0000 01a00235800006e8 00000000000000f5 f1a00235800006e8
GPR12: 0000000028000484 c0000000008dd780 0000000000001000 0000000000000000
GPR16: fffffffffffff000 0000000000000000 00000000a0000000 c000000003037a20
GPR20: c0000002e5f4ece8 0000000000001000 c0000002edc40880 0000000000000000
GPR24: c0000002e5f4ece8 0000000000000000 00000000a0000000 c0000002e5f4ece8
GPR28: 0000005700000393 c0000002e5a2e500 00000000a0000000 c000000003037880
NIP [c000000000034a80] .assert_pte_locked+0xa4/0xd0
LR [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
Call Trace:
[c000000003037880] [c000000003037990] 0xc000000003037990 (unreliable)
[c000000003037910] [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
[c0000000030379b0] [c00000000014bef8] .hugetlb_cow+0x124/0x674
[c000000003037b00] [c00000000014c930] .hugetlb_fault+0x4e8/0x6f8
[c000000003037c00] [c00000000013443c] .handle_mm_fault+0xac/0x828
[c000000003037cf0] [c0000000000340a8] .do_page_fault+0x39c/0x584
[c000000003037e30] [c0000000000057b0] handle_page_fault+0x20/0x5c
Instruction dump:
7d29582a 7d200074 7800d182 0b000000 3c004000 3960ffff 780007c6 796b00c4
7d290214 7929a302 1d290068 7d6b4a14 <800b0010> 7c000074 7800d182 0b000000
This patch fixes the problem by not asseting the PTE is locked for VMAs
backed by huge pages.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
arch/powerpc/mm/pgtable.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index f5c6fd4..ae1d67c 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -219,7 +219,8 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
entry = do_dcache_icache_coherency(entry);
changed = !pte_same(*(ptep), entry);
if (changed) {
- assert_pte_locked(vma->vm_mm, address);
+ if (!(vma->vm_flags & VM_HUGETLB))
+ assert_pte_locked(vma->vm_mm, address);
__ptep_set_access_flags(ptep, entry);
flush_tlb_page_nohash(vma, address);
}
^ permalink raw reply related
* Re: fs_enet build breakage
From: Scott Wood @ 2009-05-18 17:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <9732983B-B67C-4831-BBAB-65472BE0F279@kernel.crashing.org>
On Mon, May 18, 2009 at 08:23:17AM -0500, Kumar Gala wrote:
>
> On May 18, 2009, at 2:01 AM, Benjamin Herrenschmidt wrote:
>
> >Hi Kumar
> >
> >Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch
> >breaks my 8xx test config with the following error:
> >
> >/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In
> >function ‘setup_immap’:
> >/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:
> >947: error: ‘IMAP_ADDR’ undeclared (first use in this function)
> >/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:
> >947: error: (Each undeclared identifier is reported only once
> >/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:
> >947: error: for each function it appears in.)
> >
> >I'm still pushing it with a bunch of other stuff to "test" so people
> >get
> >to find more breakage but it will need to be fixed for the actual
> >"next"
> >branch.
> >
> >Cheers,
> >Ben.
> >
>
> I'm pretty sure the driver changes to address this are in dave's net-
> next tree.
Won't this break git bisect?
Not to mention anyone trying to use your tree now...
-Scott
^ permalink raw reply
* Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
From: Linus Torvalds @ 2009-05-18 17:26 UTC (permalink / raw)
To: Mel Gorman; +Cc: ebmunson, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20090518171322.GB13093@csn.ul.ie>
On Mon, 18 May 2009, Mel Gorman wrote:
>
> What's the story with this patch? I'm still hearing of failures with huge pages
> that this patch fixes but I'm no seeing it upstream. Was the patch
> rejected or did it just slip through the cracks?
It didn't slip through the cracks, it was apparently just delayed. It's
part of the merge requests I've gotten today (well, strictly speaking it
seems to have hit my inbox just before midnight yesterday, but that's
because those silly aussies stand upside down and sleep at odd hours).
In fact, I just merged it, I haven't even had time to push that out.
Linus
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 17:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC
In-Reply-To: <1242617089.18075.25.camel@pasglop>
On Mon, May 18, 2009 at 01:24:49PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-05-15 at 20:18 +0200, Gabriel Paubert wrote:
> > Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
> > will not work wihtout arch/powerpc/platforms/chrp/pegasos_eth.
> >
> > The patch also removes all references to MV64360 config option which
> > no more exists.
> >
> > Signed-off-by: Gabriel Paubert <paubert@iram.es>
>
> Please break that up into 2 different patches. The arch/powerpc one that
> removes the reference from IRQ_ALL_CPUs and the drivers/net/ one which
> should be set to the netdev mailing list.
>
Ok, but I have a doubt about the PPC one, should MV64360 be removed or
changed to MV64X60?
In any case, I can't test it.
Gabriel
^ permalink raw reply
* [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 17:37 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: tbm, LinuxPPC, pacman, netdev, David Miller
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix by allowing to select
the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
will not work without arch/powerpc/platforms/chrp/pegasos_eth.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 214a92d..6fc0ff4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) || PLAT_ORION
+ depends on MV64X60 || PPC_CHRP || PLAT_ORION
select INET_LRO
select PHYLIB
help
^ permalink raw reply related
* mpc5200 fec error
From: Eric Millbrandt @ 2009-05-18 17:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]
Hello all,
I am testing a 2.6.29.3 (with preempt_rt patches) kernel on a phytec
pcm030 and am getting a kernel hang when testing the fec Ethernet
controller. The error only occurs when running the preempt-patched
kernel, an unmodified kernel works fine. Is anyone out there using
preempt_rt on an MPC5200 successfully?
Eric
root@rudolph-ui:/root> iperf -c linux-5200bdevl01 -P 2 -i 1 -p 5001 -f k
-t 600
------------------------------------------------------------
Client connecting to linux-5200bdevl01, TCP port 5001
TCP window size: 36.2 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.4.88 port 37872 connected with 10.1.5.234 port 5001
[ 3] local 10.1.4.88 port 37871 connected with 10.1.5.234 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 3824 KBytes 31326 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 3656 KBytes 29950 Kbits/sec
[SUM] 0.0- 1.0 sec 7480 KBytes 61276 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 1.0- 2.0 sec 3760 KBytes 30802 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 1.0- 2.0 sec 3752 KBytes 30736 Kbits/sec
[SUM] 1.0- 2.0 sec 7512 KBytes 61538 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 2.0- 3.0 sec 3728 KBytes 30540 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 2.0- 3.0 sec 3816 KBytes 31261 Kbits/sec
[SUM] 2.0- 3.0 sec 7544 KBytes 61800 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 3.0- 4.0 sec 3712 KBytes 30409 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 3.0- 4.0 sec 3824 KBytes 31326 Kbits/sec
[SUM] 3.0- 4.0 sec 7536 KBytes 61735 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 4.0- 5.0 sec 3968 KBytes 32506 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 4.0- 5.0 sec 3624 KBytes 29688 Kbits/sec
[SUM] 4.0- 5.0 sec 7592 KBytes 62194 Kbits/sec
[ 5761.999175] net eth0: transmit queue overrun
[ 5762.003591] net eth0: transmit queue overrun
[ 5762.007948] net eth0: transmit queue overrun
[ 5762.012302] net eth0: transmit queue overrun
[ 5762.016658] net eth0: transmit queue overrun
[ 5762.021013] net eth0: transmit queue overrun
[ 5762.025381] net eth0: transmit queue overrun
[ 5762.029735] net eth0: transmit queue overrun
[ 5762.034090] net eth0: transmit queue overrun
[ 5762.038445] net eth0: transmit queue overrun
[ 5767.000928] net eth0: transmit queue overrun
[ 5767.005278] net eth0: transmit queue overrun
[ 5767.009634] net eth0: transmit queue overrun
[ 5767.013990] net eth0: transmit queue overrun
[ 5767.018345] net eth0: transmit queue overrun
[ 5767.022701] net eth0: transmit queue overrun
...
_________________________________________________________________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
[-- Attachment #2: Type: text/html, Size: 12384 bytes --]
^ permalink raw reply
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 17:48 UTC (permalink / raw)
To: Gabriel Paubert, Lennert Buytenhek
Cc: LinuxPPC, David Miller, pacman, tbm, netdev
In-Reply-To: <20090518173756.GA11805@iram.es>
> -----Original Message-----
> From: linuxppc-dev-bounces+emilian.medve=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+emilian.medve=3Dfreescale.com@ozlabs.org] On Behalf Of Gabriel
Paubert
> Sent: Monday, May 18, 2009 12:38 PM
> To: Lennert Buytenhek
> Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David Miller
> Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> the driver on CHRP platforms; Pegasos is a CHRP platform and the
driver
> will not work without arch/powerpc/platforms/chrp/pegasos_eth.
>=20
> Signed-off-by: Gabriel Paubert <paubert@iram.es>
>=20
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 214a92d..6fc0ff4 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
>=20
> config MV643XX_ETH
> tristate "Marvell Discovery (643XX) and Orion ethernet support"
> - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
PLAT_ORION
> + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> select INET_LRO
> select PHYLIB
> help
This got fixed here:
http://git.kernel.org/?p=3Dlinux/kernel/git/davem/net-next-2.6.git;a=3Dco=
mmi
tdiff;h=3D952ee9df26c487f2d73b2dced58ec904f19ea0f8
Cheers,
Emil.
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Chris Plasun @ 2009-05-18 18:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090518171028.GA18620@b07421-ec1.am.freescale.net>
Scott Wood wrote:
> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>> Hi,
>>
>> (I haven't found any answers in the archives)
>>
>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>
>> Will Samba run on a Freescale MPC8313?
>
> It should (and if it doesn't, file a bug with them).
>
> Userspace is pretty much the same at the source-code and user-interface
> level -- the answer to "how do I do X on this PPC board" is generally the
> same as the answer to "how do I do X on Linux", other than that you may
> need to compile some packages manually if they don't come with whatever
> distribution you're using.
Thanks Scott.
I did some more reading on the board and it appears that it's not as
limited as I thought. The "custom" Linux we're running is very limited
(so it appears) and I interpreted the board to be so as well.
I'm a Windows ASP.NET developer thrown off the deep end into Linux so
please forgive the noob questions. After going through many post it
appears my questions are pertinent to general Linux.
Thank you!
Chris Plasun
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Leon Woestenberg @ 2009-05-18 18:18 UTC (permalink / raw)
To: Chris Plasun; +Cc: linuxppc-dev
In-Reply-To: <4A11A3B4.7060801@yahoo.com>
Hello Chris,
On Mon, May 18, 2009 at 8:06 PM, Chris Plasun <chrispl78@yahoo.com> wrote:
> Scott Wood wrote:
>> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>>> (I haven't found any answers in the archives)
>>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>> Will Samba run on a Freescale MPC8313?
>>
>> It should (and if it doesn't, file a bug with them).
>> Userspace is pretty much the same at the source-code and user-interface
>> level -- the answer to "how do I do X on this PPC board" is generally the
>> same as the answer to "how do I do X on Linux", other than that you may
>> need to compile some packages manually if they don't come with whatever
>> distribution you're using.
>
> Thanks Scott.
>
> I did some more reading on the board and it appears that it's not as limited
> as I thought. The "custom" Linux we're running is very limited (so it
> appears) and I interpreted the board to be so as well.
>
To build your own fully-open Linux for this board, I can recommend
both these projects:
LTIB (http://www.bitshrine.org/)
OpenEmbedded (http://www.openembedded.org/)
We use the latter in an industrial setting with much success,
Regards,
--
Leon
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Chris Plasun @ 2009-05-18 18:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <c384c5ea0905181118g34896cc3s1e77b9ba22c4e164@mail.gmail.com>
Hi Leon,
Leon Woestenberg wrote:
> Hello Chris,
>
> On Mon, May 18, 2009 at 8:06 PM, Chris Plasun <chrispl78@yahoo.com> wrote:
>> Scott Wood wrote:
>>> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>>>> (I haven't found any answers in the archives)
>>>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>>> Will Samba run on a Freescale MPC8313?
>>> It should (and if it doesn't, file a bug with them).
>>> Userspace is pretty much the same at the source-code and user-interface
>>> level -- the answer to "how do I do X on this PPC board" is generally the
>>> same as the answer to "how do I do X on Linux", other than that you may
>>> need to compile some packages manually if they don't come with whatever
>>> distribution you're using.
>> Thanks Scott.
>>
>> I did some more reading on the board and it appears that it's not as limited
>> as I thought. The "custom" Linux we're running is very limited (so it
>> appears) and I interpreted the board to be so as well.
>>
>
> To build your own fully-open Linux for this board, I can recommend
> both these projects:
>
> LTIB (http://www.bitshrine.org/)
> OpenEmbedded (http://www.openembedded.org/)
>
> We use the latter in an industrial setting with much success,
Thanks Leon. I'll definitely be back to ask for help to get these
distributions running =)
cp
^ permalink raw reply
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