> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 19, 2010 0:07 AM
> To: tiejun.chen
> Cc: Zang Roy-R61911; linux-...@lists.infradead.org; Wood Scott-B07421;
> dedeki...@gmail.com; Lan Chunhe-B25806; linuxppc-...@ozlabs.org;
a...@linux-
> foundation.org; dw...@infrade
Hi again,
On Tue, 19 Oct 2010 15:48:49 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in
> arch/powerpc/kernel/time.c between commit
> cf9efce0ce3136fa076f53e53154e98455229514 ("powerpc: Account time using
> timebase rather than PURR") from the powerpc
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/powerpc/kernel/time.c between commit
cf9efce0ce3136fa076f53e53154e98455229514 ("powerpc: Account time using
timebase rather than PURR") from the powerpc tree and commit
e360adbe29241a0194e10e20595360dd7b98a2b3 ("irq_work: Add
Scott Wood wrote:
> On Mon, 18 Oct 2010 16:40:42 +0800
> "tiejun.chen" wrote:
>
>> Shawn Jin wrote:
>>> Hi,
>>>
>>> My target is a mpc875 based board and has FEC ethernet. The phy is
>>> AM79C874. I have the following configuration for the network support.
>>>
>>> CONFIG_PHYLIB=y
>>> CONFIG_NET_E
Scott Wood wrote:
> On Mon, 18 Oct 2010 16:55:49 +0800
> "tiejun.chen" wrote:
>
>> Looks you always iounmap(fsl_lbc_ctrl_dev->regs) on position 'err' but here
>> of_iomap() is already failed you should skip iounmap() fsl_lbc_ctrl_dev->regs
>> again. So you should improve that as the following on
Steven Rostedt wrote:
> On Mon, 2010-10-18 at 11:19 +0800, Li Zefan wrote:
>
>> This is a dead loop:
>>
>> trace_hcall_entry() -> trace_clock_global() -> trace_hcall_entry() ..
>>
>> And this is a PPC specific bug. Hope some ppc guys will fix it?
>> Or we kill trace_clock_global() if no one actual
On Mon, 2010-10-18 at 16:57 -0500, Dave Kleikamp wrote:
>
> I didn't like the implementation of a per-core stale map. The existing
> implementation flushes the core's tlb, but only clears a specific entry
> from the stale map. It's dealing with the stale contexts one at a time,
> where the new f
On Oct 18, 2010, at 5:32 PM, Scott Wood wrote:
> If mem= is used on the kernel command line to create reserved regions
> for userspace to map using /dev/mem, let it be mapped cacheable as long
> as it is within the memory region described in the device tree.
>
> Signed-off-by: Scott Wood
> ---
If mem= is used on the kernel command line to create reserved regions
for userspace to map using /dev/mem, let it be mapped cacheable as long
as it is within the memory region described in the device tree.
Signed-off-by: Scott Wood
---
This isn't just a performance issue, but it could also be a c
On Thu, 2010-10-14 at 11:52 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2010-09-24 at 13:01 -0500, Dave Kleikamp wrote:
> > On PPC_MMU_NOHASH processors that support a large number of contexts,
> > implement a lazy flush_tlb_mm() that switches to a free context, marking
> > the old one stale. T
On Mon, 18 Oct 2010, Andrew Morton wrote:
> On Mon, 18 Oct 2010 12:33:31 +0100
> Mel Gorman wrote:
>
> > A bit but I still don't know why it would cause corruption. Maybe this is
> > still
> > a caching issue but the difference in timing between list_add and
> > list_add_tail
> > is enough to
Benjamin Herrenschmidt writes:
>
> You can do something fun... like a timer interrupt that peeks at those
> physical addresses from the linear mapping for example, and try to find
> out "when" they get set to the wrong value (you should observe the load
> from disk, then the corruption, unless the
On Mon, 2010-10-18 at 14:10 -0500, pac...@kosh.dhis.org wrote:
> I've been flailing around quite a bit. Here's my latest result:
>
> Since I can view the corruption with md5sum /sbin/e2fsck, I know it's in a
> clean cached page. So I made an extra copy of /sbin/e2fsck, which won't be
> loaded int
On Mon, 2010-10-18 at 12:37 -0700, Andrew Morton wrote:
> Well, you've spotted a bug so I'd say we fix it asap.
>
> It's a bit of a shame that we lose the only known way of reproducing a
> different bug, but presumably that will come back and bite someone
> else
> one day, and we'll fix it then :(
On Wed, 2010-10-13 at 15:40 +0100, Mel Gorman wrote:
>
> This is somewhat contrived but I can see how it might happen even on one
> CPU particularly if the L1 cache is virtual and is loose about checking
> physical tags.
>
> > How sensitive/vulnerable is PPC32 to such things?
> >
>
> I can not
On Mon, 18 Oct 2010 12:33:31 +0100
Mel Gorman wrote:
> A bit but I still don't know why it would cause corruption. Maybe this is
> still
> a caching issue but the difference in timing between list_add and
> list_add_tail
> is enough to hide the bug. It's also possible there are some registers
>
Mel Gorman writes:
>
> A bit but I still don't know why it would cause corruption. Maybe this is
> still
> a caching issue but the difference in timing between list_add and
> list_add_tail
> is enough to hide the bug. It's also possible there are some registers
> ioremapped after the memmap arra
direct_dma_ops is the default pci dma ops.
No need to call a function to get the pci dma ops, we know they are the
dma_direct_ops.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
Acked-by: Arnd Bergmann
---
arch/powerpc/platforms/cell/beat_iommu.c |3 +--
1 files changed,
> >
> > I am trying to resubmit a patch for MSI support for ppc4xx devices.
> > One of the review feedback was not to use the bit map as it is only
> > for the devices which don’t have hard wired mapping between interrupt
> > controller interrupts and MSI number. For example intr-ctrl0
> interrupt
Eran Liberty wrote:
This should probably go to the Freescale support, as it feels like a
hardware issue yet the end result is a very frozen Linux kernel so I
post here first...
I have a programmable FPGA PCIe device connected to a Freescale's
P2020 PCIe port. As part of the bring-up tests, we
No need to initialize per-cpu pointer to NULL, it is the default.
Direct dma ops and no setup are the defaults, no need to set for
iommu-off.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
Reviewed-by: Grant Likely
---
arch/powerpc/platforms/pseries/iommu.c |9 ++---
Use set_dma_ops and remove now used-once oddly named temp pointer sd.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
Cc: b...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/microblaze/pci/pci-common.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(
The IOMMU code has been passing the dma-mask instead of the
coherent_dma_mask to the iommu allocator. Coherent allocations should
be made using the coherent_dma_mask.
Also update the vio code to ensure the coherent_dma_mask is set. Without
this change drivers, such as ibmvscsi, fail to load with
Use the set_dma_ops helper. Instead of modifying vio_dma_mapping_ops,
just create a trivial wrapper for dma_supported.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/vio.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/sysdev/dart_iommu.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/s
No need for empty helpers with iommu off, the ppc_md hooks are optional.
The direct_dma_ops are the default pci_dma_ops, so no need to set in the
them iommu off case.
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
Signed-off-by: Milton Miller
On Mon, 18 Oct 2010 16:40:42 +0800
"tiejun.chen" wrote:
> Shawn Jin wrote:
> > Hi,
> >
> > My target is a mpc875 based board and has FEC ethernet. The phy is
> > AM79C874. I have the following configuration for the network support.
> >
> > CONFIG_PHYLIB=y
> > CONFIG_NET_ETHERNET=y
> > CONFIG_MI
On Mon, 18 Oct 2010 16:55:49 +0800
"tiejun.chen" wrote:
> Looks you always iounmap(fsl_lbc_ctrl_dev->regs) on position 'err' but here
> of_iomap() is already failed you should skip iounmap() fsl_lbc_ctrl_dev->regs
> again. So you should improve that as the following on 'err', or layout 'err'
> i
>Hello all,
>I'm sure there's a standard way of doing this: I'd like to access some info
>from the DTS file from a usermode program (things like address of device,
>etc...)
>What is the best way to do this ? Write a parser ? Or query the running kernel
>somehow ?
Compile your kernel with CONFIG
On Mon, 2010-10-18 at 11:19 +0800, Li Zefan wrote:
> This is a dead loop:
>
> trace_hcall_entry() -> trace_clock_global() -> trace_hcall_entry() ..
>
> And this is a PPC specific bug. Hope some ppc guys will fix it?
> Or we kill trace_clock_global() if no one actually uses it..
trace_clock_glob
On Mon, Oct 18, 2010 at 02:13:58PM +0200, Guillaume Dargaud wrote:
> Hello all,
> I'm sure there's a standard way of doing this: I'd like to access some info
> from the DTS file from a usermode program (things like address of device,
> etc...)
> What is the best way to do this ? Write a parser ?
Replaces possibly damaging broadcast writes into the per-port SP_MODE
registers with individual writes for each port. This will preserve
individual port configurations in case if ports are configured differently.
Signed-off-by: Alexandre Bounine
Cc: Kumar Gala
Cc: Matt Porter
Cc: Li Yang
Cc: T
Replace hardcoded maximum port number with actual reported number of
switch ports.
Signed-off-by: Alexandre Bounine
Cc: Kumar Gala
Cc: Matt Porter
Cc: Li Yang
Cc: Thomas Moll
Cc: Micha Nelissen
---
drivers/rapidio/switches/tsi57x.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-
Hello all,
I'm sure there's a standard way of doing this: I'd like to access some info
from the DTS file from a usermode program (things like address of device,
etc...)
What is the best way to do this ? Write a parser ? Or query the running kernel
somehow ?
--
Guillaume Dargaud
http://www.gdarg
tiejun.chen wrote:
AFAIK we can set one bit on PEX_ERR_DISR to detect PCI Express completion
time-out. If so one interrupt should be issued. But I'm not sure if this can fix
your issue.
Tiejun
As I understand the problem, this will not help me as the CPU itself is
on hold waiting for the ass
On Wed, Oct 13, 2010 at 12:52:05PM -0500, pac...@kosh.dhis.org wrote:
> Mel Gorman writes:
> >
> > On Mon, Oct 11, 2010 at 02:00:39PM -0700, Andrew Morton wrote:
> > >
> > > It's corruption of user memory, which is unusual. I'd be wondering if
> > > there was a pre-existing bug which 6dda9d55bf5
On Mon, 2010-10-18 at 11:19 +0800, Li Zefan wrote:
> Cc: Steven
> Cc: Ingo
> Cc: Peter
> Cc: Anton Blanchard
> Cc: Paul Mackerras
>
> For those Cced, More information here:
>
> http://marc.info/?l=ltp-list&m=128569007015044&w=2
> http://marc.info/?l=ltp-list&m=128696942432669&w=2
Hrm... that's
On Mon, 2010-10-18 at 10:44 +1100, Michael Neuling wrote:
> > Greetings Linux-ppc64 folks,
> >
> > While trying to compile v2.6.36-rc8 with PAGE_SIZE=65536 I run into the
> > following compile failure w/ strict checking on a RHEL5.4 / gcc (GCC)
> > 4.1.2 20080704 (Red Hat 4.1.2-46) system:
> >
>
Eran Liberty wrote:
> This should probably go to the Freescale support, as it feels like a
> hardware issue yet the end result is a very frozen Linux kernel so I
> post here first...
>
> I have a programmable FPGA PCIe device connected to a Freescale's P2020
> PCIe port. As part of the bring-up te
tiejun.chen wrote:
> Zang Roy-R61911 wrote:
>>> -Original Message-
>>> From: tiejun.chen [mailto:tiejun.c...@windriver.com]
>>> Sent: Monday, October 18, 2010 16:56 PM
>>> To: Zang Roy-R61911
>>> Cc: linux-...@lists.infradead.org; Wood Scott-B07421; dedeki...@gmail.com;
>>> Lan
>>> Chunhe-
Zang Roy-R61911 wrote:
>
>> -Original Message-
>> From: tiejun.chen [mailto:tiejun.c...@windriver.com]
>> Sent: Monday, October 18, 2010 16:56 PM
>> To: Zang Roy-R61911
>> Cc: linux-...@lists.infradead.org; Wood Scott-B07421; dedeki...@gmail.com;
>> Lan
>> Chunhe-B25806; linuxppc-...@ozla
> -Original Message-
> From: tiejun.chen [mailto:tiejun.c...@windriver.com]
> Sent: Monday, October 18, 2010 16:56 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; Wood Scott-B07421; dedeki...@gmail.com; Lan
> Chunhe-B25806; linuxppc-...@ozlabs.org; a...@linux-foundation.org;
Roy Zang wrote:
> Move Freescale elbc interrupt from nand dirver to elbc driver.
> Then all elbc devices can use the interrupt instead of ONLY nand.
>
> For former nand driver, it had the two functions:
>
> 1. detecting nand flash partitions;
> 2. registering elbc interrupt.
>
> Now, second func
Shawn Jin wrote:
> Hi,
>
> My target is a mpc875 based board and has FEC ethernet. The phy is
> AM79C874. I have the following configuration for the network support.
>
> CONFIG_PHYLIB=y
> CONFIG_NET_ETHERNET=y
> CONFIG_MII=y
> CONFIG_FS_ENET=y
> CONFIG_FS_ENET_HAS_FEC=y
> CONFIG_FS_ENET_MDIO_FEC=
Maria Johansen wrote:
Hello,
(apologies for writing such a long e-mail, hope you can bother to read it all ☺
)
I have some difficulties with the eSDHC controller driver used on a MPC8308 evaluation board with kernel 2.6.36-rc7, and hope that some of you may be able to help me with the debugging.
WANG YiFei wrote:
> Hi,
>
> We have a board which has 1 SPI master controller and 4 SPI slave devices,
> and we'd like to use 2 GPIOs to demux to chip select these slave devices.
> Can anyone tell me if current powerpc dts support demuxer for chip select for
> spi slave devices? So far as I know
Hi,
My target is a mpc875 based board and has FEC ethernet. The phy is
AM79C874. I have the following configuration for the network support.
CONFIG_PHYLIB=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_FS_ENET=y
CONFIG_FS_ENET_HAS_FEC=y
CONFIG_FS_ENET_MDIO_FEC=y
However I found that the phy support
From: Lan Chunhe-B25806
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Sign
Move Freescale elbc interrupt from nand dirver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.
For former nand driver, it had the two functions:
1. detecting nand flash partitions;
2. registering elbc interrupt.
Now, second function is removed to fsl_lbc.c.
Sig
49 matches
Mail list logo
