On Thu, 2008-10-23 at 23:08 -0500, Nathan Fontenot wrote:
Resources for PHB's that are DLPAR added to a system are not acquired.
Not having these resources allocated causes an oops during DLPAR
remove of the PHB when we try to release non-existant resources.
The patch appears a bit messy,
On Thu, 2008-10-23 at 18:43 +0200, Gabriel Paubert wrote:
Can you tell me which devices it has, like does it have line-in,
microphone, headphones, ...?
I'm not an audio specialist, so the symbols used to
identify the ports look like hieroglyphs to me, but
The documentation says that the
On Fri, Oct 24, 2008 at 10:40:23AM +0200, Johannes Berg wrote:
On Thu, 2008-10-23 at 18:43 +0200, Gabriel Paubert wrote:
Can you tell me which devices it has, like does it have line-in,
microphone, headphones, ...?
I'm not an audio specialist, so the symbols used to
identify the
On Fri, 2008-10-24 at 14:26 +0200, Gabriel Paubert wrote:
Right. I'll assume it has a microphone too, built-in.
I doubt it:
- no mention found in the doc
- it seems to be output-only (#-inputs in the device tree is 0,
#-outputs is 3).
Yeah, I've disabled it in the patch I sent you.
I
Here's a patch that actually applies against 2.6.27.
---
sound/aoa/fabrics/snd-aoa-fabric-layout.c | 73 +++---
sound/aoa/soundbus/i2sbus/i2sbus-core.c | 16 --
2 files changed, 68 insertions(+), 21 deletions(-)
---
It appears the default IRQ affinity changes from being just cpu 0 to
all cpu's. This breaks several PPC SMP systems in which only a single
processor is allowed to be selected as the destination of the IRQ.
What is the right answer in fixing this? Should we:
cpumask_t
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
Fix the HCU4 Kconfig option to 'default n'. We don't want the
board to always be enabled for other board defconfigs.
Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/platforms/40x/Kconfig
b/arch/powerpc/platforms/40x/Kconfig
index 6573027..14e027f 100644
---
Kumar Gala wrote:
It appears the default IRQ affinity changes from being just cpu 0 to all
cpu's. This breaks several PPC SMP systems in which only a single
processor is allowed to be selected as the destination of the IRQ.
What is the right answer in fixing this? Should we:
cpumask_t
On Oct 24, 2008, at 10:17 AM, Chris Snook wrote:
Kumar Gala wrote:
It appears the default IRQ affinity changes from being just cpu 0
to all cpu's. This breaks several PPC SMP systems in which only a
single processor is allowed to be selected as the destination of
the IRQ.
What is the
Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression
on a subset of SMP based PPC systems whose interrupt controller only
allow setting an irq to a single processor. The previous behavior
was only CPU0 was initially setup to get interrupts. Revert back
to that behavior.
Now that 2.6.28-rc1 is out I'm rebasing my master branch against it.
Sorry for any pains this causes.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kumar Gala wrote:
On Oct 24, 2008, at 10:17 AM, Chris Snook wrote:
Kumar Gala wrote:
It appears the default IRQ affinity changes from being just cpu 0 to
all cpu's. This breaks several PPC SMP systems in which only a
single processor is allowed to be selected as the destination of the
On Thu, 2008-10-23 at 16:35 -0500, Matt Sealey wrote:
On Oct 23, 2008, at 7:27 AM, Wolfgang Ocker wrote:
The GPIOLIB allows the specification of a base gpio number for a
controller. That is not possible using OF. Instead, free gpio numbers
are assigned.
In order to allow static,
On Oct 24, 2008, at 11:09 AM, Chris Snook wrote:
Kumar Gala wrote:
On Oct 24, 2008, at 10:17 AM, Chris Snook wrote:
Kumar Gala wrote:
It appears the default IRQ affinity changes from being just cpu 0
to all cpu's. This breaks several PPC SMP systems in which only
a single processor is
On Thu, Oct 23, 2008 at 04:32:49PM -0500, Matt Sealey wrote:
Hi guys,
I'm a little perplexed as to how I would define a GPIO controller in a
device tree but mark off pins as available or not, so users can geek
around in their own drivers without defining in a device tree exactly
what they
On Thu, Oct 23, 2008 at 02:27:30PM +0200, Wolfgang Ocker wrote:
The GPIOLIB allows the specification of a base gpio number for a
controller. That is not possible using OF. Instead, free gpio numbers
are assigned.
In order to allow static, predefined gpio numbers, a base property in
the gpio
On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote:
On Thursday 23 October 2008, Wolfgang Ocker wrote:
The GPIOLIB allows the specification of a base gpio number for a
controller. That is not possible using OF. Instead, free gpio numbers
are assigned.
In order to allow static,
Hi, I wrote this patch for KVM [1], but now that I look closer it seems
like there might be some overlapping functionality.
First there's emulate_instruction(), but since that only handles a few
instructions it's just an ordered list of if ((instruction MASK_A) ==
INST_A) tests, so it doesn't
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
So, how do we define in a bank of GPIOs, which ones are free for use,
without them being attached to a device and given as a gpios property?
Would we suggest a node;
gpio-header {
compatible =
On Fri, Oct 24, 2008 at 10:54 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote:
On Thursday 23 October 2008, Wolfgang Ocker wrote:
The GPIOLIB allows the specification of a base gpio number for a
controller. That is not possible using
Kumar Gala wrote:
So why not just have x86 startup code set irq_default_affinity =
CPU_MASK_ALL than?
That doesn't really solve the problem, as a user could still manually
set an invalid affinity. The MPIC driver should reduce the affinity
itself to what the hardware can handle.
-Scott
Kumar Gala wrote:
On Oct 24, 2008, at 11:09 AM, Chris Snook wrote:
Kumar Gala wrote:
On Oct 24, 2008, at 10:17 AM, Chris Snook wrote:
Kumar Gala wrote:
It appears the default IRQ affinity changes from being just cpu 0
to all cpu's. This breaks several PPC SMP systems in which only a
On Fri, 2008-10-24 at 11:12 -0600, Grant Likely wrote:
On Fri, Oct 24, 2008 at 10:54 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote:
On Thursday 23 October 2008, Wolfgang Ocker wrote:
The GPIOLIB allows the specification of a
Scott Wood wrote:
Kumar Gala wrote:
So why not just have x86 startup code set irq_default_affinity =
CPU_MASK_ALL than?
That doesn't really solve the problem, as a user could still manually
set an invalid affinity. The MPIC driver should reduce the affinity
itself to what the hardware can
On Fri, 24 Oct 2008, Benjamin Herrenschmidt wrote:
On Fri, 2008-10-24 at 01:05 +0200, Guennadi Liakhovetski wrote:
i2c is broken on linkstation / kurobox machines since at least 2.6.27. Fix
it. Also remove CONFIG_SERIAL_OF_PLATFORM, which, if enabled, breaks the
serial console after the
Chris Snook wrote:
Scott Wood wrote:
Kumar Gala wrote:
So why not just have x86 startup code set irq_default_affinity =
CPU_MASK_ALL than?
That doesn't really solve the problem, as a user could still manually
set an invalid affinity. The MPIC driver should reduce the affinity
itself to
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 Love [EMAIL PROTECTED]
Index:
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 patch
modifies the walk_memory_resource callback fn to filter hugepages and add
only standard
memory to the busmap which is later on used for MR
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]
---
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 240
On Fri, Oct 24, 2008 at 1:59 PM, 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]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
SPI slave devices require the specification of a chip select address.
This patch allows that specification using the gpios property. The reg
property remains supported.
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
--- linux-2.6.27.3/drivers/of/of_spi.c.of_spi_gpio 2008-10-22
On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote:
SPI slave devices require the specification of a chip select address.
This patch allows that specification using the gpios property. The reg
property remains supported.
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
---
On Fri, Oct 24, 2008 at 3:10 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote:
SPI slave devices require the specification of a chip select address.
This patch allows that specification using the gpios property. The reg
property
On Sat, 2008-10-25 at 01:10 +0400, Anton Vorontsov wrote:
On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote:
SPI slave devices require the specification of a chip select address.
This patch allows that specification using the gpios property. The reg
property remains
On Fri, Oct 24, 2008 at 3:41 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 12:59:00PM -0700, John Linn 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
Am Freitag 24 Oktober 2008 16.31:58 schrieb Josh Boyer:
Fix the HCU4 Kconfig option to 'default n'. We don't want the
board to always be enabled for other board defconfigs.
Sorry, for this silly mistake. Thanks for your fix.
My board compiles and runs fine using Linus 2.6.28-rc1.
Mitch Bradley wrote:
[EMAIL PROTECTED] {
The name here should reflect the purpose of the pin, i.e. what it does
(perhaps NAME,magic), not the fact that is is GPIO pin. By analogy,
an ethernet controller's node name is ethernet, not pci-card. The
fact that the node represents
David Gibson wrote:
Don't be patronising.
There is an existing address space defined by the gpio binding.
Defining another one is pointless redundancy. This is standard good
ideas in computer science, no further argument necessary.
The existing address space, and the patches Anton etc.
Anton Vorontsov wrote:
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
Would we suggest a node;
gpio-header {
compatible = bplan,efika-gpio;
gpios = gpio-standard 16 0 17 0;
};
gpio-header2 {
compatible = bplan,efika-gpio-wkup;
gpios =
One thing I had a crazy dream about was a GUI-based device tree
builder
for platforms. Instead of editing them manually and passing them
through the compiler, wouldn't it be fun to drag and drop system
components (and build new ones) into something like a DirectX Filter
Graph Builder (or the
On Fri, Oct 24, 2008 at 05:17:42PM -0500, Matt Sealey wrote:
Anton Vorontsov wrote:
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
Would we suggest a node;
gpio-header {
compatible = bplan,efika-gpio;
gpios = gpio-standard 16 0 17 0;
};
gpio-header2 {
Rafael J. Wysocki wrote:
On Friday, 17 of October 2008, Kumar Gala wrote:
I've got a patch that seems to address this for me building w/
CONFIG_RELOCATABLE on ppc32/85xx.
Has that been fixed in 2.6.27 and/or current mainline?
I think CONFIG_RELOCATABLE was introduced post 2.6.27, so
This series of patches adds support for OpenFirmware bindings for GPIO based
LEDs.
I last posted a version of this in July but discussion of the OF binding
details didn't seem to be going anywhere.
I've since been contacted by some people who are actually using the previous
patches and have been
The device binding spec for OF GPIOs defines a flags field, but there is
currently no way to get it. This patch adds a parameter to of_get_gpio()
where the flags will be returned if non-NULL. of_get_gpio() in turn passes
the parameter to the of_gpio_chip's xlate method, which can extract any
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF
Yes, there is the default-on trigger but there are problems with that.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when then
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state which is otherwise unknown to Linux.
This requires that the
If something goes wrong attaching to phy driver, we weren't freeing the IRQ.
Signed-off-by: Mike Ditto [EMAIL PROTECTED]
---
cvs diff -r linux-2_6_27 -upN linux/drivers/net/fs_enet/fs_enet-main.c
Index: linux/drivers/net/fs_enet/fs_enet-main.c
On Friday, 17 of October 2008, Kumar Gala wrote:
On Oct 17, 2008, at 1:11 PM, Badari Pulavarty wrote:
On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote:
Hi,
I get this following compile error on my ppc box.
Let me know if its a known issue. Otherwise, I can figure out
From: Kumar Gala [EMAIL PROTECTED]
Date: Fri, 24 Oct 2008 10:57:38 -0500
Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression
on a subset of SMP based PPC systems whose interrupt controller only
allow setting an irq to a single processor. The previous behavior
was only
From: Kumar Gala [EMAIL PROTECTED]
Date: Fri, 24 Oct 2008 10:39:05 -0500
As for making it ARCH specific, that doesn't really help since not
all PPC hw has the limitation I spoke of. Not even all MPIC (in our
cases) have the limitation.
Since the PPC code knows exactly which MPICs have the
On Fri, Oct 24, 2008 at 5:08 PM, Trent Piepho [EMAIL PROTECTED] wrote:
The device binding spec for OF GPIOs defines a flags field, but there is
currently no way to get it. This patch adds a parameter to of_get_gpio()
where the flags will be returned if non-NULL. of_get_gpio() in turn passes
David Miller wrote:
From: Brandeburg, Jesse [EMAIL PROTECTED] Date: Thu, 23 Oct
2008 14:50:06 -0700
Chris Friesen wrote:
I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
to a Maple board). The first time I booted I got the first log below
via the serial console. I
From: Chris Friesen [EMAIL PROTECTED]
Date: Fri, 24 Oct 2008 17:39:00 -0600
So...it would appear that the NAPI code is somehow buggy, and
6ba33ac should probably be reverted until the problem is found and
fixed.
No I think the problem is simple enough that someone should study the
-poll()
Right. I had a similar discussion about this the other day with Anton (I
think he forwarded it here but I wasn't subscribed at that point..). The
current ideology for device trees is to get rid of device_type for new
trees that aren't OF-based. I think it's relevant to give nodes fancy
names
On Fri, 24 Oct 2008 23:54:24 +0200
Niklaus Giger [EMAIL PROTECTED] wrote:
Am Freitag 24 Oktober 2008 16.31:58 schrieb Josh Boyer:
Fix the HCU4 Kconfig option to 'default n'. We don't want the
board to always be enabled for other board defconfigs.
Sorry, for this silly mistake. Thanks for
On Fri, Oct 24, 2008 at 5:08 PM, Trent Piepho [EMAIL PROTECTED] wrote:
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on.
On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote:
With this patch it compiles and boots fine.
The option -mabi=no-spe is not required.
Please don't accept this patch yet. My past testing showed that
-mabi=no-spe was required for my toolchain. I'll go back and double
check though.
OK,
On Oct 24, 2008, at 6:51 PM, Nate Case wrote:
On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote:
With this patch it compiles and boots fine.
The option -mabi=no-spe is not required.
Please don't accept this patch yet. My past testing showed that
-mabi=no-spe was required for my toolchain.
On Fri, Oct 24, 2008 at 5:09 PM, Trent Piepho [EMAIL PROTECTED] wrote:
Yes, there is the default-on trigger but there are problems with that.
[...]
The platform device binding gains a field in the platform data default_state
that controls this. The OpenFirmware binding uses a property named
On Fri, 2008-10-24 at 16:55 -0600, Chris Friesen wrote:
Rafael J. Wysocki wrote:
On Friday, 17 of October 2008, Kumar Gala wrote:
I've got a patch that seems to address this for me building w/
CONFIG_RELOCATABLE on ppc32/85xx.
Has that been fixed in 2.6.27 and/or current mainline?
On Fri, Oct 24, 2008 at 5:09 PM, Trent Piepho [EMAIL PROTECTED] wrote:
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
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 -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c
Hollis Blanchard wrote:
Hi, I wrote this patch for KVM [1], but now that I look closer it seems
like there might be some overlapping functionality.
First there's emulate_instruction(), but since that only handles a few
instructions it's just an ordered list of if ((instruction MASK_A) ==
Hollis Blanchard writes:
I've also found xmon's ppc-opc.c. That parses the opcode and operands,
so could use some shared macros.
That's a direct copy from GNU binutils. I'm reluctant to modify it
because then maintenance becomes more than just copying in the latest
version.
Paul.
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
So we can describe the SPI
On Fri, 2008-10-24 at 11:47 -0700, 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).
While you're at
68 matches
Mail list logo
