Currently, the numa_node of OF-devices will be overwritten during
device_register, which simply sets the node to -1. On cell machines,
this means that devices can't find their IOMMU, which is referenced
through the device's numa node.
Set the numa node for OF devices with no parent, and use the
lo
Dave,
thanks for your valuable comments - see mine below. I'll send a reworked patch
asap.
Thomas
On Friday 24 October 2008 08:55:37 pm you wrote:
> On Fri, 2008-10-24 at 13:07 +0200, Thomas Klein wrote:
> > 16GB hugepages may not be part of a memory region (firmware restriction).
> > This pa
All kernel memory which is used for kernel/hardware data transfer must be
registered
with firmware using "memory regions". 16GB hugepages may not be part of a
memory region
due to firmware restrictions.
This patch modifies the walk_memory_resource callback fn to filter hugepages
and add
only sta
Add a new CPU feature bit, CPU_FTR_UNALIGNED_LD_STD, to be added
to the 64bit powerpc chips that can do unaligned load double and
store double (and not take a performance hit from it).
This is added to Power6 and Cell and will be used in an upcoming
patch to do the alignment in memcpy() only on CP
Update memcpy() to add two new feature sections: one for aligning the
destination before copying and one for copying using aligned load
and store doubles.
These new feature sections will only affect Power6 and Cell because
the CPU feature bit was only added to these two processors.
Power6 gets it
On Fri, Oct 24, 2008 at 11:01:45AM -0500, Kumar Gala wrote:
> Now that 2.6.28-rc1 is out I'm rebasing my master branch against it.
> Sorry for any pains this causes.
Unless the powerpc tree moves up to .28-rc2 today-ish, I'll probably do
this for my tree as well so I can get some defconfig upda
On Oct 26, 2008, at 1:33 AM, Benjamin Herrenschmidt wrote:
On Sat, 2008-10-25 at 21:04 -0700, David Miller wrote:
But back to my original wonder, since I've always tipped off of this
generic IRQ layer cpu mask, when was it ever defaulting to zero
and causing the behvaior your powerpc guys actu
On Oct 27, 2008, at 5:43 AM, Mark Nelson wrote:
Add a new CPU feature bit, CPU_FTR_UNALIGNED_LD_STD, to be added
to the 64bit powerpc chips that can do unaligned load double and
store double (and not take a performance hit from it).
This is added to Power6 and Cell and will be used in an upcom
On Oct 24, 2008, at 8:03 PM, Mike Ditto wrote:
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
I just noticed this file has already been touched in -rc1 so here is
the
patch again, adjusted accordingly.
diff -
David Gibson wrote:
Um.. I can't actually follow what you're getting at there, sorry.
Imagine in your head that you have a GPIO controller that has a
32-bit register potentially controlling 32 pins on the chip.
Imagine that rather than being able to allocate 6 GPIO pins
*right next to each
David Gibson wrote:
On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
Mitch Bradley wrote:
device_type in 1275 defines the runtime method interface. It's *not*
for declaring the general class of the device, although it often
matches that in practice.
It *is* for declaring the
Matt Sealey wrote:
I'm all for it being legacy and optional but marking ethernet ports as
network, and serial ports as serial, is a wonderfully good idea especially
if they were used in ANY firmware environment to bring up the console,
drag in the boot files, or provide a framebuffer display.
N
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
V2 - Updated based on Anton's comments
drivers/gpio/Kconfig | 15 ++--
drivers/gpio/Makefile |
On Mon, Oct 27, 2008 at 10:39 AM, John Linn <[EMAIL PROTECTED]> wrote:
> This driver supports the Xilinx XPS GPIO IP core which has the typical
> GPIO features.
>
> Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
> ---
> V2 - Updated based on Anton's
Scott Wood wrote:
Matt Sealey wrote:
Nobody is saying that device_type should not be used in real OF when an
appropriate method interface exists. What we're saying is that flat
device trees, which are incapable of providing a method interface,
should not lie and claim that they have one.
Matt Sealey wrote:
I say ANY firmware environment because at the end
of the day what methods the OF implements, or even if the firmware
(like a U-Boot modification) "lies" about it being device_type serial
or device_type network, Linux completely f**ks over the client
interface at the first oppor
David Miller wrote:
From: Kevin Diggs <[EMAIL PROTECTED]>
Date: Sat, 25 Oct 2008 15:53:46 -0700
What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
thing supposed to be able to spread irq between its cpus?
Networking interrupts should lock onto a single CPU, unconditionally.
That
Scott Wood wrote:
They did always work. The real sore points here are device bindings and a
grand total of nothing changed between OF and now with that.
The assertion in ePAPR that device_type is deprecated and ignored
because ePAPR doesn't support FCode is naive at best.
It's deprecated *i
Matt Sealey wrote:
Scott Wood wrote:
It's deprecated *in the context of flat device trees*. Anything not
using flat device trees is out-of-scope with respect to ePAPR.
Isn't the beauty of a device tree that every firmware no matter what
type can present it in whatever form it chooses, but sti
On 24.10.08 11:47:29, Carl Love wrote:
>
> The size of the pm_signal_local array should be equal to the
> number of SPUs being configured in the call. Currently, the
> array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
> loop from 0 to 7 (NUM_SPUS_PER_NODE).
>
> Signed-off-by: Carl
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 11:36:21 -0600
> David Miller wrote:
> > From: Kevin Diggs <[EMAIL PROTECTED]>
> > Date: Sat, 25 Oct 2008 15:53:46 -0700
> >
> >> What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
> >> thing supposed to be able to spr
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>
>> Um.. I can't actually follow what you're getting at there, sorry.
>
> Imagine in your head that you have a GPIO controller that has a
> 32-bit register potentially controlling 32 pins on the chip.
>
> Imagin
>From 20a2290553a1921a13449f9b7c597bcc76ec2c03 Mon Sep 17 00:00:00 2001
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 09:08:11 -0500
Subject: [PATCH] powerpc/mpic: Add support for MPICs that only support a single
CPU destination
The Freescale implementation of MPIC only allows a sin
Thomas Klein wrote:
All kernel memory which is used for kernel/hardware data transfer must be
registered
with firmware using "memory regions". 16GB hugepages may not be part of a
memory region
due to firmware restrictions.
This patch modifies the walk_memory_resource callback fn to filter hugep
Josh Boyer wrote:
The recent build fix for ibm_newemac has a typo in the config
option #ifdef used for disabling flow control. This corrects
it to the proper Kconfig option name.
Reported-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
diff --git a/
Anton Vorontsov wrote:
The GPIO spec doesn't specify a controller bank. It says
- - - -
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
- - - -
May encode. Or may not encode. FYI, for most (all) SOC GPIO
controlle
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
V2 - Updated based on Anton's comments
V3 - Cleaned up Kconfig ba
David Miller wrote:
From: "Chris Friesen" <[EMAIL PROTECTED]>
What about something like the Cavium Octeon, where we have 16 cores but a
single core isn't powerful enough to keep up with a gigE device?
Hello, we either have hardware that does flow seperation and has multiple
RX queues going t
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 13:10:55 -0600
> David Miller wrote:
> > From: "Chris Friesen" <[EMAIL PROTECTED]>
>
> > Hello, we either have hardware that does flow seperation and has multiple
> > RX queues going to multiple MSI-X interrupts or we do flow sepera
On Oct 27, 2008, at 1:28 PM, David Miller wrote:
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 11:36:21 -0600
David Miller wrote:
From: Kevin Diggs <[EMAIL PROTECTED]>
Date: Sat, 25 Oct 2008 15:53:46 -0700
What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 14:43:29 -0500
> I haven't been following the netdev patches, but what about HW that does flow
> separation w/o multiple interrupts?
>
> We (Freescale) are working on such a device:
>
> http://www.freescale.com/webapp/sps/site/prod_sum
On Mon, Oct 27, 2008 at 01:56:03PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> The GPIO spec doesn't specify a controller bank. It says
>>
>> - - - -
>> gpio-specifier may encode: bank, pin position inside the bank,
>> whether pin is open-drain and whether pin is logically inverted.
>> -
On Mon, 2008-10-27 at 08:24 -0400, [EMAIL PROTECTED] wrote:
> On Fri, Oct 24, 2008 at 11:01:45AM -0500, Kumar Gala wrote:
> > Now that 2.6.28-rc1 is out I'm rebasing my master branch against it.
> > Sorry for any pains this causes.
>
> Unless the powerpc tree moves up to .28-rc2 today-ish, I'll
On Mon, 2008-10-27 at 08:43 -0500, Kumar Gala wrote:
>
> While we have the comment the code appears not to really follow it.
> We appear to write 1 << hard_smp_processor_id().
That code is called by each CPU that gets onlined and OR's it's
bit in the mask.
Ben.
_
[added linuxppc-dev for a wider audience]
Felix Radensky wrote:
I run linux-2.6.26 on custom 460EX based board.
This platform has PCA9548 I2C mux on I2C bus 0.
I was wondering how can I describe the mux itself
and devices behind it (e.g RTC and temperature sensors)
in the device tree.
Describe
On Oct 27, 2008, at 3:27 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-27 at 08:43 -0500, Kumar Gala wrote:
While we have the comment the code appears not to really follow it.
We appear to write 1 << hard_smp_processor_id().
That code is called by each CPU that gets onlined and OR's it'
On Oct 27, 2008, at 2:49 PM, David Miller wrote:
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 14:43:29 -0500
I haven't been following the netdev patches, but what about HW that
does flow separation w/o multiple interrupts?
We (Freescale) are working on such a device:
http:/
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
Reposting to CC netdev list. (Thanks, Kumar)
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c
NEW/drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-rc1/drivers/ne
Anton Vorontsov wrote:
Can you _simply_ describe the problem you're trying to solve,
w/o that much emotions? Can you give examples of what
you've tried, and describe why you don't like it?
I've not tried anything because I don't feel confident that the
documentation or device tree examples expl
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> Can you _simply_ describe the problem you're trying to solve,
>> w/o that much emotions? Can you give examples of what
>> you've tried, and describe why you don't like it?
>
> I've not tried anything because I
On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote:
[...]
> > * How do you stop GPIOLIB from blindly approving requests to use
> > pins marked X, without making it "controller-specific"?
Btw, as for pins marked X... If the gpio controller has some register
that specify which pin
Hello
I am trying to contact Roger W Brown
Can you be of any assistance?
Thank you
Thom Gascoigne
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi, Scott
Scott Wood wrote:
[added linuxppc-dev for a wider audience]
Felix Radensky wrote:
I run linux-2.6.26 on custom 460EX based board.
This platform has PCA9548 I2C mux on I2C bus 0.
I was wondering how can I describe the mux itself
and devices behind it (e.g RTC and temperature sensors)
David Miller wrote:
> Probably the simplest fix is to get rid of the rx_not_empty label and
> protect the entire:
>
>/* Receive descriptor is empty now */
>spin_lock_irqsave(&lp->lock, flags);
>__netif_rx_complete(dev, napi);
>writel(VAL0|RINTEN0, mmio + INTEN0);
>writel(VAL2
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>
>> Um.. I can't actually follow what you're getting at there, sorry.
>
> Imagine in your head that you have a GPIO controller that has a
> 32-bit register potentially controlling 32 pins on the chip.
>
> Imagin
On Mon, Oct 27, 2008 at 11:12:07AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>> On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
>>>
>>> Mitch Bradley wrote:
>>
>> device_type in 1275 defines the runtime method interface. It's *not*
>> for declaring the general class of the d
On Mon, Oct 27, 2008 at 12:54:15PM -0500, Scott Wood wrote:
> Matt Sealey wrote:
>> Scott Wood wrote:
>>> It's deprecated *in the context of flat device trees*. Anything not
>>> using flat device trees is out-of-scope with respect to ePAPR.
>>
>> Isn't the beauty of a device tree that every firm
Anton Vorontsov wrote:
On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote:
[...]
* How do you stop GPIOLIB from blindly approving requests to use
pins marked X, without making it "controller-specific"?
Btw, as for pins marked X... If the gpio controller has some register
th
David Gibson wrote:
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&controller pin1-sp
On Thu, 23 Oct 2008 15:43:45 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Commit 549e8152de8039506f69c677a4546e5427aa6ae7 ("powerpc: Make the
> 64-bit kernel as a position-independent executable") added lines to
> vmlinux.lds.S to add the extra sections needed to implement a
> relocatable ker
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller? What do you mean by "bank"? There is no such
thing. There are GPIO controllers, and _
On Mon, Oct 27, 2008 at 07:51:23PM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> Uh.. no. The gpio specifier has a format that's gpio controller
>> specific, but it must include the actual pin number, although exactly
>> h
On Mon, Oct 27, 2008 at 08:11:12PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
>>>
>>> A bunch of things spring to mind:
>>>
>>> * How do you define a GPIO bank in a device tree, not a controller
>>
>> Not a controller? What d
Sean MacLennan writes:
> I'd like to try this. I did a git revert to back out the aforementioned
> commit. How do I get it back? Do I git revert again?
You could revert the reversion, or else rebase any patches you have on
top of the reversion onto the commit before the reversion.
Paul.
Kumar Gala writes:
> not that I have anything against this patch but is there anything we
> can do about the CPU_FTR_ usage for one of things like this?
Can you express that a little more coherently for us, please? :)
Paul.
___
Linuxppc-dev mailing
David Miller wrote:
From: "Chris Friesen" <[EMAIL PROTECTED]>
Are there any plans for a mechanism to allow the kernel to figure
out (or be told) what packets cpu-affined tasks are interested in
and route the interrupts appropriately?
No, not at all.
Now there are plans to allow the user t
These patches are related to math-emu.
[Patch 1/4] Fix a fdiv bug of FP math-emu
[Patch 2/4] Update a macro to new version
[Patch 3/4] Remove redundant code
[Patch 4/4] Add SPE/EFP handlers for E500v1/v2 processors
___
Linuxppc-dev mailing list
Linuxppc
Move to using the same macro definition for _FP_CHOOSENAN as s390,
sh, sparc32/64. The original author didn't understand this and
matched what sparc64 was doing and they have updated to this definition.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/sfp-machine.h |
PowerPC float point division emulation is derived from gcc.
I reported this problem on gcc maillist and got this reply:
http://gcc.gnu.org/ml/gcc/2008-03/msg00543.html
Since UDIV_NEEDS_NORMALIZATION is not used by kernel, we should use
_FP_DIV_MEAT_1_udiv_norm to make sure the single float point
i
FP_DECL_EX is already used, so ret is redundant.
And FP_SET_EXCEPTION will add status into return value.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/math-emu/fadd.c|1 -
arch/powerpc/math-emu/fcmpo.c |5 ++---
arch/powerpc/math-emu/fdiv.c|9 -
arch/pow
This patch add the handlers of SPE/EFP exceptions.
The code is used to emulate float point arithmetic,
when MSR(SPE) is enabled and receive EFP data interrupt or EFP round interrupt.
This patch has no conflict with or dependence on FP math-emu.
The code has been tested by TestFloat.
Now the code
On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
>
> David Gibson wrote:
>>
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> So, you use
>>gpios = <&controller pin1-specifier &controller pin8-specifier
>> &controller pin9-specifi
This series of patches is aimed at fixing all sort of issues
with the PCI hotplug support on pSeries. The meant is in the
second to last patch, but it relies on a whole bunch of small
changes to separate the bus fixup operation in two that are
needed to fix the root of most problems.
Please review
From: Nathan Fontenot <[EMAIL PROTECTED]>
Resources for PHB's that are dynamically added to a system are not
properly allocated in the resource tree.
Not having these resources allocated causes an oops when removing
the PHB when we try to release them.
The patch appears a bit messy, this is main
This removes the various DBG() macro from the powerpc PCI code and
make it use the standard pr_debug instead.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c | 77 +++--
arch/powerpc/kernel/pci_32.c | 12 +
ar
The 32-bit and 64-bit powerpc PCI code used to setup the resource
pointers of the root bus of a given PHB in completely different
places.
This unifies this in large part, but making 32-bit use a routine very
similar to what 64-bit does when initially scanning the PCI busses.
The actual setup of t
The function pcibios_do_bus_setup() was used by pcibios_fixup_bus()
to perform setup that is different between the 32-bit and 64-bit
code. This difference no longer exist, thus the function is removed
and the setup now done directly from pci-common.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL P
Currently, or PCI code uses the pcibios_fixup_bus() callback, which is
called by the generic code when probing PCI busses, for two different
thnings.
One is to setup things related to the bus itself, such as
reading bridge resources for P2P bridges, fixing them up, or setting
up the iommu's associ
To properly fix PCI hotplug, it's useful to be able to make
the fixup passes on all devices whether they were just hot
plugged or already there.
The EEH code however used to not be very friendly with calling
eeh_add_device_late() multiple time, and not very rebust in
the way it generally tests whe
To properly fix PCI hotplug, it's useful to be able to make
the fixup passes on all devices whether they were just hot
plugged or already there.
However, pcibios_allocate_bus_resources() wouldn't cope well
with being called twice for a given bus. This patch makes it
ignore resources that have alre
A typo/thinko made us pass the wrong argument to __flush_hash_table_range
when unplugging bridges, thus not flushing all the translations for
the IO space on unplug.
This causes the hypervisor to refuse unplugging slots.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc
The pseries PCI Hotplug code has a number of issues, ranging from
incorrect resource setup to crashes, depending on what is added,
when, whether it contains a bridge, etc etc
This patch fixes a whole bunch of these, while actually simplifying
the code a bit, using more generic code in the proc
This does a few costmetic cleanups, moving a couple of things
around but without actually changing what the code does.
(There is a minor change in ordering of operations in
pcibios_setup_bus_devices but it should have no impact).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arc
On Tue, 2008-10-28 at 16:48 +1100, Benjamin Herrenschmidt wrote:
> This series of patches is aimed at fixing all sort of issues
> with the PCI hotplug support on pSeries. The meant is in the
> second to last patch, but it relies on a whole bunch of small
> changes to separate the bus fixup operatio
After the merge of the 32 and 64bit DMA code, dma_direct_ops lost their
map/unmap_single() functions but gained map/unmap_page(). This caused a
problem for Cell because Cell's dma_iommu_fixed_ops called the dma_direct_ops
if the fixed linear mapping was to be used or the iommu ops if the dynamic
wi
Now that all of the remaining dma_mapping_ops have had their map_/unmap_single
functions updated to become map/unmap_page functions, there is no need to have
the map_/unmap_single function pointers in the dma_mapping_ops.
So, take this opportunity to remove them and also remove the code that does
76 matches
Mail list logo
