* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Peter Ryser @ 2006-06-01 17:05 UTC (permalink / raw)
To: Aidan Williams; +Cc: Anantharaman Chetan-W16155, linuxppc-embedded
In-Reply-To: <447E1725.4010908@nicta.com.au>
There are some silicon issues on the PPC405 in V4 with PVR 0x20011430=20
which are documented in Xilinx solution record 20658. All these issues=20
are fixed in silicon where the PPC405 has a PVR of 0x20011470.
Said that it's not true that the caches cannot be used in silicon with=20
PVR 0x20011430. The problem is a corner case which does not show in=20
typical designs.
- Peter
Aidan Williams wrote:
>Anantharaman Chetan-W16155 wrote:
> =20
>
>>Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4=20
>>FX series FPGA=92s, PPC405 processor?
>>
>> =20
>>
>
>Yes, see=20
>http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022583.html
>
>Note that there are silicon bugs that prevent caches being used in some=20
>chips.
>
> =20
>
>>More specifically, the FX100 FPGA?
>> =20
>>
>
>I don't have one of those, sorry.
>
>- aidan
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> =20
>
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Grant Likely @ 2006-06-01 17:08 UTC (permalink / raw)
To: Peter Ryser; +Cc: Anantharaman Chetan-W16155, linuxppc-embedded
In-Reply-To: <447F1E48.10808@xilinx.com>
On 6/1/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
> There are some silicon issues on the PPC405 in V4 with PVR 0x20011430
> which are documented in Xilinx solution record 20658. All these issues
> are fixed in silicon where the PPC405 has a PVR of 0x20011470.
>
> Said that it's not true that the caches cannot be used in silicon with
> PVR 0x20011430. The problem is a corner case which does not show in
> typical designs.
If I understand correctly, the cache issue only shows up with RAM
attached to the OPB (instead of PLB). Is that correct?
Cheers,
g.
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Peter Ryser @ 2006-06-01 16:59 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E8@de01exm68.ds.mot.com>
We have Linux up and running on the Virtex-4 FX100. The PVR for the
PPC405 in all FX100 is 0x20011470.
- Peter
Anantharaman Chetan-W16155 wrote:
>Was the port done on a FX100 FPGA? Also, what PVR number does the PPC405
>indicate?
>Thanks,
>Chetan
>
>-----Original Message-----
>From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant
>Likely
>Sent: Wednesday, May 31, 2006 2:35 PM
>To: Anantharaman Chetan-W16155
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
>
>On 5/31/06, Anantharaman Chetan-W16155
><Chetan.S.Anantharaman@motorola.com> wrote:
>
>
>>Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
>>
>>
>FX
>
>
>>series FPGA's, PPC405 processor?
>>
>>
>
>Linux on the V4-FX is well supported. Xilinx has an app node
>describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
>You can find out how to get the tree here:
>
>http://www.penguinppc.org/kernel/
>I've got both 2.4 & 2.6 happily running on my ML403 board here.
>
>Cheers,
>g.
>
>
>
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Peter Ryser @ 2006-06-01 18:03 UTC (permalink / raw)
To: Grant Likely; +Cc: Anantharaman Chetan-W16155, linuxppc-embedded
In-Reply-To: <528646bc0606011008o35096b43p42cc6aa9c0002f8c@mail.gmail.com>
It's a little bit more complicated than that but your statement is
basically correct.
- Peter
Grant Likely wrote:
> On 6/1/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
>
>> There are some silicon issues on the PPC405 in V4 with PVR 0x20011430
>> which are documented in Xilinx solution record 20658. All these issues
>> are fixed in silicon where the PPC405 has a PVR of 0x20011470.
>>
>> Said that it's not true that the caches cannot be used in silicon with
>> PVR 0x20011430. The problem is a corner case which does not show in
>> typical designs.
>
>
> If I understand correctly, the cache issue only shows up with RAM
> attached to the OPB (instead of PLB). Is that correct?
>
> Cheers,
> g.
>
>
^ permalink raw reply
* Re: [PATCH] use msleep() for RTAS delays
From: Arnd Bergmann @ 2006-06-01 18:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <17534.32164.268580.217501@cargo.ozlabs.ibm.com>
On Thursday 01 June 2006 07:39, Paul Mackerras wrote:
>
> > rtas_call_waitbusy(...);
>
> That's a good idea...
Do we also need an atomic version of that? Maybe there are
places where we actually need to call a slow rtas call
under a spinlock.
At the very least, rtas_call_waitbusy() should have a
might_sleep() in it to find those places.
Arnd <><
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Arnd Bergmann @ 2006-06-01 18:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <1149139576.28307.28.camel@localhost.localdomain>
On Thursday 01 June 2006 07:26, Benjamin Herrenschmidt wrote:
>=20
> > We need to get a timestamp before and after the call. =A0mftb should do
> > the trick. =A0Also, I'd prefer to have the code that stuffs the values
> > into the array be C. =A0So, the decision is to have the assembly code
> > call out to the C routine -OR- create wrappers for the assembly routine=
s.
> > I much prefer C wrappers to touching the assembly.
>=20
> Argh... yet another use of mftb for which I'll need a cell specific
> workaround=20
I guess for statistics, we should rather avoid that overhead (and
document the fact that we did on purpose).
How fast is mftb really? Would that be significant compared to the
time spent in a fast hcall?
Arnd <><
^ permalink raw reply
* Pinned TLB entries with 2.6 linux kernel on PPC4xx
From: Chris Dumoulin @ 2006-06-01 19:29 UTC (permalink / raw)
To: linuxppc-embedded
Does the idea of creating pinned TLB entries (ones that will never be
overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux
kernel? If so, how would this be accomplished?
Regards,
Chris
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: Pinned TLB entries with 2.6 linux kernel on PPC4xx
From: Eugene Surovegin @ 2006-06-01 19:51 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <447F4021.5030109@ics-ltd.com>
On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote:
> Does the idea of creating pinned TLB entries (ones that will never be
> overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux
> kernel? If so, how would this be accomplished?
44x kernel already pins some TLB entries, 40x may use this approach to
increase performance (I use this in my internal 2.4 tree
quite successfully).
Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support
for 40x, you can look at the implementation there.
--
Eugene
^ permalink raw reply
* Re: memset hangs part way through; called from early_init
From: Wolfgang Denk @ 2006-06-01 20:32 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <200606011700.k51H0WJw014425@www-webmail1.magma.ca>
In message <200606011700.k51H0WJw014425@www-webmail1.magma.ca> you wrote:
>
> Currently, the board hangs in the early_init function. Specifically, at the following line:
> memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
...
> Any ideas would be appreciated.
See http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A princess should not be afraid -- not with a brave knight to protect
her.
-- McCoy, "Shore Leave", stardate 3025.3
^ permalink raw reply
* Re: Pinned TLB entries with 2.6 linux kernel on PPC4xx
From: Matt Porter @ 2006-06-01 20:53 UTC (permalink / raw)
To: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <20060601195129.GA15262@gate.ebshome.net>
On Thu, Jun 01, 2006 at 12:51:29PM -0700, Eugene Surovegin wrote:
> On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote:
> > Does the idea of creating pinned TLB entries (ones that will never be
> > overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux
> > kernel? If so, how would this be accomplished?
>
> 44x kernel already pins some TLB entries, 40x may use this approach to
> increase performance (I use this in my internal 2.4 tree
> quite successfully).
>
> Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support
> for 40x, you can look at the implementation there.
The partial kernel lowmem pinning for ppc405 was deprecated in favor
of having all of kernel lowmem covered by large pages and then large
TLBs loaded on tlb misses. This is regarding 2.6, of course.
It can also be extended to handle arbitrary areas other than kernel
lowmem.
-Matt
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Alexandre Bounine @ 2006-06-01 20:45 UTC (permalink / raw)
To: Kumar Gala, Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, linuxppc-dev list
All differences in the Tsi108/109 PIC code from the standard MPIC are =
caused by the HW behavior. The Tsi108/109 PIC looks like standard =
OpenPIC but, in fact, is different in registers mapping and behavior. =
Its logic is close but not exactly as MPIC. =20
Here are replies on comments to the code:
1.Why do you have to check if its a LEVEL irq?
Check for LEVEL irqs is required in the ack/end pair to enable nested =
interrupt servicing and
does not hang when core (local) interrupts are re-enabled in the ISR. =
Otherwise we have to use=20
SA_INTERRUPT flag for all level signaled interrupts.
2. if the PIC works like other openpic's you dont need an 'ack' we =20
handle it via 'end'
Tsi108/109 needs it.
3. why the changes to where we do mpic_eoi for TSI108?
The Tsi108 PIC requires EOI for spurious interrupt (as all other =
interrupt sources).
The do_IRQ() does not call end routine for spurious interrupts. =20
The MPIC code patch for Tsi108/109 demonstrates HW differences and why =
we originally considered having separate code for Tsi108 pic.
Regards,
Alex.
=20
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, May 30, 2006 3:18 PM
To: Zang Roy-r61911
Cc: Benjamin Herrenschmidt; linuxppc-dev list; Yang Xin-Xin-r48390; Paul
Mackerras; Alexandre Bounine
Subject: Re: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
On May 29, 2006, at 10:28 PM, Zang Roy-r61911 wrote:
>>
>> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
>>> Add Tundra Semiconductor tsi108 host bridge interrupt
>> controller support.
>>
>> It looks a bit like an hacked up MPIC... Is it different
>> enough to justify a separate driver ? Or would it be possible
>> to define a TSI108 flag to pass the current mpic driver and
>> add the necessary bits to it ?
>>
>
> Tsi108 implementation of MPIC has many differences form the =20
> original one, the following
> code implements it with mpic. Any comment? The following patch is =20
> just based on
> my previous send out patches.
In the future please provide it against the base, much easier to read.
> Integrate Tundra Semiconductor tsi108 host bridge interrupt controller
> to mpic arch.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
>
[snip]
>
> --- linux-2.6.17-rc4-tun/arch/powerpc/sysdev/mpic.c 2006-03-20 =20
> 00:53:29.000000000 -0500
> +++ linux-2.6.17-rc4-hpc2/arch/powerpc/sysdev/mpic.c 2006-05-29 =20
> 16:07:03.000000000 -0400
> @@ -81,7 +81,7 @@ static inline void _mpic_write(unsigned
> static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
> {
> unsigned int be =3D (mpic->flags & MPIC_BIG_ENDIAN) !=3D 0;
> - unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * =20
> MPIC_GREG_IPI_STRIDE);
>
> if (mpic->flags & MPIC_BROKEN_IPI)
> be =3D !be;
> @@ -90,7 +90,7 @@ static inline u32 _mpic_ipi_read(struct
>
> static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int =20
> ipi, u32 value)
> {
> - unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * =20
> MPIC_GREG_IPI_STRIDE);
>
> _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset, =20
> value);
> }
> @@ -393,7 +393,11 @@ static inline struct mpic * mpic_from_ir
> static inline void mpic_eoi(struct mpic *mpic)
> {
> mpic_cpu_write(MPIC_CPU_EOI, 0);
> +#ifndef CONFIG_TSI108_BRIDGE
> (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
> +#else
> + (void)mpic_cpu_read(MPIC_CPU_OUTPUT);
> +#endif
> }
>
> #ifdef CONFIG_SMP
> @@ -514,9 +518,26 @@ static void mpic_end_irq(unsigned int ir
> }
> #endif /* CONFIG_MPIC_BROKEN_U3 */
>
> +#ifdef CONFIG_TSI108_BRIDGE
> + if ((irq_desc[irq].status & IRQ_LEVEL) !=3D 0)
> +#endif
Why do you have to check if its a LEVEL irq?
> mpic_eoi(mpic);
> }
>
> +#ifdef CONFIG_TSI108_BRIDGE
> +static void mpic_ack_irq(unsigned int irq)
> +{
> + struct mpic *mpic =3D mpic_from_irq(irq);
> +
> +#ifdef DEBUG_IRQ
> + DBG("%s: ack_irq: %d\n", mpic->name, irq);
> +#endif
> +
> + if ((irq_desc[irq].status & IRQ_LEVEL) =3D=3D 0)
> + mpic_eoi(mpic);
> +}
> +#endif /* CONFIG_TSI108_BRIDGE */
> +
if the PIC works like other openpic's you dont need an 'ack' we =20
handle it via 'end'
> #ifdef CONFIG_SMP
>
> static void mpic_enable_ipi(unsigned int irq)
> @@ -596,6 +617,9 @@ struct mpic * __init mpic_alloc(unsigned
> mpic->hc_irq.enable =3D mpic_enable_irq;
> mpic->hc_irq.disable =3D mpic_disable_irq;
> mpic->hc_irq.end =3D mpic_end_irq;
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic->hc_irq.ack =3D mpic_ack_irq;
> +#endif
> if (flags & MPIC_PRIMARY)
> mpic->hc_irq.set_affinity =3D mpic_set_affinity;
> #ifdef CONFIG_SMP
> @@ -955,8 +979,13 @@ void mpic_send_ipi(unsigned int ipi_no,
> DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
> #endif
>
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
> mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#else /* CONFIG_TSI108_BRIDGE */
> + mpic_write(mpic->gregs, MPIC_CPU_IPI_DISPATCH,
> + mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#endif /* !CONFIG_TSI108_BRIDGE */
> }
>
> int mpic_get_one_irq(struct mpic *mpic, struct pt_regs *regs)
> @@ -972,11 +1001,20 @@ int mpic_get_one_irq(struct mpic *mpic,
> DBG("%s: cascading ...\n", mpic->name);
> #endif
> irq =3D mpic->cascade(regs, mpic->cascade_data);
> +#ifdef DEBUG_LOW
> + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> +#endif
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_eoi(mpic);
> +#endif
> return irq;
> }
> - if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS))
> + if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS)) {
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic_eoi(mpic);
> +#endif
> return -1;
> + }
why the changes to where we do mpic_eoi for TSI108?
> if (irq < MPIC_VEC_IPI_0) {
> #ifdef DEBUG_IRQ
> DBG("%s: irq %d\n", mpic->name, irq + mpic->irq_offset);
[snip]
^ permalink raw reply
* Re: [PATCH] yaboot: enable boot from iscsi target via ethernet devices on js20.
From: Doug Maxey @ 2006-06-01 20:56 UTC (permalink / raw)
Cc: yaboot-devel, Linux PowerPC List
In-Reply-To: <200605162040.k4GKeUsY007712@falcon10.austin.ibm.com>
On Tue, 16 May 2006 15:40:30 CDT, Doug Maxey wrote:
>
>On Tue, 16 May 2006 16:20:47 EDT, Paul Nasrat wrote:
>>On Fri, 2006-04-28 at 01:05 -0500, Doug Maxey wrote:
>>> Certain levels of JS20 firmware will allow the system to boot from an
>>> iscsi target. System OFW accomplishes this by setting up a virtual
>>> disk device with parameters. These parameters, when passed back to
>>> OFW by yaboot, directs the FW to use virtual device over the ethernet
>>> port that will then access iscsi target as a block device. This patch
>>> extracts those parameters from the property of the virtual device and
>>> passes them back to OFW to indicate the kernel is to be retrieved via
>>> the iscsi protocol.
>>>
>>> Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
>>
>>Sorry for the delay in getting back to you - a few initial questions:
>
>np. been on vacation the last 10 days. Switzerland is nice, and Milan
>is cool. :)
>
>>
>>> diff --git a/second/file.c b/second/file.c
>>
>>> @@ -185,16 +188,45 @@ parse_device_path(char *imagepath, char
>>>
>>> if (!imagepath)
>>> return 0;
>>> +
>>> + /*
>>> + * Do preliminary checking for an iscsi device; it may appear as
>>> + * pure a network device (device_type == "network") if this is
>>> + * ISWI. This is the case on IBM systems doing an iscsi OFW
>>> + * boot.
>>> + */
>>> + if (strstr(imagepath, ",iscsi"))
>>
>>Is the , always guaranteed to be there - eg if I have boot
>>eth1:iscsi,ISCSIARGS won't this check fail.
>
>Yes, with the above command line this would fail.
>
>My point of reference are the bindings that we cannot yet talk about
>here, yet. The device args would always be followed by a comma. I suppose
>that we could just reference the string "iscsi", but then some wag
>would want to create some other property that included "iscsi" as a
>substring. Maybe append a comma?
Any preferences on this?
I have another, more radical solution.
Adding a parser that understands the full device path and that can
return the elements neatly packaged. Film at 11.
>
>
>>
>>> diff --git a/second/prom.c b/second/prom.c
>>> index 5ec06b8..9bc5415 100644
>>> --- a/second/prom.c
>>> +++ b/second/prom.c
>>> @@ -174,6 +174,9 @@ prom_get_devtype (char *device)
>>> int result;
>>> char tmp[64];
>>>
>>> + if (strstr(device, ",iscsi"))
>>> + device = strcpy(tmp, "/vdevice/gscsi/disk");
>>> +
>>
>>Ditto here.
>
>likewise. Maybe make it a #define so it would be common.
>
>>
>>Paul
>>
++doug
^ permalink raw reply
* SII3124-2
From: Rune Torgersen @ 2006-06-01 21:10 UTC (permalink / raw)
To: linuxppc-dev
Has anybody been successful in getting a SII3124-2 based SATA controller
to work under PPC?
I have a eval board that I tried on two different freescale boards (a
MPC8266ADS board and a MPC8560ADS board).
Kernel 2.6.16.16.
Here is the relevant output from the kernel.
ata1: SATA max UDMA/100 cmd 0xD1010000 ctl 0x0 bmdma 0x0 irq 115
ata2: SATA max UDMA/100 cmd 0xD1012000 ctl 0x0 bmdma 0x0 irq 115
ata3: SATA max UDMA/100 cmd 0xD1014000 ctl 0x0 bmdma 0x0 irq 115
ata4: SATA max UDMA/100 cmd 0xD1016000 ctl 0x0 bmdma 0x0 irq 115
ata1: SATA link down (SStatus 0)
scsi0 : sata_sil24
ata2: SATA link up 3.0 Gbps (SStatus 123)
sata_sil24 ata2: SRST failed, disabling port
scsi1 : sata_sil24
ata3: SATA link down (SStatus 0)
scsi2 : sata_sil24
ata4: SATA link down (SStatus 0)
scsi3 : sata_sil24
I added debug output to see the content of the Command Error register.
It is set to 26 which according to the datasheet for the 3124-1 (I am
running a -2), is PLDCMDERRORMASTERABORT, "A PCI Master Abort occurred
while the SiI3124 was fetching a Port Request Block (PRB) from host
memory."
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Benjamin Herrenschmidt @ 2006-06-01 21:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200606012014.20467.arnd.bergmann@de.ibm.com>
On Thu, 2006-06-01 at 20:14 +0200, Arnd Bergmann wrote:
> On Thursday 01 June 2006 07:26, Benjamin Herrenschmidt wrote:
> >
> > > We need to get a timestamp before and after the call. mftb should do
> > > the trick. Also, I'd prefer to have the code that stuffs the values
> > > into the array be C. So, the decision is to have the assembly code
> > > call out to the C routine -OR- create wrappers for the assembly routines.
> > > I much prefer C wrappers to touching the assembly.
> >
> > Argh... yet another use of mftb for which I'll need a cell specific
> > workaround
>
> I guess for statistics, we should rather avoid that overhead (and
> document the fact that we did on purpose).
Well.. if we can at one point "detect" the totally bogus value (the
timestamp going massively backward) and fix it up there, ok. Might be an
option.
> How fast is mftb really? Would that be significant compared to the
> time spent in a fast hcall?
Not sure, I would expect a few dozens cycles at least though...
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Benjamin Herrenschmidt @ 2006-06-01 22:06 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <8A1F97E8A7ACE847B1DB69DFDCBC6E807D633A@caribou.pc.tundra.com>
On Thu, 2006-06-01 at 16:45 -0400, Alexandre Bounine wrote:
> All differences in the Tsi108/109 PIC code from the standard MPIC are caused by the HW behavior. The Tsi108/109 PIC looks like standard OpenPIC but, in fact, is different in registers mapping and behavior. Its logic is close but not exactly as MPIC.
>
> Here are replies on comments to the code:
>
> 1.Why do you have to check if its a LEVEL irq?
>
> Check for LEVEL irqs is required in the ack/end pair to enable nested interrupt servicing and
> does not hang when core (local) interrupts are re-enabled in the ISR. Otherwise we have to use
> SA_INTERRUPT flag for all level signaled interrupts.
Can you be more precise about what exactly happens and why ? Unless you
EOI handling is broken of course, there should be no need to do anything
other than a single eoi in end(), period.
> 2. if the PIC works like other openpic's you dont need an 'ack' we
> handle it via 'end'
>
> Tsi108/109 needs it.
What for ? Please, give the low level details.
> 3. why the changes to where we do mpic_eoi for TSI108?
> The Tsi108 PIC requires EOI for spurious interrupt (as all other interrupt sources).
Ok, that is acceptable.
> The do_IRQ() does not call end routine for spurious interrupts.
>
> The MPIC code patch for Tsi108/109 demonstrates HW differences and why we originally considered having separate code for Tsi108 pic.
Please tell me more about the HW differences :)
Ben.
>
>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, May 30, 2006 3:18 PM
> To: Zang Roy-r61911
> Cc: Benjamin Herrenschmidt; linuxppc-dev list; Yang Xin-Xin-r48390; Paul
> Mackerras; Alexandre Bounine
> Subject: Re: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
>
>
>
> On May 29, 2006, at 10:28 PM, Zang Roy-r61911 wrote:
>
> >>
> >> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
> >>> Add Tundra Semiconductor tsi108 host bridge interrupt
> >> controller support.
> >>
> >> It looks a bit like an hacked up MPIC... Is it different
> >> enough to justify a separate driver ? Or would it be possible
> >> to define a TSI108 flag to pass the current mpic driver and
> >> add the necessary bits to it ?
> >>
> >
> > Tsi108 implementation of MPIC has many differences form the
> > original one, the following
> > code implements it with mpic. Any comment? The following patch is
> > just based on
> > my previous send out patches.
>
> In the future please provide it against the base, much easier to read.
>
> > Integrate Tundra Semiconductor tsi108 host bridge interrupt controller
> > to mpic arch.
> >
> > Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> >
>
> [snip]
>
> >
> > --- linux-2.6.17-rc4-tun/arch/powerpc/sysdev/mpic.c 2006-03-20
> > 00:53:29.000000000 -0500
> > +++ linux-2.6.17-rc4-hpc2/arch/powerpc/sysdev/mpic.c 2006-05-29
> > 16:07:03.000000000 -0400
> > @@ -81,7 +81,7 @@ static inline void _mpic_write(unsigned
> > static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
> > {
> > unsigned int be = (mpic->flags & MPIC_BIG_ENDIAN) != 0;
> > - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> > + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> > MPIC_GREG_IPI_STRIDE);
> >
> > if (mpic->flags & MPIC_BROKEN_IPI)
> > be = !be;
> > @@ -90,7 +90,7 @@ static inline u32 _mpic_ipi_read(struct
> >
> > static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int
> > ipi, u32 value)
> > {
> > - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> > + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> > MPIC_GREG_IPI_STRIDE);
> >
> > _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset,
> > value);
> > }
> > @@ -393,7 +393,11 @@ static inline struct mpic * mpic_from_ir
> > static inline void mpic_eoi(struct mpic *mpic)
> > {
> > mpic_cpu_write(MPIC_CPU_EOI, 0);
> > +#ifndef CONFIG_TSI108_BRIDGE
> > (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
> > +#else
> > + (void)mpic_cpu_read(MPIC_CPU_OUTPUT);
> > +#endif
> > }
> >
> > #ifdef CONFIG_SMP
> > @@ -514,9 +518,26 @@ static void mpic_end_irq(unsigned int ir
> > }
> > #endif /* CONFIG_MPIC_BROKEN_U3 */
> >
> > +#ifdef CONFIG_TSI108_BRIDGE
> > + if ((irq_desc[irq].status & IRQ_LEVEL) != 0)
> > +#endif
>
> Why do you have to check if its a LEVEL irq?
>
> > mpic_eoi(mpic);
> > }
> >
> > +#ifdef CONFIG_TSI108_BRIDGE
> > +static void mpic_ack_irq(unsigned int irq)
> > +{
> > + struct mpic *mpic = mpic_from_irq(irq);
> > +
> > +#ifdef DEBUG_IRQ
> > + DBG("%s: ack_irq: %d\n", mpic->name, irq);
> > +#endif
> > +
> > + if ((irq_desc[irq].status & IRQ_LEVEL) == 0)
> > + mpic_eoi(mpic);
> > +}
> > +#endif /* CONFIG_TSI108_BRIDGE */
> > +
>
> if the PIC works like other openpic's you dont need an 'ack' we
> handle it via 'end'
>
> > #ifdef CONFIG_SMP
> >
> > static void mpic_enable_ipi(unsigned int irq)
> > @@ -596,6 +617,9 @@ struct mpic * __init mpic_alloc(unsigned
> > mpic->hc_irq.enable = mpic_enable_irq;
> > mpic->hc_irq.disable = mpic_disable_irq;
> > mpic->hc_irq.end = mpic_end_irq;
> > +#ifdef CONFIG_TSI108_BRIDGE
> > + mpic->hc_irq.ack = mpic_ack_irq;
> > +#endif
> > if (flags & MPIC_PRIMARY)
> > mpic->hc_irq.set_affinity = mpic_set_affinity;
> > #ifdef CONFIG_SMP
> > @@ -955,8 +979,13 @@ void mpic_send_ipi(unsigned int ipi_no,
> > DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
> > #endif
> >
> > +#ifndef CONFIG_TSI108_BRIDGE
> > mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
> > mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> > +#else /* CONFIG_TSI108_BRIDGE */
> > + mpic_write(mpic->gregs, MPIC_CPU_IPI_DISPATCH,
> > + mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> > +#endif /* !CONFIG_TSI108_BRIDGE */
> > }
> >
> > int mpic_get_one_irq(struct mpic *mpic, struct pt_regs *regs)
> > @@ -972,11 +1001,20 @@ int mpic_get_one_irq(struct mpic *mpic,
> > DBG("%s: cascading ...\n", mpic->name);
> > #endif
> > irq = mpic->cascade(regs, mpic->cascade_data);
> > +#ifdef DEBUG_LOW
> > + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> > +#endif
> > +#ifndef CONFIG_TSI108_BRIDGE
> > mpic_eoi(mpic);
> > +#endif
> > return irq;
> > }
> > - if (unlikely(irq == MPIC_VEC_SPURRIOUS))
> > + if (unlikely(irq == MPIC_VEC_SPURRIOUS)) {
> > +#ifdef CONFIG_TSI108_BRIDGE
> > + mpic_eoi(mpic);
> > +#endif
> > return -1;
> > + }
>
> why the changes to where we do mpic_eoi for TSI108?
>
> > if (irq < MPIC_VEC_IPI_0) {
> > #ifdef DEBUG_IRQ
> > DBG("%s: irq %d\n", mpic->name, irq + mpic->irq_offset);
>
>
>
> [snip]
^ permalink raw reply
* Re: [PATCH] use msleep() for RTAS delays
From: John Rose @ 2006-06-01 22:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: External List, Paul Mackerras
In-Reply-To: <1149177349.9812.16.camel@sinatra.austin.ibm.com>
> I don't mind writing this up. The previous patch fixes a reported bug
> with minimal reorg. If possible, I'd like to restructure on top of
> that.
On second thought, why not reorg now! I'll have a patch shortly.
Thanks-
John
^ permalink raw reply
* How to find out what a process has been doing on a PPC-440 system
From: Kallol Biswas @ 2006-06-02 0:36 UTC (permalink / raw)
To: External List
Hi,
I have a list of processes running in a linux system (2.6.11 kernel).
One of the processes invokes send() system call and does not return.
The command "ps" shows that the process is in "RUNNING" state. With an ICE
I could dump each process structures and all the fields, but can't find a way to get the stack trace for each process. Not sure how contexts are saved on ppc-4xx kernel. It seems that they are saved in kernel stack. How do we
get the top of the stack from the task_struct pointers? How to find out
where in kernel send() blocks (not sleeping/scheduled)?
Kallol
^ permalink raw reply
* RE: How to find out what a process has been doing on a PPC-440 sy stem
From: Kallol Biswas @ 2006-06-02 0:47 UTC (permalink / raw)
To: Kallol Biswas, External List
I think reading the .*switch() macros/functions we can get the answers.
-----Original Message-----
From: linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org [mailto:linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org] On Behalf Of Kallol Biswas
Sent: Thursday, June 01, 2006 5:36 PM
To: External List
Subject: How to find out what a process has been doing on a PPC-440 system
Hi,
I have a list of processes running in a linux system (2.6.11 kernel).
One of the processes invokes send() system call and does not return.
The command "ps" shows that the process is in "RUNNING" state. With an ICE
I could dump each process structures and all the fields, but can't find a way to get the stack trace for each process. Not sure how contexts are saved on ppc-4xx kernel. It seems that they are saved in kernel stack. How do we
get the top of the stack from the task_struct pointers? How to find out
where in kernel send() blocks (not sleeping/scheduled)?
Kallol
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: How to find out what a process has been doing on a PPC-440 sy stem
From: Kallol Biswas @ 2006-06-02 1:02 UTC (permalink / raw)
To: External List
There is a tsk->thread.ksp (kernel stack pointer) but tsk->thread.regs is null. Next job is to get the register values from the ksp. If anyone has done it before it will save me some time.
-----Original Message-----
From: Kallol Biswas
Sent: Thursday, June 01, 2006 5:47 PM
To: Kallol Biswas; External List
Subject: RE: How to find out what a process has been doing on a PPC-440 system
I think reading the .*switch() macros/functions we can get the answers.
-----Original Message-----
From: linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org [mailto:linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org] On Behalf Of Kallol Biswas
Sent: Thursday, June 01, 2006 5:36 PM
To: External List
Subject: How to find out what a process has been doing on a PPC-440 system
Hi,
I have a list of processes running in a linux system (2.6.11 kernel).
One of the processes invokes send() system call and does not return.
The command "ps" shows that the process is in "RUNNING" state. With an ICE
I could dump each process structures and all the fields, but can't find a way to get the stack trace for each process. Not sure how contexts are saved on ppc-4xx kernel. It seems that they are saved in kernel stack. How do we
get the top of the stack from the task_struct pointers? How to find out
where in kernel send() blocks (not sleeping/scheduled)?
Kallol
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: How to find out what a process has been doing on a PPC-440 sy stem
From: Kallol Biswas @ 2006-06-02 1:45 UTC (permalink / raw)
To: External List
>From ksp it is very easy to find all the register values. Just read _switch() macro.
-----Original Message-----
From: Kallol Biswas
Sent: Thursday, June 01, 2006 6:02 PM
To: 'External List'
Subject: RE: How to find out what a process has been doing on a PPC-440 system
There is a tsk->thread.ksp (kernel stack pointer) but tsk->thread.regs is null. Next job is to get the register values from the ksp. If anyone has done it before it will save me some time.
-----Original Message-----
From: Kallol Biswas
Sent: Thursday, June 01, 2006 5:47 PM
To: Kallol Biswas; External List
Subject: RE: How to find out what a process has been doing on a PPC-440 system
I think reading the .*switch() macros/functions we can get the answers.
-----Original Message-----
From: linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org [mailto:linuxppc-dev-bounces+biswaska=pmc-sierra.com@ozlabs.org] On Behalf Of Kallol Biswas
Sent: Thursday, June 01, 2006 5:36 PM
To: External List
Subject: How to find out what a process has been doing on a PPC-440 system
Hi,
I have a list of processes running in a linux system (2.6.11 kernel).
One of the processes invokes send() system call and does not return.
The command "ps" shows that the process is in "RUNNING" state. With an ICE
I could dump each process structures and all the fields, but can't find a way to get the stack trace for each process. Not sure how contexts are saved on ppc-4xx kernel. It seems that they are saved in kernel stack. How do we
get the top of the stack from the task_struct pointers? How to find out
where in kernel send() blocks (not sleeping/scheduled)?
Kallol
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* MPC85xx PCI transfer disconnect
From: Martin, Tim @ 2006-06-02 3:09 UTC (permalink / raw)
To: linuxppc-embedded
I know this is probably a question for Freescale directly, but I thought
I would post here to see if anyone else has seen similar issues with the
MPC85xx PCI under Linux.
I'm using a Freescale MPC85xx (8541) processor and seeing an extreme
slowness to the PCI bus.
I'm attemping to do 2048 byte PCI burst reads from an external PCI
master. So an external chip is the PCI master ("initiator") and the
MPC85xx is the PCI slave ("target")
When initiating the PCI burst read, there is a 270 ns delay from the
MPC85xx claiming the transaction (DEVSEL# going low) to being ready
(TRDY# going low). Then 64 bytes (a single cacheline) are transferred,
and TRDY# goes inactive. Next, STOP# goes low, terminating the
transfer. I believe this is considered a PCI DISCONNECT type 1 since
IRDY# is active the entire time.
What I would expect is that the entire 2048 bytes are transferred in one
PCI bus mastership, but instead there are several re-arbitrations and
long delays in between several 64 byte transfers.
Additional info:
The PCI bus is 64bit running at 66 MHz.
I'm running a modified Linux 2.6.9 kernel (elinos-111).
The PCI CCSR piwar1 =3D 0xa0f4401d.
Freescale has an FAQ 21021 that describes having a PCI DISCONNECT 2,
which sounds similar to my problem, but I've already confirmed I'm doing
what the FAQ suggests (enable prefetching in the piwar register)
(http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-21021.xml)
Any thoughts/suggestions would be appreciated,
Tim
^ permalink raw reply
* RE: MPC85xx PCI transfer disconnect
From: Liu Dave-r63238 @ 2006-06-02 3:52 UTC (permalink / raw)
To: 'Martin, Tim', linuxppc-embedded
> I know this is probably a question for Freescale directly,
> but I thought I would post here to see if anyone else has
> seen similar issues with the MPC85xx PCI under Linux.
>
> I'm using a Freescale MPC85xx (8541) processor and seeing an
> extreme slowness to the PCI bus.
>
> I'm attemping to do 2048 byte PCI burst reads from an
> external PCI master. So an external chip is the PCI master
> ("initiator") and the MPC85xx is the PCI slave ("target")
>
> When initiating the PCI burst read, there is a 270 ns delay
> from the MPC85xx claiming the transaction (DEVSEL# going low)
> to being ready (TRDY# going low). Then 64 bytes (a single
> cacheline) are transferred, and TRDY# goes inactive. Next,
> STOP# goes low, terminating the transfer. I believe this is
> considered a PCI DISCONNECT type 1 since IRDY# is active the
> entire time.
>
The 85xx cacheline is 32 bytes.
Did you enable Memory Read Multiple command of your PCI master?
> What I would expect is that the entire 2048 bytes are
> transferred in one PCI bus mastership, but instead there are
> several re-arbitrations and long delays in between several 64
> byte transfers.
>
> Additional info:
> The PCI bus is 64bit running at 66 MHz.
> I'm running a modified Linux 2.6.9 kernel (elinos-111).
> The PCI CCSR piwar1 = 0xa0f4401d.
>
> Freescale has an FAQ 21021 that describes having a PCI
> DISCONNECT 2, which sounds similar to my problem, but I've
> already confirmed I'm doing what the FAQ suggests (enable
> prefetching in the piwar register)
> (http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-2
1021.xml)
Any thoughts/suggestions would be appreciated,
Tim
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] [2.6.18] U4 DART improvements
From: Olof Johansson @ 2006-06-02 4:04 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
I've given this a good beating tonight, since I finally got a pci-e
ethernet card for the new g5 to do loopback with. Profiles looked good,
I think we're good to go for 2.6.18 with this, especially if it gets
in early for extra testing.
-Olof
---
Implement single-entry TLB invalidations in the U4 DART.
Simple benchmarking with loopback flood pings of various sizes show that
the previous flush-all code will spend ~5% of the time in flush, while
the new selective invalidations will spend about an order of magnitude
less in the same code path.
This could possibly mean that invalidations larger than, say, 16
entries would better be handled in bulk, but until we have a workload
that actually shows problems or bottlenecks let's keep doing single
invalidations at all mapping sizes.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/sysdev/dart.h b/arch/powerpc/sysdev/dart.h
index c2d0576..1c8817c 100644
Index: 2.6.17-rc5-git8/arch/powerpc/sysdev/dart.h
===================================================================
--- 2.6.17-rc5-git8.orig/arch/powerpc/sysdev/dart.h
+++ 2.6.17-rc5-git8/arch/powerpc/sysdev/dart.h
@@ -47,8 +47,12 @@
/* U4 registers */
#define DART_BASE_U4_BASE_MASK 0xffffff
#define DART_BASE_U4_BASE_SHIFT 0
-#define DART_CNTL_U4_FLUSHTLB 0x20000000
#define DART_CNTL_U4_ENABLE 0x80000000
+#define DART_CNTL_U4_IONE 0x40000000
+#define DART_CNTL_U4_FLUSHTLB 0x20000000
+#define DART_CNTL_U4_IDLE 0x10000000
+#define DART_CNTL_U4_PAR_EN 0x08000000
+#define DART_CNTL_U4_IONE_MASK 0x07ffffff
#define DART_SIZE_U4_SIZE_MASK 0x1fff
#define DART_SIZE_U4_SIZE_SHIFT 0
Index: 2.6.17-rc5-git8/arch/powerpc/sysdev/dart_iommu.c
===================================================================
--- 2.6.17-rc5-git8.orig/arch/powerpc/sysdev/dart_iommu.c
+++ 2.6.17-rc5-git8/arch/powerpc/sysdev/dart_iommu.c
@@ -101,8 +101,8 @@ retry:
if (l == (1L << limit)) {
if (limit < 4) {
limit++;
- reg = DART_IN(DART_CNTL);
- reg &= ~inv_bit;
+ reg = DART_IN(DART_CNTL);
+ reg &= ~inv_bit;
DART_OUT(DART_CNTL, reg);
goto retry;
} else
@@ -111,11 +111,40 @@ retry:
}
}
+static inline void dart_tlb_invalidate_one(unsigned long bus_rpn)
+{
+ unsigned int reg;
+ unsigned int l, limit;
+
+ reg = DART_CNTL_U4_ENABLE | DART_CNTL_U4_IONE |
+ (bus_rpn & DART_CNTL_U4_IONE_MASK);
+ DART_OUT(DART_CNTL, reg);
+ mb();
+
+ limit = 0;
+wait_more:
+ l = 0;
+ while ((DART_IN(DART_CNTL) & DART_CNTL_U4_IONE) && l < (1L << limit)) {
+ rmb();
+ l++;
+ }
+
+ if (l == (1L << limit)) {
+ if (limit < 4) {
+ limit++;
+ goto wait_more;
+ } else
+ panic("DART: TLB did not flush after waiting a long "
+ "time. Buggy U4 ?");
+ }
+}
+
static void dart_flush(struct iommu_table *tbl)
{
- if (dart_dirty)
+ if (dart_dirty) {
dart_tlb_invalidate_all();
- dart_dirty = 0;
+ dart_dirty = 0;
+ }
}
static void dart_build(struct iommu_table *tbl, long index,
@@ -124,6 +153,7 @@ static void dart_build(struct iommu_tabl
{
unsigned int *dp;
unsigned int rpn;
+ long l;
DBG("dart: build at: %lx, %lx, addr: %x\n", index, npages, uaddr);
@@ -135,7 +165,8 @@ static void dart_build(struct iommu_tabl
/* On U3, all memory is contigous, so we can move this
* out of the loop.
*/
- while (npages--) {
+ l = npages;
+ while (l--) {
rpn = virt_to_abs(uaddr) >> DART_PAGE_SHIFT;
*(dp++) = DARTMAP_VALID | (rpn & DARTMAP_RPNMASK);
@@ -143,7 +174,14 @@ static void dart_build(struct iommu_tabl
uaddr += DART_PAGE_SIZE;
}
- dart_dirty = 1;
+ if (dart_is_u4) {
+ rpn = index;
+ mb(); /* make sure all updates have reached memory */
+ while (npages--)
+ dart_tlb_invalidate_one(rpn++);
+ } else {
+ dart_dirty = 1;
+ }
}
^ permalink raw reply
* pSeries_mach_cpu_die() question
From: Benjamin Herrenschmidt @ 2006-06-02 5:16 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Nathan Lynch
While doing some autumn cleaning of the irq stuff in general and xics
specifically, I found out that
the low level pSeriesLP_cppr_info() is exported because
pSeries_mach_cpu_die() calls it:
static void pSeries_mach_cpu_die(void)
{
local_irq_disable();
idle_task_exit();
/* Some hardware requires clearing the CPPR, while other hardware does
not
* it is safe either way
*/
pSeriesLP_cppr_info(0, 0);
rtas_stop_self();
/* Should never get here... */
BUG();
for(;;);
}
This leads to a few questions:
- We always pass "0" as the CPU. Is that right ? I seems not, but maybe
pHyp doesn't care and always assume the calling CPU ...
- xics has a xics_teardown_cpu() now, used by kexec, that does
something very similar except that it passes the proper CPU number, and
for secondary CPUs also does an EOI of any pending IPI (just in case). I
think that could be used instead of the direct call to the low level
pSeriesLP_* funciton (which I itend to unexport and rename anyway as
part of my rework). Can whoever knows that code confirm ?
- There is a comment about "some hardware....", what does it mean ? Is
it ok to do it unconditionally ? I suppose so but heh...
Cheers,
Ben.
^ permalink raw reply
* Re: pSeries_mach_cpu_die() question
From: Nathan Lynch @ 2006-06-02 6:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Nathan Lynch
In-Reply-To: <1149225392.16202.52.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> While doing some autumn cleaning of the irq stuff in general and xics
> specifically, I found out that
> the low level pSeriesLP_cppr_info() is exported because
> pSeries_mach_cpu_die() calls it:
>
> static void pSeries_mach_cpu_die(void)
> {
> local_irq_disable();
> idle_task_exit();
> /* Some hardware requires clearing the CPPR, while other hardware does
> not
> * it is safe either way
> */
> pSeriesLP_cppr_info(0, 0);
> rtas_stop_self();
> /* Should never get here... */
> BUG();
> for(;;);
> }
>
> This leads to a few questions:
>
> - We always pass "0" as the CPU. Is that right ? I seems not, but maybe
> pHyp doesn't care and always assume the calling CPU ...
The cpu parameter is actually unused by in the lpar case:
void pSeriesLP_cppr_info(int n_cpu, u8 value)
{
unsigned long lpar_rc;
lpar_rc = plpar_cppr(value);
if (lpar_rc != H_SUCCESS)
panic("bad return code cppr - rc = %lx\n", lpar_rc);
}
> - xics has a xics_teardown_cpu() now, used by kexec, that does
> something very similar except that it passes the proper CPU number, and
> for secondary CPUs also does an EOI of any pending IPI (just in case). I
> think that could be used instead of the direct call to the low level
> pSeriesLP_* funciton (which I itend to unexport and rename anyway as
> part of my rework). Can whoever knows that code confirm ?
Sounds okay to me.
> - There is a comment about "some hardware....", what does it mean ? Is
> it ok to do it unconditionally ? I suppose so but heh...
The comment should be changed or removed really. We got away without
doing plpar_cppr() on the Power4 hypervisor but we found out it was
necessary when testing Power5. I think it's required by the
architecture regardless, and yes, it's safe on both platforms.
^ 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