* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Liu Dave-r63238 @ 2006-06-02 8:33 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt', Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
> > I had hoped to get the pci configure base address by ioremap, but
> > failed. the tsi108 register locates at 0xc000,0000
> ~0xC001,0000. It is
> > OK to access them by ioremap. While pci configure access need to
> > ioremap 0xfb00,0000 ~0xfc00,0000. I traced my code, when I
> do ioremap,
> > there is no bat match, I get the virtual address from
> ioremap_bot. the
> > init ioremap_bot is 0xfe000000. When I do tsi108_csr_vir_base =
> > ioremap(0xfb000000,0x1000000), the ioremap_bot is
> 0xfdffe000 ( I get
> > the serial port ioremap steal some space), tsi108_csr_vir_base =
> > 0xfdfee000, I can not access the configure space with this address.
>
> What happens if you try ?
>
> > While if I use bat0 or bat1 to map my tsi108 register space, the
> > ioremap_bot will keep to 0xfe000000 until I do
> tsi108_csr_vir_base =
> > ioremap(0xfb000000,0x1000000) then I get tsi108_csr_vir_base =
> > 0xfd000000. Everything is OK.
>
> Both should work fine
>
> Ben.
>
The smallest BAT size of 74xx is 128KB, but the MPC7448_HPC2_NVRAM_SIZE
Is 0x8000 (32KB) you set in your code. I suggest you set the
MPC7448_HPC2_NVRAM_SIZE is 0x20000, try it.
Dave
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-06-02 8:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Liu Dave-r63238,
Alexandre.Bounine, Yang Xin-Xin-r48390
> How much RAM do you have ? Maybe you are running out of
> virtual space ?
>
> Ben.
>
>
512MBytes
Roy
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-06-02 8:19 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673066CF6DF@zch01exm40.ap.freescale.net>
On Fri, 2006-06-02 at 16:05 +0800, Zang Roy-r61911 wrote:
> > > If I really need to use bat0 or bat1( I see that the
> > general mmu use
> > > bat2 and bat3, where should I set up them?
> > >
> > > For tsi108 pci configuration access, I need to map 16Mbyte physical
> > > address. If I do not use an extra bat, I can not get the correct
> > > virtual address use ioremap.
> >
> > What do you mean ? An ioremap will work, it will give you any
> > virtual address, you just have to store that in a global
> > instead of hard coding it. Hard coded virtual addresses are
> > bad. Especially for things like PCI config space that really
> > isn't performance sensitive.
> >
> > Ben.
> >
>
> I had hoped to get the pci configure base address by ioremap, but failed.
> the tsi108 register locates at 0xc000,0000 ~0xC001,0000. It is OK to
> access them by ioremap. While pci configure access need to ioremap
> 0xfb00,0000 ~0xfc00,0000.
> I traced my code, when I do ioremap, there is no bat match, I get the virtual
> address from ioremap_bot. the init ioremap_bot is 0xfe000000. When I do
> tsi108_csr_vir_base = ioremap(0xfb000000,0x1000000),
> the ioremap_bot is 0xfdffe000 ( I get the serial port ioremap steal some space),
> tsi108_csr_vir_base = 0xfdfee000, I can not access the configure space with this
> address.
What happens if you try ?
> While if I use bat0 or bat1 to map my tsi108 register space, the ioremap_bot will keep
> to 0xfe000000 until I do
> tsi108_csr_vir_base = ioremap(0xfb000000,0x1000000)
> then I get tsi108_csr_vir_base = 0xfd000000. Everything is OK.
Both should work fine
Ben.
^ permalink raw reply
* Re: Recall: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-06-02 8:17 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673066CF61F@zch01exm40.ap.freescale.net>
On Fri, 2006-06-02 at 15:40 +0800, Zang Roy-r61911 wrote:
> Zang Roy-r61911 would like to recall the message, "[PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform".
Recalling of emails doesn't quite work :) Don't bother :)
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-06-02 8:17 UTC (permalink / raw)
To: Liu Dave-r63238
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673026FD937@zch01exm40.ap.freescale.net>
On Fri, 2006-06-02 at 15:38 +0800, Liu Dave-r63238 wrote:
> > > If I really need to use bat0 or bat1( I see that the
> > general mmu use
> > > bat2 and bat3,
> > > where should I set up them?
> > >
> > > For tsi108 pci configuration access, I need to map 16Mbyte
> > > physical address. If I do not use an extra bat, I can not
> > get the correct
> > > virtual address use ioremap.
> >
> > What do you mean ? An ioremap will work, it will give you any
> > virtual address, you just have to store that in a global
> > instead of hard coding it. Hard coded virtual addresses are
> > bad. Especially for things like PCI config space that really
> > isn't performance sensitive.
> >
>
> I agree ben about PCI config space, It should use ioremap
> to get virtual address. No performace indeed.
>
> I think we need find the root cause that the ioremap failed.
How much RAM do you have ? Maybe you are running out of virtual space ?
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-06-02 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> > If I really need to use bat0 or bat1( I see that the
> general mmu use
> > bat2 and bat3, where should I set up them?
> >
> > For tsi108 pci configuration access, I need to map 16Mbyte physical
> > address. If I do not use an extra bat, I can not get the correct
> > virtual address use ioremap.
>
> What do you mean ? An ioremap will work, it will give you any
> virtual address, you just have to store that in a global
> instead of hard coding it. Hard coded virtual addresses are
> bad. Especially for things like PCI config space that really
> isn't performance sensitive.
>
> Ben.
>
I had hoped to get the pci configure base address by ioremap, but failed.
the tsi108 register locates at 0xc000,0000 ~0xC001,0000. It is OK to
access them by ioremap. While pci configure access need to ioremap
0xfb00,0000 ~0xfc00,0000.
I traced my code, when I do ioremap, there is no bat match, I get the virtual
address from ioremap_bot. the init ioremap_bot is 0xfe000000. When I do
tsi108_csr_vir_base = ioremap(0xfb000000,0x1000000),
the ioremap_bot is 0xfdffe000 ( I get the serial port ioremap steal some space),
tsi108_csr_vir_base = 0xfdfee000, I can not access the configure space with this
address.
While if I use bat0 or bat1 to map my tsi108 register space, the ioremap_bot will keep
to 0xfe000000 until I do
tsi108_csr_vir_base = ioremap(0xfb000000,0x1000000)
then I get tsi108_csr_vir_base = 0xfd000000. Everything is OK.
Roy
^ permalink raw reply
* Recall: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-06-02 7:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
Zang Roy-r61911 would like to recall the message, "[PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform".
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-06-02 7:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
>
> > If I really need to use bat0 or bat1( I see that the
> general mmu use
> > bat2 and bat3, where should I set up them?
> >
> > For tsi108 pci configuration access, I need to map 16Mbyte physical
> > address. If I do not use an extra bat, I can not get the correct
> > virtual address use ioremap.
>
> What do you mean ? An ioremap will work, it will give you any
> virtual address, you just have to store that in a global
> instead of hard coding it. Hard coded virtual addresses are
> bad. Especially for things like PCI config space that really
> isn't performance sensitive.
>
> Ben.
>
>
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Liu Dave-r63238 @ 2006-06-02 7:38 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt', Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
> > If I really need to use bat0 or bat1( I see that the
> general mmu use
> > bat2 and bat3,
> > where should I set up them?
> >
> > For tsi108 pci configuration access, I need to map 16Mbyte
> > physical address. If I do not use an extra bat, I can not
> get the correct
> > virtual address use ioremap.
>
> What do you mean ? An ioremap will work, it will give you any
> virtual address, you just have to store that in a global
> instead of hard coding it. Hard coded virtual addresses are
> bad. Especially for things like PCI config space that really
> isn't performance sensitive.
>
I agree ben about PCI config space, It should use ioremap
to get virtual address. No performace indeed.
I think we need find the root cause that the ioremap failed.
Dave
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-06-02 7:32 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673066CF5BE@zch01exm40.ap.freescale.net>
> If I really need to use bat0 or bat1( I see that the general mmu use bat2 and bat3,
> where should I set up them?
>
> For tsi108 pci configuration access, I need to map 16Mbyte
> physical address. If I do not use an extra bat, I can not get the correct
> virtual address use ioremap.
What do you mean ? An ioremap will work, it will give you any virtual
address, you just have to store that in a global instead of hard coding
it. Hard coded virtual addresses are bad. Especially for things like PCI
config space that really isn't performance sensitive.
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-06-02 7:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> > +static void __init mpc7448_hpc2_map_io(void) {
> > + /* PCI IO mapping */
> > + io_block_mapping(MPC7448_HPC2_PCI_IO_BASE_VIRT,
> > + MPC7448_HPC2_PCI_IO_BASE_PHYS,
> 0x00800000, _PAGE_IO);
> > + /* Tsi108 CSR mapping */
> > + io_block_mapping(TSI108_CSR_ADDR_VIRT, TSI108_CSR_ADDR_PHYS,
> > + 0x100000, _PAGE_IO);
> > +
> > + /* PCI Config mapping */
> > + io_block_mapping(MPC7448_HPC2_PCI_CFG_BASE_VIRT,
> > + MPC7448_HPC2_PCI_CFG_BASE_PHYS,
> > + MPC7448_HPC2_PCI_CFG_SIZE, _PAGE_IO);
> > +
> > + tsi108_pci_cfg_base = MPC7448_HPC2_PCI_CFG_BASE_VIRT;
> > + /* NVRAM mapping */
> > + io_block_mapping(MPC7448_HPC2_NVRAM_BASE_ADDR,
> > + MPC7448_HPC2_NVRAM_BASE_ADDR,
> MPC7448_HPC2_NVRAM_SIZE,
> > + _PAGE_IO);
> > +}
>
> io_block_mapping is bad ! see endless discussions in the
> archives of why ... Use ioremap.
If I really need to use bat0 or bat1( I see that the general mmu use bat2 and bat3,
where should I set up them?
For tsi108 pci configuration access, I need to map 16Mbyte
physical address. If I do not use an extra bat, I can not get the correct
virtual address use ioremap.
^ permalink raw reply
* Re: pSeries_mach_cpu_die() question
From: Benjamin Herrenschmidt @ 2006-06-02 6:26 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev list, Nathan Lynch
In-Reply-To: <20060602061929.GM8934@localdomain>
On Fri, 2006-06-02 at 01:19 -0500, Nathan Lynch wrote:
> The cpu parameter is actually unused by in the lpar case:
Ok, missed that :)
> > - 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.
Ok. I'll call it with 0 for the "secondary" argument so it doesn't do
the additional EOI of the IPI in order to not change behaviour from the
current code. We can do differently in the future if we want.
> 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.
I'll remove the comment.
Thanks !
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
* 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
* [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
* 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
* 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: 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
* 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 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
* 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: [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
* 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: 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
* 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
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