On Tue, 2008-07-15 at 16:27 -0500, Kumar Gala wrote:
> Introduced a new set of low level tlb invalidate functions that do not
> broadcast invalidates on the bus:
>
> _tlbil_all - invalidate all
> _tlbil_pid - invalidate based on process id (or mm context)
> _tlbil_va - invalidate based on virtual
On Wed, 2008-07-16 at 14:22 -0700, Geoff Levand wrote:
> Hi Ben,
>
> Here are two more PS3 patches for 2.6.27. Please apply.
Thanks, they'll be in my next batch (hopefully tomorrow).
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Hi Linus, Andrew !
Should I seek somebody's ack before merging a patch like the one below ?
I'm a bit reluctant to merge via the powerpc.git tree some changes to
generic files without at least an ack from somebody else :-)
There have been some debate on whether this AT_BASE_PLATFORM is the
right
On Tue, 2008-07-15 at 15:39 +0400, Anton Vorontsov wrote:
> On Tue, Jul 15, 2008 at 04:02:09PM +1000, Benjamin Herrenschmidt wrote:
> [...]
> > If you believe I've missed something, now is time to be vocal about
> > it :-)
>
> Yes, this one is lost:
>
> [OF] of_gpio: should use new header
> http
On Wed, 2008-07-16 at 09:54 +0200, Arnd Bergmann wrote:
> 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
On Tue, 2008-07-15 at 21:51 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0007-azfs-initial-submit-of-azfs-a-non-buffered-filesys.patch)
> From: Maxim Shchetynin <[EMAIL PROTECTED]>
>
> AZFS is a file system which keeps all files on memory mapped random
> access storage. It w
Hi,
I think no one is able to understand my problem, let me break it to low
level.
What i want is that i have a buffer in driver code which is also handled
by some other application i want that this buffer data is to be used for
capture and playback stream fills data to another buffer which i can
Arnd, Maxim, please, next time, send that patch or at least CC the
bluesmoke-devel list for EDAC related bits.
Doug, if you are ok with this patch, I'll merge it via the powerpc
tree.
Cheers,
Ben.
On Tue, 2008-07-15 at 21:51 +0200, [EMAIL PROTECTED]
> From: Maxim Shchetynin <[EMAIL PROTECTED]>
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
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
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
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, 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
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
__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
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'
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 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
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 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
. = 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 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
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 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
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
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/
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
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
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
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
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
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
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,
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
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 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
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 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 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 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 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 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, 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
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 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
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: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 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
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 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
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, 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
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
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
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
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
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
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
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
* 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
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
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
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:
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
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.
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
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
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
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:
>>
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
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 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
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, 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
> >
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 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 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 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 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, 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: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
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 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 |
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
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
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
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
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
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
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 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
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 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
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
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
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
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
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
1 - 100 of 108 matches
Mail list logo
