* [PATCH v2] powerpc/fsl-booke: Rework TLB CAM code
From: Kumar Gala @ 2009-11-05 17:27 UTC (permalink / raw)
To: linuxppc-dev
Re-write the code so its more standalone and fixed some issues:
* Bump'd # of CAM entries to 64 to support e500mc
* Make the code handle MAS7 properly
* Use pr_cont instead of creating a string as we go
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Fix compile warning
arch/powerpc/kernel/asm-offsets.c | 3 -
arch/powerpc/kernel/head_fsl_booke.S | 22 ------
arch/powerpc/mm/fsl_booke_mmu.c | 132 +++++++++++++++++++---------------
arch/powerpc/mm/mmu_decl.h | 11 ---
4 files changed, 74 insertions(+), 94 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index e2e2082..a6c2b63 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -421,9 +421,6 @@ int main(void)
DEFINE(PGD_T_LOG2, PGD_T_LOG2);
DEFINE(PTE_T_LOG2, PTE_T_LOG2);
#endif
-#ifdef CONFIG_FSL_BOOKE
- DEFINE(TLBCAM_SIZE, sizeof(struct tlbcam));
-#endif
#ifdef CONFIG_KVM_EXIT_TIMING
DEFINE(VCPU_TIMING_EXIT_TBU, offsetof(struct kvm_vcpu,
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 975788c..7f4bd7f 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -944,28 +944,6 @@ _GLOBAL(__setup_e500mc_ivors)
blr
/*
- * extern void loadcam_entry(unsigned int index)
- *
- * Load TLBCAM[index] entry in to the L2 CAM MMU
- */
-_GLOBAL(loadcam_entry)
- lis r4,TLBCAM@ha
- addi r4,r4,TLBCAM@l
- mulli r5,r3,TLBCAM_SIZE
- add r3,r5,r4
- lwz r4,0(r3)
- mtspr SPRN_MAS0,r4
- lwz r4,4(r3)
- mtspr SPRN_MAS1,r4
- lwz r4,8(r3)
- mtspr SPRN_MAS2,r4
- lwz r4,12(r3)
- mtspr SPRN_MAS3,r4
- tlbwe
- isync
- blr
-
-/*
* extern void giveup_altivec(struct task_struct *prev)
*
* The e500 core does not have an AltiVec unit.
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index dc93e95..fcfcb6e 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -54,26 +54,35 @@
#include "mmu_decl.h"
-extern void loadcam_entry(unsigned int index);
unsigned int tlbcam_index;
-static unsigned long cam[CONFIG_LOWMEM_CAM_NUM];
-#define NUM_TLBCAMS (16)
+#define NUM_TLBCAMS (64)
#if defined(CONFIG_LOWMEM_CAM_NUM_BOOL) && (CONFIG_LOWMEM_CAM_NUM >= NUM_TLBCAMS)
#error "LOWMEM_CAM_NUM must be less than NUM_TLBCAMS"
#endif
-struct tlbcam TLBCAM[NUM_TLBCAMS];
+struct tlbcam {
+ u32 MAS0;
+ u32 MAS1;
+ unsigned long MAS2;
+ u32 MAS3;
+ u32 MAS7;
+} TLBCAM[NUM_TLBCAMS];
struct tlbcamrange {
- unsigned long start;
+ unsigned long start;
unsigned long limit;
phys_addr_t phys;
} tlbcam_addrs[NUM_TLBCAMS];
extern unsigned int tlbcam_index;
+unsigned long tlbcam_sz(int idx)
+{
+ return tlbcam_addrs[idx].limit - tlbcam_addrs[idx].start + 1;
+}
+
/*
* Return PA for this VA if it is mapped by a CAM, or 0
*/
@@ -94,23 +103,36 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
int b;
for (b = 0; b < tlbcam_index; ++b)
if (pa >= tlbcam_addrs[b].phys
- && pa < (tlbcam_addrs[b].limit-tlbcam_addrs[b].start)
+ && pa < (tlbcam_addrs[b].limit-tlbcam_addrs[b].start)
+tlbcam_addrs[b].phys)
return tlbcam_addrs[b].start+(pa-tlbcam_addrs[b].phys);
return 0;
}
+void loadcam_entry(int idx)
+{
+ mtspr(SPRN_MAS0, TLBCAM[idx].MAS0);
+ mtspr(SPRN_MAS1, TLBCAM[idx].MAS1);
+ mtspr(SPRN_MAS2, TLBCAM[idx].MAS2);
+ mtspr(SPRN_MAS3, TLBCAM[idx].MAS3);
+
+ if (cur_cpu_spec->cpu_features & MMU_FTR_BIG_PHYS)
+ mtspr(SPRN_MAS7, TLBCAM[idx].MAS7);
+
+ asm volatile("isync;tlbwe;isync" : : : "memory");
+}
+
/*
* Set up one of the I/D BAT (block address translation) register pairs.
* The parameters are not checked; in particular size must be a power
* of 4 between 4k and 256M.
*/
-void settlbcam(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags, unsigned int pid)
+static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
+ unsigned long size, unsigned long flags, unsigned int pid)
{
unsigned int tsize, lz;
- asm ("cntlzw %0,%1" : "=r" (lz) : "r" (size));
+ asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (size));
tsize = 21 - lz;
#ifdef CONFIG_SMP
@@ -128,8 +150,10 @@ void settlbcam(int index, unsigned long virt, phys_addr_t phys,
TLBCAM[index].MAS2 |= (flags & _PAGE_GUARDED) ? MAS2_G : 0;
TLBCAM[index].MAS2 |= (flags & _PAGE_ENDIAN) ? MAS2_E : 0;
- TLBCAM[index].MAS3 = (phys & PAGE_MASK) | MAS3_SX | MAS3_SR;
+ TLBCAM[index].MAS3 = (phys & MAS3_RPN) | MAS3_SX | MAS3_SR;
TLBCAM[index].MAS3 |= ((flags & _PAGE_RW) ? MAS3_SW : 0);
+ if (cur_cpu_spec->cpu_features & MMU_FTR_BIG_PHYS)
+ TLBCAM[index].MAS7 = (u64)phys >> 32;
#ifndef CONFIG_KGDB /* want user access for breakpoints */
if (flags & _PAGE_USER) {
@@ -148,27 +172,44 @@ void settlbcam(int index, unsigned long virt, phys_addr_t phys,
loadcam_entry(index);
}
-void invalidate_tlbcam_entry(int index)
-{
- TLBCAM[index].MAS0 = MAS0_TLBSEL(1) | MAS0_ESEL(index);
- TLBCAM[index].MAS1 = ~MAS1_VALID;
-
- loadcam_entry(index);
-}
-
-unsigned long __init mmu_mapin_ram(void)
+unsigned long map_mem_in_cams(unsigned long ram, int max_cam_idx)
{
+ int i;
unsigned long virt = PAGE_OFFSET;
phys_addr_t phys = memstart_addr;
+ unsigned long amount_mapped = 0;
+ unsigned long max_cam = (mfspr(SPRN_TLB1CFG) >> 16) & 0xf;
+
+ /* Convert (4^max) kB to (2^max) bytes */
+ max_cam = max_cam * 2 + 10;
- while (tlbcam_index < ARRAY_SIZE(cam) && cam[tlbcam_index]) {
- settlbcam(tlbcam_index, virt, phys, cam[tlbcam_index], PAGE_KERNEL_X, 0);
- virt += cam[tlbcam_index];
- phys += cam[tlbcam_index];
- tlbcam_index++;
+ /* Calculate CAM values */
+ for (i = 0; ram && i < max_cam_idx; i++) {
+ unsigned int camsize = __ilog2(ram) & ~1U;
+ unsigned int align = __ffs(virt | phys) & ~1U;
+ unsigned long cam_sz;
+
+ if (camsize > align)
+ camsize = align;
+ if (camsize > max_cam)
+ camsize = max_cam;
+
+ cam_sz = 1UL << camsize;
+ settlbcam(i, virt, phys, cam_sz, PAGE_KERNEL_X, 0);
+
+ ram -= cam_sz;
+ amount_mapped += cam_sz;
+ virt += cam_sz;
+ phys += cam_sz;
}
+ tlbcam_index = i;
+
+ return amount_mapped;
+}
- return virt - PAGE_OFFSET;
+unsigned long __init mmu_mapin_ram(void)
+{
+ return tlbcam_addrs[tlbcam_index - 1].limit - PAGE_OFFSET + 1;
}
/*
@@ -179,46 +220,21 @@ void __init MMU_init_hw(void)
flush_instruction_cache();
}
-void __init
-adjust_total_lowmem(void)
+void __init adjust_total_lowmem(void)
{
- phys_addr_t ram;
- unsigned int max_cam = (mfspr(SPRN_TLB1CFG) >> 16) & 0xff;
- char buf[ARRAY_SIZE(cam) * 5 + 1], *p = buf;
+ unsigned long ram;
int i;
- unsigned long virt = PAGE_OFFSET & 0xffffffffUL;
- unsigned long phys = memstart_addr & 0xffffffffUL;
-
- /* Convert (4^max) kB to (2^max) bytes */
- max_cam = max_cam * 2 + 10;
/* adjust lowmem size to __max_low_memory */
ram = min((phys_addr_t)__max_low_memory, (phys_addr_t)total_lowmem);
- /* Calculate CAM values */
- __max_low_memory = 0;
- for (i = 0; ram && i < ARRAY_SIZE(cam); i++) {
- unsigned int camsize = __ilog2(ram) & ~1U;
- unsigned int align = __ffs(virt | phys) & ~1U;
+ __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM);
- if (camsize > align)
- camsize = align;
- if (camsize > max_cam)
- camsize = max_cam;
-
- cam[i] = 1UL << camsize;
- ram -= cam[i];
- __max_low_memory += cam[i];
- virt += cam[i];
- phys += cam[i];
-
- p += sprintf(p, "%lu/", cam[i] >> 20);
- }
- for (; i < ARRAY_SIZE(cam); i++)
- p += sprintf(p, "0/");
- p[-1] = '\0';
-
- pr_info("Memory CAM mapping: %s Mb, residual: %dMb\n", buf,
+ pr_info("Memory CAM mapping: ");
+ for (i = 0; i < tlbcam_index - 1; i++)
+ pr_cont("%lu/", tlbcam_sz(i) >> 20);
+ pr_cont("%lu Mb, residual: %dMb\n", tlbcam_sz(tlbcam_index - 1) >> 20,
(unsigned int)((total_lowmem - __max_low_memory) >> 20));
+
__initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index d2e5321..e27a990 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -98,21 +98,10 @@ extern void _tlbia(void);
#ifdef CONFIG_PPC32
-struct tlbcam {
- u32 MAS0;
- u32 MAS1;
- u32 MAS2;
- u32 MAS3;
- u32 MAS7;
-};
-
extern void mapin_ram(void);
extern int map_page(unsigned long va, phys_addr_t pa, int flags);
extern void setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags);
-extern void settlbcam(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags, unsigned int pid);
-extern void invalidate_tlbcam_entry(int index);
extern int __map_without_bats;
extern unsigned long ioremap_base;
--
1.6.0.6
^ permalink raw reply related
* [PATCH] powerpc/fsl: Add PCI device ids for new QoirQ chips
From: Kumar Gala @ 2009-11-05 17:27 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_pci.c | 14 ++++++++++++++
include/linux/pci_ids.h | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index cf57a42..4e3a3e3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -392,8 +392,22 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8536, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1011E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1011, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1013E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1013, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1020E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1020, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1022E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1022, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2010E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2010, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020E, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4040E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4040, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4080E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4080, quirk_fsl_pcie_header);
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index b0f0f38..3b087cb 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2288,6 +2288,20 @@
#define PCI_DEVICE_ID_MPC8536 0x0051
#define PCI_DEVICE_ID_P2020E 0x0070
#define PCI_DEVICE_ID_P2020 0x0071
+#define PCI_DEVICE_ID_P2010E 0x0078
+#define PCI_DEVICE_ID_P2010 0x0079
+#define PCI_DEVICE_ID_P1020E 0x0100
+#define PCI_DEVICE_ID_P1020 0x0101
+#define PCI_DEVICE_ID_P1011E 0x0108
+#define PCI_DEVICE_ID_P1011 0x0109
+#define PCI_DEVICE_ID_P1022E 0x0110
+#define PCI_DEVICE_ID_P1022 0x0111
+#define PCI_DEVICE_ID_P1013E 0x0118
+#define PCI_DEVICE_ID_P1013 0x0119
+#define PCI_DEVICE_ID_P4080E 0x0400
+#define PCI_DEVICE_ID_P4080 0x0401
+#define PCI_DEVICE_ID_P4040E 0x0408
+#define PCI_DEVICE_ID_P4040 0x0409
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
#define PCI_DEVICE_ID_MPC8610 0x7018
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Anton Vorontsov @ 2009-11-05 17:34 UTC (permalink / raw)
To: Kumar Gopalpet-B05799
Cc: Jon Loeliger, netdev, linuxppc-dev, Fleming Andy-AFLEMING,
Jason Wessel, Stephen Hemminger, David Miller, Lennert Buytenhek
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950713@zin33exm22.fsl.freescale.net>
On Thu, Nov 05, 2009 at 10:53:08PM +0530, Kumar Gopalpet-B05799 wrote:
[...]
> >(spin_trylock_irqsave(&tx_queue->txlock, flags)) {
> >- tx_cleaned +=
> >gfar_clean_tx_ring(tx_queue);
> >-
> >spin_unlock_irqrestore(&tx_queue->txlock,
> >- flags);
> >- }
> >+ netif_tx_lock_bh(priv->ndev);
>
> Will this not lead to locking all the tx queues even though at this
> point we are working on a "particular queue" ?
Yeah, per-txq locking would be better (or not.. I need to netperf
it).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Jon Loeliger @ 2009-11-05 17:40 UTC (permalink / raw)
To: Kumar Gopalpet-B05799
Cc: netdev, linuxppc-dev, Fleming Andy-AFLEMING, Jason Wessel,
Stephen Hemminger, David Miller, Lennert Buytenhek
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950713@zin33exm22.fsl.freescale.net>
>
> [.....]
> > drivers/net/gianfar.c | 19 +++----------------
> > 1 files changed, 3 insertions(+), 16 deletions(-)
> >
> >diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c=20
> >index 197b358..a0ae604 100644
> >--- a/drivers/net/gianfar.c
> >+++ b/drivers/net/gianfar.c
> >@@ -1899,10 +1899,8 @@ static int gfar_start_xmit(struct=20
> >sk_buff *skb, struct net_device *dev)
> > u32 lstatus;
> > int i, rq = 0;
> > u32 bufaddr;
> >- unsigned long flags;
> > unsigned int nr_frags, length;
> >
> >-
> > rq = skb->queue_mapping;
> > tx_queue = priv->tx_queue[rq];
> > txq = netdev_get_tx_queue(dev, rq);
> >@@ -1928,14 +1926,11 @@ static int gfar_start_xmit(struct
> >sk_buff *skb, struct net_device *dev)
> > /* total number of fragments in the SKB */
> > nr_frags = skb_shinfo(skb)->nr_frags;
> >
> >- spin_lock_irqsave(&tx_queue->txlock, flags);
> >-
> > /* check if there is space to queue this packet */
> > if ((nr_frags+1) > tx_queue->num_txbdfree) {
> > /* no space, stop the queue */
> > netif_tx_stop_queue(txq);
> > dev->stats.tx_fifo_errors++;
> >- spin_unlock_irqrestore(&tx_queue->txlock, flags);
> > return NETDEV_TX_BUSY;
> > }
> >
> >@@ -2033,9 +2028,6 @@ static int gfar_start_xmit(struct
> >sk_buff *skb, struct net_device *dev)
> > /* Tell the DMA to go go go */
> > gfar_write(®s->tstat, TSTAT_CLEAR_THALT >> tx_queue->qindex);
> >
> >- /* Unlock priv */
> >- spin_unlock_irqrestore(&tx_queue->txlock, flags);
> >-
> > return NETDEV_TX_OK;
> > }
> >
> >@@ -2550,7 +2542,6 @@ static int gfar_poll(struct napi_struct
> >*napi, int budget)
> > int tx_cleaned = 0, i, left_over_budget = budget;
> > unsigned long serviced_queues = 0;
> > int num_queues = 0;
> >- unsigned long flags;
> >
> > num_queues = gfargrp->num_rx_queues;
> > budget_per_queue = budget/num_queues;
> >@@ -2570,13 +2561,9 @@ static int gfar_poll(struct napi_struct
> >*napi, int budget)
> > rx_queue = priv->rx_queue[i];
> > tx_queue = priv->tx_queue[rx_queue->qindex];
> >
> >- /* If we fail to get the lock,
> >- * don't bother with the TX BDs */
> >- if
> >(spin_trylock_irqsave(&tx_queue->txlock, flags)) {
> >- tx_cleaned +=
> >gfar_clean_tx_ring(tx_queue);
> >- =09
> >spin_unlock_irqrestore(&tx_queue->txlock,
> >- flags);
> >- }
> >+ netif_tx_lock_bh(priv->ndev);
>
> Will this not lead to locking all the tx queues even though at this
> point we are working on a "particular queue" ?
Similar but different question: What version is this patch based upon?
I can't find:
> >index 197b358..a0ae604 100644
My search of 2.6.31 up through current linux head (v2.6.32-rc6-26-g91d3f9b)
and benh's current head (94a8d5caba74211ec76dac80fc6e2d5c391530df) do not
have a version of this code with separate txqueues.
I confess I'm not too familiar with the history here, so I don't know
if that feature is in flux, or came, or went, or what.
That boils down to: I can't directly apply your patch, but I could
hand-fudge its intent, but only on a single tx queue variant.
jdl
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Anton Vorontsov @ 2009-11-05 17:53 UTC (permalink / raw)
To: Jon Loeliger
Cc: Kumar Gopalpet-B05799, netdev, linuxppc-dev,
Fleming Andy-AFLEMING, Jason Wessel, Stephen Hemminger,
David Miller, Lennert Buytenhek
In-Reply-To: <E1N66Jp-0004Y0-8Q@jdl.com>
On Thu, Nov 05, 2009 at 11:40:21AM -0600, Jon Loeliger wrote:
[...]
> > >+ netif_tx_lock_bh(priv->ndev);
> >
> > Will this not lead to locking all the tx queues even though at this
> > point we are working on a "particular queue" ?
>
> Similar but different question: What version is this patch based upon?
> I can't find:
>
> > >index 197b358..a0ae604 100644
>
> My search of 2.6.31 up through current linux head (v2.6.32-rc6-26-g91d3f9b)
> and benh's current head (94a8d5caba74211ec76dac80fc6e2d5c391530df) do not
> have a version of this code with separate txqueues.
>
> I confess I'm not too familiar with the history here, so I don't know
> if that feature is in flux, or came, or went, or what.
Sorry for not mentioning, it's based on
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
+ compiler/sparse warnings fixes that I sent yesterday.
> That boils down to: I can't directly apply your patch, but I could
> hand-fudge its intent, but only on a single tx queue variant.
Here is the patch on top of the Linus' git tree, if you haven't
already 'back-ported' the previous patch.
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 5bf31f1..5dca99c 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1274,7 +1274,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
u32 lstatus;
int i;
u32 bufaddr;
- unsigned long flags;
unsigned int nr_frags, length;
base = priv->tx_bd_base;
@@ -1298,14 +1297,11 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* total number of fragments in the SKB */
nr_frags = skb_shinfo(skb)->nr_frags;
- spin_lock_irqsave(&priv->txlock, flags);
-
/* check if there is space to queue this packet */
if ((nr_frags+1) > priv->num_txbdfree) {
/* no space, stop the queue */
netif_stop_queue(dev);
dev->stats.tx_fifo_errors++;
- spin_unlock_irqrestore(&priv->txlock, flags);
return NETDEV_TX_BUSY;
}
@@ -1403,9 +1399,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Tell the DMA to go go go */
gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT);
- /* Unlock priv */
- spin_unlock_irqrestore(&priv->txlock, flags);
-
return NETDEV_TX_OK;
}
@@ -1915,17 +1908,14 @@ static int gfar_poll(struct napi_struct *napi, int budget)
struct net_device *dev = priv->ndev;
int tx_cleaned = 0;
int rx_cleaned = 0;
- unsigned long flags;
/* Clear IEVENT, so interrupts aren't called again
* because of the packets that have already arrived */
gfar_write(&priv->regs->ievent, IEVENT_RTX_MASK);
- /* If we fail to get the lock, don't bother with the TX BDs */
- if (spin_trylock_irqsave(&priv->txlock, flags)) {
- tx_cleaned = gfar_clean_tx_ring(dev);
- spin_unlock_irqrestore(&priv->txlock, flags);
- }
+ netif_tx_lock_bh(priv->ndev);
+ tx_cleaned = gfar_clean_tx_ring(dev);
+ netif_tx_unlock_bh(priv->ndev);
rx_cleaned = gfar_clean_rx_ring(dev, budget);
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply related
* RE: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Kumar Gopalpet-B05799 @ 2009-11-05 17:53 UTC (permalink / raw)
To: Jon Loeliger
Cc: netdev, linuxppc-dev, Fleming Andy-AFLEMING, Jason Wessel,
Stephen Hemminger, David Miller, Lennert Buytenhek
In-Reply-To: <E1N66Jp-0004Y0-8Q@jdl.com>
=20
>
>Similar but different question: What version is this patch based upon?
>I can't find:
>
> > >index 197b358..a0ae604 100644
>
>My search of 2.6.31 up through current linux head=20
>(v2.6.32-rc6-26-g91d3f9b) and benh's current head=20
>(94a8d5caba74211ec76dac80fc6e2d5c391530df) do not have a=20
>version of this code with separate txqueues.
>
>I confess I'm not too familiar with the history here, so I=20
>don't know if that feature is in flux, or came, or went, or what.
>
>That boils down to: I can't directly apply your patch, but I=20
>could hand-fudge its intent, but only on a single tx queue variant.
>
You might want to get the code base from the top of davem/net-next-2.6
tree
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
The multi queue is a feature available in etsec2.0 version. On older
versions you might want to=20
work in a single queue mode itself.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Kumar Gala @ 2009-11-05 18:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <4AF30406.3080101@freescale.com>
On Nov 5, 2009, at 10:57 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 23, 2009, at 2:01 PM, Anton Vorontsov wrote:
>>> Currently 83xx PMC driver clears deep_sleeping variable very early,
>>> before devices are resumed. This makes fsl_deep_sleep() unusable in
>>> drivers' resume() callback.
>>>
>>> Sure, drivers can store fsl_deep_sleep() value on suspend and use
>>> the stored value on resume. But a better solution is to postpone
>>> clearing the deep_sleeping variable, i.e. move it into finish()
>>> callback.
>>>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>> arch/powerpc/platforms/83xx/suspend.c | 4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>> Scott, any comments or an ack?
>
> ACK
thanks, is that an ACK for all 3?
- k
^ permalink raw reply
* Re: [PATCH 4/6 v5] Memory DLPAR Handling
From: Roland Dreier @ 2009-11-05 18:51 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AE8B02C.3060706@austin.ibm.com>
This isn't a review of this patch -- more a question out of curiousity
about how you actually can do memory remove in practice. Do you have
any coordination between the platform/hypervisor and the kernel to make
sure that a memory region you might want to remove later gets put into
zone_movable so that there's a chance for the kernel to vacate it? Or
do you have some other way to coordinate or at least expose which
regions of memory the kernel will have a chance at releasing?
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Scott Wood @ 2009-11-05 19:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list
In-Reply-To: <2F8E2E66-8398-4ACD-9697-6C2AB6E39CD3@kernel.crashing.org>
Kumar Gala wrote:
>
> On Nov 5, 2009, at 10:57 AM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> On Sep 23, 2009, at 2:01 PM, Anton Vorontsov wrote:
>>>> Currently 83xx PMC driver clears deep_sleeping variable very early,
>>>> before devices are resumed. This makes fsl_deep_sleep() unusable in
>>>> drivers' resume() callback.
>>>>
>>>> Sure, drivers can store fsl_deep_sleep() value on suspend and use
>>>> the stored value on resume. But a better solution is to postpone
>>>> clearing the deep_sleeping variable, i.e. move it into finish()
>>>> callback.
>>>>
>>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>>> ---
>>>> arch/powerpc/platforms/83xx/suspend.c | 4 ++--
>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>> Scott, any comments or an ack?
>>
>> ACK
>
> thanks, is that an ACK for all 3?
The first. Patch 2 looks OK as well.
As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Kumar Gala @ 2009-11-05 19:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <4AF32C0B.4010109@freescale.com>
On Nov 5, 2009, at 1:48 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Nov 5, 2009, at 10:57 AM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>> On Sep 23, 2009, at 2:01 PM, Anton Vorontsov wrote:
>>>>> Currently 83xx PMC driver clears deep_sleeping variable very
>>>>> early,
>>>>> before devices are resumed. This makes fsl_deep_sleep() unusable
>>>>> in
>>>>> drivers' resume() callback.
>>>>>
>>>>> Sure, drivers can store fsl_deep_sleep() value on suspend and use
>>>>> the stored value on resume. But a better solution is to postpone
>>>>> clearing the deep_sleeping variable, i.e. move it into finish()
>>>>> callback.
>>>>>
>>>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>>>> ---
>>>>> arch/powerpc/platforms/83xx/suspend.c | 4 ++--
>>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>> Scott, any comments or an ack?
>>>
>>> ACK
>> thanks, is that an ACK for all 3?
>
> The first. Patch 2 looks OK as well.
>
> As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
Is sleep-nexus new? I thought we've had that for a bit.
- k
^ permalink raw reply
* Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Benjamin Herrenschmidt @ 2009-11-05 20:00 UTC (permalink / raw)
To: James Bottomley; +Cc: Eric.Moore, pbathija, linux-scsi, linuxppc-dev
In-Reply-To: <1257437226.2753.64.camel@mulgrave.site>
On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote:
> > > ioc->memmap = mem;
> > >- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %lx\n",
> > >- ioc->name, mem, mem_phys));
> > >+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %llx\n",
> > >+ ioc->name, mem, (u64)mem_phys));
> > >
> > > ioc->mem_phys = mem_phys;
> > > ioc->chip = (SYSIF_REGS __iomem *)mem;
> > >
> > > /* Save Port IO values in case we need to do downloadboot */
> > >- ioc->pio_mem_phys = port;
> > >+ port = ioremap(port_phys, psize);
> > >+ if (port == NULL) {
> > >+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
> > >+ " port !\n", ioc->name);
> > >+ return -EINVAL;
>
> So this looks problematic on a few platforms ... what happens to
> platforms that have no IO space? They automatically fail here and it
> looks like the adapter never attaches.
Yup, that part of the patch looks wrong.
However, a mechanical replacement of unsigned long's with
resource_size_t to hold physical addresses should be fine despite the
lack of feedback from LSI.
Pravin, that ioremap definitely seems like it has nothing to do there,
port IO is already remapped for you by the core PCI code and should work
"as is". Please respin without that change.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Scott Wood @ 2009-11-05 20:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list
In-Reply-To: <7A8DBFC0-69D9-406B-B1AC-3EAC8EE26C58@kernel.crashing.org>
Kumar Gala wrote:
> On Nov 5, 2009, at 1:48 PM, Scott Wood wrote:
>> As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
>
> Is sleep-nexus new? I thought we've had that for a bit.
It's been around in a few dts files, but as was noted, nothing uses this
stuff yet.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Anton Vorontsov @ 2009-11-05 20:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <4AF32F82.8040801@freescale.com>
On Thu, Nov 05, 2009 at 02:03:14PM -0600, Scott Wood wrote:
> Kumar Gala wrote:
> >On Nov 5, 2009, at 1:48 PM, Scott Wood wrote:
> >>As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
> >
> >Is sleep-nexus new? I thought we've had that for a bit.
>
> It's been around in a few dts files, but as was noted, nothing uses
> this stuff yet.
So I should just drop the sleep-nexus changes? I can also
prepare a patch that removes sleep-nexus from 8313rdb.dts.
But how should we handle the sleep = <> properties then?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Scott Wood @ 2009-11-05 20:25 UTC (permalink / raw)
To: avorontsov; +Cc: linux-ppc list
In-Reply-To: <20091105200931.GA30577@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Nov 05, 2009 at 02:03:14PM -0600, Scott Wood wrote:
>> Kumar Gala wrote:
>>> On Nov 5, 2009, at 1:48 PM, Scott Wood wrote:
>>>> As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
>>> Is sleep-nexus new? I thought we've had that for a bit.
>> It's been around in a few dts files, but as was noted, nothing uses
>> this stuff yet.
>
> So I should just drop the sleep-nexus changes? I can also
> prepare a patch that removes sleep-nexus from 8313rdb.dts.
> But how should we handle the sleep = <> properties then?
We could still have some sort of nexus node that is off to the side
(pointed to with sleep-parent) and not inserting itself into the hierarchy.
Or, we could allow multiple nodes to refer to the same sleep ID, and use
the ID rather than a node to tie things together. If we do that, we'll
probably want a simple index rather than a set of bits in the sleep
property, so it can correspond to some kernel object that has some
bookeeping info. Perhaps we could tie into the clock bindings that were
discussed on devtree-discuss in August.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
From: Anton Vorontsov @ 2009-11-05 20:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <4AF334AB.1030401@freescale.com>
On Thu, Nov 05, 2009 at 02:25:15PM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
> >On Thu, Nov 05, 2009 at 02:03:14PM -0600, Scott Wood wrote:
> >>Kumar Gala wrote:
> >>>On Nov 5, 2009, at 1:48 PM, Scott Wood wrote:
> >>>>As for patch 3, Ben objected to the sleep-nexus stuff on IRC.
> >>>Is sleep-nexus new? I thought we've had that for a bit.
> >>It's been around in a few dts files, but as was noted, nothing uses
> >>this stuff yet.
> >
> >So I should just drop the sleep-nexus changes? I can also
> >prepare a patch that removes sleep-nexus from 8313rdb.dts.
> >But how should we handle the sleep = <> properties then?
>
> We could still have some sort of nexus node that is off to the side
> (pointed to with sleep-parent) and not inserting itself into the
> hierarchy.
>
> Or, we could allow multiple nodes to refer to the same sleep ID, and
> use the ID rather than a node to tie things together. If we do
> that, we'll probably want a simple index rather than a set of bits
> in the sleep property, so it can correspond to some kernel object
> that has some bookeeping info. Perhaps we could tie into the clock
> bindings that were discussed on devtree-discuss in August.
Yeah, reusing the clk api would be the best.
Anyway, since we don't use the sleep-nexus stuff, I'd rather
just add the power management controller nodes.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Interrupts not Firing on PPC405EX
From: Jonathan Haws @ 2009-11-05 20:37 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I am having some troubles getting interrupts to fire from my kernel module.=
I have connected the ISR with a call to request_irq() and have configured=
my device to generate interrupts. However, my ISR is called once when I =
connect the interrupt for the first time. After that it never is called ag=
ain. It seems like that interrupt is getting stuck disabled, but that does=
not make sense as to why.
The device is on the PCIE0 bus and works just fine in another OS (namely Vx=
works - that is the driver I am working on porting to Linux).
Here is how I am connecting the ISR and the ISR itself. Am I doing somethi=
ng stupid?
Thanks for the help!
Jonathan
PS - Our hardware is a custom spun PPC405EX board based on the AMCC Kilauea=
board and uses the kilauea.dts with no modifications.
A quick note - I realize that I am not checking if I was the one to interru=
pt the CPU. I am not worried about that right now - especially since I kno=
w there is nothing else that will interrupt the CPU on this IRQ right now a=
nyway - it never fires.
int fpga_open(struct inode *inode, struct file *filp)
{
int err =3D 0;
/* Make sure we have successfully probed the device */
if (NULL =3D=3D fpga_drv.pcidev)
{
return -ENODEV;
}
/* Only one process at a time can have access to the FPGA */
if (0 !=3D atomic_read(&fpga_drv.openCount))
{
atomic_inc(&fpga_drv.openCount);
printk(KERN_WARNING "FPGA: Could not open device: already open. \n");
return -EBUSY;
}
/* If not already in use, state that we are */
atomic_inc(&fpga_drv.openCount);
/* Store a pointer to the PCI device structure */
filp->private_data =3D fpga_drv.pcidev;
/* Attach ISR to IRQ */
if (request_irq(fpga_drv.pcidev->irq, &fpga_isr, IRQF_SHARED,
FPGA_MODULE_NAME, fpga_drv.pcidev))
{
printk( KERN_ERR "FPGA: Unable to connect FPGA ISR (%d)!\n",
fpga_drv.pcidev->irq);
return -EPERM;
}
return 0;
}
/* Interrupt Service Routine */
irqreturn_t fpga_isr(int irq, void *dev_id)
{
uint32_t status =3D 0;
status =3D fpga_drv.cfg_ptr[FPGA_INTER_STATUS];
printk(KERN_NOTICE "FPGA: Interrupt fired! (%#08x)\n", status);
if (status & FPGA_INTERRUPT_SPI)
{
rt_sem_v(&fpga_drv.sarSem);
}
/* Return HANDLED */
return (IRQ_HANDLED);}
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Scott Wood @ 2009-11-06 0:33 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1257341920-29277-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> Here is the latest(last?) round of this series. I
> hope I got everything right now.
> Scott and Rex, please test and send ACK/NACK.
>
> Jocke
>
> Joakim Tjernlund (8):
> 8xx: invalidate non present TLBs
This works, and is an important fix -- it should be applied even if the rest
of the patchset isn't ready.
> 8xx: Update TLB asm so it behaves as linux mm expects.
> 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
Up through this point works.
> 8xx: Fixup DAR from buggy dcbX instructions.
With this, the kernel hangs after "Mount-cache hash table entries: 512".
> 8xx: Add missing Guarded setting in DTLB Error.
> 8xx: Restore _PAGE_WRITETHRU
> 8xx: start using dcbX instructions in various copy routines
Once I get up to this patch, it no longer hangs, but I get some user
processes consistently failing with EFAULT.
> 8xx: Remove DIRTY pte handling in DTLB Error.
No change after this patch.
-Scott
^ permalink raw reply
* RE: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
From: Gao Guanhua-B22826 @ 2009-11-06 2:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, sdhci-devel
In-Reply-To: <56F6ACCC-7FE8-44E6-BF5E-6361997F524F@kernel.crashing.org>
I will update the patch next week.
Regards,
--gaoguanhua
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Thursday, November 05, 2009 9:52 PM
> To: Gao Guanhua-B22826
> Cc: avorontsov@ru.mvista.com; linuxppc-dev@ozlabs.org;=20
> sdhci-devel@lists.ossman.eu
> Subject: Re: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
>=20
>=20
> On Sep 24, 2009, at 3:28 AM, Gao Guanhua-B22826 wrote:
>=20
> > Thanks, I will add them.
> >
> >> -----Original Message-----
> >> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]
> >> Sent: Wednesday, September 23, 2009 7:55 PM
> >> To: Gao Guanhua-B22826
> >> Cc: sdhci-devel@lists.ossman.eu; linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
> >>
> >> On Wed, Sep 23, 2009 at 05:08:09PM +0800, Gao Guanhua wrote:
> >>> The SDHC can not work on DMA mode because of the hardware
> >> bug, so we
> >>> set a broken dma flag and use PIO mode. This patch applies
> >> to Rev1.0.
> >>
> >> Signed-off-by line is missing (in all patches).
> >
>=20
> Any plan to update & repost these patches?
>=20
> - k
>=20
>=20
^ permalink raw reply
* RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Desai, Kashyap @ 2009-11-06 4:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt, James Bottomley
Cc: Moore, Eric, pbathija@amcc.com, linux-scsi@vger.kernel.org,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257451218.13611.114.camel@pasglop>
-----Original Message-----
From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-owner@vger.kernel=
.org] On Behalf Of Benjamin Herrenschmidt
Sent: Friday, November 06, 2009 1:30 AM
To: James Bottomley
Cc: Josh Boyer; Moore, Eric; pbathija@amcc.com; linux-scsi@vger.kernel.org;=
linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit re=
sources.
On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote:
> > > ioc->memmap =3D mem;
> > >- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys =3D %=
lx\n",
> > >- ioc->name, mem, mem_phys));
> > >+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys =3D %=
llx\n",
> > >+ ioc->name, mem, (u64)mem_phys));
> > >
> > > ioc->mem_phys =3D mem_phys;
> > > ioc->chip =3D (SYSIF_REGS __iomem *)mem;
> > >
> > > /* Save Port IO values in case we need to do downloadboot */
> > >- ioc->pio_mem_phys =3D port;
> > >+ port =3D ioremap(port_phys, psize);
> > >+ if (port =3D=3D NULL) {
> > >+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
> > >+ " port !\n", ioc->name);
> > >+ return -EINVAL;
>=20
> So this looks problematic on a few platforms ... what happens to
> platforms that have no IO space? They automatically fail here and it
> looks like the adapter never attaches.
Yup, that part of the patch looks wrong.
However, a mechanical replacement of unsigned long's with
resource_size_t to hold physical addresses should be fine despite the
lack of feedback from LSI.
--> I was thinking this was actual fix for the issue. Use of resource_size_=
t is understood. Why submitter has added extra ioremap code in this patch? =
Because of ioremap code only this patch was on hold before going for ACK.
Pravin, Any specific reason to add above code?
Pravin, that ioremap definitely seems like it has nothing to do there,
port IO is already remapped for you by the core PCI code and should work
"as is". Please respin without that change.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Pravin Bathija @ 2009-11-06 5:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt, James Bottomley
Cc: Eric.Moore, linux-scsi, linuxppc-dev
In-Reply-To: <1257451218.13611.114.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogVGh1cnNk
YXksIE5vdmVtYmVyIDA1LCAyMDA5IDEyOjAwIFBNDQo+IFRvOiBKYW1lcyBCb3R0b21sZXkNCj4g
Q2M6IEpvc2ggQm95ZXI7IEVyaWMuTW9vcmVAbHNpLmNvbTsgUHJhdmluIEJhdGhpamE7IGxpbnV4
LQ0KPiBzY3NpQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QG96bGFicy5vcmcNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSF0gW1NDU0ldIG1wdCBmdXNpb246IEZpeCAzMiBiaXQgcGxhdGZvcm1z
IHdpdGggNjQNCj4gYml0IHJlc291cmNlcy4NCj4gDQo+IE9uIFRodSwgMjAwOS0xMS0wNSBhdCAx
MDowNyAtMDYwMCwgSmFtZXMgQm90dG9tbGV5IHdyb3RlOg0KPiANCj4gPiA+ID4gCWlvYy0+bWVt
bWFwID0gbWVtOw0KPiA+ID4gPi0JZGluaXRwcmludGsoaW9jLCBwcmludGsoTVlJT0Nfc19JTkZP
X0ZNVCAibWVtID0gJXAsDQo+IG1lbV9waHlzID0gJWx4XG4iLA0KPiA+ID4gPi0JICAgIGlvYy0+
bmFtZSwgbWVtLCBtZW1fcGh5cykpOw0KPiA+ID4gPisJZGluaXRwcmludGsoaW9jLCBwcmludGso
TVlJT0Nfc19JTkZPX0ZNVCAibWVtID0gJXAsDQo+IG1lbV9waHlzID0gJWxseFxuIiwNCj4gPiA+
ID4rCSAgICBpb2MtPm5hbWUsIG1lbSwgKHU2NCltZW1fcGh5cykpOw0KPiA+ID4gPg0KPiA+ID4g
PiAJaW9jLT5tZW1fcGh5cyA9IG1lbV9waHlzOw0KPiA+ID4gPiAJaW9jLT5jaGlwID0gKFNZU0lG
X1JFR1MgX19pb21lbSAqKW1lbTsNCj4gPiA+ID4NCj4gPiA+ID4gCS8qIFNhdmUgUG9ydCBJTyB2
YWx1ZXMgaW4gY2FzZSB3ZSBuZWVkIHRvIGRvIGRvd25sb2FkYm9vdA0KPiAqLw0KPiA+ID4gPi0J
aW9jLT5waW9fbWVtX3BoeXMgPSBwb3J0Ow0KPiA+ID4gPisJcG9ydCA9IGlvcmVtYXAocG9ydF9w
aHlzLCBwc2l6ZSk7DQo+ID4gPiA+KwlpZiAocG9ydCA9PSBOVUxMKSB7DQo+ID4gPiA+KwkJcHJp
bnRrKE1ZSU9DX3NfRVJSX0ZNVCAiIDogRVJST1IgLSBVbmFibGUgdG8gbWFwDQo+IGFkYXB0ZXIi
DQo+ID4gPiA+KwkJCSIgcG9ydCAhXG4iLCBpb2MtPm5hbWUpOw0KPiA+ID4gPisJCXJldHVybiAt
RUlOVkFMOw0KPiA+DQo+ID4gU28gdGhpcyBsb29rcyBwcm9ibGVtYXRpYyBvbiBhIGZldyBwbGF0
Zm9ybXMgLi4uIHdoYXQgaGFwcGVucyB0bw0KPiA+IHBsYXRmb3JtcyB0aGF0IGhhdmUgbm8gSU8g
c3BhY2U/ICBUaGV5IGF1dG9tYXRpY2FsbHkgZmFpbCBoZXJlIGFuZCBpdA0KPiA+IGxvb2tzIGxp
a2UgdGhlIGFkYXB0ZXIgbmV2ZXIgYXR0YWNoZXMuDQo+IA0KPiBZdXAsIHRoYXQgcGFydCBvZiB0
aGUgcGF0Y2ggbG9va3Mgd3JvbmcuDQo+IA0KPiBIb3dldmVyLCBhIG1lY2hhbmljYWwgcmVwbGFj
ZW1lbnQgb2YgdW5zaWduZWQgbG9uZydzIHdpdGgNCj4gcmVzb3VyY2Vfc2l6ZV90IHRvIGhvbGQg
cGh5c2ljYWwgYWRkcmVzc2VzIHNob3VsZCBiZSBmaW5lIGRlc3BpdGUgdGhlDQo+IGxhY2sgb2Yg
ZmVlZGJhY2sgZnJvbSBMU0kuDQo+IA0KPiBQcmF2aW4sIHRoYXQgaW9yZW1hcCBkZWZpbml0ZWx5
IHNlZW1zIGxpa2UgaXQgaGFzIG5vdGhpbmcgdG8gZG8gdGhlcmUsDQo+IHBvcnQgSU8gaXMgYWxy
ZWFkeSByZW1hcHBlZCBmb3IgeW91IGJ5IHRoZSBjb3JlIFBDSSBjb2RlIGFuZCBzaG91bGQNCj4g
d29yaw0KPiAiYXMgaXMiLiBQbGVhc2UgcmVzcGluIHdpdGhvdXQgdGhhdCBjaGFuZ2UuDQo+IA0K
PiBDaGVlcnMsDQo+IEJlbi4NCj4gDQoNClRoYW5rcyBmb3IgdGhlIGlucHV0LiBXaWxsIG1ha2Ug
dGhlIHN1Z2dlc3RlZCBjaGFuZ2VzIGFuZCByZS1zdWJtaXQgcGF0Y2guDQpSZWdhcmRzLA0KUHJh
dmluDQo=
^ permalink raw reply
* RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Pravin Bathija @ 2009-11-06 5:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt, James Bottomley
Cc: Eric.Moore, linux-scsi, linuxppc-dev
In-Reply-To: <1257451218.13611.114.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Thu 11/5/2009 12:00 PM
To: James Bottomley
Cc: Josh Boyer; Eric.Moore@lsi.com; Pravin Bathija; linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote:
> > > ioc->memmap = mem;
> > >- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %lx\n",
> > >- ioc->name, mem, mem_phys));
> > >+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %llx\n",
> > >+ ioc->name, mem, (u64)mem_phys));
> > >
> > > ioc->mem_phys = mem_phys;
> > > ioc->chip = (SYSIF_REGS __iomem *)mem;
> > >
> > > /* Save Port IO values in case we need to do downloadboot */
> > >- ioc->pio_mem_phys = port;
> > >+ port = ioremap(port_phys, psize);
> > >+ if (port == NULL) {
> > >+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
> > >+ " port !\n", ioc->name);
> > >+ return -EINVAL;
>
> So this looks problematic on a few platforms ... what happens to
> platforms that have no IO space? They automatically fail here and it
> looks like the adapter never attaches.
> Yup, that part of the patch looks wrong.
> However, a mechanical replacement of unsigned long's with
> resource_size_t to hold physical addresses should be fine despite the
> lack of feedback from LSI.
> Pravin, that ioremap definitely seems like it has nothing to do there,
> port IO is already remapped for you by the core PCI code and should work
> "as is". Please respin without that change.
> Cheers,
>Ben.
Thanks for the input. Will make the suggested changes and re-submit the patch.
Regards,
Pravin
[-- Attachment #2: Type: text/html, Size: 2991 bytes --]
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Rusty Russell @ 2009-11-06 6:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich,
akpm, linuxppc-dev
In-Reply-To: <20091105173842.c94ba501.sfr@canb.auug.org.au>
On Thu, 5 Nov 2009 05:08:42 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
> >
> > Huh? virtio_has_feature does:
> >
> > if (__builtin_constant_p(fbit))
> > BUILD_BUG_ON(fbit >= 32);
> > else
> > BUG_ON(fbit >= 32);
>
> In Linus' tree (and linux-next) it looks like this:
Ah. My patch series fixes that as part of removing MAYBE_BUILD_BUG_ON.
I've put both in for linux-next.
Cheers,
Rusty.
^ permalink raw reply
* Re: DMA to User-Space
From: Chris Friesen @ 2009-11-06 6:05 UTC (permalink / raw)
To: Jonathan Haws; +Cc: Bo.Liu@windriver.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F033103030E@midas.usurf.usu.edu>
On 11/04/2009 11:50 AM, Jonathan Haws wrote:
> One more question about this approach: does the mmap() call prevent
> the kernel from using this memory for other purposes? Will the
> kernel be able to "move" this memory elsewhere? I guess what I am
> asking is if this memory is locked for all other purposes?
You've allocated the memory in the kernel and mapped it to userspace.
If the kernel uses that memory for anything else it will be visible to
userspace.
Chris
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Joakim Tjernlund @ 2009-11-06 8:01 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <20091106003305.GA15814@loki.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 06/11/2009 01:33:05:
>
> On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> > Here is the latest(last?) round of this series. I
> > hope I got everything right now.
> > Scott and Rex, please test and send ACK/NACK.
> >
> > Jocke
> >
> > Joakim Tjernlund (8):
> > 8xx: invalidate non present TLBs
>
> This works, and is an important fix -- it should be applied even if the rest
> of the patchset isn't ready.
True.
>
> > 8xx: Update TLB asm so it behaves as linux mm expects.
I think this is ready too.
> > 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
>
> Up through this point works.
hmm, here tagging of DAR is in place, do you ever hit the
page fault handler with address == 0x00f0? If you do,
the kernel somehow manges to fix it instead of erroring out.
I do notice one thing, I forgot to add the CPU6 errata to
the DAR tagging. Are you using the CPU6 errata?
>
> > 8xx: Fixup DAR from buggy dcbX instructions.
>
> With this, the kernel hangs after "Mount-cache hash table entries: 512".
Somewhat surprising result. I didn't expect you would even hit this
condition now as we haven't enabled the use of dcbX insn yet.
The only thing I can think of is the you hit the 0x00f0 due to other
dcbX insn use and the kernel managed to fixup this in the page fault handler
by pure luck before.
The only thing I can thing of being wrong here is your suggested fix:
+ lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
+ ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
+ rlwimi r11, r10, 22, 0xffc
What if you change that back to what worked for you before:
lis r11, swapper_pg_dir@h
ori r11, r11, swapper_pg_dir@l
rlwinm r11, r11, 0, 0x3ffff000
rlwimi r11, r10, 22, 0xffc
or possibly
lis r11, swapper_pg_dir@h
ori r11, r11, swapper_pg_dir@l
subis r11, r11, PAGE_OFFSET@h
rlwimi r11, r10, 22, 0xffc
hmm, some missed CPU6 errata calls in DARFixup too.
>
> > 8xx: Add missing Guarded setting in DTLB Error.
> > 8xx: Restore _PAGE_WRITETHRU
> > 8xx: start using dcbX instructions in various copy routines
>
> Once I get up to this patch, it no longer hangs, but I get some user
> processes consistently failing with EFAULT.
No surprise as the it seems like the DAR decoding is broken.
>
> > 8xx: Remove DIRTY pte handling in DTLB Error.
>
> No change after this patch.
>
> -Scott
>
>
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Joakim Tjernlund @ 2009-11-06 9:29 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OF2C4359C9.0EB89938-ONC1257666.00299975-C1257666.002C206F@transmode.se>
>
> Scott Wood <scottwood@freescale.com> wrote on 06/11/2009 01:33:05:
> >
> > On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> > > Here is the latest(last?) round of this series. I
> > > hope I got everything right now.
> > > Scott and Rex, please test and send ACK/NACK.
> > >
> > > Jocke
> > >
> > > Joakim Tjernlund (8):
> > > 8xx: invalidate non present TLBs
> >
> > This works, and is an important fix -- it should be applied even if the rest
> > of the patchset isn't ready.
>
> True.
>
> >
> > > 8xx: Update TLB asm so it behaves as linux mm expects.
>
> I think this is ready too.
>
> > > 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
> >
> > Up through this point works.
>
> hmm, here tagging of DAR is in place, do you ever hit the
> page fault handler with address == 0x00f0? If you do,
> the kernel somehow manges to fix it instead of erroring out.
>
> I do notice one thing, I forgot to add the CPU6 errata to
> the DAR tagging. Are you using the CPU6 errata?
DAR isn't affected by CPU6 so this should not be a problem.
>
> >
> > > 8xx: Fixup DAR from buggy dcbX instructions.
> >
> > With this, the kernel hangs after "Mount-cache hash table entries: 512".
>
> Somewhat surprising result. I didn't expect you would even hit this
> condition now as we haven't enabled the use of dcbX insn yet.
> The only thing I can think of is the you hit the 0x00f0 due to other
> dcbX insn use and the kernel managed to fixup this in the page fault handler
> by pure luck before.
>
> The only thing I can thing of being wrong here is your suggested fix:
> + lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
> + ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
> + rlwimi r11, r10, 22, 0xffc
>
> What if you change that back to what worked for you before:
> lis r11, swapper_pg_dir@h
> ori r11, r11, swapper_pg_dir@l
> rlwinm r11, r11, 0, 0x3ffff000
> rlwimi r11, r10, 22, 0xffc
> or possibly
> lis r11, swapper_pg_dir@h
> ori r11, r11, swapper_pg_dir@l
> subis r11, r11, PAGE_OFFSET@h
> rlwimi r11, r10, 22, 0xffc
>
> hmm, some missed CPU6 errata calls in DARFixup too.
Same here, not a problem
I did notice a bug that has been there a long time so
I don't think it is the problem:
+ add r10, r10, r25 ;b 151f
+ add r10, r10, r25 ;b 151f
should be r26 instead:
+ add r10, r10, r25 ;b 151f
+ add r10, r10, r26 ;b 151f
Jocke
^ 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