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 t
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 registration.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
This p
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
> > id
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 yo
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(-)
--- everything.orig/sound/aoa/fabrics/snd-aoa-fabr
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 irq_default_af
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/drivers/net/ibm_newe
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
--- a/arch/p
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 i
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 ri
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.
Signed
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
IRQ.
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 all
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 al
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
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
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 all
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 ac
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 possi
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
singl
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 specificat
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 h
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 afte
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 wha
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: Cell_kernel_10_24_2
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 registra
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 PROTEC
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
23:38:
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
>> propert
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 sup
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 <[EMAIL PROTECTED]>
Looks good. Just few comments below.
> ---
>
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-
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.
>
> Signed-
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 represen
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. just
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";
gp
> 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
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
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 should
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
flag
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 support
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 trigg
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 un
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
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 onl
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 th
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 pass
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
->pol
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 (i.e.
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. Thank
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 o
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 tho
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
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 curren
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
NE
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) ==
INST_
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 a
David Miller wrote:
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 shou
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:
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 7f2ee27..f6b0da8 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -65
72 matches
Mail list logo
