John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so tha
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO
base/limit
and Mem base/limit of the bridge (:00:02.0) because of the
following
lines.
static void
Hello, Kenji-san
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's failure seems PPC specific
> -Original Message-
> From: Michal Simek [mailto:michal.si...@petalogix.com]
> Sent: Monday, March 15, 2010 2:40 AM
> To: John Linn
> Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
> jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
> Subj
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyn
> -Original Message-
> From: Michal Simek [mailto:michal.si...@petalogix.com]
> Sent: Monday, March 15, 2010 8:40 AM
> To: John Linn
> Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
> jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
> Subj
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 8:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyn
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of John
Linn
> Sent: Friday, March 12, 2010 5:06 PM
> To: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
gra
> -Original Message-
> From: Stephen Neuendorffer
> Sent: Monday, March 15, 2010 11:03 AM
> To: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
> jwbo...@linux.vnet.ibm.com
> Cc: michal.si...@petalogix.com; John Tyner;
john.willi...@petalogix.com
> Su
> This implements a powerpc version of perf_arch_fetch_caller_regs.
> It's implemented in assembly because that way we can be sure there
> isn't a stack frame for perf_arch_fetch_caller_regs. If it was in
> C, gcc might or might not create a stack frame for it, which would
> affect the number of l
On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote:
> This implements a powerpc version of perf_arch_fetch_caller_regs.
> It's implemented in assembly because that way we can be sure there
> isn't a stack frame for perf_arch_fetch_caller_regs. If it was in
> C, gcc might or might not c
I have fixed some typos.
Thomas Weber (4):
Fix typo: [Ss]ytem => [Ss]ystem
Fix typo: udpate => update
Fix typo: paramters => parameters
Fix typo: orginal => original
Documentation/cgroups/cgroups.txt |2 +-
Documentation/kbuild/kconfig.txt|2 +-
Docu
On 03/15/10 13:55, Thomas Weber wrote:
> I have fixed some typos.
Acked-by: Randy Dunlap
Jiri, can you merge these, please, unless someone objects (?).
> Thomas Weber (4):
> Fix typo: [Ss]ytem => [Ss]ystem
> Fix typo: udpate => update
> Fix typo: paramters => parameters
> Fix typo: org
This fixes these warnings:
drivers/base/cpu.c:264: warning: initialization from incompatible pointer type
drivers/base/cpu.c:265: warning: initialization from incompatible pointer type
Cc: Andi Kleen
Signed-off-by: Stephen Rothwell
---
drivers/base/cpu.c | 16
1 files change
On Tue, Mar 16, 2010 at 10:33:32AM +1100, Stephen Rothwell wrote:
> This fixes these warnings:
>
> drivers/base/cpu.c:264: warning: initialization from incompatible pointer type
> drivers/base/cpu.c:265: warning: initialization from incompatible pointer type
>
> Cc: Andi Kleen
> Signed-off-by: S
On Fri, 12 Mar 2010 20:12:40 +0100
Albert Herranz wrote:
> The current SWIOTLB code uses a default of 64MB for the IO TLB area.
> This size can be influenced using a kernel command line parameter "swiotlb".
> Unfortunately, the parsing of the kernel command line is done _after_ the
> swiotlb is i
On Fri, 12 Mar 2010 20:12:39 +0100
Albert Herranz wrote:
> The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms.
> This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by
> adding two platform specific functions swiotlb_dma_sync_page() and
> swiotlb_dma_sync() whi
On Tue, 16 Mar 2010 10:54:40 +0900
FUJITA Tomonori wrote:
> On Fri, 12 Mar 2010 20:12:39 +0100
> Albert Herranz wrote:
>
> > The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms.
> > This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by
> > adding two platform
On Mon, Mar 15, 2010 at 10:04:54PM +0100, Frederic Weisbecker wrote:
> On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote:
> > 14.99%perf [kernel.kallsyms] [k] ._raw_spin_lock
> > |
> > --- ._raw_spin_lock
> >
Hi,
I need a deeper understanding of priorities of linux processes and
threads, especially on Linux PPC. I have done some good reading, but
found no material to be complete and therefore I am raising a few
questions below.
1) In Linux processes have a static priority level 0, with nice values
-20
> I need a deeper understanding of priorities of linux processes and
> threads, especially on Linux PPC. I have done some good reading, but
> found no material to be complete and therefore I am raising a few
> questions below.
>
> 1) In Linux processes have a static priority level 0, with nice val
Felix Radensky wrote:
Hello, Kenji-san
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's fai
FUJITA Tomonori wrote:
> On Fri, 12 Mar 2010 20:12:40 +0100
> Albert Herranz wrote:
>
>> The current SWIOTLB code uses a default of 64MB for the IO TLB area.
>> This size can be influenced using a kernel command line parameter "swiotlb".
>> Unfortunately, the parsing of the kernel command line is
FUJITA Tomonori wrote:
> On Fri, 12 Mar 2010 20:12:39 +0100
> Albert Herranz wrote:
>
>> The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms.
>> This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by
>> adding two platform specific functions swiotlb_dma_sync_pag
FUJITA Tomonori wrote:
> If we want to make swiotlb generic (make on any architectures), we
> need to handle more cache issues here, I think. So it's better to have
> more generic ways instead of adding hooks to some archs.
>
Ok. So what would be an acceptable way of handling this in a generic wa
25 matches
Mail list logo
