* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-15 2:44 UTC (permalink / raw)
To: Rune Torgersen, joakim.tjernlund
Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0307485D@ismail.innsys.innovsys.com>
> -----Original Message-----
> From: Rune Torgersen [mailto:runet@innovsys.com]
> Sent: Friday, June 15, 2007 6:50 AM
> To: joakim.tjernlund@transmode.se; Li Yang-r58472
> Cc: linuxppc-dev Development; Liu Dave-r63238
> Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> Here is what I had to do to get best-fit + not allocating too much:
> (against 2.6.18)
> --- linux-innsys/arch/ppc/lib/rheap.c 2006/10/10 22:54:41 175
> +++ linux-innsys/arch/ppc/lib/rheap.c 2006/12/03 18:04:42 205
{snip}
> if (assure_empty(info, 1) < 0)
> return ERR_PTR(-ENOMEM);
You also need to change this to assure_empty(info, 2), as you are very
likely to need 2 slots afterward. You need to assure there are enough
slots or grow the block number.
- Leo
^ permalink raw reply
* Re: Powerbook hard shutdown after boot if it's hot
From: Segher Boessenkool @ 2007-06-15 0:18 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070614164136.GB27602@iram.es>
> I believe that the hardware (PMU?) forces a power off
> when the fan speed control registers are not accessed
> for some time. This delay may depend on the temperature.
Yes, to me as well it sounds like the PMU is unhappy
because you didn't talk to it for too long while
things are hot. Pretty hard to prove this assumption
of course -- but try Gabriel's suggestion, if that
works, it means this diagnosis is at least slightly
correct. A real fix is something different of course.
> As a stab in the dark, you might try to force the fans at
> full speed in an __init function. This will make the machine
> noisy for some time before the loop starts regulating fan
> speed but might buy you some time.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Benjamin Herrenschmidt @ 2007-06-15 0:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus, Yoder Stuart-B08248
In-Reply-To: <480f44878c42c1dc6452233f9e21d663@kernel.crashing.org>
On Thu, 2007-06-14 at 17:36 +0200, Segher Boessenkool wrote:
>
> "node name" in flat device trees doesn't allow a proper
> "name" property to exist for the root node. This is a
> bug in the flat device tree tools, and either should be
> fixed, or this should be clearly documented as a divergence
> from "real" OF.
>
> "name" of the root node is a bit special, since it is
> never displayed as part of a device path or used for
> device selection (instead, "/" at start of a path is
> handled specially, just like on unix filesystems).
This 'special' behaviour, the fact that it's definition is out of sync
with the generic name recommended practice, and finally, the fact that
quite a lot of real OFs out there don't even bother having one, makes me
think that it's a good idea to stick to what I did, which is to say the
root node has no name in a flat device-tree.
Now, what I -may- do to avoid information loss is tweak prom_init.c to
actually extract that name if it exist and stick a "name" property in
the root node in that case when flattening the tree.
But I still beleive as far as flat DTs for embedded are concerned, we
shouldn't use and rely on having a name at the root of the tree.
> Since anything that matches for "compatible" entries
> also first should check the "name" contents, it should
> be okay for flat device trees to have the information
> that could/should be in "name" in "compatible", instead.
>
> Does this answer all questions / clarify my position
> on all this?
Ben.
^ permalink raw reply
* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Arnd Bergmann @ 2007-06-14 23:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <B4E893D5-A61E-4A91-B31C-AF9B7C0B116D@kernel.crashing.org>
On Thursday 14 June 2007, Kumar Gala wrote:
> I'm a little hesitant to move the embedded ppc's over to =A0
> multiplatform quite yet. =A0One feature I wanted was in Kconfig a way =A0
> to enforce the selection of at least one choice, as well as being =A0
> able to optimize things since we only had one choice selected.
What would such a potential optimization be like? Are you thinking
of turning the 'platform_is(foo)' check into a compile-time choice,
or are there more places where you can imagine an optimization?
I'd like to understand better what you want to achieve there,
maybe I can find a way to do that in the same series.
=46or the 'at least one option selected' argument, I'm not sure how
important that is, IMHO it falls into the same category as any
other essential option that you can disable.
Arnd <><
^ permalink raw reply
* Re: [patch 05/30 v2] PS3: Use ioremap_flags
From: Arnd Bergmann @ 2007-06-14 23:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Masato Noguchi, Geert Uytterhoeven, paulus
In-Reply-To: <467190F4.4000307@am.sony.com>
On Thursday 14 June 2007, Geoff Levand wrote:
> Use ioremap_flags() to map SPU and htab regions as non-guarded.
> Change the use of _ioremap() to ioremap_flags().
>
> CC: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> CC: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> CC: Takao Shinohara <shin@sm.sony.co.jp>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Rune Torgersen @ 2007-06-14 22:46 UTC (permalink / raw)
To: joakim.tjernlund, Dave Liu; +Cc: linuxppc-dev Development
In-Reply-To: <1181805466.30670.352.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund
> Sent: Thursday, June 14, 2007 2:18 AM
> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?
I've noticed (on a internal project that uses a LOT of DPRAM on a 82xx,
uses same allocator), that the current allignment stuff allocates bytes
requested + allignment and never frees the unused space.
So if you want 8 bytes with 64 bytes allignment, the allocator
allocatesd (8+64) 72 bytes. It should then return the unused 64 bytes at
the beginning and end to the pool, but doesn't.
I have an internal version of the allocator that does it correct (for us
atleast), and also does a best fit instead of first fit.
If anybody is interested, I can post it. Mine is the rheap from arch/ppc
not arch/powerpc
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Rune Torgersen @ 2007-06-14 22:50 UTC (permalink / raw)
To: joakim.tjernlund, Li Yang-r58472
Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <1181807671.30670.358.camel@gentoo-jocke.transmode.se>
Here is what I had to do to get best-fit + not allocating too much:
(against 2.6.18)
--- linux-innsys/arch/ppc/lib/rheap.c 2006/10/10 22:54:41 175
+++ linux-innsys/arch/ppc/lib/rheap.c 2006/12/03 18:04:42 205
@@ -428,19 +428,22 @@
{
struct list_head *l;
rh_block_t *blk;
- rh_block_t *newblk;
+ rh_block_t *newblk1, *newblk2;
void *start;
-
+ int align_mask =3D alignment - 1;
+ int off;
+ unsigned long s, e, m, bs, be;
+ =20
/* Validate size, (must be power of two) */
if (size <=3D 0 || (alignment & (alignment - 1)) !=3D 0)
return ERR_PTR(-EINVAL);
=20
/* given alignment larger that default rheap alignment */
- if (alignment > info->alignment)
- size +=3D alignment - 1;
+ //if (alignment > info->alignment)
+ // size +=3D alignment - 1;
=20
/* Align to configured alignment */
- size =3D (size + (info->alignment - 1)) & ~(info->alignment - 1);
+ //size =3D (size + (info->alignment - 1)) & ~(info->alignment -
1);
=20
if (assure_empty(info, 1) < 0)
return ERR_PTR(-ENOMEM);
@@ -448,8 +451,18 @@
blk =3D NULL;
list_for_each(l, &info->free_list) {
blk =3D list_entry(l, rh_block_t, list);
- if (size <=3D blk->size)
+ =09
+ if ((blk->size =3D=3D size) && (((int)blk->start &
align_mask) =3D=3D 0))
+ break;
+ =09
+ if (((int)blk->start & align_mask) !=3D 0)
+ off =3D align_mask - ((int)blk->start &
align_mask) + 1;
+ else
+ off =3D 0;
+ =20
+ if (blk->size - off >=3D size)
break;
+ =09
blk =3D NULL;
}
=20
@@ -468,25 +481,35 @@
return start;
}
=20
- newblk =3D get_slot(info);
- newblk->start =3D blk->start;
- newblk->size =3D size;
- newblk->owner =3D owner;
-
- /* blk still in free list, with updated start, size */
- blk->start =3D (int8_t *)blk->start + size;
- blk->size -=3D size;
+ bs =3D (int)blk->start;
+ be =3D (int)blk->start + blk->size;
+ s =3D (int)blk->start + off;
+ e =3D s + size;
+=09
+ if (bs =3D=3D s || be =3D=3D e) {
+ if (bs =3D=3D s)
+ blk->start =3D (int8_t *)blk->start + size;
+ blk->size -=3D size;
=20
- start =3D newblk->start;
+ } else {
+ /* The front free fragment */
+ blk->size =3D s - bs;
=20
- attach_taken_block(info, newblk);
-=09
- /* for larger alignment return fixed up pointer */
- /* this is no problem with the deallocator since */
- /* we scan for pointers that lie in the blocks */
- if (alignment > info->alignment)
- start =3D (void *)(((unsigned long)start + alignment - 1)
&
- ~(alignment - 1));
+ /* The back free fragment */
+ newblk2 =3D get_slot(info);
+ newblk2->start =3D (void *)e;
+ newblk2->size =3D be - e;
+
+ list_add(&newblk2->list, &blk->list);
+ }
+
+ newblk1 =3D get_slot(info);
+ newblk1->start =3D (void *)s;
+ newblk1->size =3D e - s;
+ newblk1->owner =3D owner;
+
+ start =3D newblk1->start;
+ attach_taken_block(info, newblk1);
=20
return start;
}
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Mark A. Greer @ 2007-06-14 22:26 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <467176EB.7060404@ru.mvista.com>
On Thu, Jun 14, 2007 at 09:12:11PM +0400, Vladislav Buzov wrote:
> Segher Boessenkool wrote:
> >> /* TODO: use HW flush assist when available */
> >
> >
> > You want to get rid of this old comment though -- and
> > perhaps branch over the non-hardware-assisted cache
> > flushing code.
>
> Ok, I agree that the comment is obsolete now. Would you please explain
> why the branch over non-hardware-assisted code should be removed as
> well. Technically the cache is flushed and there is no need to use extra
> commands to fill and then re-flush the cache.
I think Segher is saying that you can skip the manual invalidation too
(although he said "flushing", I think he really meant "invalidation"--
the manual flushing is already skipped). If I'm reading the manual
correctly, L2HWF does the invalidation as well so both the manual
flushing and invalidation can be skipped.
Mark
^ permalink raw reply
* [PATCH] 85xxCDS: Delay 8259 cascade hookup.
From: Randy Vinson @ 2007-06-14 22:05 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
The interrupts of an E100 card inserted in PCI slot 4 may be on at bootup.
The resulting interrupt flood interacts with the 8259 cascade handler and
prevents proper boot up. There is a quirk for the E100 that will disable
the E100's interrupts but to use it, the 8259 cascade hookup must be
delayed until after the quirk has run. This patch delays the 8259 cascade
hookup by registering a device_initcall() which runs after the PCI quirk
for the E100.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
NOTE: This is a follow-up to my previous 8259 cascade patch. I
encountered this problem on the 8548CDS system I use for test.
I'm not sure it is an isolated incident or a common occurance. I'm
posting this patch in case it's common.
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 33 +++++++++++++++++++---------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index a8720bf..939285a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -183,10 +183,6 @@ static void __init mpc85xx_cds_pic_init(void)
struct mpic *mpic;
struct resource r;
struct device_node *np = NULL;
-#if defined(CONFIG_PPC_I8259) && defined(CONFIG_PCI)
- struct device_node *cascade_node = NULL;
- int cascade_irq;
-#endif
np = of_find_node_by_type(np, "open-pic");
@@ -231,8 +227,16 @@ static void __init mpc85xx_cds_pic_init(void)
mpic_assign_isu(mpic, 14, r.start + 0x10100);
mpic_init(mpic);
+}
#if defined(CONFIG_PPC_I8259) && defined(CONFIG_PCI)
+static int mpc85xx_cds_8259_attach(void)
+{
+ int ret;
+ struct device_node *np = NULL;
+ struct device_node *cascade_node = NULL;
+ int cascade_irq;
+
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -242,13 +246,13 @@ static void __init mpc85xx_cds_pic_init(void)
if (cascade_node == NULL) {
printk(KERN_DEBUG "Could not find i8259 PIC\n");
- return;
+ return -ENODEV;
}
cascade_irq = irq_of_parse_and_map(cascade_node, 0);
if (cascade_irq == NO_IRQ) {
printk(KERN_ERR "Failed to map cascade interrupt\n");
- return;
+ return -ENXIO;
}
i8259_init(cascade_node, 0);
@@ -260,14 +264,21 @@ static void __init mpc85xx_cds_pic_init(void)
* disabled when the last user of the shared IRQ line frees their
* interrupt.
*/
- if (setup_irq(cascade_irq, &mpc85xxcds_8259_irqaction))
+ if ((ret = setup_irq(cascade_irq, &mpc85xxcds_8259_irqaction))) {
printk(KERN_ERR "Failed to setup cascade interrupt\n");
- else
- /* Success. Connect our low-level cascade handler. */
- set_irq_handler(cascade_irq, mpc85xx_8259_cascade_handler);
-#endif /* CONFIG_PPC_I8259 */
+ return ret;
+ }
+
+ /* Success. Connect our low-level cascade handler. */
+ set_irq_handler(cascade_irq, mpc85xx_8259_cascade_handler);
+
+ return 0;
}
+device_initcall(mpc85xx_cds_8259_attach);
+
+#endif /* CONFIG_PPC_I8259 */
+
/*
* Setup the architecture
*/
--
1.5.0.GIT
^ permalink raw reply related
* Re: [PATCH 5/13] Remove a couple of unused definitions from pgtable_32.c
From: Andy Fleming @ 2007-06-14 21:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <A02128B3-41EE-47AA-802F-C0E3400411FB@kernel.crashing.org>
On Jun 14, 2007, at 16:04, Kumar Gala wrote:
>
> On Jun 12, 2007, at 11:52 PM, David Gibson wrote:
>>
>> -/* is x a power of 4? */
>> -#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1)
>> -
>
> is_power_of_4 is used by HAVE_TLBCAM, why are you killing it?
He removed io_block_mapping() in patch #3
Andy
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Kumar Gala @ 2007-06-14 21:04 UTC (permalink / raw)
To: Marc Leeman; +Cc: linuxppc-dev
In-Reply-To: <20070612160628.GB2481@chiana.homelinux.org>
On Jun 12, 2007, at 11:06 AM, Marc Leeman wrote:
>> I'm confused what you are comparing here, 3 seconds on arch=ppc vs
>> over a minute on arch=powerpc?
>
> Loading of a TI DSP over HPI. HPI is implemented in UPMB
> (programmed by
> U-Boot); all that the kernel has to do is write to the in U-Boot
> programmed location (0xe2400000) to trigger the UPMB HPI protocol.
>
>> I'd expect the driver to be exactly the same (or close to it) for
>> arch=ppc vs arch=powerpc.
>
> Same here: there are a number of performance issues wrt to an older
> 8245
> based implementation (network seems slower too) and this was not one I
> expected while switching to powerpc.
Are you comparing 8245 on arch=ppc to 83xx on arch=powerpc or 83xx in
both cases?
>> There shouldn't be, but if you are seeing this we really should
>> figure out what's going on.
>>
>> What kernel is this on? What processor are you using?
>
> $ cat /proc/cpuinfo
> processor : 0
> cpu : e300c1
> clock : 396.000000MHz
> revision : 1.1 (pvr 8083 0011)
> bogomips : 131.28
> timebase : 66000000
> platform : BARCO834x SVC2
Hmm, we really need to put SVR in there as well (add that to the todo
list). Which 83xx is this?
> $ uname -a
> Linux barco 2.6.21.1-barco1 #1 PREEMPT Tue Jun 12 09:48:12 CEST
> 2007 ppc unknown
>
> The board is based on the FreeScale SYS/EMDS reference design.
>
> Most of the HPI operations are stuff like this:
>
> static inline int8_t _hpi_set_hhwil(uint8_t b)
> {
> volatile immap_t* im;
>
> if(!(im = ioremap((immrbar),sizeof(struct immap)))){
> return -EINVAL;
> }
> (b)?(im->gpio[0].dat |= HHWIL):(im->gpio[0].dat &= ~HHWIL);
> iounmap(im);
>
> return 0;
> }
>
> static inline uint32_t __hpi_read_hpid(void)
> {
> uint32_t returnval;
>
> /* Program HPID */
> _hpi_set_hcntl1(1);
> _hpi_set_hcntl0(1);
>
> /* first halfword */
> _hpi_set_hhwil(0);
> /* dummy read */
> returnval = (((uint32_t)(*hpi_dsp))<<16);
>
> /* delay */
> udelay(1);
>
> /* second halfword */
> _hpi_set_hhwil(1);
> /* dummy read */
> returnval |= *hpi_dsp;
>
> /* delay */
> udelay(1);
>
> return returnval;
> }
>
> The ioremap was certainly a bottleneck; and moving it to
> initialisation
> with a global pointer got us from 60 secs back to around 1 sec, but
> the
> a similar effect was obtained on the ppc arch with this change
> (this was
> just making a bad situation to be hidden).
Do you sense of how many calls you make to _hpi_set_hhwil &
__hpi_read_hpid?
I think I know why the ppc case was more efficient.
> Even after this change; the load of a streaming application was
> something of 40% on ppc and 60% on powerpc.
What's going on during the streaming?
- k
^ permalink raw reply
* Re: [PATCH 5/13] Remove a couple of unused definitions from pgtable_32.c
From: Kumar Gala @ 2007-06-14 21:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045256.B35E1DDECA@ozlabs.org>
On Jun 12, 2007, at 11:52 PM, David Gibson wrote:
> In arch/powerpc/mm/pgtable_32.c, the varialbe io_bat_index and the
> macro is_power_of_4() no longer have any users. This patch removes
> them.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> arch/powerpc/mm/pgtable_32.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> Index: working-2.6/arch/powerpc/mm/pgtable_32.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/mm/pgtable_32.c 2007-05-10
> 14:13:36.000000000 +1000
> +++ working-2.6/arch/powerpc/mm/pgtable_32.c 2007-05-10
> 14:13:44.000000000 +1000
> @@ -36,7 +36,6 @@
> unsigned long ioremap_base;
> unsigned long ioremap_bot;
> EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
> -int io_bat_index;
>
> #if defined(CONFIG_6xx) || defined(CONFIG_POWER3)
> #define HAVE_BATS 1
> @@ -299,9 +298,6 @@ void __init mapin_ram(void)
> }
> }
>
> -/* is x a power of 4? */
> -#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1)
> -
is_power_of_4 is used by HAVE_TLBCAM, why are you killing it?
- k
^ permalink raw reply
* PowerPC boot wrapper and seperate initrd images
From: Matt Sealey @ 2007-06-14 20:55 UTC (permalink / raw)
To: ppc-dev
I am trying to get my head around this, so here goes on my take on how the
current boot loader works.
In essence the wrapper script appends a linux kernel and initrd,
compresses and throws on a little loader (chrp/of or uboot/dts or whatever)
at the front.
For Open Firmware, at boot (in of.c) it takes the values in r3 & r4
(r5 being the prom entry point) as initrd address and initrd size.
Somewhat later in the main loader (main.c:prep_initrd) it sets properties
in the /chosen node which put the initrd address and initrd size in
the device-tree for further reference (linux,initrd-size and linux,initrd-start)
I think this is a given.. it doesn't get too complicated. However what I
am looking to do is have it so that a first stage bootloader (Forth
script or binary like Yaboot) loads in the initrd into memory via the
client interface or whatever other method, then just fires up the
kernel.
This is simply because.. yaboot doesn't work here yet (Pegasos/Efika).
This is causing problems with distributions as they like to ship a
kernel and seperate initrd - and expect a boot loader like BootX or
Yaboot or Quick (pick one) to do all it's heavy lifting.
However we CAN get the data into the right place, with a tiny Forth
script, and there are some standard properties to reference it.
The linux,initrd-size and linux,initrd-start properties would
be set in the device tree by this tiny forth boot loader.
That means of.c needs to pick them up, and main.c needs not to trash
them.
What I am asking, then, if all that information is correct, is if it
would be acceptable in any terms to add this code to the boot wrapper;
in platform_init, it would get the properties out of the tree and
assign them in the loader_info structure (maybe only if the r3 and
r4 values are invalid).
Then in main.c perhaps NOT set those values if they are already in
the device tree.. but I am not sure if any manipulation of the
values is going on. I assume they're absolute, real-mode addresses
and not being weirdly relocated or as an offset to the kernel
(I didn't look to hard).
Is it an insane or stupid idea, that everyone hates and thinks
we should just fix our broken firmware, or do you think it would
come in handy? I'm considering it's a 20-line patch that wouldn't
harm anyone..
Any comments?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: can you help me
From: Ricardo Scop @ 2007-06-14 20:21 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: volcano
In-Reply-To: <loom.20070614T095354-303@post.gmane.org>
On Thursday 14 June 2007 04:57, volcano wrote:
> hi all :
> I have been reading the U-BOOT code based on mpc8260 these days.Can you
> show me where can I find the document which have the explaination of the
> whole code . thanks.
You should start here:
http://www.denx.de/wiki/DULG
--
Ricardo Scop.
^ permalink raw reply
* [patch 05/30 v2] PS3: Use ioremap_flags
From: Geoff Levand @ 2007-06-14 19:03 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, Masato Noguchi, linuxppc-dev, paulus,
Geert Uytterhoeven
In-Reply-To: <466EE965.404@am.sony.com>
Use ioremap_flags() to map SPU and htab regions as non-guarded.
Change the use of _ioremap() to ioremap_flags().
CC: Arnd Bergmann <arnd.bergmann@de.ibm.com>
CC: Masato Noguchi <Masato.Noguchi@jp.sony.com>
CC: Takao Shinohara <shin@sm.sony.co.jp>
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Ver 2: Fixed casts, removed _PAGE_GUARDED from spu problem and priv2 regions.
arch/powerpc/platforms/ps3/htab.c | 2 +-
arch/powerpc/platforms/ps3/spu.c | 13 +++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -273,7 +273,7 @@ void __init ps3_map_htab(void)
result = lv1_map_htab(0, &htab_addr);
- htab = (hpte_t *)__ioremap(htab_addr, htab_size,
+ htab = (__force hpte_t *)ioremap_flags(htab_addr, htab_size,
pgprot_val(PAGE_READONLY_X));
DBG("%s:%d: lpar %016lxh, virt %016lxh\n", __func__, __LINE__,
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -182,15 +182,18 @@ static int __init setup_areas(struct spu
{
struct table {char* name; unsigned long addr; unsigned long size;};
- spu_pdata(spu)->shadow = __ioremap(
- spu_pdata(spu)->shadow_addr, sizeof(struct spe_shadow),
- pgprot_val(PAGE_READONLY) | _PAGE_NO_CACHE | _PAGE_GUARDED);
+ spu_pdata(spu)->shadow = ioremap_flags(spu_pdata(spu)->shadow_addr,
+ sizeof(struct spe_shadow),
+ pgprot_val(PAGE_READONLY) |
+ _PAGE_NO_CACHE);
if (!spu_pdata(spu)->shadow) {
pr_debug("%s:%d: ioremap shadow failed\n", __func__, __LINE__);
goto fail_ioremap;
}
- spu->local_store = ioremap(spu->local_store_phys, LS_SIZE);
+ spu->local_store = (__force void *)ioremap_flags(spu->local_store_phys,
+ LS_SIZE, _PAGE_NO_CACHE);
+
if (!spu->local_store) {
pr_debug("%s:%d: ioremap local_store failed\n",
__func__, __LINE__);
@@ -199,6 +202,7 @@ static int __init setup_areas(struct spu
spu->problem = ioremap(spu->problem_phys,
sizeof(struct spu_problem));
+
if (!spu->problem) {
pr_debug("%s:%d: ioremap problem failed\n", __func__, __LINE__);
goto fail_ioremap;
@@ -206,6 +210,7 @@ static int __init setup_areas(struct spu
spu->priv2 = ioremap(spu_pdata(spu)->priv2_addr,
sizeof(struct spu_priv2));
+
if (!spu->priv2) {
pr_debug("%s:%d: ioremap priv2 failed\n", __func__, __LINE__);
goto fail_ioremap;
^ permalink raw reply
* RE: Status of MPC5200B FEC driver ?
From: Daniel Schnell @ 2007-06-14 17:13 UTC (permalink / raw)
To: Daniel Schnell, linuxppc-embedded
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB01FFF4F9@is-hdq-exchange.marel.net>
Hmm,
If I initiate first a ping from within U-Boot and then boot Linux via =
IDE, the FEC works.
Seems that some initialization is missing inside the Linux MPC5200 FEC =
driver ?
Best regards,
Daniel.
-----Original Message-----
From: linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org] =
On Behalf Of Daniel Schnell
Sent: 14. j=FAn=ED 2007 16:50
To: linuxppc-embedded@ozlabs.org
Subject: Status of MPC5200B FEC driver ?
Hi,
I have problems with the MPC5200B fec driver.
On my custom board I can successfully boot/mount via NFS. I use a 2.6.20 =
kernel patched with all kind of things from Pengutronix Phytec MPC5200b =
tiny and patches IO collected from teh mailing list, like -rt, ata, fec, =
bestcomm (from Secretlab), etc. When activating the realtime scheduling, =
I undeterministically get errors like:
=3D=3D=3D=3D
FEC_IEVENT_RFIFO_ERROR (00020000)
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0:
transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV
WATCHDOG: eth0: transmit timed out
printk: 7 messages suppressed.
FEC_IEVENT_RFIFO_ERROR (00020000)
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0:
transmit timed out ...
=3D=3D=3D=3D
The device doesn't work after these.
Thomas Gleixner meant, this could have to do with the driver not beeing =
SMP safe, which would be a problem under -RT, similar to the problems he =
had with ibm_emac once. I can confirm when disabling -RT and enabling =
normal Linux scheduling things go to the better side again.
However if I boot via IDE I can not access eth0. Cmd ifconfig gives =
normal values as configured from the u-boot cmd line:
=3D=3D=3D
eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:28:0D
inet addr:10.100.99.251 Bcast:10.100.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:133 Base address:0x3000 =3D=3D=3D
A ifdown eth0 cmd gives the output:
=3D=3D=3D
fec_close: queues didn't drain
=3D=3D=3D
Which somehow sounds odd.
Ifup eth0 cmd tells me:
=3D=3D=3D
eth0: link down
=3D=3D=3D
Output from ping is sth. like network unreachable, which I can somehow =
understand if the above cmds do not work.
Trying to bring me up-to-date as described in =
http://www.246tnt.com/mpc52xx/ to see where my patchset differs from the =
latest, doesn't work, for the least of executing git clone on =
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git=20
I get errors like:
=3D=3D=3D=3D
...
error: Couldn't get
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/re
fs/tags/v2.6.11 for tags/v2.6.11
The requested URL returned error: 404
error: Could not interpret tags/v2.6.11 as something to pull =
=3D=3D=3D=3D
So I am somewhat stuck, but maybe anybody has a better idea how to get =
the latest MPC5200B support or some ideas about the ethernet problems ?
Best regards,
Daniel Schnell.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-14 17:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <db0d38e5b5e1a9a3a7fe35d25ebd357a@kernel.crashing.org>
Segher Boessenkool wrote:
>> I read the MPC7450 reference manual and it describes a method to flush
>> the cache using L2 hardware flushing feature. The cache flushing
>> procedure consist of several steps and some of them are dictated by
>> MPC7448 errata (www.freescale.com/files/32bit/doc/errata/MPC7448CE.pdf,
>> Erratum no.3).
>
>
> Are these errata 7448-only? If not, I wonder what is
> done on PowerMacs?
This is a errata for 7448 only. I've looked through errata for other
7450 processors (7450, 7457) and they contain the same erratum for L2
cache: "L2 hardware flush may not flush every line from the L2 cache"
The workaround for this problem is: "Set the IONLY and DONLY bits in the
L2CR prior to the L2 hardware flush", and the projected solution is:
"The workaround has been documented in the MPC7450 RISC Microprocessor
Family User’s Manual as the correct way to flush the L2 cache"
I have tried to apply the same workaround for a common
non-hardware-assistant _set_L2CR() implementation. I tried to completely
lock the cache before a whole flushing procedure, tried to set the L2DO
before filling the cache, fill it and then set the L2IO and issue a
number of dcbf's. But nothing helped.
>
>> First, I'm looking for a help and advice why the current _set_L2CR()
>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>
>
> I think that if anyone here could answer this straight
> away, the source code would have been fixed already ;-)
Yeah, I guess I'm a first person who encountered this problem.
>
>> I've
>> mentioned above about MPC7450 hardware bug in L2 hardware flushing
>> mechanism. May it be applicable to common cache flushing procedure based
>> on sequence of lwz/dcbf instructions?
>
>
> Dunno, too lazy to download that PDF, perhaps you can
> quote the relevant part?
>
>> Second, Is this patch acceptable?
>
>
> Looks reasonable enough to me... if it works (on all
> things considered "7450" by the kernel).
I've double checked this. All processors considered 7450 in the kernel
are covered by MPC7450 RISC Microprocessor Family Reference Manual where
hardware cache flushing procedure is described.
>
>> /* TODO: use HW flush assist when available */
>
>
> You want to get rid of this old comment though -- and
> perhaps branch over the non-hardware-assisted cache
> flushing code.
Ok, I agree that the comment is obsolete now. Would you please explain
why the branch over non-hardware-assisted code should be removed as
well. Technically the cache is flushed and there is no need to use extra
commands to fill and then re-flush the cache.
Thank you,
Vlad.
>
>
> Segher
>
^ permalink raw reply
* Re: [patch 29/30 v2] PS3: Device tree source.
From: Geoff Levand @ 2007-06-14 17:05 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.62.0706140954540.26873@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> On Wed, 13 Jun 2007, Geoff Levand wrote:
>> Subject: PS3: Device tree source.
>>
>> The PS3 device tree source.
>>
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> ---
>>
>> ver2: Here's an updated version based on the discussions.
>
> This one doesn't seem to work. The kernel hangs very early in the boot process.
> I haven't digged into it yet to find out why.
The trouble was not in this patch, but that I didn't update
ps3-legacy-bootloader-hack.diff to match this change. I
committed an update to my git repositories on kernel.org.
Sorry if this inconvenienced anyone.
-Geoff
^ permalink raw reply
* Status of MPC5200B FEC driver ?
From: Daniel Schnell @ 2007-06-14 16:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have problems with the MPC5200B fec driver.
On my custom board I can successfully boot/mount via NFS. I use a 2.6.20
kernel patched with all kind of things from Pengutronix Phytec MPC5200b
tiny and patches IO collected from teh mailing list, like -rt, ata, fec,
bestcomm (from Secretlab), etc. When activating the realtime scheduling,
I undeterministically get errors like:
=3D=3D=3D=3D
FEC_IEVENT_RFIFO_ERROR (00020000)
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0:
transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV
WATCHDOG: eth0: transmit timed out
printk: 7 messages suppressed.
FEC_IEVENT_RFIFO_ERROR (00020000)
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0:
transmit timed out ...
=3D=3D=3D=3D
The device doesn't work after these.
Thomas Gleixner meant, this could have to do with the driver not beeing
SMP safe, which would be a problem under -RT, similar to the problems he
had with ibm_emac once. I can confirm when disabling -RT and enabling
normal Linux scheduling things go to the better side again.
However if I boot via IDE I can not access eth0. Cmd ifconfig gives
normal values as configured from the u-boot cmd line:
=3D=3D=3D
eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:28:0D
inet addr:10.100.99.251 Bcast:10.100.255.255
Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:133 Base address:0x3000
=3D=3D=3D
A ifdown eth0 cmd gives the output:
=3D=3D=3D
fec_close: queues didn't drain
=3D=3D=3D
Which somehow sounds odd.
Ifup eth0 cmd tells me:
=3D=3D=3D
eth0: link down
=3D=3D=3D
Output from ping is sth. like network unreachable, which I can somehow
understand if the above cmds do not work.
Trying to bring me up-to-date as described in
http://www.246tnt.com/mpc52xx/ to see where my patchset differs from the
latest, doesn't work, for the least of executing git clone on
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git=20
I get errors like:
=3D=3D=3D=3D
...
error: Couldn't get
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/re
fs/tags/v2.6.11 for tags/v2.6.11
The requested URL returned error: 404
error: Could not interpret tags/v2.6.11 as something to pull
=3D=3D=3D=3D
So I am somewhat stuck, but maybe anybody has a better idea how to get
the latest MPC5200B support or some ideas about the ethernet problems ?
Best regards,
Daniel Schnell.
^ permalink raw reply
* Re: Powerbook hard shutdown after boot if it's hot
From: Gabriel Paubert @ 2007-06-14 16:41 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200706141739.12754.mb@bu3sch.de>
On Thu, Jun 14, 2007 at 05:39:12PM +0200, Michael Buesch wrote:
> Hi,
>
> I have a strange problem that my Powerbook shuts down hard
> right after boot, if the machine is hot.
> For example, if I compile a kernel and then want to reboot
> into it, it will shutdown the machine right after userspace
> is booted. Cooling down the machine will fix the issue.
> I first thought this might be a problem with the adt746x
> chip driver (thermostat). But this turns out to not be
> the case. I disabled the module (put return 0; early into
> the module_init function), but the problem still exists.
> I'm not sure how to debug this, as I don't see what's
> going on. I tried to boot with init=/bin/bash. It will
> boot into the shell but shutdown hard after 1 or 2 seconds.
> It seems like there is some timer hitting in right after
> userspace is up and running (some workqueue?). Strange is
> that it _only_ shuts down the machine when it's hot
> and it _only_ does this right after boot. If it survived
> the first few seconds after boot, it's rock-stable and
> it won't show any problems when getting hot (will drive
> the fans correctly, etc etc...)
>
> Any idea how to debug this?
I believe that the hardware (PMU?) forces a power off
when the fan speed control registers are not accessed
for some time. This delay may depend on the temperature.
When my PB motherboard failed, the fans were driven at full
speed at power-up and then ran for about a minute before
they were stopped and the machine completely shut-down.
As a stab in the dark, you might try to force the fans at
full speed in an __init function. This will make the machine
noisy for some time before the loop starts regulating fan
speed but might buy you some time.
Regards,
Gabriel
^ permalink raw reply
* Powerbook hard shutdown after boot if it's hot
From: Michael Buesch @ 2007-06-14 15:39 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a strange problem that my Powerbook shuts down hard
right after boot, if the machine is hot.
For example, if I compile a kernel and then want to reboot
into it, it will shutdown the machine right after userspace
is booted. Cooling down the machine will fix the issue.
I first thought this might be a problem with the adt746x
chip driver (thermostat). But this turns out to not be
the case. I disabled the module (put return 0; early into
the module_init function), but the problem still exists.
I'm not sure how to debug this, as I don't see what's
going on. I tried to boot with init=/bin/bash. It will
boot into the shell but shutdown hard after 1 or 2 seconds.
It seems like there is some timer hitting in right after
userspace is up and running (some workqueue?). Strange is
that it _only_ shuts down the machine when it's hot
and it _only_ does this right after boot. If it survived
the first few seconds after boot, it's rock-stable and
it won't show any problems when getting hot (will drive
the fans correctly, etc etc...)
Any idea how to debug this?
--
Greetings Michael.
^ permalink raw reply
* RE: [patch 29/30] PS3: Device tree source.
From: Yoder Stuart-B08248 @ 2007-06-14 15:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <480f44878c42c1dc6452233f9e21d663@kernel.crashing.org>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Segher Boessenkool
> Sent: Thursday, June 14, 2007 10:36 AM
> To: Yoder Stuart-B08248
> Cc: linuxppc-dev@ozlabs.org; Olaf Hering; paulus@samba.org
> Subject: Re: [patch 29/30] PS3: Device tree source.
>=20
> >> "compatible" is only needed if your "name" is bogus, or your
> >> machine _actually_ is 100% compatible to some other machine.
> >
> > Segher,
> >
> > I don't understand this if we are following the 'Generic Names'
> > recommendation (which I thought we were).
>=20
> Yes, we should follow that recommended practice.
>=20
> > Guideline 1: "name" property values must be generic, reflecting
> > the device's function, but not necessarily its precise programming
> > model.
>=20
> Yes -- a short clear name that makes device tree paths
> easily readable (and easy to type ;-) ) for human beings.
>=20
> > Guideline 2: The "compatible" property must be present.
>=20
> ...if "name" doesn't perform the same function yet, which
> of course is almost always.
But the recommended practice doesn't have an "...if". It says
"compatible" must always be present.
The reason an OS would need to support "name" as well as=20
"compatbile" for device driver matching would be
for _legacy_ device trees that don't follow the recommended
practice.
For newly developed trees "compatible" should specify the programming
model, if we are following that recommended practice.
So bottom line is that we shouldn't be moving toward using "name"
to specify the programming model.
[snip]
>=20
> Since anything that matches for "compatible" entries
> also first should check the "name" contents, it should
> be okay for flat device trees to have the information
> that could/should be in "name" in "compatible", instead.
As mentioned above, matching on "name" would seem to be
needed to handle legacy device trees as I read some of
the reasoning in the generic names recommended practice.
Not sure if that applies to Linux or not...=20
Stuart
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-14 15:36 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302F33549@az33exm25.fsl.freescale.net>
>> "compatible" is only needed if your "name" is bogus, or your
>> machine _actually_ is 100% compatible to some other machine.
>
> Segher,
>
> I don't understand this if we are following the 'Generic Names'
> recommendation (which I thought we were).
Yes, we should follow that recommended practice.
> Guideline 1: "name" property values must be generic, reflecting
> the device's function, but not necessarily its precise programming
> model.
Yes -- a short clear name that makes device tree paths
easily readable (and easy to type ;-) ) for human beings.
> Guideline 2: The "compatible" property must be present.
...if "name" doesn't perform the same function yet, which
of course is almost always.
> Its first
> component should be an explicit, unique name that identifies the
> device precisely enough to be able to infer the detailed programming
> model from that name. The format of that explicit name is
> manufacturer,model,...
Yep. You understand "generic names" just fine.
> I read that and my understand is that _compatible_ is required
> and specifies the precise programming model. name is supposed
> to be generic-- currently booting-without-of.txt says the
> property is optional because the name can be inferred from
> the node name which should be generic.
"node name" in flat device trees doesn't allow a proper
"name" property to exist for the root node. This is a
bug in the flat device tree tools, and either should be
fixed, or this should be clearly documented as a divergence
from "real" OF.
"name" of the root node is a bit special, since it is
never displayed as part of a device path or used for
device selection (instead, "/" at start of a path is
handled specially, just like on unix filesystems).
Since anything that matches for "compatible" entries
also first should check the "name" contents, it should
be okay for flat device trees to have the information
that could/should be in "name" in "compatible", instead.
Does this answer all questions / clarify my position
on all this?
Cheers,
Segher
^ permalink raw reply
* RE: [patch 29/30] PS3: Device tree source.
From: Yoder Stuart-B08248 @ 2007-06-14 14:39 UTC (permalink / raw)
To: Segher Boessenkool, Benjamin Herrenschmidt
Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <590cd31b74053f7499c1f53a29639175@kernel.crashing.org>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Segher Boessenkool
> Sent: Thursday, June 14, 2007 2:33 AM
> To: Benjamin Herrenschmidt
> Cc: linuxppc-dev@ozlabs.org; Olaf Hering; paulus@samba.org
> Subject: Re: [patch 29/30] PS3: Device tree source.
>=20
> > No name for the root of the DT.
>=20
> See my previous mail.
>=20
> > IMHO, model can be whatever he wants, I would say SonyPS3-XX or
> > something like that, whatever, doens't matter, the most precise the
> > better.
>=20
> It should be the model number of the machine.
>=20
> > Then you want compatible which is the really important one. sony,ps3
> > looks good to me for that, though you could have a list if=20
> you wanted.
>=20
> "compatible" is only needed if your "name" is bogus, or your
> machine _actually_ is 100% compatible to some other machine.
Segher,
I don't understand this if we are following the 'Generic Names'
recommendation (which I thought we were).
http://playground.sun.com/1275/practice/gnames/gnamv14a.html
It gives two guidelines:
Guideline 1: "name" property values must be generic, reflecting
the device's function, but not necessarily its precise programming
model.=20
Guideline 2: The "compatible" property must be present. Its first
component should be an explicit, unique name that identifies the
device precisely enough to be able to infer the detailed programming
model from that name. The format of that explicit name is
manufacturer,model,...
I read that and my understand is that _compatible_ is required
and specifies the precise programming model. name is supposed
to be generic-- currently booting-without-of.txt says the
property is optional because the name can be inferred from
the node name which should be generic.
Stuart
^ permalink raw reply
* Re: [PATCH 13/13] Fix problems with device tree representation of TSI-1xx bridges
From: Segher Boessenkool @ 2007-06-14 14:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045301.111A1DDEBB@ozlabs.org>
> The ethernet, i2c, bridge and PCI nodes were
> given only as "tsi-*" which is somewhat inprecise, we replace with
> "tsi108-*" in the case of Taiga (which has a TSI108 bridge), and
> "tsi109-*", "tsi108-*" in the case of Holly (which has a TSI109
> bridge).
To be sure -- are all those ts109 devices actually
compatible to their ancestors on tsi108?
Since I _have_ to complain about _something_ -- don't
you run a spellchecker on your commit messages? :-)
Perfect patch as far as I can see, thank you David!
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ 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