* Re: Flash paritioning and JFFS2
From: Michael Brian Willis @ 2007-08-23 16:08 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12293748.post@talk.nabble.com>
On Thu, 2007-08-23 at 06:36 -0700, Mirek23 wrote:
> Could someone advice me how to configure Linux kernel to make use of the
> Flash (with above mentioned partitions and JFFS2.
The Denx U-boot and Linux Guide (DULG) will tell you how to configure
the kernel for MTD devices and will give some good general information:
http://www.denx.de/wiki/view/DULG/FlashFilesystemsMTD
> I do not know however which specific options to enable for MTD/JFFS2 since
> it has many sub options.
The following post has some relevant information for your setup:
http://osdir.com/ml/linux.uclinux.devel/2005-12/msg00130.html
> I do not know also where to place:
> -the partition information (which I have mentioned above)
The partition information probably should go in a file that you create
for your board located at "drivers/mtd/maps/<your_file>.c"
> -the start (0xFF800000) and end (0xFFBFFFFF) physical location of my Flash
> memory.
I think this information just needs to be defined in your board's .h
file in u-boot. I don't think you need to specify this in any linux
config files.
I hope this info helps.
Regards,
Michael Willis
Applied Research Labs - University of Texas
willis@arlut.utexas.edu
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] spu_manage: use newer physical-id
From: Arnd Bergmann @ 2007-08-23 16:12 UTC (permalink / raw)
To: kou.ishizaki; +Cc: linuxppc-dev, paulus, linux-kernel, cbe-oss-dev, jk
In-Reply-To: <20070823.180152.-1300528381.kouish@swc.toshiba.co.jp>
On Thursday 23 August 2007, kou.ishizaki@toshiba.co.jp wrote:
> Please check "unit-id" if "physical-id" doesn't exist. Because Celleb
> uses "unit-id" to provide spe_id.
Ok, I need to discuss this with Christian then, to make sure we get to
a version that works everywhere. Paul, please ignore this patch for now.
I've update the git repository to only have the other four patches.
Arnd <><
^ permalink raw reply
* Re: wmb vs mmiowb
From: Linus Torvalds @ 2007-08-23 16:14 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <20070823035448.GG18788@wotan.suse.de>
On Thu, 23 Aug 2007, Nick Piggin wrote:
>
> OK, but we'd have some kind of functions that are called not to
> serialise the CPUs, but to serialise the IO. It would be up to
> the calling code to already provide CPU synchronisation.
>
> serialize_io(); / unserialize_io(); / a nicer name
We could call it "mmiowb()", for example?
Radical idea, I know.
> If we could pass in some kind of relevant resoure (eg. the IO
> memory or device or something), then we might even be able to
> put debug checks there to ensure two CPUs are never inside the
> same critical IO section at once.
We could certainly give it the spinlock as an argument.
Linus
^ permalink raw reply
* Re: wmb vs mmiowb
From: Linus Torvalds @ 2007-08-23 16:16 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <20070823042038.GI18788@wotan.suse.de>
On Thu, 23 Aug 2007, Nick Piggin wrote:
>
> Also, FWIW, there are some advantages of deferring the mmiowb thingy
> until the point of unlock.
And that is exactly what ppc64 does.
But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
total no-op. So when you talk about "advantages", you're not talking about
any *real* advantage, are you?
Linus
^ permalink raw reply
* Re: wmb vs mmiowb
From: Benjamin Herrenschmidt @ 2007-08-23 16:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nick Piggin, linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708230915000.30176@woody.linux-foundation.org>
On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > until the point of unlock.
>
> And that is exactly what ppc64 does.
>
> But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
> total no-op. So when you talk about "advantages", you're not talking about
> any *real* advantage, are you?
I wonder whether it might be worth removing mmiowb and having all archs
that matter do like ppc64 though... It's just yet another confusing
barrier that most driver writers get wrong..
Cheers,
Ben.
^ permalink raw reply
* Re: signals handling in the kernel
From: David Hawkins @ 2007-08-23 16:32 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12291367.post@talk.nabble.com>
Hi Mirek,
> Thank you for your hints. I was not aware about race
> conditions in signal handling routines. So far I did
> not noticed any anomalies when running my server
> since I use only one interrupt which refers to only one
> signal. I would be interested however in the solution
> you have suggested with: SIGIO and fasync()
>
> Would you be so kind to provide me with some example code.
Look at simple_driver.c and simple_driver_test.c in
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
Note that I used the old signals API in the user-space test:
/* Connect up the signal handler */
signal(SIGIO, &sigio_handler);
But you should really use the new signals API. I can't
remember the reason, it'll be explained in the Robbins&Robbins
book I reference below.
Note that another issue with signals is that they are
not queued. So if you have multiple events, you might
miss one.
I found a reference to unreliable signals. Take a look
at the signals chapter in "Advanced Programming in the Unix
Environment", by Stevens. However, that book is a bit old
now. The lack of safety may now only apply to that specific
signals API.
Another nice book is "Unix Systems Programming", by Robbins
and Robbins. Look in Chapter 8. Especially Section 8.6. That
section discusses the problems you'll face when your signal
interrupts POSIX calls, and functions that are signal handler
safe.
These types of issues would not be faced using select().
Hence the reason I can't remember the details on using
signals; as I rarely use them. The exception is that I
do catch ctrl-C to then shut down a process cleanly.
However, most of my user-space code is written using the
ACE C++ classes and infra-structure, and in that case you
deal with signals by creating an event handler, and
registering it with a reactor, which is implemented with,
you guessed it, select(). Notice the theme ... :)
The ACE C++ libraries are detailed in: "C++ Network
Programming" Volume 1 & 2 by Huston and Schmidt, and
in "The ACE programmers guide", by Huston et al.
Cheers,
Dave
^ permalink raw reply
* Re: wmb vs mmiowb
From: Jesse Barnes @ 2007-08-23 16:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <1187854035.5972.4.camel@localhost.localdomain>
On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
> > Of course, the normal memory barrier would usually be a
> > "spin_unlock()" or something like that, not a "wmb()". In fact, I
> > don't think the powerpc implementation (as an example of this) will
> > actually synchronize with anything *but* a spin_unlock().
>
> We are even more sneaky in the sense that we set a per-cpu flag on
> any MMIO write and do the sync automatically in spin_unlock() :-)
Yeah, that's a reasonable thing to do, and in fact I think there's code
to do something similar when a task is switched out (this keeps user
level drivers from having do mmiowb() type things).
FWIW, I think I had an earlier version of the patch that used the name
pioflush() or something similar, the only confusing thing about that
name is that the primitive doesn't actually force I/Os down to the
device level, just to the closest bridge.
It'll be interesting to see if upcoming x86 designs share this problem
(e.g. large HT or CSI topologies).
Jesse
^ permalink raw reply
* Re: wmb vs mmiowb
From: Jesse Barnes @ 2007-08-23 17:02 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <20070823022043.GB18788@wotan.suse.de>
> > Yeah, they keep threatening to use this instead, but I'm not sure
> > how easy it would be. Also they may have more devices/drivers to
> > worry about than sn2, so maybe changing over would mean too much
> > driver debugging (well auditing really since it's not that hard to
> > know where to put them). Irix actually had an io_unlock() routine
> > that did this implicitly, but iirc that was shot down for Linux...
>
> Why was it shot down? Seems like a pretty good idea to me ;)
Well, like Linus said, it had some significant downsides (though I think
Irix had fewer lock types, so the multiplicative effect wasn't so bad
there).
> I'm clueless when it comes to drivers, but I see a lot of mmiowb()
> that are not paired with spin_unlock. How are these obvious? (ie.
> what is the pattern?) It looks like some might be lockless FIFOs (or
> maybe I'm just not aware of where the locks are). Can you just
> quickly illustrate the problem being solved?
Wow, it certainly has proliferated since it was added to the tree. :)
I didn't audit all the uses, but it seems like many of them get it
right, i.e. mmiowb() before spin_unlock() where PIO has been done. I'd
have to look carefully to see whether lockless usages are correct, it's
likely they're not.
Jesse
^ permalink raw reply
* Any success with EP8248 and u-boot?
From: daniel.garoz @ 2007-08-23 16:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]
Hi everybody.
Has anyone successfully started linux using u-boot on the EmbeddedPlanet
EP8248 evaluation board?
Thanks.
Daniel Garoz.
Q No imprima este e-mail si no es necesario. Protejamos el Medio Ambiente.
E
Este mensaje y sus ficheros adjuntos se dirigen exclusivamente a su
destinatario y pueden contener información confidencial y/o sujeta a
secreto profesional. Si no es usted el destinatario indicado, queda
notificado de que la utilización, divulgación y/o copia sin autorización
está prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique inmediatamente por esta
misma vía y proceda a su destrucción. Los ficheros adjuntos han sido
comprobados con un programa anti virus antes de su transmisión, pero les
recomendamos que efectúen sus propias comprobaciones antes de abrir
cualquiera de ellos. No aceptamos responsabilidad alguna por daños o
pérdidas causados por virus informáticos.
La empresa no asume ningún tipo de responsabilidad legal por el contenido
de este mensaje. Cualquier opinión manifestada en el pertenece solo al
autor y no representa necesariamente la opinión de la empresa salvo que
expresamente se especifique lo contrario.
Dimetronic, S.A. con domicilio en Avda. Castilla nº2, Parque Empresarial
San Fernando (Edificio Grecia), 28830 San Fernando de Henares, Madrid,
España y CIF A-28512598 se encuentra inscrita en el Registro Mercantil de
Madrid al tomo 4.948 general, sección 3ª, folio 23, hoja nº 39135 y
Dimetronic S.A., Sucursal Portuguesa con domicilio en Avenida D. João II,
Lote 1.16.05, Edificio Infante 3ºQ, 1990-083 Lisboa, Freguesia de Santa
Maria dos Olivais, Concelho de Lisboa, (Portugal), NIPC 980 020 891 se
encuentra inscrita en el Registro Comercial de Lisboa con el nº
68850/880725.
Dimetronic, S.A. y Dimetronic, S.A. Sucursal Portuguesa son filiales de
Invensys, Plc, cuyo domicilio social está en Portland House, Bressenden
Place, London SW1E 5BF. Registrada en Inglaterra y Gales con el nº
1641421.
English translation
Tradução portuguesa
[-- Attachment #2: Type: text/html, Size: 3558 bytes --]
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Scott Wood @ 2007-08-23 17:33 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20070823024757.GC7042@localhost.localdomain>
On Thu, Aug 23, 2007 at 12:47:57PM +1000, David Gibson wrote:
> > ./drivers/mtd/maps/tqm834x.c:#include <asm/ppcboot.h>
> > ./drivers/mtd/maps/pq2fads.c:#include <asm/ppcboot.h>
>
> Although these both have an extern of type bd_t (defined in
> ppcboot.h), afaict they don't actually use it, so these should be
> removable.
They look like they're using it to me... See the bd->bi_flashstart and
bd->bi_flashsize references in init_pq2fads_mtd.
-Scott
^ permalink raw reply
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: Scott Wood @ 2007-08-23 17:48 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070823020147.GB7042@localhost.localdomain>
David Gibson wrote:
> Actually, no - sorry, that's the other problem with this, which I
> forgot to mention. On real OF, the "name" property contains the
> node's name *without the unit address*; that is, only the portion
> before the '@'. So your getprop change does not match real OF
> behaviour - and real OF behaviour will not do what you want for
> dt_get_path().
Ah, OK.
> Actually, in any case, I don't think we want to implement get_path()
> this way for real OF. Better to have get_path() itself as a callback:
> on real OF I believe we can directly ask for the full path to a given
> phandle, the get name based implementation can then be made specific
> to the flat device tree.
>
> Or actually, I think we might be able to come up with a get_path()
> implementation for flat tree that's less hideous than repeatedly
> calling get_parent() which is an ugly, ugly operation on the flat tree
It's likely to be ugly no matter what, though I'll try to come up with
something slightly nicer. If I were doing this code from scratch, I'd
probably liven the tree first and reflatten it to pass to the kernel.
> (and will get worse with libfdt).
Why is that?
>>Plus, something might come along that needs to dynamically look for
>>either name or something else. It's more flexible this way.
>
> Hrm... "something might come along" just seems contrived to me.
Well, I generally prefer doing things the more flexible way in the
absence of a good reason not to. OF returning the bare name is a good
reason not to.
-Scott
^ permalink raw reply
* Re: [patch 1/2] powerpc: rmb fix
From: Segher Boessenkool @ 2007-08-23 17:49 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070822040504.GC26374@wotan.suse.de>
>>> Drivers are definitely using these __raw_ accessors, and from a quick
>>> look, they do appear to be hoping that *mb() is going to order access
>>> for
>>> them.
>>
>> Which drivers?
>
> There are maybe a dozen that use the raw accessors, and use non-smp_
> memory barriers. I just looked at drivers/video/tgafb.c, which
> indeed appears to intermix them.
Hrm yeah. It also looks like old buggy code that could use a
cleanup or two (or three or four). I wonder if all __raw_ users
are like that?
Segher
^ permalink raw reply
* Re: [patch 1/2] powerpc: rmb fix
From: Segher Boessenkool @ 2007-08-23 17:57 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070822035539.GB26374@wotan.suse.de>
>> The powerpc kernel needs to have full sync insns in every I/O
>> accessor in order to enforce all the ordering rules Linux demands.
>> It's a bloody shame, but the alternative would be to make the
>> barriers lots more expensive. A third alternative would be to
>
> Well lots more expensive compared to what you have now. But what
> you have now is like having those expensive barriers between
> *every* io access.
Yeah. But I/O reads are very expensive anyway, and the barriers
are used for more than just I/O ordering.
I/O writes are a different thing; ideally, they would use only
eieio, if anything at all.
Maybe the tradeoff isn't optimal. The I/O primitives didn't have
all those "sync"s in there before, they got added because some bad
interaction with spinlocks was discovered, if my memory isn't failing
me.
>> have barrier ops that do not order everything, but just A vs. B
>> for various choices of A and B (coherent accesses, MMIO accesses,
>> etc.)
>
> The non-smp_ variant is supposed to order everything, AFAIK. Maybe
> you could get more fancy and have PIO vs MMIO etc etc. but it looks
> like this whole area is in a pretty sticky state anyway so let's
> not think about that.
*Thinking* about it is fun. Trying to get the code merged would be
a different thing ;-)
Segher
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Kumar Gala @ 2007-08-23 18:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20070823173314.GA18412@ld0162-tx32.am.freescale.net>
On Aug 23, 2007, at 12:33 PM, Scott Wood wrote:
> On Thu, Aug 23, 2007 at 12:47:57PM +1000, David Gibson wrote:
>>> ./drivers/mtd/maps/tqm834x.c:#include <asm/ppcboot.h>
>>> ./drivers/mtd/maps/pq2fads.c:#include <asm/ppcboot.h>
>>
>> Although these both have an extern of type bd_t (defined in
>> ppcboot.h), afaict they don't actually use it, so these should be
>> removable.
>
> They look like they're using it to me... See the bd->bi_flashstart
> and
> bd->bi_flashsize references in init_pq2fads_mtd.
Both of these are dead in one way or another. pq2fads.c isn't in the
makefile and you can't Kconfig tqm834x.c into existence. Thus my
patch to remove them.
- k
^ permalink raw reply
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: Segher Boessenkool @ 2007-08-23 18:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070823020147.GB7042@localhost.localdomain>
> Actually, in any case, I don't think we want to implement get_path()
> this way for real OF. Better to have get_path() itself as a callback:
> on real OF I believe we can directly ask for the full path to a given
> phandle,
Yes. "package-to-path" from the client interface.
Segher
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Brad Boyer @ 2007-08-23 18:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <F19C9986-9E53-47F3-835D-C93DA9C3ADED@kernel.crashing.org>
On Wed, Aug 22, 2007 at 11:16:03PM -0500, Kumar Gala wrote:
> On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
> >> My analysis of <asm/bootinfo.h> usage:
> >>
> >> ./drivers/macintosh/adb-iop.c:#include <asm/bootinfo.h> remove
> >> ./drivers/char/vme_scc.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/char/serial167.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/serial/dz.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/mtd/devices/ms02-nv.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/net/macsonic.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/net/jazzsonic.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/pmag-aa-fb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/maxinefb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/logo/logo.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/macfb.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/video/valkyriefb.c:#include <asm/bootinfo.h> 68k
> >
> > Uh.. I'm pretty sure valkyriefb.c is for (old) PowerMacs, not 68k.
>
> It appears to be both. If you look at the include its protected by a
> #ifdef CONFIG_MAC which we is only defined on m68k.
According to drivers/video/macfb.c, both the Quadra 630 and Performa 588
have the Valkyrie chip for their video. I don't remember which ppc based
models have it, but it's definitely on both architectures.
Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
so you should probably leave that alone as well. It probably doesn't need
that header, but the change should really come from the 68k side of things.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Olof Johansson @ 2007-08-23 18:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070823103103.a1815a07.sfr@canb.auug.org.au>
On Thu, Aug 23, 2007 at 10:31:03AM +1000, Stephen Rothwell wrote:
> On Wed, 22 Aug 2007 09:12:48 -0500 Olof Johansson <olof@lixom.net> wrote:
> >
> > -static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
> > +static inline unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
> ^^^^^^
> For static functions in C files, we tend not to bother marking them
> inline any more as the compiler does a pretty good job theses days.
Yeah, sloppy coding on my behalf. It was still there from when I
explicitly added noinline during debugging, forgot to take it out
alltogether.
> > - pci_read_config_dword(mac->iob_pdev, reg, &val);
> > + val = in_le32(mac->iob_regs+reg);
> > +
> > return val;
>
> Why not just "return in_le32(mac->iob_regs+reg);" ?
> And similarly below?
Residual from debugging as well, I had debug hooks showing what was
read/written that I took out, but didn't fix up the surrounding stuff.
Refreshed patch posted separately. Thanks for the feedback.
-Olof
^ permalink raw reply
* [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Olof Johansson @ 2007-08-23 18:13 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070822141248.GC16830@lixom.net>
Move away from using the pci config access functions for simple register
access. Our device has all of the registers in the config space (hey,
from the hardware point of view it looks reasonable :-), so we need to
somehow get to it. Newer firmwares have it in the device tree such that
we can just get it and ioremap it there (in case it ever moves in future
products). For now, provide a hardcoded fallback for older firmwares.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Updated: Removed explicit inlines, cleaned up read functions, fixed
grammar.
Index: mainline/drivers/net/pasemi_mac.c
===================================================================
--- mainline.orig/drivers/net/pasemi_mac.c
+++ mainline/drivers/net/pasemi_mac.c
@@ -83,44 +83,35 @@ static struct pasdma_status *dma_status;
static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->iob_pdev, reg, &val);
- return val;
+ return in_le32(mac->iob_regs+reg);
}
static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->iob_pdev, reg, val);
+ out_le32(mac->iob_regs+reg, val);
}
static unsigned int read_mac_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->pdev, reg, &val);
- return val;
+ return in_le32(mac->regs+reg);
}
static void write_mac_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->pdev, reg, val);
+ out_le32(mac->regs+reg, val);
}
static unsigned int read_dma_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->dma_pdev, reg, &val);
- return val;
+ return in_le32(mac->dma_regs+reg);
}
static void write_dma_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->dma_pdev, reg, val);
+ out_le32(mac->dma_regs+reg, val);
}
static int pasemi_get_mac_addr(struct pasemi_mac *mac)
@@ -585,7 +576,6 @@ static int pasemi_mac_clean_tx(struct pa
}
mac->tx->next_to_clean += count;
spin_unlock_irqrestore(&mac->tx->lock, flags);
-
netif_wake_queue(mac->netdev);
return count;
@@ -1076,6 +1066,73 @@ static int pasemi_mac_poll(struct net_de
}
}
+static void __iomem * __devinit map_onedev(struct pci_dev *p, int index)
+{
+ struct device_node *dn;
+ void __iomem *ret;
+
+ dn = pci_device_to_OF_node(p);
+ if (!dn)
+ goto fallback;
+
+ ret = of_iomap(dn, index);
+ if (!ret)
+ goto fallback;
+
+ return ret;
+fallback:
+ /* This is hardcoded and ugly, but we have some firmware versions
+ * that don't provide the register space in the device tree. Luckily
+ * they are at well-known locations so we can just do the math here.
+ */
+ return ioremap(0xe0000000 + (p->devfn << 12), 0x2000);
+}
+
+static int __devinit pasemi_mac_map_regs(struct pasemi_mac *mac)
+{
+ struct resource res;
+ struct device_node *dn;
+ int err;
+
+ mac->dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
+ if (!mac->dma_pdev) {
+ dev_err(&mac->pdev->dev, "Can't find DMA Controller\n");
+ return -ENODEV;
+ }
+
+ mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
+ if (!mac->iob_pdev) {
+ dev_err(&mac->pdev->dev, "Can't find I/O Bridge\n");
+ return -ENODEV;
+ }
+
+ mac->regs = map_onedev(mac->pdev, 0);
+ mac->dma_regs = map_onedev(mac->dma_pdev, 0);
+ mac->iob_regs = map_onedev(mac->iob_pdev, 0);
+
+ if (!mac->regs || !mac->dma_regs || !mac->iob_regs) {
+ dev_err(&mac->pdev->dev, "Can't map registers\n");
+ return -ENODEV;
+ }
+
+ /* The dma status structure is located in the I/O bridge, and
+ * is cache coherent.
+ */
+ if (!dma_status) {
+ dn = pci_device_to_OF_node(mac->iob_pdev);
+ if (dn)
+ err = of_address_to_resource(dn, 1, &res);
+ if (!dn || err) {
+ /* Fallback for old firmware */
+ res.start = 0xfd800000;
+ res.end = res.start + 0x1000;
+ }
+ dma_status = __ioremap(res.start, res.end-res.start, 0);
+ }
+
+ return 0;
+}
+
static int __devinit
pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
@@ -1104,21 +1161,6 @@ pasemi_mac_probe(struct pci_dev *pdev, c
mac->pdev = pdev;
mac->netdev = dev;
- mac->dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
-
- if (!mac->dma_pdev) {
- dev_err(&pdev->dev, "Can't find DMA Controller\n");
- err = -ENODEV;
- goto out_free_netdev;
- }
-
- mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
-
- if (!mac->iob_pdev) {
- dev_err(&pdev->dev, "Can't find I/O Bridge\n");
- err = -ENODEV;
- goto out_put_dma_pdev;
- }
/* These should come out of the device tree eventually */
mac->dma_txch = index;
@@ -1161,12 +1203,9 @@ pasemi_mac_probe(struct pci_dev *pdev, c
dev->poll = pasemi_mac_poll;
dev->features = NETIF_F_HW_CSUM;
- /* The dma status structure is located in the I/O bridge, and
- * is cache coherent.
- */
- if (!dma_status)
- /* XXXOJN This should come from the device tree */
- dma_status = __ioremap(0xfd800000, 0x1000, 0);
+ err = pasemi_mac_map_regs(mac);
+ if (err)
+ goto out;
mac->rx_status = &dma_status->rx_sta[mac->dma_rxch];
mac->tx_status = &dma_status->tx_sta[mac->dma_txch];
@@ -1193,10 +1232,17 @@ pasemi_mac_probe(struct pci_dev *pdev, c
return err;
out:
- pci_dev_put(mac->iob_pdev);
-out_put_dma_pdev:
- pci_dev_put(mac->dma_pdev);
-out_free_netdev:
+ if (mac->iob_pdev)
+ pci_dev_put(mac->iob_pdev);
+ if (mac->dma_pdev)
+ pci_dev_put(mac->dma_pdev);
+ if (mac->dma_regs)
+ iounmap(mac->dma_regs);
+ if (mac->iob_regs)
+ iounmap(mac->iob_regs);
+ if (mac->regs)
+ iounmap(mac->regs);
+
free_netdev(dev);
out_disable_device:
pci_disable_device(pdev);
@@ -1220,6 +1266,10 @@ static void __devexit pasemi_mac_remove(
pci_dev_put(mac->dma_pdev);
pci_dev_put(mac->iob_pdev);
+ iounmap(mac->regs);
+ iounmap(mac->dma_regs);
+ iounmap(mac->iob_regs);
+
pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
}
Index: mainline/drivers/net/pasemi_mac.h
===================================================================
--- mainline.orig/drivers/net/pasemi_mac.h
+++ mainline/drivers/net/pasemi_mac.h
@@ -52,6 +52,9 @@ struct pasemi_mac_rxring {
struct pasemi_mac {
struct net_device *netdev;
+ void __iomem *regs;
+ void __iomem *dma_regs;
+ void __iomem *iob_regs;
struct pci_dev *pdev;
struct pci_dev *dma_pdev;
struct pci_dev *iob_pdev;
^ permalink raw reply
* powersave-nap
From: Benedict, Michael @ 2007-08-23 20:03 UTC (permalink / raw)
To: linuxppc-embedded
I was curious what the common setting was for
/proc/sysctl/kernel/powersave-nap.
For what its worth, we are running an MPC8347 and we are not counting on
powersaving for our power or heat budget. We are not running off of
batteries and are much more concerned about responsiveness over power
saving.
>From what I have read, it seems that both nap and doze require "a couple
instructions" to wake up. If the responsiveness is the same, is there
any reason to use doze? Why is doze the default?
Thank you,
Michael
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-08-23 20:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560634.8055.170.camel@ld0161-tx32>
On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
> This patch series removes lingering jiffies initialization
> code from several platforms. Note that the first patch in
> this series for the 86xx has been rebased to current top of
> Paul's repository and replaces an earlier version.
>
>
> arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
> arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
> arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
> 9 files changed, 4 insertions(+), 107 deletions(-)
Kumar,
Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
did not get applied and ushered upstream with the others?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/3] Consolidate XILINX_VIRTEX board support.
From: Robert Woodworth @ 2007-08-23 20:34 UTC (permalink / raw)
To: wolfgang.reissnegger; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <20070822005049.12FE46F8069@mail8-cpk.bigfish.com>
On Tue, 2007-08-21 at 17:53 -0700, wolfgang.reissnegger@xilinx.com
wrote:
> From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Make support for Xilinx boards more generic, making it easier
> to add new boards. ML300 and ML403 now use this. Added
> CONFIG_XILINX_EMBED_CONFIG to do the consolidation, while still
> allowing boards not in the tree to avoid embed_config.
>
I like it!
This is exactly what I'll use for my custom board.
RJW
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Kumar Gala @ 2007-08-23 20:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1187900581.28951.17.camel@ld0161-tx32>
On Aug 23, 2007, at 3:23 PM, Jon Loeliger wrote:
> On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
>> This patch series removes lingering jiffies initialization
>> code from several platforms. Note that the first patch in
>> this series for the 86xx has been rebased to current top of
>> Paul's repository and replaces an earlier version.
>>
>>
>> arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
>> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
>> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
>> arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
>> arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
>> 9 files changed, 4 insertions(+), 107 deletions(-)
>
> Kumar,
>
> Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
> did not get applied and ushered upstream with the others?
No, I'm glad you said something cause I assumed paul grabbed them all.
I'll grab them in my tree once I beat paul into pulling the include
fixup changes.
- k
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-08-23 21:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CF601BCB-6F43-4CE2-A70B-0790DDBB19F7@kernel.crashing.org>
On Thu, 2007-08-23 at 15:47, Kumar Gala wrote:
> > Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
> > did not get applied and ushered upstream with the others?
>
> No, I'm glad you said something cause I assumed paul grabbed them all.
>
> I'll grab them in my tree once I beat paul into pulling the include
> fixup changes.
>
> - k
OK, sounds good.
Thanks,
jdl
^ permalink raw reply
* c67x00 driver again.
From: Robertson, Joseph M. @ 2007-08-23 21:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]
Hi all,
I think I am getting closer. With the c67x00 hcd driver do I need the usb-hcd to be running?
I think I missed a link somewhere. The driver loads, buts inserting a memstick does nothing.
I'm thinking I need to be connected to the core somehow. I have the usb-core as builtin.
Again its heavily custom 2.6.17.3 on a virtex-4 ppc. 2 usb ports wired out.
I had a meltdown yesterday so some of the prinks are different...
-----
c67x00 init.
c67x00 udc init.
c67x00 drv probing.
c67x00 before mem.
c67x00 before irq.
c67x00 before mem alloc.
c67x00 setup sies.
c67x00 before ll init.
c67x00 c67x00.0: USB OTG controller, p:0x43e00000, v:0xc5220000, irq:3
c67x00 c67x00_sie.0: Cypress C67X00 Host Controller
c67x00 c67x00_sie.0: new USB bus registered, assigned bus number 1
c67x00, hcd start.<6>usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
c67x00 c67x00_sie.1: Cypress C67X00 Host Controller
c67x00 c67x00_sie.1: new USB bus registered, assigned bus number 2
c67x00, hcd start.<6>usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: usb_stor_exit() called
usb-storage: -- calling usb_deregister()
usbcore: deregistering driver usb-storage
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
-----
Thanks,
Joe Robertson
x8259
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 3399 bytes --]
^ permalink raw reply
* [RFC] xmon: setjmp / longjmp implementation problems
From: Florian Boelstler @ 2007-08-23 22:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
I was hunting an ugly problem in the NuBus PowerMac port of Linux [1]
for a while now (that platform isn't included in mainline kernel and
still is based on 2.4 kernel series).
Linux was successfully built using gcc-3.3.5/binutils-2.15 so far.
Later toolchain versions (e.g. gcc-3.4.5/binutils-2.15) turned out to
break things during hardware detection on the NuBus.
Looking at the relevant code sections shows that the register probing
code is based on the setjmp/longjmp implementation [2] found in xmon.
Regarding the "ppc" platform that code almost matches at least up to
mainline kernel 2.6.20.1 [3].
On the "powerpc" platform the code did dramatically change [4].
I was extracting both implementations to a simple userspace application
to be able to easily try different compiler versions and optimization
levels.
Eventually I found out that the temporary solution is to build the
ppc-implementation using -O1 for gcc versions >3.3.5.
Since I found a comment by Paul in arch/ppc/xmon/setjmp.c: "NB this file
must be compiled with -O2.", I was wondering which toolchain versions
are/were used to compile xmon-enabled kernels for the ppc and powerpc
platform.
Since -O2 seems to be the default for 2.6 kernels as well, I am
wondering what gcc version is known to build a kernel with xmon support.
Are there are any known gcc versions, which are causing trouble with
xmon (actually its setjmp/longjmp implementation)?
Some details of toolchain tests follow:
"ppc" implementation:
When -O2 is used gcc-3.4.5 inlines static functions by default, which
turned out to be the first problem. Even when "static" is removed the
resulting program flow reflects an infinite loop (when longjumped
function returns).
I found out that -O1 with gcc-3.4.5 generates code, which resembles the
functionality of gcc-3.3.5 with -O2. I.e. a working version of
setjmp/longjmp. A segmentation fault occurs when no optimization level
is used.
With gcc-4.1.0 no successful working build was possible.
"powerpc" implementation:
The binary works with no optimization level, -O0 and -O1 with gcc-3.4.5.
Using -O2 turns the resulting code into an infinite loop again.
With gcc-4.1.0/binutils-2.16.1 only -O0 generated a useful binary.
Thanks for any suggestions!
Florian
[1] http://nubus-pmac.sf.net
[2]
http://nubus-pmac.cvs.sourceforge.net/nubus-pmac/linuxppc-2.4-nubus/arch/ppc/platforms/nbpmac_setup.c
Lines 162-194
[3] http://lxr.linux.no/source/arch/ppc/xmon/setjmp.c?a=ppc
[4] http://lxr.linux.no/source/arch/powerpc/xmon/setjmp.S?a=ppc
^ 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