On Wed, 2008-02-06 at 23:43 -0500, Sean MacLennan wrote:
> I just did a git pull of Josh's tree, and
> arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
> glossing over the linuxppc-dev emails, so forgive me if this already
> came up.
>
> It looks like, at least for the Warp
*bump*? :) If anything is wrong with it, please let me know.
Imre
On Sun, 03 Feb 2008 11:41:44 +0100, Imre Kaloz <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Imre Kaloz <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/taishan.dts | 33 +++-
> arch/powerpc/configs/taishan_defcon
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git for-2.6.25
I have added a few more commits since yesterday's pull request: some
commits updating the 4xx support from Josh Boyer's tree, a compile fix
for 52xx, and a string of commits from Roland McGrat
Hi,
Can anyone help me on KDB patches for ppc32? Is any patches available for
the same? If yes, please give me the links.
Thanks,
Gk
--
View this message in context:
http://www.nabble.com/KDB-on-ppc32-tp15330900p15330900.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
__
On Thu, 07 Feb 2008 11:29:55 +0100
"Imre Kaloz" <[EMAIL PROTECTED]> wrote:
> *bump*? :) If anything is wrong with it, please let me know.
Nothing wrong that I could see. I just need to test it first.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozl
Well, arch/ppc calculates the mtd2 dynamically and doesn't create
a separate partition for kozio.
I've based this on how it's currently done for the Sequoia, too.
Imre
On Thu, 07 Feb 2008 14:46:43 +0100, Valentine Barshak
<[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>> On Thu, 07 Feb 2008
On Thu, 07 Feb 2008 15:05:23 +0100, Valentine Barshak
<[EMAIL PROTECTED]> wrote:
>> Well, arch/ppc calculates the mtd2 dynamically and doesn't create
>> a separate partition for kozio.
>
> That dynamic size calculation depends on the flash size.
> The board I use has a 64MB NOR flash (I'm not aw
Hi,
I'm using a 2.6.23 kernel and trying to get the AC97 running on my MPC5200B
based CPU card. I'm using a patch stack posted here last year. FEC and ATA
seems running correctly. Also the AC97 seems to run, but I can hear some
noise only. But ALSA does detect the external Wolfson codec and its
1. Detect (and bail out on) more conditions that violate the
assumptions of the setup code -- we assume in such cases that the device
tree is correct and reflects what the firmware did.
2. The inbound memory mask calculation was wrong.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/power
Benjamin Herrenschmidt wrote:
> On Wed, 2008-02-06 at 23:43 -0500, Sean MacLennan wrote:
>
>> I just did a git pull of Josh's tree, and
>> arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
>> glossing over the linuxppc-dev emails, so forgive me if this already
>> came up.
>
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
> I just did a git pull of Josh's tree, and
> arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
> glossing over the linuxppc-dev emails, so forgive me if this already
> came up.
>
> It looks like, at least for th
Josh Boyer wrote:
> On Thu, 07 Feb 2008 11:29:55 +0100
> "Imre Kaloz" <[EMAIL PROTECTED]> wrote:
>
>> *bump*? :) If anything is wrong with it, please let me know.
The arch/ppc had a bit different partition table.
Something like this:
mtd0: 0018 0004 "kernel"
mtd1: 0020 0004 "root"
On Fri, 8 Feb 2008, Paul Mackerras wrote:
>
> From: Tony Breeds <[EMAIL PROTECTED]>
>
> Commit ad7f71674ad7c3c4467e48f6ab9e85516dae2720 corrected the clock
> ..
Please, when mentioning hex numbers, also do the one-liner shortlog.
I realize that in gitk (or even just with two terminal windows o
From: Tony Breeds <[EMAIL PROTECTED]>
Commit ad7f71674ad7c3c4467e48f6ab9e85516dae2720 corrected the clock
resolution reported by the VDSO clock_getres() but introduced another
problem in that older versions of gcc (gcc-4.0 and earlier) fail to
compile the new code in arch/powerpc/kernel/asm-offset
Imre Kaloz wrote:
> Well, arch/ppc calculates the mtd2 dynamically and doesn't create
> a separate partition for kozio.
That dynamic size calculation depends on the flash size.
The board I use has a 64MB NOR flash (I'm not aware of other Taishan
boards having chips of different size). So AFAIU if
Imre Kaloz wrote:
> On Thu, 07 Feb 2008 15:05:23 +0100, Valentine Barshak
> <[EMAIL PROTECTED]> wrote:
>
>>> Well, arch/ppc calculates the mtd2 dynamically and doesn't create
>>> a separate partition for kozio.
>>
>> That dynamic size calculation depends on the flash size.
>> The board I use has
David Gibson wrote:
> And here's a revised version. This now also handles recursive
> iteration and iteration across nodes without respect to depth. I've
> removed the for_each() macros for the time being, because they were
> making my brain hurt, but I'm still contemplating bringing them back.
>
- couple of fixes and preparatory patches
- rework of PowerMac media-bay support ([un]register IDE devices instead of
[un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
- IDE warm-plug support (though it is still experimental it should work fine,
unlike the older me
This hwif->chipset fixup is already present in ide_device_add_all()
but for warm-plug support we also need to reserve not currently present
interfaces.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-generic.c |4 +++-
1 file changed, 3 insertions(+), 1 deleti
* Instead of checking for '->io_ports[IDE_DATA_OFFSET] == 0' check for
'->chipset == ide_unknown' when looking for an empty ide_hwifs[] slot.
* Do ide-pnp initialization after ide-generic when IDE is built-in
(ide-pnp is the only user of ide_find_port() which needs such fixup).
Signed-off-by:
* Use ide_find_port() instead of ide_deprecated_find_port() in bast-ide/
palm_bk3710/ide-cs/delkin_cb host drivers and in ide_register_hw().
* Remove no longer needed ide_deprecated_find_port().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/bast-ide.c|
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-acpi.c |2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/ide/ide-acpi.c
===
--
* Factor out cable detection from ide_init_port() to ide_port_cable_detect().
* Move ide_port_cable_detect() call to ide_device_add_all().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c |4
1 file changed, 4 insertions(+)
Index: b/drivers/ide/i
Factor out code unregistering devices from ide_unregister() to
ide_port_unregister_devices().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
Index: b/drivers/ide/ide.c
===
* Factor out devices init from ide_init_port_data() to
ide_port_init_devices_data().
While at it:
* Add explicit clearing of IDE device structure.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c
Add ide_cfg_mtx lock/unlock to ide_port_setup_devices() and then move
ide_port_setup_devices() call from init_irq() to ide_device_add_all().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Ind
Rework PowerMac media-bay support in such way that instead of
un/registering the IDE interface we un/register IDE devices:
* Add ide_port_scan() helper for probing+registerering devices on a port.
* Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
* Add ide_port_unregiste
* Add 'struct class ide_port_class' ('ide_port' class) and embedd 'struct
class_device classdev' ('ide_port' class device) in ide_hwif_t.
* Register 'ide_port' class in ide_init() and unregister it in
cleanup_module().
* Add class_to_ide_port() macro and ide_port_class_release().
* Register
* Add ide_generic_sysfs_init() helper registering 'ide_generic' class
(together with ide_generic_class_release() ->class_release method)
and use it in ide_generic_init().
* Add "add" class attribute to 'ide_generic' class for adding new interfaces
(it is intended to be a replacement for obso
request_irq() will fail if there is already another IRQ handler
registered and IRQ flags are mismatched.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c |7 ---
1 file changed, 7 deletions(-)
Index: b/drivers/ide/ide-probe.c
==
* Remove CONFIG_BLK_DEV_HD hack from init_hwif_default() ("ide0=noprobe"
kernel parameter should be used instead if somebody wishes to use the
old "hd" driver).
* Make CONFIG_BLK_DEV_HD_ONLY config option available also when IDE
subsystem is used and update help entry.
* Remove no longer ne
* Remove obsoleted "idex=base[,ctl[,irq]]" kernel parameters
and update Documentation/ide.txt.
* Remove no longer needed ide_forced chipset type.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-244 bytes (x86-32)
Documentation/ide.txt | 31 -
hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
and given the number of bugs we can assume that there are no real users:
* DMA has no chance of working because DMA resources are released by
ide_unregister() and they are never allocated again.
* Since ide_init_hwif_ports
->hold is write-only now, remove it.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/mips/au1xxx-ide.c |3 ---
drivers/ide/ppc/pmac.c|1 -
include/linux/ide.h |1 -
3 files changed, 5 deletions(-)
Index: b/drivers/ide/mips/au1xxx-ide.c
=
init_hwif_default() is only used by init_ide_data() now, inline it there.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
Index: b/drivers/ide/ide.c
=
ide_init_hwif_ports() is only used by init_ide_data() now, inline it there.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c | 11 +--
include/linux/ide.h | 32
2 files changed, 9 insertions(+), 34 deletions(-)
Inde
From: Luke Browning <[EMAIL PROTECTED]>
Stop bits are only valid when the running bit is not set. Status bits carry
over from one invocation of spufs_run_spu() to another, so the RUNNING bit
gets added to the previous state of the register which may have been a remote
library call. In this case,
From: Christoph Hellwig <[EMAIL PROTECTED]>
Fix various state_mutex leaks. The worst one was introduced by the
interrutible state_mutex conversion but there've been a few before
too. Notably spufs_wait now returns without the state_mutex held
when returning an error, which actually cleans up some
From: Luke Browning <[EMAIL PROTECTED]>
We don't need to update the libassist statistic with the context in a
runnable state, so do it after spu_disable_spu().
Signed-off-by: Luke Browning <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]>
Acked-by: Christoph Hellwig <[EMAIL PROTE
From: Masato Noguchi <[EMAIL PROTECTED]>
Currently, the kernel may fail to restart a SPE context which
has stopped and been swapped out.
This patch changes spu_backing_runcntl_write to emulate the real
SPU_Status register exactly. When the SPU Run Control register
is written with SPU_RunCntl[Run
Hi Paul,
Here are a few spufs fixes & updates for 2.6.25. Let me know if these
are all OK.
Cheers,
Jeremy
---
Christoph Hellwig (1):
spufs: fix state_mutex leaks
Luke Browning (2):
spufs: no need to have a runnable SPU for libassist update
spufs: fix timing dependent false r
The cell IOMMU fixed mapping support has a null pointer bug if you run
it on older firmwares that don't contain the "dma-ranges" properties.
Fix it and convert to using of_get_next_parent() while we're there.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iomm
If we get a 64-bit dma mask we switch to the fixed ops and call
cell_dma_dev_setup(). If the driver then switches back to a 32-bit dma
mask for any reason we don't call cell_dma_dev_setup() again, which
has the potential to leave bogus data in dev->archdata.dma_data.
Signed-off-by: Michael Ellerma
Currently the cell IOMMU fixed mapping just printks that it's been setup,
which is not particularly useful. Much more interesting is the address
ranges for the different windows. This adds one line to dmesg on a blade.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms
In order for the cell IOMMU fixed mapping to work we need "dma-ranges"
properties in the device tree. If there are none then there's no point
enabling the fixed mapping support.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 12
1 file
On Tue, Feb 05, 2008 at 09:39:02AM -0700, Grant Likely wrote:
> On 2/5/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Fri, Feb 01, 2008 at 09:23:47AM -0700, Grant Likely wrote:
> > > cell-index has been useful for things like clock controllers to know
> > > what offset into a shared clock contr
46 matches
Mail list logo
