On Mon, Sep 27, 2010 at 10:14:23AM -0600, M. Warner Losh wrote:
This is a common error that I've seen repeated in this thread. The
only reason that it has historically been important is because when
you are doing timestamping in software based on an interrupt, that
stuff does matter.
Yes,
On Mon, Sep 27, 2010 at 06:05:58PM +0100, Alan Cox wrote:
On Mon, 27 Sep 2010 10:56:09 -0500 (CDT)
Christoph Lameter c...@linux.com wrote:
On Fri, 24 Sep 2010, Alan Cox wrote:
Whether you add new syscalls or do the fd passing using flags and hide
the ugly bits in glibc is another
This is version 2 of patches to add MPC512x USB support in
mainline kernel. USB OTG support is not included in this
patch series, it will be submitted later.
The patches have been rebased on current linux-next tree
and reworked to address comments from Grant.
Anatolij Gustschin (3):
This removed code will be replaced by simple of_platform
driver for creation of FSL USB platform devices which is
added by next patch of the series.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
The driver creates platform devices based on the information
from USB nodes in the flat device tree. This is the replacement
for old arch fsl_soc usb code removed by the previous patch.
It uses usual of-style binding, available EHCI-HCD and UDC
drivers can be bound to the created devices. The new
Extends FSL EHCI platform driver glue layer to support
MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI
registers are in big endian format. The appropriate flags
are set using the information in the platform data structure.
MPC83xx system interface registers are not available on
MPC512x, so
In the next patch, you introduce a mutex for adding/removing memory blocks.
Is there really a need for this to be atomic? If you reorder the patches
so the mutex comes first, would the atomic be needed any longer?
Robin
On Mon, Sep 27, 2010 at 02:22:24PM -0500, Nathan Fontenot wrote:
Add a
On Mon, Sep 27, 2010 at 05:23:34PM +0200, Linus Walleij wrote:
2010/9/25 Ira W. Snyder i...@ovro.caltech.edu:
This adds support for scatterlist to scatterlist DMA transfers.
This is a good idea, we have a local function to do this in DMA40 already,
stedma40_memcpy_sg().
I think that
Hi Ben,
On Fri, Sep 17, 2010 at 07:52:31AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-16 at 17:38 +0530, Ankita Garg wrote:
Thanks Ben for taking a look at this. So I checked the rtas messages
on
the serial console and see the following:
instantiating rtas at
Hi,
I have a simple doubt about linux PCI/PCIe infraestructure.
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
I am loading a PCI driver that
Hi Grant,
On Tue, 28 Sep 2010 19:01:28 +0900
Grant Likely grant.lik...@secretlab.ca wrote:
...
Looks pretty good. Comments below. Main comment is that with the
recent changes in mainline, this no longer needs to be an
of_platform_driver. It can be a plain old platform_driver instead.
It
On Tue, Sep 28, 2010 at 11:36:32AM +0200, Anatolij Gustschin wrote:
This removed code will be replaced by simple of_platform
driver for creation of FSL USB platform devices which is
added by next patch of the series.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala
MPC8308 has pretty much the same DMA controller as MPC5121 and
this patch adds support for MPC8308 to the mpc512x_dma driver.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Cc: Piotr Ziecik ko...@semihalf.com
---
drivers/dma/Kconfig |2 +-
drivers/dma/mpc512x_dma.c | 95
Current code clears interrupt active status _after_ submiting new
transfers. This leaves a possibility of clearing the interrupt for this
new transfer (if it is triggered fast enough) and thus lose this
interrupt. We want to clear interrupt active status _before_ new
transfers is submited and for
While testing mpc512x-dma driver with dmatest module I've found that
I can hang the mpc512x-dma issueing request from multiple threads to
the single channel.
(insmod dmatest.ko max_channels=1 threads_per_chan=16)
After investingating this case I've managed to find that this happens
if and only if
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I made a dramatic improvement on a 16TB machine in that function by
merely caching the most recent memory section
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB) there are perfomance issues
related to creating the large
On 09/27/2010 09:28 PM, Nathan Fontenot wrote:
For example, assume 1GiB section size. A device for a memory starting at
0x1 is /sys/device/system/memory/memory4
(0x1 / 1Gib = 4)
This device covers address range [0x1 ... 0x14000)
-Under each section, you can
Dear Ilya Yanok,
In message 1285676696-5358-4-git-send-email-ya...@emcraft.com you wrote:
MPC8308 has pretty much the same DMA controller as MPC5121 and
this patch adds support for MPC8308 to the mpc512x_dma driver.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Cc: Piotr Ziecik
Hi all,
I have a serious problem with latest stable kernel (2.6.35.6) and gianfar
ethernet driver.
I'am using default SMP kernel configuration and MPC8572DS development board and
also using an hardware packet generator.
My test is ip forwarding between eth0 and eth1, and Hardware packet
Carlos Roberto Moratelli wrote:
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
Yes, vendor and device id must match. You can find those in lspci.
Hi,
I have a simple doubt about linux PCI/PCIe infraestructure.
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
When you register your driver, you
I finally found my problems accessing the PPC OWBAR registers as an
endpoint (copy/paste brown paper bag bug on my part), but I still get a
bus fault trying to access the device.
The problem is that I don't know if the fault is internal to the PPC (e.g.
I don't have something in the chip set up)
Dear Wolfgang,
28.09.2010 17:09, Wolfgang Denk wrote:
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
- depends on PPC_MPC512x
+ depends on PPC_MPC512x || PPC_MPC831x
Is MPC831x correct here? My understanding is that MPC831x processors
have yet
Calling unmask_msi_irq on irq shutdown is at least suboptimal.
Use mask_msi_irq instead.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/powerpc/platforms/cell/axon_msi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote:
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB)
On Tuesday 28 September 2010, Thomas Gleixner wrote:
Calling unmask_msi_irq on irq shutdown is at least suboptimal.
Use mask_msi_irq instead.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Acked-by: Arnd Bergmann a...@arndb.de
___
Linuxppc-dev
On Tue, 2010-09-28 at 14:44 +0200, Avi Kivity wrote:
Why not update sysfs directory creation to be fast, for example by using
an rbtree instead of a linked list. This fixes an implementation
problem in the kernel instead of working around it and creating a new ABI.
New ABIs mean old tools
On Tue, 2010-09-28 at 04:29 -0500, Robin Holt wrote:
Also, I don't think I much care for the weirdness that occurs if a
memory block spans two nodes. I have not thought through how possible
(or likely) this is, but the code certainly permits it. If that were
the case, how would we know which
On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hag...@gmail.com wrote:
I finally found my problems accessing the PPC OWBAR registers as an
endpoint (copy/paste brown paper bag bug on my part), but I still get a
bus fault trying to access the device.
The problem is that I don't know if the
On 09/28/2010 05:12 PM, Robin Holt wrote:
Why not update sysfs directory creation to be fast, for example by
using an rbtree instead of a linked list. This fixes an
implementation problem in the kernel instead of working around it
and creating a new ABI.
Because the old ABI creates
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE and BULK_REMOVE h-calls.
By default, those hcalls are enabled, active, and good for throughput
and performance. The ability to disable them will be useful for some of
the PREEMPT_RT related investigation and
Nice. I've got minor nits below, and you might also want to run the patch
through checkpatch and fix up some of the whitespace warnings.
-Olof
On Tue, Sep 28, 2010 at 12:02:51PM -0500, Will Schmidt wrote:
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE
On 09/27/2010 06:55 PM, Dave Hansen wrote:
On Mon, 2010-09-27 at 14:25 -0500, Nathan Fontenot wrote:
+static inline int base_memory_block_id(int section_nr)
+{
+ return section_nr / sections_per_block;
+}
...
- mutex_lock(mem_sysfs_mutex);
-
- mem-phys_index =
On 09/28/2010 04:31 AM, Robin Holt wrote:
In the next patch, you introduce a mutex for adding/removing memory blocks.
Is there really a need for this to be atomic? If you reorder the patches
so the mutex comes first, would the atomic be needed any longer?
I think you're right. Looking at
On 09/28/2010 07:38 AM, Robin Holt wrote:
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I made a dramatic improvement on a 16TB machine in that function by
On 09/28/2010 07:45 AM, Avi Kivity wrote:
On 09/27/2010 09:28 PM, Nathan Fontenot wrote:
For example, assume 1GiB section size. A device for a memory
starting at
0x1 is /sys/device/system/memory/memory4
(0x1 / 1Gib = 4)
This device covers address range [0x1
On 09/28/2010 07:48 AM, Robin Holt wrote:
+u32 __weak memory_block_size_bytes(void)
+{
+return MIN_MEMORY_BLOCK_SIZE;
+}
+
+static u32 get_memory_block_size(void)
Can we make this an unsigned long? We are testing on a system whose
smallest possible configuration is 4GB per socket
On Tue, 28 Sep 2010 08:31:54 -0700
Ira W. Snyder i...@ovro.caltech.edu wrote:
On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hag...@gmail.com wrote:
Alternatively, can somebody see a hint in the message that I don't know
enough to pick out? At this point, my code is trying to memcpy() from
Version 3 of the patches to add MPC512x USB support in
mainline kernel. USB OTG support is not included in
this patch series, it will be submitted later.
There are only two patches now: patches 1/3 and 2/3 of
the previous version are merged into the first patch and
now bisectable. Additionally
Replace FSL USB platform code by simple platform driver for
creation of FSL USB platform devices.
The driver creates platform devices based on the information
from USB nodes in the flat device tree. This is the replacement
for old arch fsl_soc usb code removed by this patch. The driver
uses usual
Extends FSL EHCI platform driver glue layer to support
MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI
registers are in big endian format. The appropriate flags
are set using the information in the platform data structure.
MPC83xx system interface registers are not available on
MPC512x, so
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE and BULK_REMOVE h-calls.
By default, those hcalls are enabled, active, and good for throughput
and performance. The ability to disable them will be useful for some of
the PREEMPT_RT related investigation and
On Fri, Sep 24, 2010 at 04:14:53PM -0600, Grant Likely wrote:
Commit 959e85f7, i2c: add OF-style registration and binding caused a
module dependency loop where of_i2c.c calls functions in i2c-core, and
i2c-core calls of_i2c_register_devices() in of_i2c. This means that
when i2c support is
On Fri, Sep 24, 2010 at 04:14:53PM -0600, Grant Likely wrote:
Commit 959e85f7, i2c: add OF-style registration and binding caused a
module dependency loop where of_i2c.c calls functions in i2c-core, and
i2c-core calls of_i2c_register_devices() in of_i2c. This means that
when i2c support is
On Tue, Sep 28, 2010 at 10:12:18AM -0500, Robin Holt wrote:
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote:
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
46 matches
Mail list logo
