Because a mailing list is the best of backups and I've get something
working allright on ebony right now, I figured I would post my WIP
pile of patch bringing PCI to the 44x arch/powerpc world.
At this stage, only ebony is hooked up, there's a known problem with
the SCSI layer and non-coherent
This defines isa_mem_base on both 32 and 64 bits (it used to be 32 bits
only). This avoids a few ifdef's in later patches and potentially can
allow support for VGA text mode on 64 bits powerpc.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Small cleanup pre-requisite for my next
This patch merges the 32 and 64 bits implementations of
pci_process_bridge_OF_ranges(). The new function is cleaner than both
the old ones supports 64 bits ranges on ppc32 which is necessary for
the 4xx port.
It also adds some better (hopefully) output to the kernel log which
should help
This is the common 4xx PCI support code for PCI, PCI-X and PCI-E bridges
The bridges are configured based on device-tree properties.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Only PCI-X in this version, I'll do 405-type PCI soon and will wait for
others to do PCI-E unless
Based on the previous patch, this hooks up PCI for Ebony.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/ebony.dts| 39 -
arch/powerpc/platforms/44x/ebony.c |7 ++
2 files changed, 41 insertions(+), 5
On Mon, 19 Nov 2007 08:15:48 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote:
On Nov 18, 2007 8:18 PM, Trond Myklebust [EMAIL PROTECTED] wrote:
On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
unlink and sillyrename
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see
Matt, the various properties you list do not mean what you think they
mean.
name - should be named according to the generic names convention.
It's pretty much arbitrary, meant for human readability of the device
tree. Drivers should not depend on it (some do, historically, but new
drivers
Matt Sealey wrote:
Jon Smirl wrote:
The codec-fabric node was just being used to trigger the loading of
the platform specific driver.
Just remember one thing.
1) the term fabric when coined for audio drivers is a new, ALSA SoC
specific term. It isn't relevant for anything but ALSA SoC
Jon Smirl wrote:
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric driver.
Do not use the device tree to load the fabric
So, like, the other day Timur Tabi mumbled:
If I weren't on vacation this week, I'd email you my code. It's almost done
and it demonstrates what I'm thinking.
Are the margins of this paper too small for your proof?
jdl
___
Linuxppc-dev mailing
On Wednesday 07 November 2007 20:51, Adam Litke wrote:
When calling get_user_pages(), a write flag is passed in by the caller to
indicate if write access is required on the faulted-in pages. Currently,
follow_hugetlb_page() ignores this flag and always faults pages for
read-only access.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric
David Gibson wrote:
On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
Gah! For the benefit of others on this list who may be misled.
*Neither* of you correctly understands the device tree, what I've seen
of *both* your suggested approaches is crap.
The device tree describes
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
You probably mean don't use the of_platform bus to load the fabric
driver.
Yes, that is what I meant.
He still needs to use the data in the device tree to decide
what fabric drivers to use.
I'm not sure about that.
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In the
On Thu, Nov 15, 2007 at 04:00:09PM -0800, Siva Prasad wrote:
Hi,
This sounds like a familiar problem, but could not get answers in posts
that came up in google search.
My system hangs after printing the message Freeing unused kernel
memory. It should execute init after that, but not sure
On Nov 19, 2007 10:00 AM, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 19 Nov 2007 08:15:48 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote:
On Nov 18, 2007 8:18 PM, Trond Myklebust [EMAIL PROTECTED] wrote:
I had already fixed that one in my own stack. Attached are the 3 patches
that I've
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
I never said drivers should depend on it but why do you want to name
an i2s bus as i2s or the i2c bus as i2c?
Because that's what they are?
There are far, far more descriptive names that can be used. i2s is
basically audio, so why
Bartlomiej Zolnierkiewicz wrote:
Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed
defines (IDE0_BASE_OFFSET and friends) in the platform header file.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
MBR, Sergei
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/19/07, Timur Tabi [EMAIL
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
You might be stuck with using either a platform_device or an
of_platform_device as a stepping stone to creating the device on the
ALSA fabric driver.
I also concluded that I need a
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15
14:09:16.0 +1100
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.0
+1100
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
to pick up a few bug fixes for 2.6.24. The AC97 change is fairly
harmless and is required to get AC97 working on Virtex boards.
josh
Joachim Foerster (1):
[POWERPC] Xilinx:
Jon Smirl wrote:
Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
I believe that is your only choice on v1. V1 is not set up to
correctly handle for
On Sun, 18 Nov 2007, root wrote:
@@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
{
struct page *page;
struct kmem_cache_node *n;
+ unsigned long flags;
BUG_ON(kmalloc_caches-size sizeof(struct kmem_cache_node));
Well local_irq_save is a bit of
On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips [EMAIL PROTECTED] wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new RGMII Internal Delay
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a different BCSR); this patch points
the PHY reset code
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cache blocks,
which are only used on IBM's 64-bit processors.
Convert it to get the blocks sizes out of vdso_data instead, similar
to how the ppc64 in-kernel cache flush does it.
Signed-off-by:
The rtas_os_term() routine was being called at the wrong time.
The actual rtas call os-term will not ever return, and so
calling it from the panic notifier is too early. Instead,
call it from the machine_reset() call.
The patch splits the rtas_os_term() routine into two: one
part to capture
Kim Phillips wrote:
On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips [EMAIL PROTECTED] wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24
For the following bugfix for 2.6.24:
Olof Johansson (1):
[POWERPC] pasemi: Don't reset mpic at boot
setup.c |2 +-
1 file changed, 1 insertion(+), 1
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
David Gibson wrote:
On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
Gah! For the benefit of others on this list who may be misled.
*Neither* of you correctly understands the device tree, what I've seen
of
On Mon, Nov 19, 2007 at 04:58:44PM +, Matt Sealey wrote:
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
Matt, the various properties you list do not mean what you think they
mean.
name - should be named according to the generic names convention.
It's pretty much arbitrary, meant for human readability of the device
tree.
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
arch/powerpc/kernel/isa-bridge.c |4 ++--
arch/powerpc/mm/fault.c|2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c|2 +-
arch/powerpc/platforms/celleb/io-workarounds.c |2 +-
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote:
You might be stuck with using either a platform_device or an
of_platform_device as a stepping stone to creating the device on
In a number of places through libfdt and its tests, we have *_typed()
macro variants on functions which use gcc's typeof and statement
expression extensions to allow passing literals where the underlying
function takes a buffer and size.
These seemed like a good idea at the time, but in fact they
Johannes Berg writes:
This patch adds sysfs attributes to the PMU to allow getting
the information on the PMU type and whether adb is present from
there instead of via the ioctl. The ioctl is made optional and
scheduled for removal.
I don't see any reason to ever remove the ioctls. We're
This fixes a problem noticed by Balbir Singh
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
It's a bad idea to call flush_scheduled_work from within a
netdev-stop because the linkwatch will occasionally take the
rtnl lock from a workqueue context, and thus that can deadlock.
This reworks things a bit in that area to avoid the problem.
Signed-off-by: Benjamin Herrenschmidt [EMAIL
In message [EMAIL PROTECTED] you wrote:
Michael Neuling wrote:
This fixes a problem noticed by Balbir Singh
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c |5 +++--
1 file changed, 3 insertions(+), 2
Michael Neuling wrote:
This fixes a problem noticed by Balbir Singh
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index:
(sorry, untested for lack of hardware)
--
xmon uses a bit lock spinlock but doesn't close the critical section
when releasing it. It doesn't seem like a big deal because it will
eventually break out of the lock anyway, but presumably that's only
in exceptional cases where some error is tolerated,
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
in the trylock).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Acked-by: Benjamin
On Thu, 15 Nov 2007, Cyrill Gorcunov wrote:
This patch does fix potential NULL pointer dereference
that could take place inside of strcmp() if
of_get_property() call failed.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/usb.c |8
1 files
On Mon, 19 Nov 2007, Kim Phillips wrote:
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a
On Tue, 13 Nov 2007, Kim Phillips wrote:
correct the reg property, remove duplicate io port entry, whitespace fixes.
Thanks to Peter Van Ackeren for pointing this out.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_mds.dts |9 -
1 files
On Mon, 5 Nov 2007, Kim Phillips wrote:
if on a rev. 2.1, adjust UCC clock and data timing characteristics
as specified in the rev.2.1 erratum #2.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 ++--
1 files
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
Documentation/powerpc/booting-without-of.txt |5 -
arch/powerpc/boot/dts/mpc832x_mds.dts|9 -
On Tue, Nov 20, 2007 at 04:28:02PM +1100, Paul Mackerras wrote:
Nick Piggin writes:
xmon uses a bit lock spinlock but doesn't close the critical section
when releasing it. It doesn't seem like a big deal because it will
eventually break out of the lock anyway, but presumably that's only
On Sun, 18 Nov 2007 14:18:06 -0500 Trond Myklebust [EMAIL PROTECTED] wrote:
Torsten
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Andrew, could you please unapply the sillyrename patches you've got, and
apply these 3
The interrupt map for the PCI PHB that had the ULI1575 was not correct
on the boards that have it.
* 8544 DS:
- Fix interrupt mask
- Be explicit about use of INTA for on chip peripherals
* 8572 DS/8641 HPCN:
- Fix interrupt mask
- Expand interrupt map for PCI slots to cover all
On Mon, 5 Nov 2007, Kim Phillips wrote:
A h/w bug requires we program the PHY in RGMII mode for internal delay
on the receive or transmit side only; document the new property values.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |5 +++--
On Tue, Nov 20, 2007 at 05:08:24PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote:
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for
On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote:
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
in the trylock).
From: Grant Likely [EMAIL PROTECTED]
xmon is broken under arch/ppc so remove it from the defconfig.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Josh; I'm not going to even bother doing a full defconfig update for these
boards right now; it's probably not worth it. This change just
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a
couple of places. This fixes it.
Spotted by Olof Johansson
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c |2 +-
On Tue, 2007-11-20 at 07:26 +0100, Nick Piggin wrote:
BTW, here is another thing which you might want to think about. Again
untested for temporary lack of hardware.
--
The radix-tree is now RCU safe, so powerpc can avoid the games it was playing
in order to have a lockless readside.
63 matches
Mail list logo
