* [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the stock linux-2.5
From: Vitaly @ 2005-04-13 15:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
Kumar,
This patch adds support for the MPC8272ADS PCI bridge.
The stuff that alters delay after RST deassertion relative to the
current PCI frequency included (thus it will wait for 1 second if PCI
bus is 33MHz).
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 2005-04-12-8272ADS.patch --]
[-- Type: text/x-patch, Size: 17613 bytes --]
===== arch/ppc/Kconfig 1.109 vs edited =====
--- 1.109/arch/ppc/Kconfig 2005-04-04 07:03:47 +04:00
+++ edited/arch/ppc/Kconfig 2005-04-12 16:47:48 +04:00
@@ -1123,7 +1123,7 @@
config PCI_8260
bool
- depends on PCI && 8260 && !8272
+ depends on PCI && 8260
default y
config 8260_PCI9
===== arch/ppc/platforms/pq2ads.h 1.3 vs edited =====
--- 1.3/arch/ppc/platforms/pq2ads.h 2005-01-16 01:01:51 +03:00
+++ edited/arch/ppc/platforms/pq2ads.h 2005-04-12 19:57:14 +04:00
@@ -49,10 +49,10 @@
/* PCI interrupt controller */
#define PCI_INT_STAT_REG 0xF8200000
#define PCI_INT_MASK_REG 0xF8200004
-#define PIRQA (NR_SIU_INTS + 0)
-#define PIRQB (NR_SIU_INTS + 1)
-#define PIRQC (NR_SIU_INTS + 2)
-#define PIRQD (NR_SIU_INTS + 3)
+#define PIRQA (NR_CPM_INTS + 0)
+#define PIRQB (NR_CPM_INTS + 1)
+#define PIRQC (NR_CPM_INTS + 2)
+#define PIRQD (NR_CPM_INTS + 3)
/*
* PCI memory map definitions for MPC8266ADS-PCI.
@@ -71,6 +71,7 @@
/* window for a PCI master to access MPC8266 memory */
#define PCI_SLV_MEM_LOCAL 0x00000000 /* Local base */
#define PCI_SLV_MEM_BUS 0x00000000 /* PCI base */
+#define PCI_SLV_MEM_SIZE 0x10000000 /* 256 Mb */
/* window for the processor to access PCI memory with prefetching */
#define PCI_MSTR_MEM_LOCAL 0x80000000 /* Local base */
@@ -83,9 +84,75 @@
#define PCI_MSTR_MEMIO_SIZE 0x20000000 /* 512MB */
/* window for the processor to access PCI I/O */
+#ifndef CONFIG_ADS8272
+
#define PCI_MSTR_IO_LOCAL 0xF4000000 /* Local base */
#define PCI_MSTR_IO_BUS 0x00000000 /* PCI base */
#define PCI_MSTR_IO_SIZE 0x04000000 /* 64MB */
+
+#else /* CONFIG_ADS8272 */
+
+#define PCI_MSTR_IO_LOCAL 0xF6000000 /* Local base */
+#define PCI_MSTR_IO_BUS 0x00000000 /* PCI base */
+#define PCI_MSTR_IO_SIZE 0x02000000 /* 64MB */
+
+/*-----------------------------------------------------------------------
+ * SIUMCR - SIU Module Configuration Register 4-31
+ */
+#define SIUMCR_BBD 0x80000000 /* Bus Busy Disable */
+#define SIUMCR_ESE 0x40000000 /* External Snoop Enable */
+#define SIUMCR_PBSE 0x20000000 /* Parity Byte Select Enable */
+#define SIUMCR_CDIS 0x10000000 /* Core Disable */
+#define SIUMCR_DPPC00 0x00000000 /* Data Parity Pins Configuration*/
+#define SIUMCR_DPPC01 0x04000000 /* - " - */
+#define SIUMCR_DPPC10 0x08000000 /* - " - */
+#define SIUMCR_DPPC11 0x0c000000 /* - " - */
+#define SIUMCR_L2CPC00 0x00000000 /* L2 Cache Pins Configuration */
+#define SIUMCR_L2CPC01 0x01000000 /* - " - */
+#define SIUMCR_L2CPC10 0x02000000 /* - " - */
+#define SIUMCR_L2CPC11 0x03000000 /* - " - */
+#define SIUMCR_LBPC00 0x00000000 /* Local Bus Pins Configuration */
+#define SIUMCR_LBPC01 0x00400000 /* - " - */
+#define SIUMCR_LBPC10 0x00800000 /* - " - */
+#define SIUMCR_LBPC11 0x00c00000 /* - " - */
+#define SIUMCR_APPC00 0x00000000 /* Address Parity Pins Configuration*/
+#define SIUMCR_APPC01 0x00100000 /* - " - */
+#define SIUMCR_APPC10 0x00200000 /* - " - */
+#define SIUMCR_APPC11 0x00300000 /* - " - */
+#define SIUMCR_CS10PC00 0x00000000 /* CS10 Pin Configuration */
+#define SIUMCR_CS10PC01 0x00040000 /* - " - */
+#define SIUMCR_CS10PC10 0x00080000 /* - " - */
+#define SIUMCR_CS10PC11 0x000c0000 /* - " - */
+#define SIUMCR_BCTLC00 0x00000000 /* Buffer Control Configuration */
+#define SIUMCR_BCTLC01 0x00010000 /* - " - */
+#define SIUMCR_BCTLC10 0x00020000 /* - " - */
+#define SIUMCR_BCTLC11 0x00030000 /* - " - */
+#define SIUMCR_MMR00 0x00000000 /* Mask Masters Requests */
+#define SIUMCR_MMR01 0x00004000 /* - " - */
+#define SIUMCR_MMR10 0x00008000 /* - " - */
+#define SIUMCR_MMR11 0x0000c000 /* - " - */
+#define SIUMCR_LPBSE 0x00002000 /* LocalBus Parity Byte Select Enable*/
+
+/*-----------------------------------------------------------------------
+ * SCCR - System Clock Control Register 9-8
+ */
+#define SCCR_PCI_MODE 0x00000100 /* PCI Mode */
+#define SCCR_PCI_MODCK 0x00000080 /* Value of PCI_MODCK pin */
+#define SCCR_PCIDF_MSK 0x00000078 /* PCI division factor */
+#define SCCR_PCIDF_SHIFT 3
+
+#endif
+
+#if defined(CONFIG_ADS8272)
+#define PCI_INT_TO_SIU SIU_INT_IRQ2
+#elif defined(CONFIG_PQ2FADS)
+#define PCI_INT_TO_SIU SIU_INT_IRQ6
+#else
+#warning PCI Bridge will be without interrupts support
+#endif
+
+#define POTA_ADDR_SHIFT 12
+#define PITA_ADDR_SHIFT 12
#define _IO_BASE PCI_MSTR_IO_LOCAL
#define _ISA_MEM_BASE PCI_MSTR_MEMIO_LOCAL
===== arch/ppc/syslib/Makefile 1.51 vs edited =====
--- 1.51/arch/ppc/syslib/Makefile 2005-03-31 14:59:04 +04:00
+++ edited/arch/ppc/syslib/Makefile 2005-04-12 16:47:50 +04:00
@@ -82,6 +82,9 @@
todc_time.o
obj-$(CONFIG_8260) += m8260_setup.o
obj-$(CONFIG_PCI_8260) += m8260_pci.o indirect_pci.o
+ifeq ($(CONFIG_ADS8272),y)
+obj-$(CONFIG_PCI) += pci_auto.o
+endif
obj-$(CONFIG_8260_PCI9) += m8260_pci_erratum9.o
obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
ifeq ($(CONFIG_PPC_GEN550),y)
===== arch/ppc/syslib/m8260_pci.c 1.2 vs edited =====
--- 1.2/arch/ppc/syslib/m8260_pci.c 2004-06-17 16:57:15 +04:00
+++ edited/arch/ppc/syslib/m8260_pci.c 2005-04-12 19:56:31 +04:00
@@ -1,4 +1,7 @@
/*
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
* (C) Copyright 2003
* Wolfgang Denk, DENX Software Engineering, wd@denx.de.
*
@@ -28,6 +31,8 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -38,12 +43,144 @@
#include <asm/immap_cpm2.h>
#include <asm/mpc8260.h>
+#if !defined(CONFIG_ADS8272) || !defined(CONFIG_PQ2FADS)
#include "m8260_pci.h"
+#endif
+
+/*
+ * Interrupt routing
+ */
+
+static inline int
+pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
+ { PIRQA, PIRQB, PIRQC, PIRQD }, /* IDSEL 22 - PCI slot 0 */
+ { PIRQD, PIRQA, PIRQB, PIRQC }, /* IDSEL 23 - PCI slot 1 */
+ { PIRQC, PIRQD, PIRQA, PIRQB }, /* IDSEL 24 - PCI slot 2 */
+ };
+
+ const long min_idsel = 22, max_idsel = 24, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+static void
+pq2pci_mask_irq(unsigned int irq)
+{
+ int bit = irq - NR_CPM_INTS;
+
+ *(volatile unsigned long *) PCI_INT_MASK_REG |= (1 << (31 - bit));
+ return;
+}
+
+static void
+pq2pci_unmask_irq(unsigned int irq)
+{
+ int bit = irq - NR_CPM_INTS;
+
+ *(volatile unsigned long *) PCI_INT_MASK_REG &= ~(1 << (31 - bit));
+ return;
+}
+
+static void
+pq2pci_mask_and_ack(unsigned int irq)
+{
+ int bit = irq - NR_CPM_INTS;
+
+ *(volatile unsigned long *) PCI_INT_MASK_REG |= (1 << (31 - bit));
+ return;
+}
+
+static void
+pq2pci_end_irq(unsigned int irq)
+{
+ int bit = irq - NR_CPM_INTS;
+
+ *(volatile unsigned long *) PCI_INT_MASK_REG &= ~(1 << (31 - bit));
+ return;
+}
+
+struct hw_interrupt_type pq2pci_ic = {
+ "PQ2 PCI",
+ NULL,
+ NULL,
+ pq2pci_unmask_irq,
+ pq2pci_mask_irq,
+ pq2pci_mask_and_ack,
+ pq2pci_end_irq,
+ 0
+};
+
+static irqreturn_t
+pq2pci_irq_demux(int irq, void *dev_id, struct pt_regs *regs)
+{
+ unsigned long stat, mask, pend;
+ int bit;
+
+ for(;;) {
+ stat = *(volatile unsigned long *) PCI_INT_STAT_REG;
+ mask = *(volatile unsigned long *) PCI_INT_MASK_REG;
+ pend = stat & ~mask & 0xf0000000;
+ if (!pend)
+ break;
+ for (bit = 0; pend != 0; ++bit, pend <<= 1) {
+ if (pend & 0x80000000)
+ __do_IRQ(NR_CPM_INTS + bit, regs);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
+static struct irqaction pq2pci_irqaction = {
+ .handler = pq2pci_irq_demux,
+ .flags = SA_INTERRUPT,
+ .mask = CPU_MASK_NONE,
+ .name = "PQ2 PCI cascade",
+};
+
+
+void
+pq2pci_init_irq(void)
+{
+ int irq;
+ volatile cpm2_map_t *immap = cpm2_immr;
+#ifdef CONFIG_ADS8272
+ /* configure chip select for PCI interrupt controller */
+ immap->im_memctl.memc_br3 = PCI_INT_STAT_REG | 0x00001801;
+ immap->im_memctl.memc_or3 = 0xffff8010;
+#endif
+ for (irq = NR_CPM_INTS; irq < NR_CPM_INTS + 4; irq++)
+ irq_desc[irq].handler = &pq2pci_ic;
+
+ /* make PCI IRQ level sensitive */
+ immap->im_intctl.ic_siexr &=
+ ~(1 << (14 - (PCI_INT_TO_SIU - SIU_INT_IRQ1)));
+
+ /* mask all PCI interrupts */
+ *(volatile unsigned long *) PCI_INT_MASK_REG |= 0xfff00000;
+
+ /* install the demultiplexer for the PCI cascade interrupt */
+ setup_irq(PCI_INT_TO_SIU, &pq2pci_irqaction);
+ return;
+}
+
+static int
+pq2pci_exclude_device(u_char bus, u_char devfn)
+{
+ return PCIBIOS_SUCCESSFUL;
+}
/* PCI bus configuration registers.
*/
+#ifndef CONFIG_ADS8272
static void __init m8260_setup_pci(struct pci_controller *hose)
{
volatile cpm2_map_t *immap = cpm2_immr;
@@ -146,10 +283,148 @@
tempShort | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
}
-void __init m8260_find_bridges(void)
+#else /* setup hardware for 8272ADS and PQ2FADS */
+
+static void
+pq2ads_setup_pci(struct pci_controller *hose)
+{
+ __u32 val;
+ volatile cpm2_map_t *immap = cpm2_immr;
+ bd_t* binfo = (bd_t*) __res;
+ u32 sccr = immap->im_clkrst.car_sccr;
+ uint pci_div,freq,time;
+ /* PCI int lowest prio */
+ /* Each 4 bits is a device bus request and the MS 4bits
+ is highest priority */
+ /* Bus 4bit value
+ --- ----------
+ CPM high 0b0000
+ CPM middle 0b0001
+ CPM low 0b0010
+ PCI reguest 0b0011
+ Reserved 0b0100
+ Reserved 0b0101
+ Internal Core 0b0110
+ External Master 1 0b0111
+ External Master 2 0b1000
+ External Master 3 0b1001
+ The rest are reserved
+ */
+ immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x61207893;
+ /* park bus on core */
+ immap->im_siu_conf.siu_82xx.sc_ppc_acr = PPC_ACR_BUS_PARK_CORE;
+ /*
+ * Set up master windows that allow the CPU to access PCI space. These
+ * windows are set up using the two SIU PCIBR registers.
+ */
+
+ immap->im_memctl.memc_pcimsk0 = ~(PCI_MSTR_IO_SIZE - 1U);
+ immap->im_memctl.memc_pcibr0 = PCI_MSTR_IO_LOCAL | PCIBR_ENABLE;
+
+ immap->im_memctl.memc_pcimsk1 = ~(PCI_MSTR_MEM_SIZE + PCI_MSTR_MEMIO_SIZE - 1U);
+ immap->im_memctl.memc_pcibr1 = PCI_MSTR_MEM_LOCAL | PCIBR_ENABLE;
+#ifdef CONFIG_ADS8272
+ immap->im_siu_conf.siu_82xx.sc_siumcr = (immap->im_siu_conf.siu_82xx.sc_siumcr &
+ ~SIUMCR_BBD &
+ ~SIUMCR_ESE &
+ ~SIUMCR_PBSE &
+ ~SIUMCR_CDIS &
+ ~SIUMCR_DPPC11 &
+ ~SIUMCR_L2CPC11 &
+ ~SIUMCR_LBPC11 &
+ ~SIUMCR_APPC11 &
+ ~SIUMCR_CS10PC11 &
+ ~SIUMCR_BCTLC11 &
+ ~SIUMCR_MMR11)
+ | SIUMCR_DPPC11 | SIUMCR_L2CPC01 | SIUMCR_LBPC00
+ | SIUMCR_APPC10 | SIUMCR_CS10PC00 | SIUMCR_BCTLC00 | SIUMCR_MMR11;
+#elif defined CONFIG_PQ2FADS
+ /*
+ * Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
+ * and local bus for PCI (SIUMCR [LBPC]).
+ */
+ immap->im_siu_conf.siu_82xx.sc_siumcr = (immap->im_siu_conf.sc_siumcr &
+ ~SIUMCR_LBPC11 &
+ ~SIUMCR_CS10PC11 &
+ ~SIUMCR_LBPC11) |
+ SIUMCR_LBPC01 | SIUMCR_CS10PC01 | SIUMCR_APPC10;
+#endif
+ /* Enable PCI */
+ immap->im_pci.pci_gcr = cpu_to_le32(PCIGCR_PCI_BUS_EN);
+
+ pci_div = ( (sccr & SCCR_PCI_MODCK) ? 2 : 1) *
+ ( ( (sccr & SCCR_PCIDF_MSK) >> SCCR_PCIDF_SHIFT) + 1);
+ freq = (uint)((2*binfo->bi_cpmfreq)/(pci_div));
+ time = (int)666666/freq;
+ /* due to PCI Local Bus spec, some devices needs to wait such a long
+ time after RST deassertion. More specifically, 0.508s for 66MHz & twice more for 33 */
+ printk("%s: The PCI bus is %d Mhz.\nWaiting %s after deasserting RST...\n",__FILE__,freq,
+ (time==1) ? "0.5 seconds":"1 second" );
+
+ {
+ int i;
+ for(i=0;i<(500*time);i++)
+ udelay(1000);
+ }
+
+ /* setup ATU registers */
+ immap->im_pci.pci_pocmr0 = cpu_to_le32(POCMR_ENABLE | POCMR_PCI_IO |
+ ((~(PCI_MSTR_IO_SIZE - 1U)) >> POTA_ADDR_SHIFT));
+ immap->im_pci.pci_potar0 = cpu_to_le32(PCI_MSTR_IO_BUS >> POTA_ADDR_SHIFT);
+ immap->im_pci.pci_pobar0 = cpu_to_le32(PCI_MSTR_IO_LOCAL >> POTA_ADDR_SHIFT);
+
+ /* Set-up non-prefetchable window */
+ immap->im_pci.pci_pocmr1 = cpu_to_le32(POCMR_ENABLE | ((~(PCI_MSTR_MEMIO_SIZE-1U)) >> POTA_ADDR_SHIFT));
+ immap->im_pci.pci_potar1 = cpu_to_le32(PCI_MSTR_MEMIO_BUS >> POTA_ADDR_SHIFT);
+ immap->im_pci.pci_pobar1 = cpu_to_le32(PCI_MSTR_MEMIO_LOCAL >> POTA_ADDR_SHIFT);
+
+ /* Set-up prefetchable window */
+ immap->im_pci.pci_pocmr2 = cpu_to_le32(POCMR_ENABLE |POCMR_PREFETCH_EN |
+ (~(PCI_MSTR_MEM_SIZE-1U) >> POTA_ADDR_SHIFT));
+ immap->im_pci.pci_potar2 = cpu_to_le32((PCI_MSTR_MEM_BUS) >> POTA_ADDR_SHIFT);
+ immap->im_pci.pci_pobar2 = cpu_to_le32((PCI_MSTR_MEM_LOCAL) >> POTA_ADDR_SHIFT);
+
+ /* Inbound transactions from PCI memory space */
+ immap->im_pci.pci_picmr0 = cpu_to_le32(PICMR_ENABLE | PICMR_PREFETCH_EN |
+ ((~(PCI_SLV_MEM_SIZE-1U)) >> PITA_ADDR_SHIFT));
+ immap->im_pci.pci_pibar0 = cpu_to_le32(PCI_SLV_MEM_BUS >> PITA_ADDR_SHIFT);
+ immap->im_pci.pci_pitar0 = cpu_to_le32(PCI_SLV_MEM_LOCAL>> PITA_ADDR_SHIFT);
+
+#if defined CONFIG_ADS8272
+ /* PCI int highest prio */
+ immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x01236745;
+#elif defined CONFIG_PQ2FADS
+ immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x03124567;
+#endif
+ /* park bus on PCI */
+ immap->im_siu_conf.siu_82xx.sc_ppc_acr = PPC_ACR_BUS_PARK_PCI;
+
+ /* Enable bus mastering and inbound memory transactions */
+ early_read_config_dword(hose, hose->first_busno, 0, PCI_COMMAND, &val);
+ val &= 0xffff0000;
+ val |= PCI_COMMAND_MEMORY|PCI_COMMAND_MASTER;
+ early_write_config_dword(hose, hose->first_busno, 0, PCI_COMMAND, val);
+
+}
+
+static void pq2ads_setup_hose(struct pci_controller * hose)
+{
+ hose->io_space.start = MPC826x_PCI_LOWER_IO;
+ hose->io_space.end = MPC826x_PCI_UPPER_IO;
+ hose->mem_space.start = MPC826x_PCI_LOWER_MEM;
+ hose->mem_space.end = MPC826x_PCI_UPPER_MMIO;
+ hose->io_base_virt = (void*)MPC826x_PCI_IO_BASE;
+ isa_io_base = MPC826x_PCI_IO_BASE;
+}
+
+#endif
+
+
+void __init pq2_find_bridges(void)
{
extern int pci_assign_all_busses;
struct pci_controller * hose;
+ int host_bridge;
pci_assign_all_busses = 1;
@@ -164,18 +439,45 @@
hose->bus_offset = 0;
hose->last_busno = 0xff;
+#ifdef CONFIG_ADS8272
+ hose->set_cfg_type = 1;
+#endif
+
setup_m8260_indirect_pci(hose,
(unsigned long)&cpm2_immr->im_pci.pci_cfg_addr,
(unsigned long)&cpm2_immr->im_pci.pci_cfg_data);
+ /* Make sure it is a supported bridge */
+ early_read_config_dword(hose,
+ 0,
+ PCI_DEVFN(0,0),
+ PCI_VENDOR_ID,
+ &host_bridge);
+ switch (host_bridge) {
+ case PCI_DEVICE_ID_MPC8265:
+ break;
+ case PCI_DEVICE_ID_MPC8272:
+ break;
+ default:
+ printk("Attempting to use unrecognized host bridge ID"
+ " 0x%08x.\n", host_bridge);
+ break;
+ }
+
+#if defined(CONFIG_ADS8272) || defined(CONFIG_PQ2FADS)
+ pq2ads_setup_pci(hose);
+ pq2ads_setup_hose(hose);
+#else
m8260_setup_pci(hose);
+
hose->pci_mem_offset = MPC826x_PCI_MEM_OFFSET;
- isa_io_base =
+ isa_io_base =
(unsigned long) ioremap(MPC826x_PCI_IO_BASE,
MPC826x_PCI_IO_SIZE);
hose->io_base_virt = (void *) isa_io_base;
-
+#endif
+
/* setup resources */
pci_init_resource(&hose->mem_resources[0],
MPC826x_PCI_LOWER_MEM,
@@ -191,4 +493,15 @@
MPC826x_PCI_LOWER_IO,
MPC826x_PCI_UPPER_IO,
IORESOURCE_IO, "PCI I/O");
+
+#if defined(CONFIG_ADS8272) || defined(CONFIG_PQ2FADS)
+ ppc_md.pci_exclude_device = pq2pci_exclude_device;
+ hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+
+ ppc_md.pci_map_irq = pq2pci_map_irq;
+ ppc_md.pcibios_fixup = NULL;
+ ppc_md.pcibios_fixup_bus = NULL;
+
+#endif
+
}
===== arch/ppc/syslib/m8260_setup.c 1.30 vs edited =====
--- 1.30/arch/ppc/syslib/m8260_setup.c 2005-03-31 14:59:04 +04:00
+++ edited/arch/ppc/syslib/m8260_setup.c 2005-04-12 16:47:51 +04:00
@@ -34,7 +34,8 @@
unsigned char __res[sizeof(bd_t)];
extern void cpm2_reset(void);
-extern void m8260_find_bridges(void);
+extern void pq2_find_bridges(void);
+extern void pq2pci_init_irq(void);
extern void idma_pci9_init(void);
/* Place-holder for board-specific init */
@@ -56,7 +57,11 @@
idma_pci9_init();
#endif
#ifdef CONFIG_PCI_8260
+#if defined(CONFIG_ADS8272) || defined(CONFIG_PQ2FADS)
+ pq2_find_bridges();
+#else
m8260_find_bridges();
+#endif
#endif
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -173,6 +178,12 @@
* in case the boot rom changed something on us.
*/
cpm2_immr->im_intctl.ic_siprr = 0x05309770;
+
+#if defined(CONFIG_PCI) && (defined(CONFIG_ADS8272) || defined(CONFIG_ADS8272))
+ /* Initialize stuff for the 82xx CPLD IC and install demux */
+ pq2pci_init_irq();
+#endif
+
}
/*
@@ -195,6 +206,9 @@
m8260_map_io(void)
{
uint addr;
+#if defined(CONFIG_PCI) && (defined(CONFIG_ADS8272) || defined(CONFIG_ADS8272))
+ io_block_mapping(0x80000000,0x80000000,0x10000000, _PAGE_IO);
+#endif
/* Map IMMR region to a 256MB BAT */
addr = (cpm2_immr != NULL) ? (uint)cpm2_immr : CPM_MAP_ADDR;
===== include/asm-ppc/m8260_pci.h 1.1 vs edited =====
--- 1.1/include/asm-ppc/m8260_pci.h 2004-06-17 02:56:05 +04:00
+++ edited/include/asm-ppc/m8260_pci.h 2005-04-12 17:17:29 +04:00
@@ -19,6 +19,7 @@
* Define the vendor/device ID for the MPC8265.
*/
#define PCI_DEVICE_ID_MPC8265 ((0x18C0 << 16) | PCI_VENDOR_ID_MOTOROLA)
+#define PCI_DEVICE_ID_MPC8272 ((0x18C1 << 16) | PCI_VENDOR_ID_MOTOROLA)
#define M8265_PCIBR0 0x101ac
#define M8265_PCIBR1 0x101b0
^ permalink raw reply
* RE: bdi2000 + mpc8560ads, very early breakpoints
From: Fahd Abidi @ 2005-04-13 13:37 UTC (permalink / raw)
To: Kylo Ginsberg, linuxppc-embedded
Try the suggestions pointed out in here:
http://www.ultsol.com/faq-P308.htm
This is based off suggestions from another customer. Let me know if this
works for you or not.
Fahd
-----Original Message-----
From: Kylo Ginsberg [mailto:kylo@veriwave.com]=20
Sent: Tuesday, April 12, 2005 3:21 PM
To: linuxppc-embedded@ozlabs.org
Subject: bdi2000 + mpc8560ads, very early breakpoints
I'm running a bdi2000 (with mpc85xx-gdb f/w 1.03) with a mpc8560ads=20
target, and I'm trying to set breakpoints early on in linux startup (in=20
the head_e500.S code that sets up tlb's). I'm setting the breakpoints=20
from within the bdi telnet interface.
I can:
--succesfully hit a breakpoint set up to any instruction <=3D the =
address=20
of the first 'tlbwe'.
--single step (with the bdi "TI" command) past that 'tlbwe' as far as=20
I've cared to try
I cannot:
--hit a breakpoint once the first 'tlbwe' has executed. If I attempt to
do so, linux startup doesn't proceed, I lose further communication with=20
the target and the BDI claims "COP Freeze" and I have to reset the
target.
Btw, the 'tlbwe' in question marks invalid the first tlb1 entry setup by
u-boot, which pointed at flash address space. Code is running out of=20
ram at this point.
I'm probably missing something very basic here. Any ideas?
Thanks,
Kylo
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-13 12:32 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <20050413051326.GA12632@gate.ebshome.net>
On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> Then do it. It should be trivial to unwind the stack and much simpler
> than moving this code to process context.
Actually, Im not too sure what is required to put something in kernel
in process context. Maybe its alot harder than I think it is...
> I think it's a bad idea. You are trying to workaround a problem
> instead of fixing it. My experience shows that sooner or later it'll
> come back and hit you anyway :).
I'm with you on this. It just that I didnt think putting my code in
process context would be regarded as workaround. Since kernel itself
ran fine, only after putting in my change it caused problem, I simply
thought that putting changes to code that was already there is more
severe than making further changes to what I've done. At least this
way, change is still within my domain.
But again, if putting my function in process context is that hard..
okay I better think otherwise :)
--=20
Daniel
^ permalink raw reply
* Re: cpm_uart console problems?
From: Robert P. J. Day @ 2005-04-13 11:52 UTC (permalink / raw)
To: Tsang, Chi Kit; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <797470E884C6D611B7A500B0D0AA56D0F195AE@batistuta.spider.com>
On Wed, 13 Apr 2005, Tsang, Chi Kit wrote:
> ttyCPM0 at MMIO 0xf0011a80 (irq = 4) is a CPM UART
> ...
> ...
>
> I currently do not specify the "console=ttyCPM" in my boot command
> line. Would this be an issue?
this may or may not help you but, with my 8xx board, i had to add
"console=ttyCPM0,9600" to my boot command line.
rday
^ permalink raw reply
* Re: cpm_uart console problems?
From: Vitaly Bordug @ 2005-04-13 11:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <797470E884C6D611B7A500B0D0AA56D0F195AE@batistuta.spider.com>
Tsang, Chi Kit wrote:
>Hi,
>
>I am working on an 8260 based board and currently cannot get
>the serial (running on SMC 1) to work using the 2.6.11 kernel.
>The last message I see in my console is: "Now booting the
>kernel".
>
>
>
>I currently do not specify the "console=ttyCPM" in my boot command
>line. Would this be an issue?
>
>
>
Well, I think so. I don't have 8260 but with similar cpm2 board with
"console=ttyCPM0,115200 " parameter serial console works fine.
>I have tried to add "console=ttyCPM" to my boot command line but in
>such cases, the kernel would fail to boot. Using some LEDs as debug,
>I tracked down the hang which seems to happen during cpm_uart_console_write.
>This is as far as I got.
>
>
>
Because there is no such console device...
>I am running with devfs enabled in the kernel. Does the cpm_uart
>driver work with devfs?
>
>
>
Yes, but not very good actually, as far as devfs seems to be
deprecated. At least on my 8272ADS.
>As an aside, I have ported the 2.6.5 kernel to my 8260 based board and
>both ethernet (FCC 1) and serial (SMC 1) worked okay using this particular
>kernel.
>
>Any suggestions/ideas would be much appreciated.
>
>Thanks,
>Chi
>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* cpm_uart console problems?
From: Tsang, Chi Kit @ 2005-04-13 11:01 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi,
I am working on an 8260 based board and currently cannot get
the serial (running on SMC 1) to work using the 2.6.11 kernel.
The last message I see in my console is: "Now booting the
kernel".
I currently use NFS root for mounting the root filesystem.
Despite not seeing any output from the serial console, the
board does actually boot up and I can telnet in okay. Here is
what I see in:
/proc/interrupts:
CPU0
4: 0 CPM2 SIU Edge cpm_uart
32: 23184 CPM2 SIU Edge fenet
BAD: 793
/proc/devices:
Character devices:
1 mem
2 pty
3 ttyp
4 /dev/vc/0
4 tty
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
128 ptm
136 pts
204 ttyCPM
254 devfs
Block devices:
There are no block devices installed.
In /dev, I see:
crw--w--w- 1 root root 204, 46 Jan 1 00:32 ttyCPM0
And when I do "dmesg", I see:
...
...
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a80 (irq = 4) is a CPM UART
...
...
I currently do not specify the "console=ttyCPM" in my boot command
line. Would this be an issue?
I have tried to add "console=ttyCPM" to my boot command line but in
such cases, the kernel would fail to boot. Using some LEDs as debug,
I tracked down the hang which seems to happen during cpm_uart_console_write.
This is as far as I got.
I am running with devfs enabled in the kernel. Does the cpm_uart
driver work with devfs?
As an aside, I have ported the 2.6.5 kernel to my 8260 based board and
both ethernet (FCC 1) and serial (SMC 1) worked okay using this particular
kernel.
Any suggestions/ideas would be much appreciated.
Thanks,
Chi
^ permalink raw reply
* Re: Dynamic changing of Hz value
From: Geert Uytterhoeven @ 2005-04-13 11:12 UTC (permalink / raw)
To: Garcia Jérémie; +Cc: Linux/PPC Development
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B21@exnet.3il.fr>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1165 bytes --]
On Wed, 13 Apr 2005, [iso-8859-1] Garcia Jérémie wrote:
> I'm working on a project that needs the clock granularity changed from 10ms to 5ms while running.
> So as a kernel newbie, I understand that I have to deal with the HZ value. I read a lot of things on it through many forums and mailing lists but they always talk about it in a static way (how to fix a value different from 100) as with the Robert love's patch. What I would like to do is to code a routine that allows to modify the HZ value dynamically but the more I read about it and the more I begin to think that it is not possible.
> Could someone tell me if, first of all, it is possible? If yes, what would be the process?
>
> Note: I'm using a linux montavista pro 3.1 ( kernel 2.4.20 ) with a powerPC 405EP
Googling for `dynamic HZ' gives http://kerneltrap.org/node/4393
It's for 2.6, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Can you suggest a small FTP utility for Linux suitable for embedded systems?
From: Robert P. J. Day @ 2005-04-13 10:58 UTC (permalink / raw)
To: Vijay Padiyar; +Cc: BusyBox Support, LinuxPPC Support
In-Reply-To: <BAY1-DAV1171F1D6CBF80125D8198D8B340@phx.gbl>
On Wed, 13 Apr 2005, Vijay Padiyar wrote:
> Hi there
>
> I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260
> target. Since BusyBox currently doesn't appear to provide an FTP
> server utility, I wanted to know where I can get a small FTP utility
> for Linux that doesn't take up much space and is suitable for
> embedded applications.
whoops, sorry, i just noticed the word "server" in there. my previous
post referred just to a client. sorry.
rday
^ permalink raw reply
* Re: Can you suggest a small FTP utility for Linux suitable for embedded systems?
From: Robert P. J. Day @ 2005-04-13 10:57 UTC (permalink / raw)
To: Vijay Padiyar; +Cc: BusyBox Support, LinuxPPC Support
In-Reply-To: <BAY1-DAV1171F1D6CBF80125D8198D8B340@phx.gbl>
On Wed, 13 Apr 2005, Vijay Padiyar wrote:
> Hi there
>
> I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260
> target. Since BusyBox currently doesn't appear to provide an FTP
> server utility, I wanted to know where I can get a small FTP utility
> for Linux that doesn't take up much space and is suitable for
> embedded applications.
we're using "ftplib", which comes with both the library and the "qftp"
client. seems to run well on our 8xx board alongside busybox-1.00.
rday
^ permalink raw reply
* Bamboo, PCI and 33Mhz
From: Andriy Korud @ 2005-04-13 10:01 UTC (permalink / raw)
To: linuxppc-embedded
Hi,=20
does anybody has PCI working at 33MHz on bamoo board with 2.6 linux?
I've spent a lot time on it, at 66MHz PCI works like a charm, but at =
33MHz there are problems wich make me completely stupid (details =
available if anybody interested).
AMCC's support is willing to help, but as for now - with moderate =
success.
Best regards,
--
Andriy Korud=20
software engineer=20
http://www.vector.com.pl/
^ permalink raw reply
* Dynamic changing of Hz value
From: Garcia Jérémie @ 2005-04-13 10:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I'm working on a project that needs the clock granularity changed from =
10ms to 5ms while running.
So as a kernel newbie, I understand that I have to deal with the HZ =
value. I read a lot of things on it through many forums and mailing =
lists but they always talk about it in a static way (how to fix a value =
different from 100) as with the Robert love's patch. What I would like =
to do is to code a routine that allows to modify the HZ value =
dynamically but the more I read about it and the more I begin to think =
that it is not possible.
Could someone tell me if, first of all, it is possible? If yes, what =
would be the process?
Note: I'm using a linux montavista pro 3.1 ( kernel 2.4.20 ) with a =
powerPC 405EP
^ permalink raw reply
* Re: Can you suggest a small FTP utility for Linux suitable for embedded systems?
From: Jarno Manninen @ 2005-04-13 9:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <s25d2c02.087@EMAIL>
On Wednesday 13 April 2005 11:55, Rupesh S wrote:
> I know 'betaftpd' is small & suitable for small systems.
I'm not sure if these two are related but I have found
http://bftpd.sourceforge.net/
useful.
- Jarno
> >>> "Vijay Padiyar" <vijay_padiyar@hotmail.com> 04/13/05 02:00PM >>>
>
> Hi there
>
> I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260 target.
> Since BusyBox currently doesn't appear to provide an FTP server utility, I
> wanted to know where I can get a small FTP utility for Linux that doesn't
> take up much space and is suitable for embedded applications.
>
> Regards
>
> Vijay Padiyar
>
> http://www.vijaypadiyar.eu.tf
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Sound drivers for newer machines: need help
From: Demke Torsten-atd012 @ 2005-04-13 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, debian-powerpc, linuxppc-dev list
Hi,
just another one:
echo `cat /proc/device-tree/model`
PowerBook5,5
for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
Nothing
Regards,
Torsten
> -----Original Message-----
> From: linuxppc-dev-bounces@ozlabs.org
> [mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of Benjamin
> Herrenschmidt
> Sent: Samstag, 9. April 2005 02:31
> To: debian-powerpc@lists.debian.org; linuxppc-dev list
> Subject: Sound drivers for newer machines: need help
>
>
> Hi !
>
> If you have a newer machine, that is a machine released on or after
> 2002, can you please send me the output of:
>
> echo `cat /proc/device-tree/model`
>
> and
>
> for i in `find /proc/device-tree -name layout-id -print`; do
> echo $i && hexdump -n4 $i; done
>
> If the later returns nothing, it's fine, just tell me.
>
> I'm especially interested in the various models of G5 based
> machines. It
> seems apple is having all sorts of very different sound HW setups on
> those machines, and I'm trying to figure out exactly what is
> where based
> on those infos and the darwin sources.
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Can you suggest a small FTP utility for Linux suitable for embedded systems?
From: Rupesh S @ 2005-04-13 8:55 UTC (permalink / raw)
To: vijay_padiyar, busybox, linuxppc-embedded
I know 'betaftpd' is small & suitable for small systems.
--
Rupesh S
>>> "Vijay Padiyar" <vijay_padiyar@hotmail.com> 04/13/05 02:00PM >>>
Hi there
I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260 target.
Since BusyBox currently doesn't appear to provide an FTP server utility, I
wanted to know where I can get a small FTP utility for Linux that doesn't
take up much space and is suitable for embedded applications.
Regards
Vijay Padiyar
http://www.vijaypadiyar.eu.tf=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org=20
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Can you suggest a small FTP utility for Linux suitable for embedded systems?
From: Vijay Padiyar @ 2005-04-13 8:30 UTC (permalink / raw)
To: LinuxPPC Support, BusyBox Support
Hi there
I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260 target.
Since BusyBox currently doesn't appear to provide an FTP server utility, I
wanted to know where I can get a small FTP utility for Linux that doesn't
take up much space and is suitable for embedded applications.
Regards
Vijay Padiyar
http://www.vijaypadiyar.eu.tf
^ permalink raw reply
* Re: [PATCH 2.6.11+] ppc32: Make the Powerstack II Pro4000 boot again
From: Greg KH @ 2005-04-13 5:18 UTC (permalink / raw)
To: Leigh Brown; +Cc: Andrew Morton, linuxppc-dev, Tom Rini
In-Reply-To: <20050409113317.25ECF157F18@jar.solinno.co.uk>
On Sat, Apr 09, 2005 at 12:33:17PM +0100, Leigh Brown wrote:
> On Fri, 8 Apr 2005 07:54:31 -0700 Tom Rini wrote:
> > On Fri, Apr 08, 2005 at 12:36:02PM +0100, Leigh Brown wrote:
> > > Tom Rini said:
> > > > On Wed, Apr 06, 2005 at 03:47:13AM +0200, Christian wrote:
> > > >> Tom Rini wrote:
> > > >> > Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> > > >> > command-line works? Thanks.
> > > >>
> > > >> i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as
> > > >> Sven sugggested), but the scsi errors did not went away :(
> > > >>
> > > >> on a side note, and perhaps totally unrelated: i always have
> > > >> PROC_PREPRESIDUAL=y in my .config, but i never had /proc/residual as
> > > >> promised from the help text.
> > > >
> > > > Odd. I thought that only happened if you had no residual data at all
> > > > (which can happen on Powerstacks, esp if netbooting the kernel). But
> > > > in that case the new code shouldn't be hit at all. Leigh?
> > >
> > > Hi, I'm back from my holidays, and have had a look at this. As I spent
> > > lots of time understanding the horrendous mess that was
> > > prep_pcibios_fixup(), I'd be loath to back out the changes I made
> > > (especially as they work so well for me ;-) ).
> > >
> > > It turns out that prep_pib_init() is the culprit. Although it would
> > > appear to be coded for the non-openpic case, it obviously doesn't work.
> > > The old version of prep_pcibios_fixup() only called it if there is an
> > > openpic on the machine. We can restore that behaviour with the
> > > following patch:
> > >
> > > --- prep_pci.c.orig 2005-04-08 11:49:25.743718088 +0000
> > > +++ prep_pci.c 2005-04-08 12:23:00.541422280 +0000
> > > @@ -1245,8 +1245,13 @@
> > > pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> > > }
> > >
> > > - /* Setup the Winbond or Via PIB */
> > > - prep_pib_init();
> > > + /* Setup the Winbond or Via PIB - prep_pib_init() is coded for
> > > + * the non-openpic case, but it breaks (at least) the Utah
> > > + * (Powerstack II Pro4000), so only call it if we have an
> > > + * openpic.
> > > + */
> > > + if (have_openpic)
> > > + prep_pib_init();
> > > }
> > >
> > > static void __init
> > >
> > > I've no idea even what machines would be affected by this, but it
> > > fixes Sven's problem and restores the old behaviour, so that
> > > can't be bad.
> > >
> > > I guess fixing prep_pib_init() would be the better solution but
> > > I wouldn't know where to start. If this band-aid is good enough
> > > I can submit a proper patch, if you like.
> >
> > If this works, I'd like to see this get into 2.6.12. Please re-send to
> > akpm / this list. Assuming it's just the above:
> > Acked-by: Tom Rini <trini@kernel.crashing.org>
>
> On Fri, 8 Apr 2005 08:57:17 -0700, Tom Rini wrote:
> > On Fri, Apr 08, 2005 at 05:51:40PM +0200, Christian wrote:
> > > Tom Rini wrote:
> > > >
> > > > If this works, I'd like to see this get into 2.6.12. Please re-send to
> > > > akpm / this list. Assuming it's just the above:
> > > > Acked-by: Tom Rini <trini@kernel.crashing.org>
> > >
> > > yes! i just applied Leigh's patch (thanks!) to a pristine 2.6.11.6 and my
> > > PReP here booted fine:
> > > http://www.nerdbynature.de/bits/hal/2.6.11.6/leigh/
> >
> > Great. Leigh, can you also submit to gregkh for 2.6.11.7? Thanks.
>
> This patch restores the original behaviour of prep_pcibios_fixup() to
> only call prep_pib_init() on machines with an openpic. This allows
> the Powerstack II Pro4000 to boot again.
>
> Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
The proper place for -stable patches, is to have them sent to
stable@kernel.org with a valid changelog comment (not a ton of
context...)
Please do that, and it will be reviewed.
Also, is this patch already in mainline?
thanks,
greg k-h
^ permalink raw reply
* Re: MPC5200 I2S driver
From: Wolfgang Denk @ 2005-04-12 23:40 UTC (permalink / raw)
To: Eric N. Johnson (ACD); +Cc: linuxppc-embedded
In-Reply-To: <6.2.1.2.1.20050412173010.02adaaa0@mail.int.acdstar.com>
In message <6.2.1.2.1.20050412173010.02adaaa0@mail.int.acdstar.com> you wrote:
>
> Humm, any pointers on writing our own driver then then? Digging through
> the source for other drivers, bestcomm seems to be a real house of
> cards. We just want simple audio output capability. No need to make it
> work with the standard Linux/OSS sound API.
User the i2s_ring.c driver as model.
> Where can we keep track of the eratta/bugs in bestcomm? Browsing through
> the mailing list, I've found references that:
> IDE and Ethernet DMA can't work at the same time
> I2S TX and RX DMA can't work at the same time
> AC-97 is terminally broken (no way to handle the slot tags properly
> for variable sampling rates)
> Are these all still true?
This probably depends on your definition of "can't work". If you
allow for a failure every now and then under certain (more or less
exotic) usage conditions ... ;-)
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
I have been over into the future, and it works.
- Lincoln Steffens in _Letters_ (1938) vol. 1, p. 463
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Donald White @ 2005-04-13 6:05 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <9b7ca657050412215025872ce3@mail.gmail.com>
Maybe reading LINUX DEVICE DRIVERS would help. The third edition is
just out. While x86 centric, the book does explain the Linux driver
model, the kernel API, workqueues and such.
Don
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Eugene Surovegin @ 2005-04-13 5:13 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca657050412215025872ce3@mail.gmail.com>
On Wed, Apr 13, 2005 at 01:50:05PM +0900, Daniel Ann wrote:
> On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> > You don't need any locks, just pass correct gfp_mask parameter to
> > alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.
>
> Thing is, I'm not actually calling alloc_skb directly from my
> function. I'm calling notifier_call_chain() and somehow inadvertently
> it is getting called. If I was to give GFP_ATOMIC, then I'd have to
> first find the code that is responsible.
Then do it. It should be trivial to unwind the stack and much simpler
than moving this code to process context.
> Reading what John said earlier, rather than trying to find the code
> that is calling alloc_skb, I should be moving the calls to my
> fnuctions into process context.
I think it's a bad idea. You are trying to workaround a problem
instead of fixing it. My experience shows that sooner or later it'll
come back and hit you anyway :).
--
Eugene
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-13 4:50 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <20050412161230.GA18567@gate.ebshome.net>
On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> You don't need any locks, just pass correct gfp_mask parameter to
> alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.
Thing is, I'm not actually calling alloc_skb directly from my
function. I'm calling notifier_call_chain() and somehow inadvertently
it is getting called. If I was to give GFP_ATOMIC, then I'd have to
first find the code that is responsible.
Reading what John said earlier, rather than trying to find the code
that is calling alloc_skb, I should be moving the calls to my
fnuctions into process context.
So.. I'm gonna go ahead with John's suggestion.. but only problem now
is how do I move it to process context :P (May be more importantly,
how do I know that the code needs to be in process context or not?
which will prevent further headaches and possible coding a time bomb
:) )
--=20
Daniel
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-13 4:40 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <20050412135114.GB27920@tuxdriver.com>
On 4/12/05, John W. Linville <linville@tuxdriver.com> wrote:
> My guess would be that your best bet is to move your call to
> notifier_call_chain off to a workqueue. notifier_call_chain (and/or
> one or more of the functions it is calling) is likely written to
> expect to be in process context.
I was thinking that this might have something to do with BH stuff that
I've left out from reading. (rather complicated :P)
Forgive me for trying to take an easy way, but moving things to
workqueue, do you mean putting it in bottom half? (Im sorta guessing
bottom half is like something you do after finishing high priority
tasks)
(I guess you had this coming) How do you move it to the workqueue?
--=20
Daniel
^ permalink raw reply
* [PATCH] ppc32: Fix IDE related crash on wakeup
From: Benjamin Herrenschmidt @ 2005-04-13 4:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
Hi !
I noticed an occasional crash on wakeup from sleep on my powerbook
(strangly never happened before, probably timing related) that appears
to be due to a dangling interrupt while the chip is put to sleep and
beeing reset on wakeup.
This patch fixes is by disabling the irq in the ide pmac driver while
asleep and only re-enable it after the chip has been fully reset. This
is safe to do so as the interrupt of these apple IDE cells is never
shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/ide/ppc/pmac.c
===================================================================
--- linux-work.orig/drivers/ide/ppc/pmac.c 2005-04-13 10:53:39.000000000 +1000
+++ linux-work/drivers/ide/ppc/pmac.c 2005-04-13 14:17:41.000000000 +1000
@@ -1204,6 +1204,8 @@
}
#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
+ disable_irq(pmif->irq);
+
/* The media bay will handle itself just fine */
if (pmif->mediabay)
return 0;
@@ -1236,7 +1238,6 @@
ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif->node, pmif->aapl_bus_id, 1);
msleep(10);
ppc_md.feature_call(PMAC_FTR_IDE_RESET, pmif->node, pmif->aapl_bus_id, 0);
- msleep(jiffies_to_msecs(IDE_WAKEUP_DELAY));
/* Kauai has it different */
if (pmif->kauai_fcr) {
@@ -1244,11 +1245,15 @@
fcr |= KAUAI_FCR_UATA_RESET_N | KAUAI_FCR_UATA_ENABLE;
writel(fcr, pmif->kauai_fcr);
}
+
+ msleep(jiffies_to_msecs(IDE_WAKEUP_DELAY));
}
/* Sanitize drive timings */
sanitize_timings(pmif);
+ enable_irq(pmif->irq);
+
return 0;
}
^ permalink raw reply
* Re: Help needed Linux-2.6 - MPC8541
From: Junita Ajith @ 2005-04-13 0:39 UTC (permalink / raw)
To: Andy Fleming, linuxppc-embedded, pari
[-- Attachment #1: Type: text/plain, Size: 4393 bytes --]
Andy
1. The code hangs exaclty at the point where it looks for the 'graceful transmit/receive' bits set in the IEVENT register. (IEVENT_GRSC , IEVENT_GTSC) .
File - (linux-2.6/drivers/net/gianfar.c)
Function - static int gfar_probe(struct device *device) ;
In that ,we write Graceful Receive Stop and Graceful Transmit Stop, and then wait until the corresponding bits in IEVENT indicate the stops have completed.
This never happens and hence hangs at the 'while' loop inside that function.
2. We are using Linux-2.6.11
Here's the serial output dump with a few debug messages.
## Booting image at 02000000 ...
Image Name: PCIG8400-Rel-1.1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 883221 Bytes = 862.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 03000000 ...
Image Name: PCIG8400
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2751807 Bytes = 2.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fd12000, end 0ffb1d3f ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.11 (pari@sjswsvr11) (gcc version 3.3.2) #16 Tue Apr 5 11:19:57
PDT 2005
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram rw doPci=1
OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fcfbb000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 254720k available (1252k kernel code, 444k data, 292k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 2687k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing enabled
ttyS0 at MMIO 0xfdf04500 (irq = 90) is a 16550A
io scheduler noop registered inside elv_register()
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
Inside gfar_probe()
einfo Phy ID 7
gfar 1: additional data!
Inside alloc_etherdev() for eth-1072721560
start e0024000
Resetting MAC........
--2--MACCFG1 is 0x80000000
MACCFG2 is 0x 0
-2- tempval 000000db
-3- tempval 00000000
-4-1- tempval 00000000
-4-2- tempval 00000000
-4-2-a tempval 00000000
-4-3 tempval 00000000
-4-4 tempval 00000000
Before loop -5- after writing to IEVENT tempval
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
-5- after writing to IEVENT tempval 80000000
thanks,
Junita
Andy Fleming <afleming@freescale.com> wrote:
Could you send me what the kernel prints up to the point of the hang?
Also, what version of 2.6 are you using? The board interface for the
driver changed recently to support the new driver model.
Andy
On Apr 12, 2005, at 12:38, Junita Ajith wrote:
> Hi
> We are trying to port Linux-2.6 for our custom
> MPC8541 board.
>
> We have a TSEC and an FEC in the board.
>
> With the "Networking Support" disabled in the Kernel,
> the board boots up fine and gets to the prompt.
>
> But with the "Networking Support" enabled in the
> kernel the board hangs where it identifies the PHY,
> inspite of giving the corrct PHY ID.
>
>
> Any help is greatly appreciated.
>
> PS:
> We have linux-2.4 ported for the same board and so
> taking that as reference trying to port Linux-2.6 ,
> but havent succeeded yet.
>
> Thanks
> Junita
>
>
>
> __________________________________
> Do you Yahoo!?
> Make Yahoo! your home page
> http://www.yahoo.com/r/hs
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
---------------------------------
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
[-- Attachment #2: Type: text/html, Size: 5942 bytes --]
^ permalink raw reply
* 8xx UART TX > 8 data bits
From: Robin Gilks @ 2005-04-12 23:17 UTC (permalink / raw)
To: ppc embedded list
Greetings
I'm trying to get an SMC channel to operate as a UART with more than 8
data bits (13 in fact!!). Using a 2.4.22 kernel on a mpc859 (basic 866).
This means its going to be getting two half words from the BDs for each
'character'. With the constraints of the SMC requiring even addresses
etc for this mode of operation, does anyone know if it will work writing
2x8 bit characters at a time so as to keep the existing tty structure
for SMC handling?
I've tried tracing the tty layers by code inspection but I keep getting
lost in the indirections!! If I could find how the BDs are allocated as
a result of a character write, then perhaps I could make minor mods to
ensure memory allocs on an even address.
Could be that I'm totally off the wall but I'm trying for a 'minimum
effort' viability hack :-))
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* Re: MPC5200 I2S driver
From: Eric N. Johnson (ACD) @ 2005-04-12 22:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050412211342.B7C92C108D@atlas.denx.de>
At 04:13 PM 4/12/2005, Wolfgang Denk wrote:
>i2s.c is not really a driver, but a (very OLD) test version of one
>used to demonstrate certain BestComm related problems. Don't try
>using it as a real driver ;-)
Humm, any pointers on writing our own driver then then? Digging through
the source for other drivers, bestcomm seems to be a real house of
cards. We just want simple audio output capability. No need to make it
work with the standard Linux/OSS sound API.
Where can we keep track of the eratta/bugs in bestcomm? Browsing through
the mailing list, I've found references that:
IDE and Ethernet DMA can't work at the same time
I2S TX and RX DMA can't work at the same time
AC-97 is terminally broken (no way to handle the slot tags properly
for variable sampling rates)
Are these all still true?
We've tried asking our local Freescale rep, but they seem to think that
Linux==Metrowerks, and they are looking into the bestcomm question, but
official responses from Freescale tend to take >1 week.
This is for a custom MPC5200 board, heavily based on IceCube with a single
I2S DAC on PSC2 running in "CODEC with MCLK" mode.
Sorry about the null subject line previously: fingers were working faster
than brain...
Thanks
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ 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