* Re: [PATCH 2/2] powerpc: pseries: Use generic dma-window parsing function
From: Olof Johansson @ 2006-05-18 17:13 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933975.516311.850847048300.qpush@pokey>
On Thu, May 18, 2006 at 04:32:55PM +1000, Jeremy Kerr wrote:
> Change the pseries iommu init code to use the new of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 01/16] ehca: module infrastructure
From: Jörn Engel @ 2006-05-18 17:41 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4468BD39.3010008@de.ibm.com>
On Mon, 15 May 2006 19:41:13 +0200, Heiko J Schick wrote:
> + * This source code is distributed under a dual license of GPL v2.0 and
> OpenIB
Your mailer is still mangling long lines, it seems. If you need a
quick solution, I could offer you a gmail invite.
> +
> + EDEB_EX(7, "ret=%x", ret);
> +
> + return ret;
> +
> +create_aqp1:
> + ib_destroy_cq(sport->ibcq_aqp1);
> +
> + EDEB_EX(7, "ret=%x", ret);
> +
> + return ret;
> +}
Those two cases could be combined with a goto. Saves a tiny amount of
rodata.
> +#define EHCA_RESOURCE_ATTR(name)
> \
> +static ssize_t ehca_show_##name(struct device *dev,
> \
You have spaces instead of tabs in the lines the mailer mangled.
> +
> \
> + data = rblock->name; \
> + kfree(rblock); \
> + \
> + if ((strcmp(#name, "num_ports") == 0) && (ehca_nr_ports == 1)) \
> + return snprintf(buf, 256, "1\n"); \
> + else \
> + return snprintf(buf, 256, "%d\n", data); \
> + \
Is rblock->num_ports uninitialized when (ehca_nr_ports == 1)? Looks
rather odd.
> + shca = (struct ehca_shca *)ib_alloc_device(sizeof(*shca));
A quick grep showed that every single return value of
ib_alloc_device() has a cast.
Roland, can't you just change ib_alloc_device() to return void*?
> +static struct of_device_id ehca_device_table[] =
> +{
> + {
> + .name = "lhca",
> + .compatible = "IBM,lhca",
> + },
> + {},
> +};
Is the extra element needed?
> + if ((ret = ehca_create_slab_caches(&ehca_module))) {
> + EDEB_ERR(4, "Cannot create SLAB caches");
> + ret = -ENOMEM;
> + goto module_init1;
> + }
ret = try_something()
if (ret) {
...
}
> + ehca_module.timer.data = (unsigned long)(void*)&ehca_module;
Why the double cast?
Jörn
--
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike
^ permalink raw reply
* remap_page_range vs. map_user_kiobuf
From: Stephen Williams @ 2006-05-18 17:43 UTC (permalink / raw)
To: linuxppc-embedded
My setup is Linux 2.4.33 w/ bigphysarea patch. My application is
using a virtual device driver to mmap a bigphysarea chunk, which
uses the remap_page_range function. This works well, and for my
devices that are aware of this and take advantage, the contiguous
physical memory is a real boon.
However, I also have a device driver that is not made specifically
aware of this heap. In its "read" method, it uses a map_user_kiobuf
to map user memory into the kernel. I do this as part of preparing
to DMA the read. This driver gets a -EFAULT back from map_user_kiobuf
when it is passed a user buffer that is mapped from the bigphysarea
heap.
It appears that get_user_pages (in mm/memory.c) does not like the
VM_RESERVED flag and returns -EFAULT if it tries to get reserved
pages in this manner. Am I reading this right?
Is there a way I can map the bigphysarea heap into user space such
that map_user_kiobuf works on these heaps, or am I stuck with
making all drivers aware of this bigphysarea heap?
(This is an embedded system, so this is possible to do, if painful.)
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Wolfgang Pfeiffer @ 2006-05-18 18:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147947192.15507.40.camel@johannes>
On Thu, May 18, 2006 at 12:13:12PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:
>
> > changed /etc/modules to explicitly load only i2sbus:
>
> Even that should not be necessary.
True. Just tested it (i.e. booted the machine) with this /etc/modules file:
----------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
apm_emu
ide-cd
#ide-disk
#ide-generic
sbp2
i2c-powermac
#snd-powermac
#snd-aoa:
#soundbus
#i2sbus
#snd-aoa
#snd-aoa-fabric-layout
#snd-aoa-codec-onyx
# End snd-aoa
cpufreq_performance
cpufreq_powersave
sr_mod
therm_adt746x
-----------------
And this is lsmod, after booting with he file above (op. slightly
edited for better readability):
# lsmod | grep snd
snd_aoa_codec_onyx 12736 2
snd_aoa_fabric_layout 7716 1
snd_aoa 8076 2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
snd_pcm_oss 45824 0
snd_mixer_oss 19392 1 snd_pcm_oss
snd_pcm 89060 2 i2sbus,snd_pcm_oss
snd_timer 22468 1 snd_pcm
snd_page_alloc 8744 1 snd_pcm
soundbus 6436 2 snd_aoa_fabric_layout,i2sbus
snd 60148 10 snd_aoa_codec_onyx,
snd_aoa_fabric_layout,snd_aoa,i2sbus,
snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 8612 1 snd
BTW: Is there a way to let 'alsaconf' detect the soundcard on this
PB5,8 ?
So far that's impossible, as it seems. But this could also be
related to mistakes I made in my modules files, or wherever.
That's why I changed a few files today below /etc/modprobe.d/ and
/etc/modutils/ that still had a few instances calling snd-powermac:
I simply replaced 'snd-powermac' with i2sbus resp. (IIRC)
snd-aoa. To no avail so far: alsaconf still does not detect any
soundcard ..
Status quo:
$ grep -irs i2sbus /etc/
/etc/modprobe.d/alsa-base:install i2sbus /sbin/modprobe --ignore-install i2sbus $CMDLINE_OPTS && /lib/alsa/modprobe-post-install i2sbus
/etc/modprobe.d/sound:alias snd-card-0 i2sbus
/etc/modutils/alsa-base:post-install i2sbus /lib/alsa/modprobe-post-install i2sbus
Anything wrong up there?
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-18 21:07 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446CDE26.8090504@rtr.ca>
Mark Lord wrote:
> 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
When will this happen? I'm getting worried that useful stuff is
disappearing into the Mark Lord ether, with no changes appearing on the
other side. Haven't seen patches from you in weeks.
I'm happy that you have an updated internal driver, but that helps no
one else.
Jeff
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-18 20:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446C9219.4080300@pobox.com>
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
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-18 21:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446CE217.2070703@pobox.com>
Jeff Garzik wrote:
>
> I'm happy that you have an updated internal driver, but that helps no
> one else.
Yikes! Mine own words, echoed back at me!
I'll organize some patches for you Friday.
Cheers
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Benjamin Herrenschmidt @ 2006-05-18 21:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <jek68jqz1l.fsf@sykes.suse.de>
> > Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
> > file.
>
> I think it's a tas3004.
Those G5s have tas3004 + topaz afaik (possilby using 2 busses). Check
the layout-id's :)
Ben
^ permalink raw reply
* [patch] fix RTC/NVRAM accesses on Maple
From: Hollis Blanchard @ 2006-05-18 21:34 UTC (permalink / raw)
To: linuxppc-dev
It looks like RTC and NVRAM accesses (including halt/reboot) on Maple
have been broken since January, when an untested build fix went in
("[PATCH] powerpc: Fix Maple build").
PIBS (the firmware on Maple) has a bad "ranges" property for the ISA
bus, which means of_address_to_resource() fails for ISA devices, and
that breaks maple_find_nvram_base() and maple_get_boot_time().
This patch adds ifdefs mid-file, but some were already present anyways,
and I don't see a better way.
Please apply.
--
Hollis Blanchard
IBM Linux Technology Center
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
diff -r 5158eb8d85b7 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c Thu May 18 11:32:22 2006 +0700
+++ b/arch/powerpc/kernel/prom_init.c Thu May 18 16:23:40 2006 -0500
@@ -2057,10 +2057,44 @@ static void __init flatten_device_tree(v
}
-
-static void __init fixup_device_tree(void)
-{
+#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)
+{
+ phandle isa;
+ u32 isa_ranges[6];
+
+ isa = call_prom("finddevice", 1, 1, ADDR("/ht@0/isa@4"));
+ if (!PHANDLE_VALID(isa))
+ return;
+
+ if (prom_getprop(isa, "ranges", isa_ranges, sizeof(isa_ranges))
+ == PROM_ERROR)
+ return;
+
+ if (isa_ranges[0] != 0x1 ||
+ isa_ranges[1] != 0xf4000000 ||
+ isa_ranges[2] != 0x00010000)
+ return;
+
+ prom_printf("fixing up bogus ISA range on Maple...\n");
+
+ 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));
+}
+#endif
+
+
#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+static void __init fixup_device_tree_pmac(void)
+{
phandle u3, i2c, mpic;
u32 u3_rev;
u32 interrupts[2];
@@ -2097,9 +2131,18 @@ static void __init fixup_device_tree(voi
parent = (u32)mpic;
prom_setprop(i2c, "/u3@0,f8000000/i2c@f8001000", "interrupt-parent",
&parent, sizeof(parent));
-#endif
-}
-
+}
+#endif
+
+static void __init fixup_device_tree(void)
+{
+#ifdef CONFIG_PPC_MAPLE
+ fixup_device_tree_maple();
+#endif
+#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+ fixup_device_tree_pmac();
+#endif
+}
static void __init prom_find_boot_cpu(void)
{
^ permalink raw reply
* [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
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