* [PATCH] powerpc: Auto reserve of device tree blob
From: Michael Neuling @ 2006-05-18 22:03 UTC (permalink / raw)
To: linuxppc-dev, paulus
In-Reply-To: <5148225C-AE27-4365-A1C2-40C46491AF0D@watson.ibm.com>
From: Jimi Xenidis <jimix@watson.ibm.com>
A devtree compiler (dtc) generated devtree blob is "relocatable" and so
does not contain a reserved_map entry for the blob itself. This means
that if passed to Linux, Linux will not get lmb_reserve() the blob and
it could be over. The following patch will explicitly reserve the
"blob" as it was given to us and stops prom_init.c from creating a
reserved mapping for the blob.
NOTE: that the dtc/kexec should not generate the blob reservation entry.
Although if they do, LMB reserver handles overlaps.
Signed-off-by: <jimix@watson.ibm.com>
Acked-by: Michael Neuling <mikey@neuling.org>
---
After some discussion last time, it seemed this was the right was to do
this. I'll post the kexec cleanups if/when this gets upstream.
Mikey
arch/powerpc/kernel/prom.c | 5 +++++
arch/powerpc/kernel/prom_init.c | 9 ++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
Index: linux-2.6-powerpc/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6-powerpc/arch/powerpc/kernel/prom.c
@@ -1240,6 +1240,11 @@ static void __init early_reserve_mem(voi
reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
initial_boot_params->off_mem_rsvmap);
+
+ /* before we do anything, lets reserve the dt blob */
+ lmb_reserve(__pa((unsigned long)initial_boot_params),
+ initial_boot_params->totalsize);
+
#ifdef CONFIG_PPC32
/*
* Handle the case where we might be booting from an old kexec
Index: linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
@@ -2031,11 +2031,7 @@ static void __init flatten_device_tree(v
/* Version 16 is not backward compatible */
hdr->last_comp_version = 0x10;
- /* Reserve the whole thing and copy the reserve map in, we
- * also bump mem_reserve_cnt to cause further reservations to
- * fail since it's too late.
- */
- reserve_mem(RELOC(dt_header_start), hdr->totalsize);
+ /* Copy the reserve map in */
memcpy(rsvmap, RELOC(mem_reserve_map), sizeof(mem_reserve_map));
#ifdef DEBUG_PROM
@@ -2048,6 +2044,9 @@ static void __init flatten_device_tree(v
RELOC(mem_reserve_map)[i].size);
}
#endif
+ /* Bump mem_reserve_cnt to cause further reservations to fail
+ * since it's too late.
+ */
RELOC(mem_reserve_cnt) = MEM_RESERVE_MAP_SIZE;
prom_printf("Device tree strings 0x%x -> 0x%x\n",
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 22:04 UTC (permalink / raw)
To: Kumar Gala
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <F9D52BC7-8314-42FD-8068-93A91DAD09E6@kernel.crashing.org>
On Thu, 2006-05-18 at 11:41 -0500, Kumar Gala wrote:
> >> I will get rid of those tables. I can see that in file
> >> arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
> >> a similar table. Should it be removed in future :)?
> >
> > Yes. And somebody beaten up for letting that stuff leak into
> > arch/powerpc :)
> >
> >>> Yes, please do so, we will not accept a board that does the above :)
> >>
> >> I just do the same thing as 85xx :).
> >
> > Yes and I intend to LART Kumar seriously for that next time I meet
> > him :)
>
> Get in line ;) [lets be fair, I didn't actually do the 85xx/ads.c
> port, but it was based on the 83xx which I did do]
>
> The problem with the irq mapping is we dont have any code yet that
> handles the "static" tables.
We do, though right now it doesn't do much good if you don't have device
nodes for PCI devices indeed :) Fix real soon now !
Ben.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Andreas Schwab @ 2006-05-18 22:06 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, Johannes Berg, debian-powerpc
In-Reply-To: <20060518181748.GA2836@localhost>
Wolfgang Pfeiffer <roto@gmx.net> writes:
> BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> PB5,8 ?
AFAIK, alsaconf has only support for probing PCI and ISA sound cards, but
the AOA sound is hidden behind an i2s bus that is hidden behind a mac-io
bus. The version included in SuSE has hardcoded special cases for Sparc
and PPC.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* PPC host with a PCI root-complex
From: Srinivas Murthy @ 2006-05-18 21:56 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hi,
We have a ppc host with a PCI root-complex across which there are multiple
PCI end points.
An application running on the ppc host reading one of the device memory
regions (not DMA access but direct CPU read) causes a parity error on the
PCI interface controller.
We think that the error should be propagated up as a machine-check which is
considered a non-recoverable system-wide error. However with multiple PCI
devices present we think that this is too generic and could be reduced to be
a critical-error which could be recovered from.
Are there any other approaches/thoughts keeping in mind that this is PPC
host and we're running a PCI-rootcomplex interface?
Thanks,
_Srinivas
[-- Attachment #2: Type: text/html, Size: 919 bytes --]
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Paul Mackerras @ 2006-05-18 22:58 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1147988040.2692.40.camel@basalt.austin.ibm.com>
Hollis Blanchard writes:
> This patch adds ifdefs mid-file, but some were already present anyways,
> and I don't see a better way.
It would look better as:
#ifdef CONFIG_PPC_MAPLE
/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
* The values are bad, and it doesn't even have the right number of cells. */
static void __init fixup_device_tree_maple(void)
{
... etc ...
}
#else
#define fixup_device_tree_maple()
#endif
#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
static void __init fixup_device_tree_pmac(void)
{
... etc ...
}
#else
#define fixup_device_tree_pmac()
#endif
static void __init fixup_device_tree(void)
{
fixup_device_tree_maple();
fixup_device_tree_pmac();
}
Care to redo the patch?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Segher Boessenkool @ 2006-05-18 23:11 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060518171159.GD8220@pb15.lixom.net>
> Acked-by: Olof Johansson <olof@lixom.net>
>
> (I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
> have access to either to make sure it doesn't break there. Main worry
> would be if it lacked ibm,#dma*-properties for some reason.)
The code seems to be resilient against that. Haven't tested though.
Segher
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Olof Johansson @ 2006-05-18 23:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <06890505-B9A0-42B9-A713-A035FBCBDD1B@kernel.crashing.org>
On Fri, May 19, 2006 at 01:11:51AM +0200, Segher Boessenkool wrote:
> > Acked-by: Olof Johansson <olof@lixom.net>
> >
> > (I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
> > have access to either to make sure it doesn't break there. Main worry
> > would be if it lacked ibm,#dma*-properties for some reason.)
>
> The code seems to be resilient against that. Haven't tested though.
Well, yes. I should have said: if it lacks the ibm,#dma- and the
normal addr-cells properties aren't the same as we assumed before.
-Olof
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Segher Boessenkool @ 2006-05-18 23:38 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605181456p3c1726e2n56942dfbd4217f70@mail.gmail.com>
> We have a ppc host with a PCI root-complex across which there are
> multiple PCI end points.
>
> An application running on the ppc host reading one of the device
> memory regions (not DMA access but direct CPU read) causes a parity
> error on the PCI interface controller.
>
> We think that the error should be propagated up as a machine-check
> which is considered a non-recoverable system-wide error. However
> with multiple PCI devices present we think that this is too generic
> and could be reduced to be a critical-error which could be
> recovered from.
>
> Are there any other approaches/thoughts keeping in mind that this
> is PPC host and we're running a PCI-rootcomplex interface?
You can handle the machine check in a platform-specific way --
see ppc_md.machine_check_exception().
Segher
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Paul Mackerras @ 2006-05-18 23:50 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-arch, linuxppc-dev, linux-kernel, amodra, rth
In-Reply-To: <20060510.171127.42619262.davem@davemloft.net>
David S. Miller writes:
> If you have to hide the operation so deeply like this, maybe you can
> do something similar to sparc64, by explicitly doing the per-cpu fixed
> register and offsets, and still get the single instruction relocs that
> powerpc can do for up to 64K by doing something like:
>
> &per_cpu_blah - &per_cpu_base
>
> to calculate the offset.
I don't know how to tell gcc that (&per_cpu_blah - &per_cpu_base) is a
quantity that the linker can compute and that will fit into a 16-bit
offset. If I use an inline asm, then I have to generate the address
and let gcc dereference it, because __get_cpu_var is used both as an
lvalue and an rvalue. That means two instructions where one would
suffice. So there doesn't seem to be a way to get the optimal code,
unless the gcc folks are willing to add a -fkernel or something for
us. :)
Paul.
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Segher Boessenkool @ 2006-05-18 23:53 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1147988040.2692.40.camel@basalt.austin.ibm.com>
> + isa_ranges[0] = 0x1;
> + isa_ranges[1] = 0x0;
> + isa_ranges[2] = 0x0;
> + isa_ranges[3] = 0x0;
> + isa_ranges[4] = 0x0;
> + isa_ranges[5] = 0x00010000;
> + prom_setprop(isa, "/ht@0/isa@4", "ranges",
> + isa_ranges, sizeof(isa_ranges));
isa_ranges[2] = 0x01002000;
isa_ranges[5] looks suspicious as well; the value you put in
means that *no* (16-bit, which is all that 8111 supports) legacy
I/O sits on any other than the LPC bus; so no 8111 ATA support,
for example.
Showing only I/O ranges in the "ranges" property means that no
devices below the "isa" node sit on memory space; is that true
for the Maple device tree? (The node for the flash chip,
specifically, if it exists in their tree at all). If not, I'll
dig out the proper "ranges" value for it tomorrow (it depends on
hardware settings on their SIO chip, I have no idea what they
set it to right now :-) ).
I'm sure this all works for your kernel right now, but if you're
fixing up, let's fix it properly :-)
Segher
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Segher Boessenkool @ 2006-05-18 23:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060518231306.GG8220@pb15.lixom.net>
>> The code seems to be resilient against that. Haven't tested though.
>
> Well, yes. I should have said: if it lacks the ibm,#dma- and the
> normal addr-cells properties aren't the same as we assumed before.
Missing #addr-cells means it's 2; does our code handle that correctly?
Sorry, too tired to check it myself :-)
Segher
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Mark A. Greer @ 2006-05-19 0:37 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1147960021.7607.5.camel@localhost.localdomain>
On Thu, May 18, 2006 at 08:47:01AM -0500, Matthew McClintock wrote:
> On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> > +void *
> > +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
>
> Is there a reason you are not using of_get_flat_dt_prop() instead of
> implementing your own version?
Yes. One is in the kernel, one isn't. Or, are you asking why I didn't
just copy the kernel code? If so, I probably should have.
Hrm, we almost need a library of code shared between the kernel &
the bootwrapper. Sort of illegal but it would save duplicating code
like the flat dt code.
Comments?
Mark
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Michael Ellerman @ 2006-05-19 0:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060519003730.GA7338@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
On Thu, 2006-05-18 at 17:37 -0700, Mark A. Greer wrote:
> On Thu, May 18, 2006 at 08:47:01AM -0500, Matthew McClintock wrote:
> > On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> > > +void *
> > > +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
> >
> > Is there a reason you are not using of_get_flat_dt_prop() instead of
> > implementing your own version?
>
> Yes. One is in the kernel, one isn't. Or, are you asking why I didn't
> just copy the kernel code? If so, I probably should have.
>
> Hrm, we almost need a library of code shared between the kernel &
> the bootwrapper. Sort of illegal but it would save duplicating code
> like the flat dt code.
>
> Comments?
Yeah we do. And it's not illegal IMHO as two of our boot wrappers
(prom_init and the iSeries one) are linked with the kernel anyway.
I think you should write it ;)
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-19 1:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Yang Xin-Xin-r48390, Alexandre.Bounine, linuxppc-dev list
> Zang Roy-r61911 writes:
>
> > I can migrate my code to embedded6xx technically. In fact,
> > I can move it into anywhere in the arch/powerpc/platforms.
> > While for mpc7448hpc2(taiga) board, it is not a embedded
> > application board. It is a high performance server! It seems
> > odd to put code there :). What's your opinion?
>
> What sort of machine(s) is this board used in? Or what machines will
> it be in?
>
> Paul.
>
mpc7448hpc2 (taiga) board is a high-performance PowerPC
server reference design,which is optimized for high speed throughput
between the processor (mpc7448 or 7447A) and the memory, disk drive
and Ethernet port subsystems.
mpc7448hpc2 (taiga) is designed to the micro-ATX chassis,
allowing it to be used in 1U or 2U rack-mount chassis' , as well as
in standard ATX/Micro-ATX chassis.
Roy
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Hollis Blanchard @ 2006-05-19 2:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17516.64514.854281.64425@cargo.ozlabs.ibm.com>
On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
>
> It would look better as:
>
> #ifdef CONFIG_PPC_MAPLE
> /* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
> * The values are bad, and it doesn't even have the right number of cells. */
> static void __init fixup_device_tree_maple(void)
> {
> ... etc ...
> }
> #else
> #define fixup_device_tree_maple()
> #endif
>
> #if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
> static void __init fixup_device_tree_pmac(void)
> {
> ... etc ...
> }
> #else
> #define fixup_device_tree_pmac()
> #endif
>
> static void __init fixup_device_tree(void)
> {
> fixup_device_tree_maple();
> fixup_device_tree_pmac();
> }
>
> Care to redo the patch?
If you really think that looks better, sure. :)
-Hollis
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Andy Fleming @ 2006-05-18 20:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <1147936929.17679.106.camel@localhost.localdomain>
On May 18, 2006, at 02:22, Benjamin Herrenschmidt wrote:
> On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
>>> I'm not repeating Kumar's comments about that CONFIG_7xxx
>>> thing and that
>>> 7xxx/ directory, it should all go.
>>>
>>
>> Should I move my code to embedded6xx?
>
> Probably for now yes.
>
>> I will get rid of those tables. I can see that in file
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
>> a similar table. Should it be removed in future :)?
>
> Yes. And somebody beaten up for letting that stuff leak into
> arch/powerpc :)
>
>>> Yes, please do so, we will not accept a board that does the above :)
>>
>> I just do the same thing as 85xx :).
>
> Yes and I intend to LART Kumar seriously for that next time I meet
> him :)
So some of this needs to be moved into u-boot (look at my patches to
u-boot for the 85xx CDS support, and support in the current
powerpc.git tree). A lot of the PCI initialization is now there.
However, the interrupt maps, while properly setup in the current 85xx
u-boot oftree.dts files, is currently meaningless. I may be wrong,
but I thought support for getting the map from the flat-dev tree was
still pending....
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Zang Roy-r61911 @ 2006-05-19 4:06 UTC (permalink / raw)
To: Mark Lord, Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
> Jeff Garzik wrote:
> > Benjamin Herrenschmidt wrote:
> >> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
> ..
> >>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
> >>> static void mv5_enable_leds(struct mv_host_priv *hpriv,
> void __iomem
> >> *mmio)
> >>> {
> >>> u32 tmp;
> >>> -
> >>> +#ifndef CONFIG_PPC
> >>> writel(0, mmio + MV_GPIO_PORT_CTL);
> >>> +#endif
> >>
> >> You'll have to do better here too... I don't wee why when
> compiled on
> >> PPC, this driver should "magically" not clear those
> bits... At the very
> >> least, you should test the machine type if you want to do something
> >> specific to your platform, but first, you'll have to
> convince Jeff why
> >> this change has to be done in the first place and if there
> is a better
> >> way to handle it.
> >
> > Correct... it does seem some bugs were found, but #ifdef
> powerpc is
> > certainly out of the question. We want the driver to work without
> > ifdefs on all platforms.
>
> Yup. I have a powerpc platform here with PCI-X, and a PCI-X
> Marvell card
> to try in it. So I'll pick up these changes and try to
> integrate them a
> little more nicely in my internal updated driver, and then
> pass it on to Jeff.
>
> Cheers
>
^ permalink raw reply
* Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-19 4:07 UTC (permalink / raw)
To: linuxppc-dev list, cbe-oss-dev; +Cc: Paul Mackerras, Arnd Bergmann
The Cell has a couple of "features" that should be exposed to userland
in a way or another. That raises some questions however about how those
should be done. Among others that come to mind:
- The timebase errata (should we use a separate aux vector for "bugs"
than for "features" ?
- Additional Altivec instructions (load/store right/left). A new
feature bit for these ?
- Lack of data stream instructions. Until now, it was assumed that
those were tied to the presence
of an Altivec (and they are documented in the Altivec manual). Maybe
we should split that to a
new bit. I don't know if existing applications use them though, if
they do, there will be a
problem to get them updated as the new bit isn't present on older
kernels...
- Extended implementation of dcbt. (Another bit ? Or sould we just have
a "CELL" bit ? In which
case should it cover the altivec additions too or are those likely to
exist in future non-Cell
processors ?)
- Not strictly Cell specific but we currently don't expose the support
for optional instructions
fres and frsqte (which are supported by Cell)
Part of the problem is that we only have 32 userland feature bits and
for some reason decided to put the microarchitecture in there, thus we
are running out fast...
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Zang Roy-r61911 @ 2006-05-19 4:12 UTC (permalink / raw)
To: Mark Lord, Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
> Jeff Garzik wrote:
> > Benjamin Herrenschmidt wrote:
> >> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
> ..
> >>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
> >>> static void mv5_enable_leds(struct mv_host_priv *hpriv,
> void __iomem
> >> *mmio)
> >>> {
> >>> u32 tmp;
> >>> -
> >>> +#ifndef CONFIG_PPC
> >>> writel(0, mmio + MV_GPIO_PORT_CTL);
> >>> +#endif
> >>
> >> You'll have to do better here too... I don't wee why when
> compiled on
> >> PPC, this driver should "magically" not clear those
> bits... At the very
> >> least, you should test the machine type if you want to do something
> >> specific to your platform, but first, you'll have to
> convince Jeff why
> >> this change has to be done in the first place and if there
> is a better
> >> way to handle it.
> >
> > Correct... it does seem some bugs were found, but #ifdef
> powerpc is
> > certainly out of the question. We want the driver to work without
> > ifdefs on all platforms.
>
> Yup. I have a powerpc platform here with PCI-X, and a PCI-X
> Marvell card
> to try in it. So I'll pick up these changes and try to
> integrate them a
> little more nicely in my internal updated driver, and then
> pass it on to Jeff.
>
> Cheers
>
The reason why I use "ifdef" is that I do not want to affect other platform. I do not
have other platform to verify. If you can verify my patch on your powerpc platform,
please help to integrate it into your driver.
^ permalink raw reply
* Recall: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on po werp c pl atform
From: Zang Roy-r61911 @ 2006-05-19 4:12 UTC (permalink / raw)
To: Mark Lord, Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
Zang Roy-r61911 would like to recall the message, "[PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform".
^ permalink raw reply
* Re: [PATCH] remove powerpc bitops infavor of existing generic bitops
From: Paul Mackerras @ 2006-05-19 5:00 UTC (permalink / raw)
To: Jon Mason; +Cc: linuxppc-dev
In-Reply-To: <20060515180108.GB17646@us.ibm.com>
Jon Mason writes:
> There already exists a big endian safe bitops implementation in
> lib/find_next_bit.c. The code in it is 90%+ common with the powerpc
> specific version, so the powerpc version is redundant. This patch
> makes the necessary changes to use the generic bitops in powerpc, and
> removes the powerpc specific version.
This patch breaks ARCH=ppc builds. Please resubmit with the necessary
changes to arch/ppc/Kconfig as well.
Paul.
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-19 5:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <1148011621.13249.7.camel@localhost.localdomain>
On Fri, May 19, 2006 at 02:07:01PM +1000, Benjamin Herrenschmidt wrote:
> The Cell has a couple of "features" that should be exposed to userland
> in a way or another. That raises some questions however about how those
> should be done. Among others that come to mind:
Good questions, to make things scale when going from here on out
(including new products from various companies in the PPC arena), more
fine-grained features would certainly be useful.
> - The timebase errata (should we use a separate aux vector for "bugs"
> than for "features" ?
How are other userspace-exposed erratas normally handled? How are they
handled on other architectures? Adding it to the feature aux table
sounds like a bad idea.
> - Additional Altivec instructions (load/store right/left). A new
> feature bit for these ?
> - Lack of data stream instructions. Until now, it was assumed that
> those were tied to the presence
> of an Altivec (and they are documented in the Altivec manual). Maybe
> we should split that to a
> new bit. I don't know if existing applications use them though, if
> they do, there will be a
> problem to get them updated as the new bit isn't present on older
> kernels...
I'm assuming you mean the instructions described under "AltiVec Memory
Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
dstst, dss and dssall?
Since they're explicitly part of the Altivec ISA, not the PPC ISA,
I don't see a need for a separate feature bit for them. They are not
marked as optional in the version I'm looking at right now (2.0).
> - Extended implementation of dcbt. (Another bit ? Or sould we just have
> a "CELL" bit ? In which
> case should it cover the altivec additions too or are those likely to
> exist in future non-Cell
> processors ?)
If you're referring to the extended dcbt that includes streaming hints
(as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
separate bit is likely needed -- obviously at least 970 seems to
implement them.
> - Not strictly Cell specific but we currently don't expose the support
> for optional instructions
> fres and frsqte (which are supported by Cell)
>
> Part of the problem is that we only have 32 userland feature bits and
> for some reason decided to put the microarchitecture in there, thus we
> are running out fast...
From what I understood by Paul's choice of feature naming (see the
POWER6 patch discussions), PPC_ARCH_2_05 and similar will mean base
architecture version implemented and should not be used to assume
anything about optional features.
So, with that as a base, there will need to be a way to
indicate which optional features are available, plus what possible
extensions/implementation-specific features are there, at least if they
are common to more than one implementation/processor version. Bit arrays
seem to be the New Way of doing it between firmware and kernel, maybe
the same can/should be used for kernel->userspace? Can the aux vectors
be of arbitrary length?
-Olof
^ permalink raw reply
* pci-OF-bus-map deprecation
From: Benjamin Herrenschmidt @ 2006-05-19 5:24 UTC (permalink / raw)
To: linuxppc-dev list, Linux Kernel list
For 32 bits machines with Open Firmware, we used to create a
pci-OF-bus-map property in the device-tree that provided a mapping
between linux and Open Firmware PCI bus numbers (since on some platforms
like PowerMac, we still renumber PCI busses).
This property is no longer necessary as
- Nowadays, we have sysfs and the PCI devices in there do have a full
Open Firmware device path exposed as a "devspec" file in their sysfs
directories
- I don't think anybody ever used that property in userland :)
This mail is mostly to make sure of the later. I intend to get rid of it
in 2.6.18 (that's early, but as I said, I think nobody uses it anyway. I
intended to use it in some X stuff I never ended up actually
implementing...)
It only concerns 32 bits ppc machines with OF, and only the ones that
renumber busses, which means basically only PowerMacs.
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Andrew Pinski @ 2006-05-19 5:27 UTC (permalink / raw)
To: Olof Johansson; +Cc: cbe-oss-dev, Arnd Bergmann, linuxppc-dev list
In-Reply-To: <20060519051939.GJ8220@pb15.lixom.net>
On May 18, 2006, at 10:19 PM, Olof Johansson wrote:
>> - Lack of data stream instructions. Until now, it was assumed that
>> those were tied to the presence
>> of an Altivec (and they are documented in the Altivec manual).
>> Maybe
>> we should split that to a
>> new bit. I don't know if existing applications use them though, if
>> they do, there will be a
>> problem to get them updated as the new bit isn't present on older
>> kernels...
>
> I'm assuming you mean the instructions described under "AltiVec Memory
> Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
> dstst, dss and dssall?
They are nops on the Cell though. They are also microcoded on the 970.
>
> If you're referring to the extended dcbt that includes streaming hints
> (as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
> separate bit is likely needed -- obviously at least 970 seems to
> implement them.
Yes they are implemented on the 970.
Thanks,
Andrew Pinski
^ permalink raw reply
* powerpc.git updated
From: Paul Mackerras @ 2006-05-19 6:07 UTC (permalink / raw)
To: linuxppc-dev
I just pushed a bunch of patches to the powerpc.git tree (master
branch) and pulled in Linus' current linux-2.6.git tree. The list
below shows which patches are in there but not in Linus' tree yet.
These will all go upstream after 2.6.17 is released. If you have a
patch that you want to go in that I haven't picked up yet, please
resend it.
Paul.
Andy Fleming:
Add 85xx CDS to arch/powerpc
Anton Blanchard:
powerpc: remove io_page_mask
Geoff Levand:
powerpc: remove do-nothing cpu setup routines
Haren Myneni:
powerpc: clear IPIs on kdump
Jeremy Kerr:
powerpc: cell: use kzalloc in alloc_spu_context()
powerpc: Add of_parse_dma_window()
powerpc: pseries: Use generic dma-window parsing function
Jimi Xenidis:
powerpc: Auto reserve of device tree blob
jimix@watson.ibm.com:
powerpc: udbg_printf() formatting attribute
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
Linas Vepstas:
powerpc/pseries: clear PCI failure counter if no new failures
powerpc/pseries: Increment fail counter in PCI recovery
Michael Ellerman:
powerpc: Disable and EOI interrupts in machine_crash_shutdown()
powerpc: Make early debugging options behave with oldconfig
powerpc: Make early xmon logic immune to location of early parsing
powerpc: Parse early parameters earlier
powerpc: Unify mem= handling
powerpc: Kdump header cleanup
powerpc: Move crashkernel= handling into the kernel.
Michael Neuling:
powerpc: whitespace cleanup in reg.h
mostrows@watson.ibm.com:
powerpc: Create /proc/rtas, /proc/ppc64/rtas if RTAS exists.
Olof Johansson:
powerpc: Quiet HVSI boot output
powerpc: Quiet time init output
powerpc: Quiet page order output
powerpc: Quiet VETH version printk
powerpc: Don't print chosen idle loop at every boot
powerpc: Less verbose mem configuration output
powerpc: Lack of ISA interrupts on XICS isn't dangerous
powerpc: Quiet PCI init printouts
powerpc: Quiet rtasd output at boot
powerpc: Quiet oprofile output at boot
powerpc: Remove stale iseries global
powerpc: kill union tce_entry
powerpc iommu: minor cleanup
Stephen Rothwell:
powerpc: add all the iSeries virtual devices to the device tree
powerpc: use the device tree for the iSeries vio bus probe
powerpc: use a common vio_match_device routine
powerpc: merge the rest of the vio code
powerpc: update iseries_veth device-tree information
powerpc: update iSeries viodasd device-tree entries
powerpc: update iSeries vdevice
powerpc: update iSeries viocd and viotape device-tree
powerpc: the iSeries vio lan driver changed device type
Will Schmidt:
nvram_print_partitions cosmetic fixup
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox