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
> > >/s
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 i
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 i
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 wor
On Wed, Sep 29, 2010 at 8:21 AM, Ben Dooks wrote:
> 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_de
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 th
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
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 the
On Tue, 28 Sep 2010 08:31:54 -0700
"Ira W. Snyder" 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 the
> > PCIe bu
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
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 [
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 functio
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 a
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_i
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
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 wo
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
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 t
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 wh
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 t
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
Acked-by: Arnd Bergmann
___
Linuxppc-dev mailing list
Linuxppc-dev@lis
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
Calling unmask_msi_irq on irq shutdown is at least suboptimal.
Use mask_msi_irq instead.
Signed-off-by: Thomas Gleixner
---
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
===
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
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) o
> 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,
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.
Mic
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 genera
Hi Ben,
A few small updates for the next branch. A new board/SoC from AMCC, and
some 476 changes from Shaggy. Please pull.
josh
The following changes since commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352:
powerpc/perf: Fix sampling enable for PPC970 (2010-09-23 17:03:56 +1000)
are availabl
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
> Cc: Piotr Ziecik
> ---
> drivers/dma/Kco
> +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 with 512 sockets.
We would like to be abl
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
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 numbe
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 a
Hello everybody,
I've found that mpc512x_dma doesn't work reliable in my tests (dmatest
module and NetPipe with CONFIG_NET_DMA enabled).
These patches fixes two issues I've found: inproper handling of
scatter/gather transfers and missing interrupts.
The third patch adds support for MPC8308 which h
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 w
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 c
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
Cc: Piotr Ziecik
---
drivers/dma/Kconfig |2 +-
drivers/dma/mpc512x_dma.c | 95 +---
2 file
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
> Cc: Kumar Gala
> Cc: Grant Likely
Hi Grant,
On Tue, 28 Sep 2010 19:01:28 +0900
Grant Likely 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 gets registered as a pla
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 regist
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 0x000
Hi Anatolij
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 gets registered as a platform_driver anyway, but of_platform_driver
is a shim that adds a
> On Mon, Sep 27, 2010 at 05:23:34PM +0200, Linus Walleij wrote:
>> 2010/9/25 Ira W. Snyder :
>>
>>> 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 having
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 sec
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 th
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 o
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
Cc: Kumar Gala
Cc: Grant Likely
---
arch/powerpc/sysdev/fsl_soc.c | 163 --
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):
powerpc/fsl
This patch may work, but it appears it is lacking in, at least the
link_mem_sections() function. Assuming you have a memory block covering
2GB and a section size of 128MB (some values we are toying with for
large SGI machines), you end up calling register_mem_sect_under_node()
16 times which then
50 matches
Mail list logo