Hi David,
On Tue, 15 Jul 2008 09:31:29 -0600, David Hubbard wrote:
> On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > I always assumed that there was no way to know in advance if a
> > Super-I/O (LPC) chip was present or not, let alone the exact model of
> > the chip. T
On Wednesday 16 July 2008, Roland Dreier wrote:
> > Strong ordering is only active when both the bridge and the IOMMU enable
> > it, but for correctly written drivers, this only results in a slowdown.
>
> So when would someone use this dma attribute? As a hack to fix drivers
> where the real fi
On Wednesday 16 July 2008, Dave Jones wrote:
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129:
> undefined reference to `alloc_mdio_bitbang'
> /builddir/build/BUILD/kernel-2.6.26/
Hi,
I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i want
to do data transfer to and from device myself using BUFFER DESCRIPTOR not with
the usual DMA transfer.
Please help me.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.o
Hi Jean,
Jean Delvare wrote:
Hi Wolfgang,
On Fri, 11 Jul 2008 14:40:58 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
There's no "detection" involved for the new-style i2c devices.
Presumably you are still using the old binding model, not taking
benefit of the patch at all. Use i2c_reg
On 16-07-08 09:46, Jean Delvare wrote:
As a conclusion, there is no clear relationship between the presence
of an ISA or LPC bridge and the presence of a Super-I/O chip. All we
can say is that apparently all PC systems have an ISA bridge. So
indeed we can probably make the probes conditional upo
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > For hwmon chips, probing only occurs if the i2c adapter accepts to be
> > probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> > you do not want a given i2c bus to be probed, the
Hi Jean;
Jean Delvare wrote:
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
For hwmon chips, probing only occurs if the i2c adapter accepts to be
probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
you do not want a given i2c b
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> >
> > I have a set of patches c
no i am working on powerpc. MPC8323
-Original Message-
From: Nobin Mathew <[EMAIL PROTECTED]>
To: dinesh <[EMAIL PROTECTED]>
Cc: Grant Likely <[EMAIL PROTECTED]>, linuxppc-dev@ozlabs.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
Jean Delvare wrote:
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
The problem is that at this point in time, only a couple hwmon drivers
have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
would break most systems.
I have a set of patches
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
> want to do data transfer to and from device myself using BUFF
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device node:
[EMAIL PROTECTED] {
...
compatible = "fsl-i2c";
prob
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Dave Jones wrote:
> > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> > /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129:
> > undefined referenc
On Tue, 15 Jul 2008 22:34:36 -0700
[EMAIL PROTECTED] wrote:
> From: Victor Gallardo <[EMAIL PROTECTED]>
>
> ppc4xx: Add AMCC Arches DTS
>
> Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/arches.dts | 522
> ++
> 1 files cha
On Tue, 15 Jul 2008 22:33:26 -0700
[EMAIL PROTECTED] wrote:
> From: Victor Gallardo <[EMAIL PROTECTED]>
>
> ppc4xx: Add AMCC Arches 460GT eval board support
>
> Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
>From what I can tell, you don't even need this patch or the defconfig.
Nothing di
Hi Wolfgang,
On Wed, 16 Jul 2008 12:47:25 +0200, Wolfgang Grandegger wrote:
> Currently, the I2C buses are probed for HWMON I2C devices, which might
> not be acceptable in same cases. This patch makes device probing
> configurable through the property "probe" of the FDT I2C device node:
>
>
On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> Currently, the I2C buses are probed for HWMON I2C devices, which might
> not be acceptable in same cases. This patch makes device probing
> configurable through the property "probe" of the FDT I2C device node:
All this patch seems to b
On Jul 16, 2008, at 6:13 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
On Wednesday 16 July 2008, Dave Jones wrote:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerp
Jean Delvare wrote:
Hi Wolfgang,
On Wed, 16 Jul 2008 12:47:25 +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device
Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device node:
All this p
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
`alloc_mdio_bitbang'
arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
`mdiobus_register'
Signed
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote:
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31
+--
1 files changed, 12 insertions(+), 19 deletions(-)
applied.
- k
___
L
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote:
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |3 +
drivers/net/gianfar.c | 118
-
drivers/net/gianfar.h | 12 -
drivers/net/gianfar_ethtool.c |
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
to receive the following updates:
Documentation/powerpc/booting-without-of.txt| 189 ++--
Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt |
On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
> On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> > Jean Delvare wrote:
> >
> > Yep, as probing might not be acceptable in some cases, I makes sense to
> > add a property to suppress probing:
>
> It'd rather make no-p
On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> >
> > > Currently, the I2C buses are probed for HWMON I2C devices, which might
> > > not be acceptable in same cases. This patch makes device probing
> >
On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> On Tue, 15 Jul 2008 22:33:26 -0700
> [EMAIL PROTECTED] wrote:
>
> > From: Victor Gallardo <[EMAIL PROTECTED]>
> >
> > ppc4xx: Add AMCC Arches 460GT eval board support
> >
> > Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
>
> Fr
On 7/16/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
> > On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> > > Jean Delvare wrote:
> > >
>
> > > Yep, as probing might not be acceptable in some cases, I makes sense to
>
On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> >
> > > Currently, the I2C buses are probed for HWMON I2C devices, which might
> > > not be acceptable in same cases. This patch makes device probing
> >
On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
> Currently, the I2C buses are probed for HWMON I2C devices, which might
> not be acceptable in same cases. This patch makes device probing
> configurable through the property "probe" of the FDT I2C device node:
>
> [EMAIL P
On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
> On 7/16/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
> > > On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> > > > Jean Delvare wrote:
> > > >
> >
> > > > Yep, a
On Wed, Jul 16, 2008 at 10:24:22AM -0400, Jon Smirl wrote:
> On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> >
> > > On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> > >
> > > > Currently, the I2C buses are probed for HWMON I2C devices, which might
> >
Segher Boessenkool wrote:
>> Trying to cross-compile arch/powerpc for an freescale 8280:
>>
>> Gcc 4.1.2
>> Binutils 2.17
>>
>> BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps
>> previous sections
>
> [etc]
>
> Could you try with binutils 2.18?
Not easilly, I would have to re
On Wed, 16 Jul 2008 08:15:39 -0600
Grant Likely <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> > On Tue, 15 Jul 2008 22:33:26 -0700
> > [EMAIL PROTECTED] wrote:
> >
> > > From: Victor Gallardo <[EMAIL PROTECTED]>
> > >
> > > ppc4xx: Add AMCC Arches 460
On 7/16/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 10:24:22AM -0400, Jon Smirl wrote:
> > On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> > > Jon Smirl wrote:
> > >
> > > > On 7/16/08, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Cur
On Wednesday 16 July 2008, Grant Likely wrote:
>
> >
> > And then you don't need this file at all. Just add a
> > "amcc,canyonlands" string to your root node compatible property.
>
> No! Don't do this because it is not true!
>
> Instead, add your board name to canyonlands.c in canyonlands_pro
Hi Grant,
> On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
>> Currently, the I2C buses are probed for HWMON I2C devices, which might
>> not be acceptable in same cases. This patch makes device probing
>> configurable through the property "probe" of the FDT I2C device node:
>>
Jon Smirl wrote:
> Probing an i2c bus does not necessarily come to a good conclusion. The
> probes for some chips can alter the states in others. People have
> accidentally changed voltage settings and fried CPU chips. The process
> is not well defined.
I agree. We should not be implementing any
On Wed, Jul 16, 2008 at 10:37:52AM -0400, Josh Boyer wrote:
> On Wed, 16 Jul 2008 08:15:39 -0600
> Grant Likely <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> > > And then you don't need this file at all. Just add a
> > > "amcc,canyonlands" string t
On Wed, Jul 16, 2008 at 04:46:01PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> >
> > >
> > > And then you don't need this file at all. Just add a
> > > "amcc,canyonlands" string to your root node compatible property.
> >
> > No! Don't do this because it is no
Hi.
I've been working with Debian bintuils 2.17-3 (which identifies
itself as 2.17) on my build box for some time.
When testing all-yes-config, I was getting warnings, but the
vmlinux was booting via kexec.
Since I was replicating the warnings from BFD about section lmas
overlapping in vmlinux.
It seems that some machines, like a default RHEL4 install, will
not have a definition for YYRHSLOC, and that prevents building
dtc. This supplies what appears to be the standard definition
for it in the event that the host system does not have it defined.
Signed-off-by: Paul Gortmaker <[EMAIL PRO
Grant Likely wrote:
On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device node:
08
Faulting instruction address: 0xc002d114
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c002d114 LR: c05d3c68 CTR:
REGS: c000e9137580 TRAP: 0300 Not tainted
(2.6.26-next-20080716-08333-g49de20b)
MSR: 80
Timur Tabi wrote:
> The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for some
> audio related options. In particular, OSS emulation should be enabled,
> and the old ALSA API should be disabled.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
Kumar, can you apply this patch
* 64-bit PTEs and reader vs writer hazards. How do we ensure that
the
TLB miss handler samples a consistent view of the pte. pte_updates
seem ok since we only update the flag word. However set_pte_at seems
like it could be problematic.
eieio on the writer and a data dependency on the reader
Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Rune Torgersen wrote:
>> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
>> test I did is almost identical (within 1%) of what the arch/powerpc
>> 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
>> (I'll see i
On Jul 16, 2008, at 3:57 PM, Kumar Gala wrote:
* 64-bit PTEs and reader vs writer hazards. How do we ensure that
the
TLB miss handler samples a consistent view of the pte. pte_updates
seem ok since we only update the flag word. However set_pte_at
seems
like it could be problematic.
ei
We need to create a false data dependency to ensure the loads of
the pte are done in the right order.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_fsl_booke.S | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerp
There are some minor issues with support 64-bit PTEs on a 32-bit processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag word
is set second.
* We want to ensure that set_pte_at is always called w/a pte that is not
valid. Change kunmap_atomic to alway
Hi Ben,
Here are two more PS3 patches for 2.6.27. Please apply.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Masakazu Mokuno <[EMAIL PROTECTED]>
Add sub match id for ps3 system bus so that two different system bus
devices can be connected to a shared device.
Signed-off-by: Masakazu Mokuno <[EMAIL PROTECTED]>
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/ps3/device-in
Update ps3_defconfig.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/configs/ps3_defconfig | 196 +++--
1 file changed, 122 insertions(+), 74 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,7
On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
> This makes sense. I think we need to order the stores in set_pte_at
> regardless of CONFIG_SMP.
Nah, that shouldn't be necessary.
> Also, I think we should change pte_clear to
> use pte_update() so we only clear the low-order flag bits
On Wednesday 16 July 2008, Rune Torgersen wrote:
> Turns out the story is no so simple.
> I redid the test wih all versions of arch/ppc from 2.6.18 to 2.6.26, and
> also arch/powerpc (2.6.24 and 25, 26 doesn't compile because of binutil
> issues)
>
> This time I made very sure that the tests were
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> If we don't enable FS_ENET we get build issues:
>
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
> `alloc_mdio_bitbang'
> arch/powerpc/platform
Arnd Bergmann wrote:
> Ok, I think this could be related mostly to two changes:
>
> * In 2.6.23, the process scheduler was replaced, the new one
> is the CFS,
> the 'completely fair scheduler'. This has changed a lot of data.
> To verify this, you could check out a git version just before and
> ju
On Jun 24, 2008, at 5:35 PM, Timur Tabi wrote:
The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for
some
audio related options. In particular, OSS emulation should be
enabled,
and the old ALSA API should be disabled.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
appli
On Jul 16, 2008, at 4:47 PM, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
`
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> > If we don't enable FS_ENET we get build issues:
> >
> > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> > arch/powerpc/platforms/82xx/ep8248e.c:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/pow
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
On Wednesday 16 July 2008, Nathan Lynch wrote:
> Arnd Bergmann wrote:
> > Implement save_stack_trace_tsk on powerpc, so that we can run with
On Sat, 28 Jun 2008 13:16:16 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
> <[EMAIL PROTECTED]> wrote:
> > If an I2C device node does not specify an interrupt, the .irq
> > member of the board_info struct was set to -1. This caused crashes
> > on
On Jul 16, 2008, at 4:41 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
This makes sense. I think we need to order the stores in set_pte_at
regardless of CONFIG_SMP.
Nah, that shouldn't be necessary.
Yeah I finally came to that realization.
Also,
On Sat, Jul 12, 2008 at 2:00 AM, Wolfram Sang <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 11, 2008 at 12:23:23PM -0600, Grant Likely wrote:
>> On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
>> > Firstly kernel warns at set_irq_chip, and then dies completely:
>> >
>> > Trying to insta
On Wed, Jul 16, 2008 at 4:15 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> On Sat, 28 Jun 2008 13:16:16 -0600
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
>> <[EMAIL PROTECTED]> wrote:
>> > If an I2C device node does not specify an interrupt, the
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
>
> On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
>
> > On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
> >> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> >>> If we don't enable FS_ENET we get build iss
On Jul 16, 2008, at 5:10 PM, Kumar Gala wrote:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/buil
On Thu, 2008-07-17 at 00:12 +0200, Arnd Bergmann wrote:
> We need to pass the kernel stack pointer instead of the user space
> stack pointer in save_stack_trace_tsk().
>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
>
> On Wednesday 16 July 2008, Nathan Lynch wrote:
> > Arnd Bergmann wrote:
On Wednesday 16 July 2008, Rune Torgersen wrote:
> I did run oprofile, but I could not figure out how to get it to show me
> where in the kernel it was spending time. It showed that a lot of time
> was spent in vmlinux, but not anything specific. I probably just don't
> know how to set up or run op
Arnd Bergmann wrote:
> We need to pass the kernel stack pointer instead of the user space
> stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https:
On Jul 16, 2008, at 5:19 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't ena
On Wednesday 16 July 2008, Grant Likely wrote:
>
> > Shouldn't it be enough to have a common compatible value in each
> > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > specific type unless you need to do something special?
>
> This is bad for the same reason that "amcc,
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
Note: this tree is based on Linus's master as I need to revert a commit he
applied to the ep8248e board.
to receive the following updates:
Documentation/powerpc/booting
Its possible to build the phylib as a module, however this breaks the
board code because alloc_mdio_bitbang and mdiobus_register are not
available if we build as a module. These are needed by the board code
since it implements the low level mdio bitbang ops.
So we unconditionally select PHYLIB to
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> is not much code can be shared between the two drivers (both are mostly
> driver bindings anyway).
Why can't this driver use the existing gpio-led driver? Basically, do
something l
From: Lee Nipper <[EMAIL PROTECTED]>
Remove of_node_put calls since there is no corresponding of_node_get.
This patch prevents an exception when talitos is loaded a 2nd time.
This sequence: modprobe talitos; rmmod talitos; modprobe talitos
causes this message: "WARNING: Bad of_node_put() on /[EMAI
From: Lee Nipper <[EMAIL PROTECTED]>
Seems that dst == src, but this fixes the logic in case it's not.
Signed-off-by: Lee Nipper <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --gi
add requests pending/submit count to prevent request queue full
condition by preempting h/w overflow interrupts in software.
We do this due to the delay in the delivery and handling of the
channel overflow error interrupt.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Acked-by: Lee Nipper <[EMAI
use GFP_ATOMIC when necessary; use atomic_t when allocating submit_count.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Acked-by: Lee Nipper <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/
free edescriptor when returning error (such as -EAGAIN).
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Acked-by: Lee Nipper <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto
On Tue, 15 Jul 2008, Richard Purdie wrote:
> On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
>>> Spell out openfirmware :). I initially had no idea "of == openfirmware"
>>> and I suspect others won't either...
>>
>> This would be unusually long name, that is
>>
>> $ find . -iname '*openfi
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index a81265b..681c15f 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP_ATOMIC when necessary; use atomic_t when allocating
submit_count.
why?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
. = ALIGN(0x1000) /* this align directive aparently gets lost
when stripping the file */
.rodata: AT (.rodata - LOAD_OFFSET): {
...
}
the effects of that align were dropped during strip, shifting all
following sections up in memory and the resulting failure.
The ELF
On 7/16/08, Milton Miller <[EMAIL PROTECTED]> wrote:
> Hi.
Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.
I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzi
On Wed, Jul 16, 2008 at 08:38:14PM -0400, Jon Smirl wrote:
> On 7/16/08, Milton Miller <[EMAIL PROTECTED]> wrote:
> > Hi.
>
> Previous threads have mentioned that binutil-2.17 is broken for
> building powerpc kernels. It is fixed in binutils-2.18.
>
> I have encountered this and upgrading to 2.18
On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> >
> > > Shouldn't it be enough to have a common compatible value in each
> > > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > > specific type unless you need to do s
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that "amcc,44x-" compatible
values
are bad in device nodes. The definitio
And then you don't need this file at all. Just add a
"amcc,canyonlands" string to your root node compatible property.
No! Don't do this because it is not true!
If the board actually _is_ compatible to the canyonlands board (it
only _adds_ stuff, doesn't change things or takes away things), i
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that "amcc,44x-" compatible
values
are bad in device nodes. The definitio
On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> > Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> > is not much code can be shared between the two drivers (both are mostly
> > driver bindings anyway).
>
> Why can'
__WARN() is not defined for all configs, use WARN_ON(1) instead.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/lib/feature-fixups.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups
The offb driver already has a collection of hacks to be able to set
the palette on various chips. This adds support for r5xx/r6xx radeons.
This is needed as offb is the only console solution on these currently
and the firmware in some cases sets a really bad color palette. This
fixes using some Ra
on Wed, 16 Jul 2008, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
>> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
>>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
>>> is not much code can be shared between the two drivers (both are mostl
Nathan Lynch wrote:
Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
Sweet. One week from mention to working in -next...not bad.
My thanks to Arnd
On Wed, Jul 16, 2008 at 01:53:57PM -0400, Paul Gortmaker wrote:
> It seems that some machines, like a default RHEL4 install, will
> not have a definition for YYRHSLOC, and that prevents building
> dtc. This supplies what appears to be the standard definition
> for it in the event that the host sys
The OF parsing code for PCI addresses isn't always treating properly
the address space indication 0b11 (ie. 0x3) as meaning 64 bits
memory space.
This means that it fails to parse addresses for PCI BARs that have
this encoding set by the firmware, which happens on some SLOF
versions and breaks off
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 000..7e9ce81
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
+LED connected to GPIO
+
+Required properties:
+- compati
1 - 100 of 108 matches
Mail list logo
