* Re: [POWERPC] convert string i/o operations to C
From: David Howells @ 2006-09-19 12:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060919222351.d27a1a06.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> +void _insb(volatile u8 __iomem *port, void *buf, int ns)
> +{
> + asm volatile("sync");
> + if (ns <= 0)
> + return;
What is "ns" meant to do? It seems to degrade the _insb() op to just a sync,
but is that correct?
David
^ permalink raw reply
* Re: Measure Interrupt Latency on MPC5200B
From: Josu Onandia @ 2006-09-19 12:44 UTC (permalink / raw)
To: Esben Nielsen; +Cc: Linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0609191414090.10784@frodo.shire>
Esben Nielsen wrote:
> On Tue, 19 Sep 2006, Josu Onandia wrote:
>
>> Syed Amer Gilani wrote:
>>
>>> We have a MPC5200B(ppc) Board from Phytec, running with a 2.6 Linux
>>> Kernel. For Documentation purposes and testings how patches to the
>>> Kernel affects real time capabilities we want to measure the Interrupt
>>> Latency.
>>> I only found tools for other arches or patches for far to old kernels.
>>> Does somebody know a way for a 2.6 kernel on ppc? I already thought of
>>> generating a signal on an Output of the Board and measure it with a
>>> Oscilloscope but i don't find that method satisfying.
>>>
>>> Thank you in advance,
>>> Syed Amer Gilani
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>> Hi. I'm sorry for my own latency, but I've been very busy.
>>
>> I'm measuring interrup latency in an MPC5200B, too, but with Linux 2.4.
>>
>> With this processor you can use the TB registers to measure a lapse
>> of time.
>>
>> I use a GPT timer to generate a periodic interrupt. From the interrupt
>> routine I read the TBL and compare it with the expected value.
>>
>> I do this using RTAI, because I need real-time response to interrupts,
>> but I suppose that with little effort you can port it to standard Linux.
>>
>> If you want more details, or my actual source code, email me.
>>
>> Josu Onandia
>>
>>
>
> What are your results under the normal kernel and under RTAI?
> Have anyone tried with -rt kernels? What are the results?
>
> I work for a company using MPC5200 with VxWorks. It could be fun to
> compare numbers...
>
> Esben
This is a Lite5200B running at 462MHz, kernel 2.4.25 and RTAI 24.1.11,
from Denx.
I haven't tried under normal kernel. With RTAI I have 1,5usec from the
actual interrupt until RTAI call my ISR function. This adds the
processor latency plus the RTAI dispatcher overhead. With heavy IO load,
ethernet and disk, the maximum is 8usec.
I'd really like to see your results, to compare with a real RTOS.
Josu
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-19 14:16 UTC (permalink / raw)
To: John Bonesio; +Cc: linuxppc-embedded
In-Reply-To: <2FE3DBF1797A1443AAB3FA0EF6BF4EEC021EAC01@XSJ-EXCHVS1.xlnx.xilinx.com>
[edited for context]
On 9/15/06, John Bonesio <john.bonesio@xilinx.com> wrote:
> On Thursday, September 14, 2006 5:09 PM, Keith J Outwater wrote:
> > I thinking in terms of something like a 32 bit register (i.e. like a
> > processor's PVR register) that has a hard-coded magic number
> > which a driver can read and decode to determine driver compatibility.
> > That does not sound resource-intensive given the size FPGAs we are
> > talking about. Probably don't even need 32 bits.
>
> I know that on the surface it seems like a simple thing. Some of our
> parts are big, yet some are small. We are always getting pressure to
> make our IP as small as possible.
>
> Though, this may be something we can revisit again, for now this
> information just isn't going to be available.
Then its probably just a matter of whoever configures the kernel needs
to know what version of IP is being used. ie. always have the
fallback of compile time specification of IP version. Could be done
manually, or by putting the info into the dts. We probably need a
tool to generate a dts from the .mhs or xparameters.h file anyway.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-19 14:17 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87hcz4z47p.fsf@sleipner.barco.com>
On 9/19/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
> GL> If we reject the Xilinx driver code, then we either have to do
> GL> without Xilinx support in mainline, or we need to write new
> GL> drivers that address the above issues (support multiple IP
> GL> versions, etc). The Xilinx support in mainline right now does not
> GL> use any Xilinx code. (Xilinx PIC and UART).
>
> I think the best option is to simply forget about the Xilinx code,
> see the FPGAs as any other PPC system and write normal device drivers
> for it. Your platform bus stuff and my (to-be-mainlined) uartlite
> driver is a first step in this direction..
Too bad platform bus is sooo last year. :p
Time to hack device trees.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] fix error in cpm2
From: Vitaly Bordug @ 2006-09-19 14:55 UTC (permalink / raw)
To: Amy Fong; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060919030625.GA24944@lucciola.windriver.com>
On Mon, 18 Sep 2006 23:06:25 -0400
Amy Fong <amy.fong@windriver.com> wrote:
> The following patch fixes a typo in cpm2.h resulting in a compile error.
>
> Signed-off-by: Amy Fong <amy.fong@windriver.com>
>
> Index: linux-2.6.18-rc6/include/asm-ppc/cpm2.h
> ===================================================================
> --- linux-2.6.18-rc6.orig/include/asm-ppc/cpm2.h
> +++ linux-2.6.18-rc6/include/asm-ppc/cpm2.h
> @@ -1186,7 +1186,7 @@
> #define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
> #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
> #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
> -#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
> +#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
>
> #endif /* __CPM2__ */
> #endif /* __KERNEL__ */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
Well, I have this hunk in
[PATCH 3/7] POWERPC: Move generic cpm2 stuff to powerpc
already...
Paul, does it make sense to extract and re-send this specific fix?
I think it will be OK for this to appear next major merge...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: problems with PLB_TEMAC & xilinx_gige driver under linux 2.4 ...
From: rimas @ 2006-09-19 16:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <450F8062.1000606@dlasys.net>
well i'm not sure what the gemac is but the plb_temac and hard_temac
are the blocks you're supposed to use to utilize the tri-mode MAC
built into the virtex 4 parts and the xilinx_gige driver is the one
the EDK tools generate to go with those blocks
in any case i think i've found a way to solve my problem and thought
i would share it with the list (and perhaps someone who understands
the issues involved better than i do could shed some light on the
subject)
its seems that some time between 2.4.20 and 2.4.26 the assembly
language that is used to implement the inb/inw/inl instructions changed
in 2.4.20 it was lwz; eieio; as seen here (from include/asm-ppc/io.h)
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1; eieio" : "=r" (ret) :
"m" (*addr));
return ret;
}
and in 2.4.26 the sequence is lwz, twi, isync
i changed it back to lwz; eieio; and my problems have gone away (whew!)
does anyone know why that change was made and why it would be causing
a trap and crashing my ppc ?
thanks
-rimas
On Sep 18, 2006, at 10:30 PM, David H. Lynch Jr. wrote:
> I do nto know much about Xilinx under 2.4 but I am pretty sure
> the gemac and the plb temac are similar but different
> NIC's.
>
> rimas wrote:
>> Greetings,
>>
>> i am having problems using the xilinx_gige driver under linux
>> 2.4.26 running on a Virtex-4 FX12 Mini Module board (from
>> avnet). I am using the plb_temac and hard_temac blocks under ISE/
>> EDK 8.1.02.
>>
>> the machine boots fine and the network interface seems to work
>> okay but it randomly panics sometimes (rather quickly if i'm
>> generating network traffic):
>>
>> Oops: Exception in kernel mode, sig: 4
>> NIP: C00DA340 XER: 20000000 LR: C00D34F8 SP: C3945B20 REGS:
>> c3945a70 TRAP: 0700
>> Not tainted
>> MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>> TASK = c3944000[52] 'telnetd' Last syscall: 4
>> last math 00000000 last altivec 00000000
>> GPR00: 00000004 C3945B20 C3944000 C02E49F4 C02E4800 00000004
>> 00000001 C0456260
>> GPR08: C0177424 00000031 C50D8000 00021F03 0008C8E4 10122AA8
>> 00000000 C01A0000
>> GPR16: 00000000 0000001A 00000000 C3945F18 00001032 03945BA0
>> 00000000 C00038E0
>> GPR24: C0004800 00000020 C04C06E0 C01864E0 C3945BB0 0000001F
>> 00000000 C02E49F4
>> Call backtrace:
>> C0190000 C00D34F8 C0004748 C000483C C00038E0 C00D398C C00F8094
>> C00EE04C C01039B0 C0104D70 C0115570 C01163A8 C010A600 C012A61C
>> C00E52F4 C00E5574 C003AB2C C000369C 100572BC 10005064 10005108
>> 0FD9221C 00000000
>> Kernel panic: Aiee, killing interrupt handler!
>> In interrupt handler - not syncing
>> <0>Rebooting in 180 seconds..
>>
>> it always causes a trap on the same instruction (c00da340) which
>> is inside of
>> XTemac_IntrFifoHandler()
>>
>> c00da330: 81 6a 00 28 lwz r11,40(r10)
>> c00da334: 0c 0b 00 00 twi 0,r11,0
>> c00da338: 4c 00 01 2c isync
>> c00da33c: 81 2a 00 20 lwz r9,32(r10)
>> c00da340: 0c 09 00 00 twi 0,r9,0
>> c00da344: 4c 00 01 2c isync
>>
>> this code corresponds to two consecutive in_be32() calls
>>
>> extern inline unsigned in_be32(volatile unsigned *addr)
>> {
>> unsigned ret;
>>
>> __asm__ __volatile__("lwz%U1%X1 %0,%1;\n"
>> "twi 0,%0,0;\n"
>> "isync" : "=r" (ret) : "m" (*addr));
>> return ret;
>> }
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Andrew @ 2006-09-19 18:06 UTC (permalink / raw)
To: John Bonesio; +Cc: linuxppc-embedded
In-Reply-To: <2FE3DBF1797A1443AAB3FA0EF6BF4EEC021EA645@XSJ-EXCHVS1.xlnx.xilinx.com>
On Thu, 14 Sep 2006 09:40:53 -0700
"John Bonesio" <john.bonesio@xilinx.com> wrote:
> I am in the group that has control over how this is done. What would
> you propose be done different? Keep in mind that we are trying to
> support a process where someone builds a hardware design and the
> later changes it with new peripherals or perhaps makes minor tweaks.
> We want to make the updating of the Linux kernel to reflect these
> hardware changes easy for people.
>
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.
I am coming into this a bit late and it has been awhile since I worked
Virtex parts. But it doesn't look like things have changed much.
Since Linux is from a PC base, hardware changes are as rapid as
powering off and plugging a new device in the machine. Rebuilding the
kernel for this is not usually something people consider for this.
So to say Linux people aren't use to rapid hardware changes, seems
pretty backwards to me.
The static configuration of the hardware is the thing that is very
unusual for the software. And having that static hardware setup
compiled into the kernel is a real source of problems.
Typically things get probed, discovered/learned at boot time. Either by
the boot loader, pin strapping, dip switches, user config etc.
I worked on a board with 2 Virtex chips. They had some set of common IP
cores with minor differences between the two. There was no way I wanted
to build 2 sets of kernels and drivers to deal with things.
The first small difference of one chip having 2 serial ports and the
other side only having 1 serial port, rippled the entire IRQ mapping in
both xparameters.h file. There were all kinds of little changes between
the mem mapping and everything else as well.
Depending on how things were used from xparemeters.h I could change the
static numbers to function calls to get values, but most of the time I
easist to hack up the drivers to pick one of two values depending on
the chip.
At first I just used a kernel boot param saved in u-boot flash to tell
the SW which chip it was running on. Then I got our HW people to put
in a single bit in another register for SW to tell which chip was
running. That saved us setup step in production of setting up flash
with different items.
There are trade offs on how much it is worth being determined at run
time compared to compiled into the kernel, but with the current
xparemters.h you are stuck with things compiled in. Getting to a point
where anything can be learned at run time, or just pulled from flash
would be a big step forward. But at that point it should still be easy
to compile things into the kernel if someone has major sw space
constraints.
I also keep hearing about doing partial re-configuration bit streams.
Were the FPGA can change at run time as well. (ie switch from an
CAT5 ethernet IP core over to an 802.11 ethernet depending on if the
user plugs in a cable or an antenna)
How would you even plan to do that with the xparemters.h file and the
drivers as it is now?
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Linas Vepstas @ 2006-09-19 18:29 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060919222351.d27a1a06.sfr@canb.auug.org.au>
On Tue, Sep 19, 2006 at 10:23:51PM +1000, Stephen Rothwell wrote:
Perhaps this:
> +void _insb(volatile u8 __iomem *port, void *buf, int ns)
> +{
> + asm volatile("sync");
> + if (ns <= 0)
> + return;
> + asm volatile(
should be this:
> +void _insb(volatile u8 __iomem *port, void *buf, int ns)
> +{
> + if (ns <= 0)
> + return;
> + asm volatile("sync");
> + asm volatile(
to assuage David Howell's concern. Not that ns should be negative
in the first place ... but what the hey.
Re Davids other comment: "ns" stands for "no byte-swap", and
"s" stands for "string" so "insl_ns" is input string of longs,
no byte swap.
Here's a question:
> + asm volatile(
> + "mtctr %2\n"
> + "subi %1,%1,1\n"
> + "0: lbz %2,0(%0)\n"
> + "eieio\n"
> + "stbu %2,1(%1)\n"
> + "bdnz 0b\n"
> + "twi 0,%2,0\n"
What does this twi do? According to my powerpc docs, this would be a
no-op. Does this have some magic synchronizing powers on certain
implementations? If so, there should be at least a comment card added
about why the twi is there. (This special ability of twi might be
well-known to some, but still, this is not immediately obvious,
and not immedately documented in e.g. the PEM.)
--linas
^ permalink raw reply
* Re: Fw: [PATCH] Remove powerpc specific parts of 3c509 driver
From: Linas Vepstas @ 2006-09-19 18:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: akpm, ppc-dev, jgarzik, netdev
In-Reply-To: <20060919145433.8fc7d478.sfr@canb.auug.org.au>
On Tue, Sep 19, 2006 at 02:54:33PM +1000, Stephen Rothwell wrote:
>
> On powerpc and ppc, insl_ns and insl are identical as are outsl_ns and
> outsl, so remove the conditional use of insl_ns and outsl_ns.
The rest of this patch might indeed be correct, but the above comment
bothers me. The "ns" versions of routines are supposed to be
non-byte-swapped versions of the insl/outsl routines (which would
byte-swap on big-endian archs such as powerpc.)
> diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c
> index cbdae54..add6381 100644
> --- a/drivers/net/3c509.c
> +++ b/drivers/net/3c509.c
> @@ -879,11 +879,7 @@ #endif
> outw(skb->len, ioaddr + TX_FIFO);
> outw(0x00, ioaddr + TX_FIFO);
> /* ... and the packet rounded to a doubleword. */
> -#ifdef __powerpc__
> - outsl_ns(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >> 2);
> -#else
> outsl(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >> 2);
> -#endif
Dohh, a hack like this to work around some possbile byte-swapping
bug should never have been done in the first place :-(
However, I presume someone added the __powerpc__ define here
because they picked up a 3c509 at a garage sale, stuck it in
a powerpc, found out it didn't work due to a byte-swapping bug,
and then patched it as above. I'm disturbed that somehow
outsl_ns() became identical to outsl() at some point, presumably
breaking this patch.
--linas
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Kim Phillips @ 2006-09-19 18:52 UTC (permalink / raw)
To: Linas Vepstas; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20060919182953.GK29167@austin.ibm.com>
On Tue, 19 Sep 2006 13:29:53 -0500
linas@austin.ibm.com (Linas Vepstas) wrote:
>
> What does this twi do? According to my powerpc docs, this would be a
> no-op. Does this have some magic synchronizing powers on certain
> implementations? If so, there should be at least a comment card added
> about why the twi is there. (This special ability of twi might be
> well-known to some, but still, this is not immediately obvious,
> and not immedately documented in e.g. the PEM.)
include/asm-p[ower]pc/io.h sheds some light on the matter:
* With the sequence below (twi; isync; nop), we have found that
* the machine check occurs on one of the three instructions on
* all PPC implementations tested so far. The twi and isync are
* needed on the 601 (in fact twi; sync works too), the isync and
* nop are needed on 604[e|r], and any of twi, sync or isync will
* work on 603[e], 750, 74xx.
* The twi creates an explicit data dependency on the returned
* value which seems to be needed to make the 601 wait for the
* load to finish.
Kim
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Matt Sealey @ 2006-09-19 18:58 UTC (permalink / raw)
To: Kim Phillips; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20060919135259.303706d3.kim.phillips@freescale.com>
Shouldn't this stuff be optimized out depending on what processor you're
ACTUALLY running?
For a generic "powerpc" kernel it can be understood, but when you
consider that on 970/POWER4 and above they use lwsync instead of sync
(google for them and see the mailing list posts :), just to breathe back
some performance in spinlocks and so on, surely this can be rejigged so
that processors don't do more work than necessary..? Even a noop takes
time doesn't it?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Kim Phillips wrote:
> On Tue, 19 Sep 2006 13:29:53 -0500
> linas@austin.ibm.com (Linas Vepstas) wrote:
>
>> What does this twi do? According to my powerpc docs, this would be a
>> no-op. Does this have some magic synchronizing powers on certain
>> implementations? If so, there should be at least a comment card added
>> about why the twi is there. (This special ability of twi might be
>> well-known to some, but still, this is not immediately obvious,
>> and not immedately documented in e.g. the PEM.)
>
> include/asm-p[ower]pc/io.h sheds some light on the matter:
>
> * With the sequence below (twi; isync; nop), we have found that
> * the machine check occurs on one of the three instructions on
> * all PPC implementations tested so far. The twi and isync are
> * needed on the 601 (in fact twi; sync works too), the isync and
> * nop are needed on 604[e|r], and any of twi, sync or isync will
> * work on 603[e], 750, 74xx.
> * The twi creates an explicit data dependency on the returned
> * value which seems to be needed to make the 601 wait for the
> * load to finish.
>
> Kim
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Fw: [PATCH] Remove powerpc specific parts of 3c509 driver
From: Matt Sealey @ 2006-09-19 18:52 UTC (permalink / raw)
To: Linas Vepstas; +Cc: akpm, Stephen Rothwell, netdev, jgarzik, ppc-dev
In-Reply-To: <20060919184243.GL29167@austin.ibm.com>
Some northbridges and PCI bridges have "clever" byteswapping in
hardware, maybe this is just an effect of that. In theory depending on
the host bridge, you should pass in big endian data and have it swap or
not swap, not pick that way in the driver, UNLESS your driver expects
bigendian data, in which case on a bigendian platform you can tell it to
write without swapping. Voila, two functions.
However the existance of these PCI bridges these days? I haven't seen
one in years, and when I have nobody has ever enabled the magic swappy
thing as it's unreliable and can't always tell how you present the data.
One wishes that there was a ntoh and hton style macro in standard use
for PCI access.. hang on though that jsut wouldn't work would it.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Linas Vepstas wrote:
> On Tue, Sep 19, 2006 at 02:54:33PM +1000, Stephen Rothwell wrote:
>> On powerpc and ppc, insl_ns and insl are identical as are outsl_ns and
>> outsl, so remove the conditional use of insl_ns and outsl_ns.
>
> The rest of this patch might indeed be correct, but the above comment
> bothers me. The "ns" versions of routines are supposed to be
> non-byte-swapped versions of the insl/outsl routines (which would
> byte-swap on big-endian archs such as powerpc.)
>
>> diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c
>> index cbdae54..add6381 100644
>> --- a/drivers/net/3c509.c
>> +++ b/drivers/net/3c509.c
>> @@ -879,11 +879,7 @@ #endif
>> outw(skb->len, ioaddr + TX_FIFO);
>> outw(0x00, ioaddr + TX_FIFO);
>> /* ... and the packet rounded to a doubleword. */
>> -#ifdef __powerpc__
>> - outsl_ns(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >> 2);
>> -#else
>> outsl(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >> 2);
>> -#endif
>
> Dohh, a hack like this to work around some possbile byte-swapping
> bug should never have been done in the first place :-(
>
> However, I presume someone added the __powerpc__ define here
> because they picked up a 3c509 at a garage sale, stuck it in
> a powerpc, found out it didn't work due to a byte-swapping bug,
> and then patched it as above. I'm disturbed that somehow
> outsl_ns() became identical to outsl() at some point, presumably
> breaking this patch.
>
> --linas
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Linas Vepstas @ 2006-09-19 19:04 UTC (permalink / raw)
To: Kim Phillips; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20060919135259.303706d3.kim.phillips@freescale.com>
On Tue, Sep 19, 2006 at 01:52:59PM -0500, Kim Phillips wrote:
> On Tue, 19 Sep 2006 13:29:53 -0500
> linas@austin.ibm.com (Linas Vepstas) wrote:
>
> >
> > What does this twi do? According to my powerpc docs, this would be a
> > no-op. Does this have some magic synchronizing powers on certain
> > implementations? If so, there should be at least a comment card added
> > about why the twi is there. (This special ability of twi might be
> > well-known to some, but still, this is not immediately obvious,
> > and not immedately documented in e.g. the PEM.)
>
> include/asm-p[ower]pc/io.h sheds some light on the matter:
>
> * With the sequence below (twi; isync; nop), we have found that
> * the machine check occurs on one of the three instructions on
> * all PPC implementations tested so far. The twi and isync are
> * needed on the 601 (in fact twi; sync works too), the isync and
> * nop are needed on 604[e|r], and any of twi, sync or isync will
> * work on 603[e], 750, 74xx.
> * The twi creates an explicit data dependency on the returned
> * value which seems to be needed to make the 601 wait for the
> * load to finish.
Thanks. I notice that this commentary appears in asm-ppc/io.h
but not in asm-powerpc/io.h -- Perhaps a patch is in order ...
I'm creating such a patch now ...
--linas
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Segher Boessenkool @ 2006-09-19 19:06 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Stephen Rothwell, paulus, ppc-dev
In-Reply-To: <20060919182953.GK29167@austin.ibm.com>
> What does this twi do? According to my powerpc docs, this would be a
> no-op. Does this have some magic synchronizing powers on certain
> implementations?
On all implementations; it's in the PowerPC architecture.
A data-dependent branch followed by an isync ensures that no
instructions after the isync in program order will be
(speculatively) executed, so the load that the twi depends
on has to complete before anything else is executed; in
particular, it's a barrier to keep MMIO reads ordered before
main-storage accesses.
Note that twi alone is not enough; it needs an isync as well.
Any other data-dependent branch instead of twi would do fine
as well.
Segher
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Segher Boessenkool @ 2006-09-19 19:10 UTC (permalink / raw)
To: Matt Sealey; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <45103DF0.9050409@genesi-usa.com>
> For a generic "powerpc" kernel it can be understood, but when you
> consider that on 970/POWER4 and above they use lwsync instead of sync
lwsync (sync 1) doesn't (architecturally) do anything to order MMIO
accesses, so you're misunderstanding something.
> (google for them and see the mailing list posts :), just to breathe
> back
> some performance in spinlocks and so on, surely this can be
> rejigged so
> that processors don't do more work than necessary..? Even a noop takes
> time doesn't it?
No-ops don't matter for performance, compared to the cost of the I/O
itself. It would help to avoid heavier-than-necessary synchronisation
instructions if not needed on some certain CPU (or on non-SMP kernels,
etc.)
Segher
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Matt Sealey @ 2006-09-19 19:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <9E674786-9AF3-4322-B642-7BAA58462B74@kernel.crashing.org>
Segher Boessenkool wrote:
>> For a generic "powerpc" kernel it can be understood, but when you
>> consider that on 970/POWER4 and above they use lwsync instead of sync
>
> lwsync (sync 1) doesn't (architecturally) do anything to order MMIO
> accesses, so you're misunderstanding something.
See below :D
>> (google for them and see the mailing list posts :), just to breathe back
>> some performance in spinlocks and so on, surely this can be rejigged so
>> that processors don't do more work than necessary..? Even a noop takes
>> time doesn't it?
>
> No-ops don't matter for performance, compared to the cost of the I/O
> itself. It would help to avoid heavier-than-necessary synchronisation
> instructions if not needed on some certain CPU (or on non-SMP kernels,
> etc.)
But it couldn't hurt, right? There has to be an application note per-CPU
on the correct sequence of operations for such an access (I seem to have
collected a directory full for firmware development), it seems a little
odd to pick and choose one instruction over another for one thing, and
then say you need to do it to support the 601 of all things, and run
this code against the G3/G4/G5 which perhaps doesn't care or is more
intelligent about it (or is guaranteed to have a more intelligent host
bridge at least).
Maybe I'm talking crap, please say so :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [PATCH]: powerpc: clarify use of twi/isync in io macros
From: Linas Vepstas @ 2006-09-19 19:30 UTC (permalink / raw)
To: paulus; +Cc: Stephen Rothwell, ppc-dev
Paul, please apply.
Clarify why twi appears in the i/o macros.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
----
include/asm-powerpc/io.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: linux-2.6.18-rc7-git1/include/asm-powerpc/io.h
===================================================================
--- linux-2.6.18-rc7-git1.orig/include/asm-powerpc/io.h 2006-09-14 13:38:48.000000000 -0500
+++ linux-2.6.18-rc7-git1/include/asm-powerpc/io.h 2006-09-19 14:26:26.000000000 -0500
@@ -278,6 +278,17 @@ static inline void iosync(void)
* These routines do not perform EEH-related I/O address translation,
* and should not be used directly by device drivers. Use inb/readb
* instead.
+ *
+ * Read operations have additional twi & isync to make sure the read
+ * is actually performed (i.e. the data has come back) before we start
+ * executing any following instructions.
+ *
+ * A data-dependent branch followed by an isync ensures that no
+ * instructions after the isync in program order will be
+ * (speculatively) executed, so the load that the twi depends
+ * on has to complete before anything else is executed; in
+ * particular, it's a barrier to keep MMIO reads ordered before
+ * main-storage accesses.
*/
static inline int in_8(const volatile unsigned char __iomem *addr)
{
^ permalink raw reply
* Re: Fw: [PATCH] Remove powerpc specific parts of 3c509 driver
From: Linas Vepstas @ 2006-09-19 19:44 UTC (permalink / raw)
To: Matt Sealey; +Cc: akpm, Stephen Rothwell, netdev, jgarzik, ppc-dev
In-Reply-To: <45103C62.4080003@genesi-usa.com>
On Tue, Sep 19, 2006 at 08:52:18PM +0200, Matt Sealey wrote:
[...]
>
> Linas Vepstas wrote:
> >On Tue, Sep 19, 2006 at 02:54:33PM +1000, Stephen Rothwell wrote:
> >>On powerpc and ppc, insl_ns and insl are identical as are outsl_ns and
> >>outsl, so remove the conditional use of insl_ns and outsl_ns.
> >
> >The rest of this patch might indeed be correct, but the above comment
> >bothers me. The "ns" versions of routines are supposed to be
> >non-byte-swapped versions of the insl/outsl routines (which would
Never mind. Silly me don't know my history.
asm-powerpc/io.h clearly states
* The *_ns versions below don't do byte-swapping.
* Neither do the standard versions now, these are just here
* for older code.
Seems that the byteswapping machanism was changed a while ago,
and no longer handled in this way any more.
--linas
^ permalink raw reply
* Re: common flatdevtree code
From: Mark A. Greer @ 2006-09-19 19:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <17665.28367.380866.565218@cargo.ozlabs.ibm.com>
On Fri, Sep 08, 2006 at 11:23:27PM +1000, Paul Mackerras wrote:
Content-Description: message body text
> Mark,
>
> Here's where I'm up to...
>
> Paul.
Paul,
Any update to this or do you want to go with this? (I haven't tested
it, btw).
Mark
^ permalink raw reply
* Re: [POWERPC] convert string i/o operations to C
From: Segher Boessenkool @ 2006-09-19 19:47 UTC (permalink / raw)
To: Matt Sealey; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <45104304.3000205@genesi-usa.com>
> But it couldn't hurt, right? There has to be an application note
> per-CPU on the correct sequence of operations for such an access (I
> seem to have collected a directory full for firmware development),
The architecture describes the rules already, not many CPUs
have "faster"/"better" sequences.
> it seems a little odd to pick and choose one instruction over
> another for one thing, and then say you need to do it to support
> the 601 of all things, and run this code against the G3/G4/G5 which
> perhaps doesn't care or is more intelligent about it (or is
> guaranteed to have a more intelligent host bridge at least).
The comment you're referring to is old; it doesn't talk about
synchronisation requirements, but focuses on having the CPU
trap on exactly these instructions when an access causes a
(asynchronous) machine check. Asynchronous exceptions don't
necessarily return the instruction pointer where the real
failure was, so it's no surprise different CPUs have a different
idea about it. It's pretty safe to assume (but not guaranteed)
that it will always be somewhere between the load and the insn
after the isync, inclusive, though.
Segher
^ permalink raw reply
* Re: [PATCH]: powerpc: clarify use of twi/isync in io macros
From: Segher Boessenkool @ 2006-09-19 19:57 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Stephen Rothwell, paulus, ppc-dev
In-Reply-To: <20060919193020.GN29167@austin.ibm.com>
> + *
> + * Read operations have additional twi & isync to make sure the read
> + * is actually performed (i.e. the data has come back) before we
> start
> + * executing any following instructions.
> + *
> + * A data-dependent branch followed by an isync ensures that no
> + * instructions after the isync in program order will be
> + * (speculatively) executed
..."before the isync has completed, and it won't complete until
the branch is resolved;"...
> so the load that the twi depends
> + * on has to complete before anything else is executed; in
> + * particular, it's a barrier to keep MMIO reads ordered before
> + * main-storage accesses.
> */
You shouldn't post my test and put your signed-off on it, esp.
if I forgot to type half a sentence :-) Here, have one though:
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-19 20:10 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609190717u1c7cd349m7e08e5bafd341c38@mail.gmail.com>
On 9/19/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 9/19/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
> > GL> If we reject the Xilinx driver code, then we either have to do
> > GL> without Xilinx support in mainline, or we need to write new
> > GL> drivers that address the above issues (support multiple IP
> > GL> versions, etc). The Xilinx support in mainline right now does not
> > GL> use any Xilinx code. (Xilinx PIC and UART).
> >
> > I think the best option is to simply forget about the Xilinx code,
> > see the FPGAs as any other PPC system and write normal device drivers
> > for it. Your platform bus stuff and my (to-be-mainlined) uartlite
> > driver is a first step in this direction..
>
> Too bad platform bus is sooo last year. :p
>
> Time to hack device trees.
Avast! After getting quizzed on IRC about this off-the-cuff comment,
I should probably clarify. Since the Xilinx IP could be wired up to a
ublaze core or an off-chip processor, the drivers still need to use a
platform bus attachment to keep it all cross platform.
So, replace above comment with the following:
Populating the platform device with static code during initialization
is sooo last year.
Time to hack device trees to populate it instead.
:)
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH]: powerpc: clarify use of twi/isync in io macros
From: Linas Vepstas @ 2006-09-19 20:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Stephen Rothwell, paulus, ppc-dev
In-Reply-To: <72674737-8325-48FA-B04F-C4ADCA2E2BF9@kernel.crashing.org>
On Tue, Sep 19, 2006 at 09:57:11PM +0200, Segher Boessenkool wrote:
> ..."before the isync has completed, and it won't complete until
> the branch is resolved;"...
New improved patch attched.
> You shouldn't post my test and put your signed-off on it, esp.
> if I forgot to type half a sentence :-) Here, have one though:
My moral fiber did twinge before I hit the send button,
but I confused it with a muscle spasm.
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
--------
Clarify why twi appears in the i/o macros.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
----
include/asm-powerpc/io.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: linux-2.6.18-rc7-git1/include/asm-powerpc/io.h
===================================================================
--- linux-2.6.18-rc7-git1.orig/include/asm-powerpc/io.h 2006-09-14 13:38:48.000000000 -0500
+++ linux-2.6.18-rc7-git1/include/asm-powerpc/io.h 2006-09-19 15:04:30.000000000 -0500
@@ -278,6 +278,18 @@ static inline void iosync(void)
* These routines do not perform EEH-related I/O address translation,
* and should not be used directly by device drivers. Use inb/readb
* instead.
+ *
+ * Read operations have additional twi & isync to make sure the read
+ * is actually performed (i.e. the data has come back) before we start
+ * executing any following instructions.
+ *
+ * A data-dependent branch followed by an isync ensures that no
+ * instructions after the isync in program order will be
+ * (speculatively) executed before the isync has completed, and
+ * the isync won't complete until the branch is resolved. The
+ * the load that the twi depends on has to complete before
+ * anything else is executed; in particular, it's a barrier to
+ * keep MMIO reads ordered before main-storage accesses.
*/
static inline int in_8(const volatile unsigned char __iomem *addr)
{
^ permalink raw reply
* Re: [PATCH]: powerpc: clarify use of twi/isync in io macros
From: Segher Boessenkool @ 2006-09-19 20:30 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Stephen Rothwell, paulus, ppc-dev
In-Reply-To: <20060919201053.GP29167@austin.ibm.com>
> My moral fiber did twinge before I hit the send button,
> but I confused it with a muscle spasm.
Heh.
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
The other way around, or change mine to a From: -- you took my
stuff, not the other way around. Oh well, doesn't matter as
far as I'm concerned. Some people think that keeping the chain
in the correct order is very important though. Let's just say
it was a cooperative work and fool them all :-)
Segher
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: David H. Lynch Jr. @ 2006-09-19 20:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609191310l240d9f94tb18415941f8b5d4f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
Grant Likely wrote:
>
>
> Avast! After getting quizzed on IRC about this off-the-cuff comment,
> I should probably clarify. Since the Xilinx IP could be wired up to a
> ublaze core or an off-chip processor, the drivers still need to use a
> platform bus attachment to keep it all cross platform.
>
> So, replace above comment with the following:
>
> Populating the platform device with static code during initialization
> is sooo last year.
>
> Time to hack device trees to populate it instead.
>
So I got another X V4 board. I hacked in the Platform device stuff
from you ml403 code with changes needed for my hardware.
and my brain is slowly begining to actually grasp what is going on
- I am begining to grasp the platform devices big picture (over a
mountain through a spyglass in the fog)
Where do I begin with Device Trees ?
The vague Picture I have is the have something to do with some
datastructure that Mac's typically create at or prior to boot. And that
for embedded systems we are building them
externally compiling them and then attaching the compiled device
tree to our project.
I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC,
Flash and Keyhole (pseuodo serial host interface). Of those it is only
certain that the flash will always be there.
We have bit images with Keyhole only, Uartlite only TEMAC only,
Sometimes we have a Pic sometimes not. I was trying to get to the point
were I could dynamically add what was there
to Platform devices during initialization.
If Device trees are static, then do they even apply to what I have
to deal with ?
Please pardon my ignorance.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 2866 bytes --]
^ 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