* MPC8240 EPIC Driver (Attached)
@ 2001-08-11 7:18 James F Dougherty
2001-08-11 23:47 ` Dan Malek
0 siblings, 1 reply; 15+ messages in thread
From: James F Dougherty @ 2001-08-11 7:18 UTC (permalink / raw)
To: dan, linuxppc-embedded, cort; +Cc: jfd
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
A while ago, I posted some questions on getting the OpenPIC driver working
correctly for the EPIC (Embedded Programmable Interrupt Controller) internal
to the MPC8240. After several attempts on open_pic.*, I gave up, and ported a
an existing driver.
The attached files function as an interrupt driver for MPC8240 (PPC603)
systems with the internal EPIC operating in discrete mode. In this mode,
IRQ's are connected to the MPC8240 EPIC and the 8259 cascade function
is not needed. Typically, one or more PCI devices will use one of IRQ X (0-5)
on the MPC8240 EPIC, these interrupts will be received as EPIC_VECTOR_XX
and perform the EPIC EOI handling. Interrupts can be nested, such that higher
priority interrupts are not blocked out. For more information, see the Motorola
MPC8240 Users Manual, Chapter 11, Embedded Programmable Interrupt Controller.
Also, although I have not checked, I am pretty sure the same logic is in the
MPC8245.
If anyone has improvements or suggestions on how to improve this driver,
please email me directly.
Thanks,
-James
[-- Attachment #2: mpc8240_pic.h --]
[-- Type: text/plain, Size: 7347 bytes --]
/*
* arch/ppc/kernel/mpc8240_pic.h ---- MPC8240 EPIC Interrupt Controller
*
* Copyright (C) 2001 James Dougherty (jfd@cs.stanford.edu)
* Copyright (C) 1999 Motorola Inc.
*
* Modification History:
* =====================
* 01a,04Feb99,My Created.
*
*/
#ifndef _PPC_KERNEL_PPC8240_H
#define _PPC_KERNEL_PPC8240_H
#include "local_irq.h"
extern void* EPIC_Addr;
/*
* All of these registers are accessed from the EPIC_BASE
* which is the EUMBBAR BASE + EPIC_EUMBBAR_OFFSET address
* that gets remapped in mpc10x_bridge_init()
*/
#define EPIC_EUMBBAR_OFFSET 0x40000 /* Offset of EPIC from EUMBBAR*/
#define EPIC_FEATURES_REG 0x01000 /* Feature reporting */
#define EPIC_GLOBAL_REG 0x01020 /* Global config. */
#define EPIC_INT_CONF_REG 0x01030 /* Interrupt config. */
#define EPIC_VENDOR_ID_REG 0x01080 /* Vendor id */
#define EPIC_PROC_INIT_REG 0x01090 /* Processor init. */
#define EPIC_SPUR_VEC_REG 0x010e0 /* Spurious vector */
#define EPIC_TM_FREQ_REG 0x010f0 /* Timer Frequency */
#define EPIC_TM0_CUR_COUNT_REG 0x01100 /* Gbl TM0 Cur. Count*/
#define EPIC_TM0_BASE_COUNT_REG 0x01110 /* Gbl TM0 Base Count*/
#define EPIC_TM0_VEC_REG 0x01120 /* Gbl TM0 Vector Pri*/
#define EPIC_TM0_DES_REG 0x01130 /* Gbl TM0 Dest. */
#define EPIC_TM1_CUR_COUNT_REG 0x01140 /* Gbl TM1 Cur. Count*/
#define EPIC_TM1_BASE_COUNT_REG 0x01150 /* Gbl TM1 Base Count*/
#define EPIC_TM1_VEC_REG 0x01160 /* Gbl TM1 Vector Pri*/
#define EPIC_TM1_DES_REG 0x01170 /* Gbl TM1 Dest. */
#define EPIC_TM2_CUR_COUNT_REG 0x01180 /* Gbl TM2 Cur. Count*/
#define EPIC_TM2_BASE_COUNT_REG 0x01190 /* Gbl TM2 Base Count*/
#define EPIC_TM2_VEC_REG 0x011a0 /* Gbl TM2 Vector Pri*/
#define EPIC_TM2_DES_REG 0x011b0 /* Gbl TM2 Dest */
#define EPIC_TM3_CUR_COUNT_REG 0x011c0 /* Gbl TM3 Cur. Count*/
#define EPIC_TM3_BASE_COUNT_REG 0x011d0 /* Gbl TM3 Base Count*/
#define EPIC_TM3_VEC_REG 0x011e0 /* Gbl TM3 Vector Pri*/
#define EPIC_TM3_DES_REG 0x011f0 /* Gbl TM3 Dest. */
#define EPIC_TMx_CUR_COUNT_REG(x) (EPIC_TM0_CUR_COUNT_REG + 0x40 * (x))
#define EPIC_TMx_BASE_COUNT_REG(x) (EPIC_TM0_BASE_COUNT_REG + 0x40 * (x))
#define EPIC_TMx_VEC_REG(x) (EPIC_TM0_VEC_REG + 0x40 * (x))
#define EPIC_TMx_DES_REG(x) (EPIC_TM0_DES_REG + 0x40 * (x))
#define EPIC_EX_INT0_VEC_REG 0x10200 /* Ext. Int. Sr0 Des */
#define EPIC_EX_INT0_DES_REG 0x10210 /* Ext. Int. Sr0 Vect*/
#define EPIC_EX_INT1_VEC_REG 0x10220 /* Ext. Int. Sr1 Des */
#define EPIC_EX_INT1_DES_REG 0x10230 /* Ext. Int. Sr1 Vect*/
#define EPIC_EX_INT2_VEC_REG 0x10240 /* Ext. Int. Sr2 Des */
#define EPIC_EX_INT2_DES_REG 0x10250 /* Ext. Int. Sr2 Vect*/
#define EPIC_EX_INT3_VEC_REG 0x10260 /* Ext. Int. Sr3 Des */
#define EPIC_EX_INT3_DES_REG 0x10270 /* Ext. Int. Sr3 Vect*/
#define EPIC_EX_INT4_VEC_REG 0x10280 /* Ext. Int. Sr4 Des */
#define EPIC_EX_INT4_DES_REG 0x10290 /* Ext. Int. Sr4 Vect*/
#define EPIC_EX_INTx_VEC_REG(x) (EPIC_EX_INT0_VEC_REG + (x) * 0x20)
#define EPIC_EX_INTx_DES_REG(x) (EPIC_EX_INT0_DES_REG + (x) * 0x20)
#define EPIC_SR_INT0_VEC_REG 0x10200 /* Sr. Int. Sr0 Des */
#define EPIC_SR_INT0_DES_REG 0x10210 /* Sr. Int. Sr0 Vect */
#define EPIC_SR_INT1_VEC_REG 0x10220 /* Sr. Int. Sr1 Des */
#define EPIC_SR_INT1_DES_REG 0x10230 /* Sr. Int. Sr1 Vect.*/
#define EPIC_SR_INT2_VEC_REG 0x10240 /* Sr. Int. Sr2 Des */
#define EPIC_SR_INT2_DES_REG 0x10250 /* Sr. Int. Sr2 Vect.*/
#define EPIC_SR_INT3_VEC_REG 0x10260 /* Sr. Int. Sr3 Des */
#define EPIC_SR_INT3_DES_REG 0x10270 /* Sr. Int. Sr3 Vect.*/
#define EPIC_SR_INT4_VEC_REG 0x10280 /* Sr. Int. Sr4 Des */
#define EPIC_SR_INT4_DES_REG 0x10290 /* Sr. Int. Sr4 Vect.*/
#define EPIC_SR_INT5_VEC_REG 0x102a0 /* Sr. Int. Sr5 Des */
#define EPIC_SR_INT5_DES_REG 0x102b0 /* Sr. Int. Sr5 Vect.*/
#define EPIC_SR_INT6_VEC_REG 0x102c0 /* Sr. Int. Sr6 Des */
#define EPIC_SR_INT6_DES_REG 0x102d0 /* Sr. Int. Sr6 Vect.*/
#define EPIC_SR_INT7_VEC_REG 0x102e0 /* Sr. Int. Sr7 Des */
#define EPIC_SR_INT7_DES_REG 0x102f0 /* Sr. Int. Sr7 Vect.*/
#define EPIC_SR_INT8_VEC_REG 0x10300 /* Sr. Int. Sr8 Des */
#define EPIC_SR_INT8_DES_REG 0x10310 /* Sr. Int. Sr8 Vect.*/
#define EPIC_SR_INT9_VEC_REG 0x10320 /* Sr. Int. Sr9 Des */
#define EPIC_SR_INT9_DES_REG 0x10330 /* Sr. Int. Sr9 Vect.*/
#define EPIC_SR_INT10_VEC_REG 0x10340 /* Sr. Int. Sr10 Des */
#define EPIC_SR_INT10_DES_REG 0x10350 /* Sr. Int. Sr10 Vect*/
#define EPIC_SR_INT11_VEC_REG 0x10360 /* Sr. Int. Sr11 Des */
#define EPIC_SR_INT11_DES_REG 0x10370 /* Sr. Int. Sr11 Vect*/
#define EPIC_SR_INT12_VEC_REG 0x10380 /* Sr. Int. Sr12 Des */
#define EPIC_SR_INT12_DES_REG 0x10390 /* Sr. Int. Sr12 Vect*/
#define EPIC_SR_INT13_VEC_REG 0x103a0 /* Sr. Int. Sr13 Des */
#define EPIC_SR_INT13_DES_REG 0x103b0 /* Sr. Int. Sr13 Vect*/
#define EPIC_SR_INT14_VEC_REG 0x103c0 /* Sr. Int. Sr14 Des */
#define EPIC_SR_INT14_DES_REG 0x103d0 /* Sr. Int. Sr14 Vect*/
#define EPIC_SR_INT15_VEC_REG 0x103e0 /* Sr. Int. Sr15 Des */
#define EPIC_SR_INT15_DES_REG 0x103f0 /* Sr. Int. Sr15 Vect*/
#define EPIC_SR_INTx_VEC_REG(x) (EPIC_SR_INT0_VEC_REG + (x) * 0x20)
#define EPIC_SR_INTx_DES_REG(x) (EPIC_SR_INT0_DES_REG + (x) * 0x20)
#define EPIC_I2C_INT_VEC_REG 0x11020 /* I2C Int. Vect Pri.*/
#define EPIC_I2C_INT_DES_REG 0x11030 /* I2C Int. Dest */
#define EPIC_DMA0_INT_VEC_REG 0x11040 /* DMA0 Int. Vect Pri*/
#define EPIC_DMA0_INT_DES_REG 0x11050 /* DMA0 Int. Dest */
#define EPIC_DMA1_INT_VEC_REG 0x11060 /* DMA1 Int. Vect Pri*/
#define EPIC_DMA1_INT_DES_REG 0x11070 /* DMA1 Int. Dest */
#define EPIC_MSG_INT_VEC_REG 0x110c0 /* Msg Int. Vect Pri*/
#define EPIC_MSG_INT_DES_REG 0x110d0 /* Msg Int. Dest */
#define EPIC_VECREG_PRIO_SHFT 16
#define EPIC_VECREG_PRIO_MASK (0xf << EPIC_EIS_PRIO_SHFT)
#define EPIC_VECREG_VEC_SHFT 0
#define EPIC_VECREG_VEC_MASK (0xff << EPIC_EIS_VEC_SHFT)
#define EPIC_VECREG_M (1<<31) /* MASK bit */
#define EPIC_VECREG_A (1<<30) /* Activity */
#define EPIC_VECREG_P (1<<23) /* Polarity */
#define EPIC_VECREG_S (1<<22) /* Sense */
#define EPIC_VECTOR_EXT0 0
#define EPIC_VECTOR_EXT1 1
#define EPIC_VECTOR_EXT2 2
#define EPIC_VECTOR_EXT3 3
#define EPIC_VECTOR_EXT4 4
#define EPIC_VECTOR_TM0 16
#define EPIC_VECTOR_TM1 17
#define EPIC_VECTOR_TM2 18
#define EPIC_VECTOR_TM3 19
#define EPIC_VECTOR_I2C 20
#define EPIC_VECTOR_DMA0 21
#define EPIC_VECTOR_DMA1 22
#define EPIC_VECTOR_I2O 23
#define EPIC_VECTOR_CNT 0x100
#define EPIC_VECTOR_USED 24
#define EPIC_GCR_RESET (1<<31)
#define EPIC_GCR_M (1<<29)
#define EPIC_ICR_R_SHFT 28
#define EPIC_ICR_R_MASK (7<<EPIC_ICR_R_SHFT)
#define EPIC_ICR_SIE (1<<27)
#define EPIC_PROC_CTASK_PRI_REG 0x20080 /* Proc. current task*/
#define EPIC_PROC_INT_ACK_REG 0x200a0 /* Int. acknowledge */
#define EPIC_PROC_EOI_REG 0x200b0 /* End of interrupt */
#define EPIC_DIRECT_IRQ 0
#define EPIC_VEC_REG_INTERVAL 0x20 /* Distance between int. vector regs */
#define EPIC_VEC_SPURIOUS 127 /* Spurious interrupt */
extern struct hw_interrupt_type ppc8240_pic;
void mpc8240_pic_init(void);
void mpc8240_do_IRQ(struct pt_regs *regs,
int cpu,
int isfake);
int mpc8240_get_irq(struct pt_regs *regs);
void mpc8240_set_timer(int i, u_int freq);
#endif /* _PPC_KERNEL_PPC8260_H */
[-- Attachment #3: mpc8240_pic.c --]
[-- Type: text/plain, Size: 10567 bytes --]
/*
* arch/ppc/kernel/mpc8240_pic.c -- MPC8240 EPIC Interrupt Handling
*
* Copyright (C) 2001 James Dougherty (jfd@cs.stanford.edu)
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
* for more details.
*/
#include <linux/config.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/init.h>
#include <linux/irq.h>
#include <asm/ptrace.h>
#include <asm/signal.h>
#include <asm/io.h>
#include <asm/irq.h>
#include "mpc10x.h"
#include "mpc8240_pic.h"
void* EPIC_Addr;
static inline u_int
epic_read(u_int reg)
{
return in_le32(((volatile u_int*)((u_int)EPIC_Addr + reg)));
}
static inline void
epic_write(u_int reg, u_int val)
{
out_le32(((volatile u_int*)((u_int)EPIC_Addr+reg)), val);
}
/*
* Typedef: epic_table_t
* Purpose: Defines an entry in the EPIC table indexed by vector.
* Each entry represents a vector that is permanently
* assigned to a specific function as follows (see definitions
* for EPIC_VECTOR_xxx):
*
* Vector(s) Assignment
* --------- -------------------
* 0-15 External (and unused serial interrupts)
* 16-19 Global timers
* 20 I2C
* 21-22 DMA
* 23 I2O message
*
* NOTE: Higher priority numbers represent higher priority.
*/
typedef struct epic_table_s {
int et_prio; /* Interrupt priority, fixed */
/* IRQ handler to call, set when connected */
void (*et_func)(int, void *, struct pt_regs *);
int et_par; /* Param to func, set when connected */
u_int et_vecadr; /* Address of EPIC vector register */
u_int et_desadr; /* Address of EPIC destination register */
} epic_table_t;
static epic_table_t epic_table[EPIC_VECTOR_USED] = {
/* 0 */ { 5, 0, 0, EPIC_EX_INTx_VEC_REG(0), EPIC_EX_INTx_DES_REG(0) },
/* 1 */ { 5, 0, 0, EPIC_EX_INTx_VEC_REG(1), EPIC_EX_INTx_DES_REG(1) },
/* 2 */ { 5, 0, 0, EPIC_EX_INTx_VEC_REG(2), EPIC_EX_INTx_DES_REG(2) },
/* 3 */ { 5, 0, 0, EPIC_EX_INTx_VEC_REG(3), EPIC_EX_INTx_DES_REG(3) },
/* 4 */ { 10, 0, 0, EPIC_EX_INTx_VEC_REG(4), EPIC_EX_INTx_DES_REG(4) },
/* 5 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(5), EPIC_SR_INTx_DES_REG(5) },
/* 6 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(6), EPIC_SR_INTx_DES_REG(6) },
/* 7 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(7), EPIC_SR_INTx_DES_REG(7) },
/* 8 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(8), EPIC_SR_INTx_DES_REG(8) },
/* 9 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(9), EPIC_SR_INTx_DES_REG(9) },
/* 10 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(10), EPIC_SR_INTx_DES_REG(10) },
/* 11 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(11), EPIC_SR_INTx_DES_REG(11) },
/* 12 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(12), EPIC_SR_INTx_DES_REG(12) },
/* 13 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(13), EPIC_SR_INTx_DES_REG(13) },
/* 14 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(14), EPIC_SR_INTx_DES_REG(14) },
/* 15 */ { 5, 0, 0, EPIC_SR_INTx_VEC_REG(15), EPIC_SR_INTx_DES_REG(15) },
/* 16 */ { 8, 0, 0, EPIC_TMx_VEC_REG(0), EPIC_TMx_DES_REG(0) },
/* 17 */ { 5, 0, 0, EPIC_TMx_VEC_REG(1), EPIC_TMx_DES_REG(1) },
/* 18 */ { 5, 0, 0, EPIC_TMx_VEC_REG(2), EPIC_TMx_DES_REG(2) },
/* 19 */ { 5, 0, 0, EPIC_TMx_VEC_REG(3), EPIC_TMx_DES_REG(3) },
/* 20 */ { 5, 0, 0, EPIC_I2C_INT_VEC_REG, EPIC_I2C_INT_DES_REG },
/* 21 */ { 5, 0, 0, EPIC_DMA0_INT_VEC_REG, EPIC_DMA0_INT_DES_REG },
/* 22 */ { 5, 0, 0, EPIC_DMA1_INT_VEC_REG, EPIC_DMA1_INT_DES_REG },
/* 23 */ { 5, 0, 0, EPIC_MSG_INT_VEC_REG, EPIC_MSG_INT_DES_REG },
};
#define NUM_EPIC_SOURCES (sizeof(epic_table)/sizeof(epic_table[0]))
void
mpc8240_set_timer(int i, u_int freq)
{
switch(i){
case 0:
epic_write(EPIC_TM0_BASE_COUNT_REG, freq);
break;
case 1:
epic_write(EPIC_TM1_BASE_COUNT_REG, freq);
break;
case 2:
epic_write(EPIC_TM2_BASE_COUNT_REG, freq);
break;
case 3:
epic_write(EPIC_TM3_BASE_COUNT_REG, freq);
break;
default:
break;
}
}
/*
* Enable/disable an external interrupt source
*
* Externally called, irq is an offseted system-wide interrupt number
*/
void
mpc8240_enable_irq(u_int irq)
{
epic_table_t *et ;
u_int vecreg;
if (irq < 0 || irq > NUM_EPIC_SOURCES)
return;
et = epic_table + irq;
#if CONFIG_SANDPOINT_DEBUG
if( irq != 1){
sandpoint_progress("enable irq:",0x122);
sandpoint_printhex(irq,1);
}
#endif
#if 0
if (NULL == et->et_func) {
return(ERROR);
}
printf("EPIC: interrupt enable --- <vec=0x%x level=0x%x prio=0x%x>\n",
vec, et->et_level, et->et_prio);
#endif
/*
* Look up the interrupt level for the vector and enable that level
* setting the correct vector #, priority,
*/
vecreg = (et->et_prio << EPIC_VECREG_PRIO_SHFT |
irq << EPIC_VECREG_VEC_SHFT);
/* MPC8240 EPIC in Discrete mode, IRQ 0-4 external */
if (irq >= EPIC_VECTOR_EXT0 && irq <= EPIC_VECTOR_EXT4)
vecreg |= EPIC_VECREG_S; /* Set sense bit */
epic_write(et->et_vecadr, vecreg);
/* Direct the interrupt to this processor */
epic_write(et->et_desadr, 1);
mb(); /* sync */
}
/*
* Disable an EPIC interrupt.
*/
static void
mpc8240_disable_irq(u_int irq)
{
epic_table_t *et ;
u_int vecreg;
if (irq < 0 || irq > NUM_EPIC_SOURCES)
return;
et = epic_table + irq;
#if 0
if (NULL == et->et_func)
return;
#endif
/* Set mask bit */
vecreg = epic_read(et->et_vecadr);
vecreg |= EPIC_VECREG_M;
epic_write(et->et_vecadr, vecreg);
mb(); /* sync */
}
/*
* Disabled and Acknowledge an EPIC interrupt.
*/
void
mpc8240_ack_irq(u_int irq)
{
mpc8240_disable_irq(irq);
if ((irq_desc[irq].status & IRQ_LEVEL) != 0)
epic_write(EPIC_PROC_EOI_REG, 0x0); /* Signal EOI */
}
/*
* Acknowledge and re-enable an EPIC Interrupt
*/
void
mpc8240_end_irq(u_int irq)
{
if ((irq_desc[irq].status & IRQ_LEVEL) != 0)
epic_write(EPIC_PROC_EOI_REG, 0x0); /* Signal EOI */
if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
mpc8240_enable_irq(irq);
}
/*
* Configure an EPIC interrupt with a given vector and prio.
* Parameters: vec - interrupt vector number/level
* prio - PPC interrupt priority
* func - function to call
* par - parameter passed to func on interrupt.
* Returns: 0, -1 on error
*/
int
mpc8240_int_configure(int vec, int prio,
void (*func)(int, void *, struct pt_regs *),
int par)
{
epic_table_t *et = &epic_table[vec];
if (NULL != et->et_func || vec < 0 || vec >= EPIC_VECTOR_USED) {
return -1;
}
et->et_func = func;
et->et_par = par;
et->et_prio = prio;
return 0;
}
struct hw_interrupt_type mpc8240_pic = {
" MPC8240 EPIC ",
NULL,
NULL,
mpc8240_enable_irq,
mpc8240_disable_irq,
#if 1
0,0,
#else
mpc8240_ack_irq,
mpc8240_end_irq,
#endif
0
};
/*
* Initialize the MPC8240 EPIC
* Use discrete mode, which allows for IRQ0-4 to be directed
* from up to 5 external sources.
*/
void
mpc8240_pic_init(void)
{
int i;
u_int tmp;
epic_table_t *et ;
u_int vecreg;
/* Set current task priority to 0 */
epic_write(EPIC_PROC_CTASK_PRI_REG, 0);
/* Set reset bit and wait for reset to complete */
epic_write(EPIC_GLOBAL_REG, EPIC_GCR_RESET);
while (epic_read(EPIC_GLOBAL_REG) & EPIC_GCR_RESET)
;
/* Set current task priority to 0 */
epic_write(EPIC_PROC_CTASK_PRI_REG, 0);
/* Discrete ints please */
epic_write(EPIC_GLOBAL_REG, EPIC_GCR_M); /* GCR[M]=1 */
/* Set direct interrupts (disable serial interrupts) */
tmp = epic_read(EPIC_INT_CONF_REG);
epic_write(EPIC_INT_CONF_REG, tmp & ~EPIC_ICR_SIE);
#if 1
/* Set serial mode and frequency */
tmp = epic_read(EPIC_INT_CONF_REG);
tmp &= ~0x70000000; /* Clear bits 27,28,29 */
tmp |= 0x40000000; /* Set bit 29 */
epic_write(EPIC_INT_CONF_REG, tmp);
#endif
/* Clear M Bit in all vectors */
for( vecreg = 0; vecreg < NUM_EPIC_SOURCES; vecreg ++){
et = epic_table + vecreg;
/* Mask all IRQ's mask bit */
vecreg = epic_read(et->et_vecadr);
vecreg |= EPIC_VECREG_M;
epic_write(et->et_vecadr, vecreg);
}
/* Clear all pending interrupt */
while (epic_read(EPIC_PROC_INT_ACK_REG) != 0xff);
/* Set current task priority to 0 */
epic_write(EPIC_PROC_CTASK_PRI_REG, 0);
/* Publish interface */
for(i = 0; i < NUM_EPIC_SOURCES; i++) {
irq_desc[i].handler = &mpc8240_pic;
irq_desc[i].status |= IRQ_DISABLED | IRQ_LEVEL;
}
/*
* Set clock rate to default just in case, which is 1/8 of the timebase
* divider input frequency. The PPC timebase counter itself operates
* at 1/4 the divider input frequency (twice the aux clock).
*/
mpc8240_set_timer(0, 33000000 );
#if CONFIG_SANDPOINT_DEBUG
sandpoint_progress("timer0:ok ",0);
#endif
if ( ppc_md.progress ) ppc_md.progress(" mpc8240_epic_init_ok ",0x122);
}
/*
* Handle an interrupt from the EPIC.
*/
int
do_IRQ(struct pt_regs *regs,
int cpu,
int isfake)
{
int irq, msr;
u_int o_pri; /* Old priority */
epic_table_t *et;
/* int cpu = smp_processor_id();*/
hardirq_enter(cpu);
irq = epic_read(EPIC_PROC_INT_ACK_REG) ;
et = epic_table + irq;
#if CONFIG_SANDPOINT_DEBUG
if( irq != 0){
sandpoint_progress(" do_IRQ:",0x122);
sandpoint_printhex(irq,1);
}
#endif
if (irq < 0) {
if( irq != -2){
printk(KERN_DEBUG "Bogus interrupt %d from PC = %lx\n",
irq, regs->nip);
ppc_spurious_interrupts++;
}
goto out;
}
else if ((irq >= 0) && (irq < EPIC_VECTOR_USED)) {
o_pri = epic_read(EPIC_PROC_CTASK_PRI_REG); /* Save prev level */
epic_write(EPIC_PROC_CTASK_PRI_REG, et->et_prio);/* Set task level */
/* Allow nesting */
save_flags(msr);
msr |=MSR_EE;
restore_flags(msr);
ppc_irq_dispatch_handler( regs, irq ); /* Call IRQ handler */
if ( ppc_md.post_irq)
ppc_md.post_irq(regs, irq);
epic_write(EPIC_PROC_CTASK_PRI_REG, o_pri); /* Restore level */
epic_write(EPIC_PROC_EOI_REG, 0x0); /* Signal EOI */
}
out:
hardirq_exit(cpu);
return 1;
}
/*
* Get current EPIC Interrupt
*/
int
mpc8240_get_irq(struct pt_regs *regs)
{
int irq;
irq = epic_read(EPIC_PROC_INT_ACK_REG) ;
return irq;
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-11 7:18 James F Dougherty
@ 2001-08-11 23:47 ` Dan Malek
2001-08-13 15:56 ` Andrew Johnson
0 siblings, 1 reply; 15+ messages in thread
From: Dan Malek @ 2001-08-11 23:47 UTC (permalink / raw)
To: James F Dougherty; +Cc: linuxppc-embedded, cort, jfd
James F Dougherty wrote:
>
> A while ago, I posted some questions on getting the OpenPIC driver working
> correctly for the EPIC (Embedded Programmable Interrupt Controller) internal
> to the MPC8240. After several attempts on open_pic.*, I gave up, and ported a
> an existing driver.
Ummm, I'm confused. The existing PowerPC OpenPIC works just fine with
the 8240/8245/MPC107 EPICs, at least on the Sandpoint. I can't believe
there would be much of anything needed for a custom board. I have some
Sandpoint X3 patches that enables the serial mode control lines as well.
I think there could be a few minor improvements, but it is certainly
functional. All you should need are the interrupt senses table for
the OpenPIC initialization and the proper routing table for the PCI
setup.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 15:56 ` Andrew Johnson
@ 2001-08-13 12:54 ` Matt Porter
2001-08-13 18:00 ` Mark A. Greer
0 siblings, 1 reply; 15+ messages in thread
From: Matt Porter @ 2001-08-13 12:54 UTC (permalink / raw)
To: Andrew Johnson; +Cc: Dan Malek, James F Dougherty, linuxppc-embedded, cort, jfd
On Mon, Aug 13, 2001 at 10:56:09AM -0500, Andrew Johnson wrote:
>
> Dan Malek wrote:
> >
> > James F Dougherty wrote:
> > >
> > > A while ago, I posted some questions on getting the OpenPIC driver working
> > > correctly for the EPIC (Embedded Programmable Interrupt Controller) internal
> > > to the MPC8240. After several attempts on open_pic.*, I gave up, and ported a
> > > an existing driver.
> >
> > Ummm, I'm confused. The existing PowerPC OpenPIC works just fine with
> > the 8240/8245/MPC107 EPICs, at least on the Sandpoint.
>
> Not quite - the Sandpoint has an i8259 as well, and the OpenPic code as
> shipped with HHL-2.0 assumes that there is one present (at least you have
> to link in the i8259 code, although you can arrange that it is never
> called). Not all 8240 systems have an 8259 such as the MVME2100, and I
> had to #if out some stuff from OpenPic.c to be able to omit the i8259.
>
> Then there's the problem of accessing the 8240's interrupts for I2C, 2 DMA
> channels and Message Unit, which are highly dis-contiguous with the other
> interrupts; these would appear at IRQs 129, 130, 131 and 134 in the
> current scheme (needing a rather large and sparse interrupt senses
> table). Oh, and the 4 Global timer interrupts would have to appear at
> negative IRQ numbers, so it's a good thing Linux doesn't need to use
> these.
>
> I haven't looked at James' code, but the OpenPIC stuff certainly does need
> some changes to be truly universal.
There's a hack in the OpenPIC code for HHL 2.0 to allow for some of
the above situations. The hack was rejected in the public tree in
favor of a not yet implemented clean way to handle this stuff.
If somebody has time to abstract the OpenPIC code for EPIC correctly,
it will get in the tree.
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-11 23:47 ` Dan Malek
@ 2001-08-13 15:56 ` Andrew Johnson
2001-08-13 12:54 ` Matt Porter
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Johnson @ 2001-08-13 15:56 UTC (permalink / raw)
To: Dan Malek; +Cc: James F Dougherty, linuxppc-embedded, cort, jfd
Dan Malek wrote:
>
> James F Dougherty wrote:
> >
> > A while ago, I posted some questions on getting the OpenPIC driver working
> > correctly for the EPIC (Embedded Programmable Interrupt Controller) internal
> > to the MPC8240. After several attempts on open_pic.*, I gave up, and ported a
> > an existing driver.
>
> Ummm, I'm confused. The existing PowerPC OpenPIC works just fine with
> the 8240/8245/MPC107 EPICs, at least on the Sandpoint.
Not quite - the Sandpoint has an i8259 as well, and the OpenPic code as
shipped with HHL-2.0 assumes that there is one present (at least you have
to link in the i8259 code, although you can arrange that it is never
called). Not all 8240 systems have an 8259 such as the MVME2100, and I
had to #if out some stuff from OpenPic.c to be able to omit the i8259.
Then there's the problem of accessing the 8240's interrupts for I2C, 2 DMA
channels and Message Unit, which are highly dis-contiguous with the other
interrupts; these would appear at IRQs 129, 130, 131 and 134 in the
current scheme (needing a rather large and sparse interrupt senses
table). Oh, and the 4 Global timer interrupts would have to appear at
negative IRQ numbers, so it's a good thing Linux doesn't need to use
these.
I haven't looked at James' code, but the OpenPIC stuff certainly does need
some changes to be truly universal.
- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 12:54 ` Matt Porter
@ 2001-08-13 18:00 ` Mark A. Greer
2001-08-13 19:56 ` Andrew Johnson
0 siblings, 1 reply; 15+ messages in thread
From: Mark A. Greer @ 2001-08-13 18:00 UTC (permalink / raw)
To: Matt Porter
Cc: Andrew Johnson, Dan Malek, James F Dougherty, linuxppc-embedded,
cort, jfd
Matt Porter wrote:
> On Mon, Aug 13, 2001 at 10:56:09AM -0500, Andrew Johnson wrote:
> > Then there's the problem of accessing the 8240's interrupts for I2C, 2 DMA
> > channels and Message Unit, which are highly dis-contiguous with the other
> > interrupts; these would appear at IRQs 129, 130, 131 and 134 in the
> > current scheme (needing a rather large and sparse interrupt senses
> > table). Oh, and the 4 Global timer interrupts would have to appear at
> > negative IRQ numbers, so it's a good thing Linux doesn't need to use
> > these.
> >
> > I haven't looked at James' code, but the OpenPIC stuff certainly does need
> > some changes to be truly universal.
>
> There's a hack in the OpenPIC code for HHL 2.0 to allow for some of
> the above situations. The hack was rejected in the public tree in
> favor of a not yet implemented clean way to handle this stuff.
>
> If somebody has time to abstract the OpenPIC code for EPIC correctly,
> it will get in the tree.
Yes, there should be better support for 8240/107 interrupt ctlrs in the openpic code.
However, as long as they are used in direct interrupt mode, the openpic code will work
as is for the most part (except for the negative irq's :). Note that to use the
openpic_init()/initsenses table as it is, you need to skip the first 16 irq's no
matter what (i.e., even if you don't have an 8259). DO NOT set the offset to anything
but 0 in the openpic_init() call.
The changes to the openpic code for supporting serial interrupt mode are very minor.
I sent out an email many moons ago about expanding the "initsenses" table but I never
really had to time to follow thru on it...I should have. I still think that's the way
to go.
What I mean is a table where you specify the irq, the offset fo the regs from the base
address, the sensitivity, and the polarity all separately. Also the appropriate
extensions to support serial interrupt mode (e.g., MVME2100 uses that). With a table
format something like that, you can avoid the sparse and negative irq's on the
8240/107 and still keep things pretty clean looking.
Anyway, someone needs to take the time to do it...
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 18:00 ` Mark A. Greer
@ 2001-08-13 19:56 ` Andrew Johnson
2001-08-13 20:38 ` Mark A. Greer
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Johnson @ 2001-08-13 19:56 UTC (permalink / raw)
To: Mark A. Greer
Cc: Matt Porter, Dan Malek, James F Dougherty, linuxppc-embedded,
cort, jfd
"Mark A. Greer" wrote:
>
> The changes to the openpic code for supporting serial interrupt mode are very minor.
Actually IIRC they're already present in the version shipped with
HHL-2.0. I don't remember making any changes for that at all on the
MVME2100 support, but my memory has been known to be faulty.
> What I mean is a table where you specify the irq, the offset fo the regs from the base
> address, the sensitivity, and the polarity all separately. Also the appropriate
> extensions to support serial interrupt mode (e.g., MVME2100 uses that). With a table
> format something like that, you can avoid the sparse and negative irq's on the
> 8240/107 and still keep things pretty clean looking.
That sounds right. It could also use the NIRQ field of the Feature
Reporting Register to cross-check that the table given is the correct size
for the chip it's controlling, and have some way of specifying the
presence or absensce of a cascaded i8259 (presumably with its own table).
- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 19:56 ` Andrew Johnson
@ 2001-08-13 20:38 ` Mark A. Greer
2001-08-13 21:30 ` Andrew Johnson
0 siblings, 1 reply; 15+ messages in thread
From: Mark A. Greer @ 2001-08-13 20:38 UTC (permalink / raw)
To: Andrew Johnson
Cc: Matt Porter, Dan Malek, James F Dougherty, linuxppc-embedded,
cort, jfd
Andrew Johnson wrote:
> "Mark A. Greer" wrote:
> >
> > The changes to the openpic code for supporting serial interrupt mode are very minor.
>
> Actually IIRC they're already present in the version shipped with
> HHL-2.0. I don't remember making any changes for that at all on the
> MVME2100 support, but my memory has been known to be faulty.
Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
adjusts NumSources if it is less than OpenPIC_NumInitSenses. That let's you proceed with
an initsenses with more irq's than the pic tells you it has. Its not a complete, long-term
solution.
Also, I'm trying to keep this discussion relative to 2_4_devel not hhlx.x
> > What I mean is a table where you specify the irq, the offset fo the regs from the base
> > address, the sensitivity, and the polarity all separately. Also the appropriate
> > extensions to support serial interrupt mode (e.g., MVME2100 uses that). With a table
> > format something like that, you can avoid the sparse and negative irq's on the
> > 8240/107 and still keep things pretty clean looking.
>
> That sounds right. It could also use the NIRQ field of the Feature
> Reporting Register to cross-check that the table given is the correct size
> for the chip it's controlling, and have some way of specifying the
> presence or absensce of a cascaded i8259 (presumably with its own table).
The NIRQ field is a part of the problem in serial mode. You can have 16 lines hooked up in
serial mode and the NIRQ still tells you that there should only be 5, IIRC.
The table changes are intended to solve more than just epic serial mode. They're intended
to make explicit--and flexible--all the assumptions that are currently buried in the
initsenses table (irq #, the offset of corresponding reg in pic, sensifivity and
polarity). These aren't extensive changes, I should just do them, post a patch for review
& shut up... :)
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 20:38 ` Mark A. Greer
@ 2001-08-13 21:30 ` Andrew Johnson
2001-08-13 21:47 ` Mark A. Greer
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Johnson @ 2001-08-13 21:30 UTC (permalink / raw)
To: Mark A. Greer
Cc: Matt Porter, Dan Malek, James F Dougherty, linuxppc-embedded,
cort, jfd
"Mark A. Greer" wrote:
>
> Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
> adjusts NumSources if it is less than OpenPIC_NumInitSenses. That let's you proceed with
> an initsenses with more irq's than the pic tells you it has. Its not a complete, long-term
> solution.
There was something present that switches the chip between serial and
discrete mode. Other than that and the actual location of the config
registers for each IRQ I don't think there's anything more needed to
distinguish the two in software.
> Also, I'm trying to keep this discussion relative to 2_4_devel not hhlx.x
I'm only comparing to that as I'm not actively following 2_4_devel and
assume that those who need to know can relate hhl2.0 to some point in the
2_4_devel tree.
> The NIRQ field is a part of the problem in serial mode. You can have 16 lines hooked up in
> serial mode and the NIRQ still tells you that there should only be 5, IIRC.
Actually it doesn't tell you that at all - from the EPIC documentation in
the 8240 manual, NIRQ provides the (fixed) maximum number of interrupt
sources supported by the EPIC. On the 8240 the NIRQ value is 0x17=23
which corresponds to 24 interrupt sources (NIRQ=0 means 1 source),
comprising 16 serial IRQs, 4 timers, I2C, 2*DMA channels and the Mesage
Unit. Nothing tells you where to find the config registers for those IRQs
though, hence the problems we're discussing. The offset to the first
Serial or Direct IRQ config register is not accounted for in the NIRQ
number; it's only by chance that a discrete-mode EPIC works with the
OpenPic driver (check for off-by-1 errors BTW, see the above definition
for NIRQ).
> The table changes are intended to solve more than just epic serial mode. They're intended
> to make explicit--and flexible--all the assumptions that are currently buried in the
> initsenses table (irq #, the offset of corresponding reg in pic, sensifivity and
> polarity).
As I understood, and I encourage you to implement them. It looks like the
NIRQ check would have to be a maximum test only though, warn if the table
contains more than NIRQ-1 entries.
- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-13 21:30 ` Andrew Johnson
@ 2001-08-13 21:47 ` Mark A. Greer
0 siblings, 0 replies; 15+ messages in thread
From: Mark A. Greer @ 2001-08-13 21:47 UTC (permalink / raw)
To: Andrew Johnson
Cc: Matt Porter, Dan Malek, James F Dougherty, linuxppc-embedded,
cort, jfd
Andrew Johnson wrote:
> "Mark A. Greer" wrote:
> >
> > Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
> > adjusts NumSources if it is less than OpenPIC_NumInitSenses. That let's you proceed with
> > an initsenses with more irq's than the pic tells you it has. Its not a complete, long-term
> > solution.
>
> There was something present that switches the chip between serial and
> discrete mode. Other than that and the actual location of the config
> registers for each IRQ I don't think there's anything more needed to
> distinguish the two in software.
That is correct in the code that I gave you. Those particular pieces were not put in official
hhl2.0
>
> > The NIRQ field is a part of the problem in serial mode. You can have 16 lines hooked up in
> > serial mode and the NIRQ still tells you that there should only be 5, IIRC.
>
> Actually it doesn't tell you that at all - from the EPIC documentation in
> the 8240 manual, NIRQ provides the (fixed) maximum number of interrupt
> sources supported by the EPIC. On the 8240 the NIRQ value is 0x17=23
> which corresponds to 24 interrupt sources (NIRQ=0 means 1 source),
> comprising 16 serial IRQs, 4 timers, I2C, 2*DMA channels and the Mesage
> Unit.
All of this is correct, the problem is you have to put in 16 dummy entries at the beginning of
initsenses to get the registers to line up correctly. When you add 16 serial external inputs to
the 16 dummies you end up with more than what NIRQ allows.
We're wasting bandwidth here, the real problem is that the current openpic_init interface isn't
quite flexible enough to suit the epic in anything but a vanilla, direct mode, external IRQ-only
set up. That interface should be extended.
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
@ 2001-08-14 7:43 James F Dougherty
2001-08-14 17:45 ` Mark A. Greer
0 siblings, 1 reply; 15+ messages in thread
From: James F Dougherty @ 2001-08-14 7:43 UTC (permalink / raw)
To: anj, mgreer; +Cc: mporter, dan, jfd, linuxppc-embedded, cort, jfd
Mark,
Send me your changes and I'll
gladly test them...
Thanks,
-James
>
> > "Mark A. Greer" wrote:
> > >
> > > The changes to the openpic code for supporting serial interrupt mode are
very minor.
> >
> > Actually IIRC they're already present in the version shipped with
> > HHL-2.0. I don't remember making any changes for that at all on the
> > MVME2100 support, but my memory has been known to be faulty.
>
> Well, there is no _explicit_ support for serial mode but there was an 'if'
stmt added that
> adjusts NumSources if it is less than OpenPIC_NumInitSenses. That let's you
proceed with
> an initsenses with more irq's than the pic tells you it has. Its not a
complete, long-term
> solution.
>
> Also, I'm trying to keep this discussion relative to 2_4_devel not hhlx.x
>
> > > What I mean is a table where you specify the irq, the offset fo the regs
from the base
> > > address, the sensitivity, and the polarity all separately. Also the
appropriate
> > > extensions to support serial interrupt mode (e.g., MVME2100 uses that).
With a table
> > > format something like that, you can avoid the sparse and negative irq's on
the
> > > 8240/107 and still keep things pretty clean looking.
> >
> > That sounds right. It could also use the NIRQ field of the Feature
> > Reporting Register to cross-check that the table given is the correct size
> > for the chip it's controlling, and have some way of specifying the
> > presence or absensce of a cascaded i8259 (presumably with its own table).
>
> The NIRQ field is a part of the problem in serial mode. You can have 16 lines
hooked up in
> serial mode and the NIRQ still tells you that there should only be 5, IIRC.
>
> The table changes are intended to solve more than just epic serial mode.
They're intended
> to make explicit--and flexible--all the assumptions that are currently buried
in the
> initsenses table (irq #, the offset of corresponding reg in pic, sensifivity
and
> polarity). These aren't extensive changes, I should just do them, post a
patch for review
> & shut up... :)
>
> Mark
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-14 7:43 MPC8240 EPIC Driver (Attached) James F Dougherty
@ 2001-08-14 17:45 ` Mark A. Greer
2001-08-14 21:37 ` Mark A. Greer
0 siblings, 1 reply; 15+ messages in thread
From: Mark A. Greer @ 2001-08-14 17:45 UTC (permalink / raw)
To: James F Dougherty; +Cc: anj, mporter, dan, linuxppc-embedded, cort, jfd
James F Dougherty wrote:
> Mark,
>
> Send me your changes and I'll
> gladly test them...
I never finished them. I had some changes in an old 2.4.0-testxxx kernel but never
finished what I started.
This was several months ago so I kinda forget but I was going to make the
initsenses table look something like what gets passed to openpic_initirq plus a
field to specify the offset in from OpenPIC_addr/OpenPIC. I also added a couple
routines to set the epic in serial or direct mode and I think that was about it.
I may have some of this laying around. I'll take a look this afternoon & if its
worth sending, I'll send it to you.
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-14 17:45 ` Mark A. Greer
@ 2001-08-14 21:37 ` Mark A. Greer
2001-08-14 23:20 ` Dan Malek
0 siblings, 1 reply; 15+ messages in thread
From: Mark A. Greer @ 2001-08-14 21:37 UTC (permalink / raw)
To: James F Dougherty, anj, mporter, dan, linuxppc-embedded, cort,
jfd
James,
I took a look around and I think I deleted what I had. It really wasn't that much
code anyway. The important things are to get the functionality and not cause
wholesale changes to the existing code.
Please let me know if you're going to work on it and I'll wait to see what you come up
with. Otherwise, now that there seems to be interest, I'll start working on it when
I'm done with my current project (in a few weeks).
Mark
--
"Mark A. Greer" wrote:
> James F Dougherty wrote:
>
> > Mark,
> >
> > Send me your changes and I'll
> > gladly test them...
>
> I never finished them. I had some changes in an old 2.4.0-testxxx kernel but never
> finished what I started.
> This was several months ago so I kinda forget but I was going to make the
> initsenses table look something like what gets passed to openpic_initirq plus a
> field to specify the offset in from OpenPIC_addr/OpenPIC. I also added a couple
> routines to set the epic in serial or direct mode and I think that was about it.
>
> I may have some of this laying around. I'll take a look this afternoon & if its
> worth sending, I'll send it to you.
>
> Mark
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
2001-08-14 21:37 ` Mark A. Greer
@ 2001-08-14 23:20 ` Dan Malek
0 siblings, 0 replies; 15+ messages in thread
From: Dan Malek @ 2001-08-14 23:20 UTC (permalink / raw)
To: Mark A. Greer
Cc: James F Dougherty, anj, mporter, linuxppc-embedded, cort, jfd
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
"Mark A. Greer" wrote:
> I took a look around and I think I deleted what I had.....
Attached is a patch that works with Sandpoint X3, adds the new
serial mode interrupt stuff, and 8245. You may have to manually
apply it, but it gets you started.
It's on my check-in list, but I have higher priority things at
the moment. Like Mark said, I would like to see a better OpenPIC
solution that could also include EPIC and be a little more configurable.
I was hoping this would have happened by now, as I would have rather
added to that instead of propagating more hacks.
-- Dan
[-- Attachment #2: x3patch --]
[-- Type: text/plain, Size: 10715 bytes --]
diff -Naru linux-hhl20/arch/ppc/config.in hhl-sandpointx3/arch/ppc/config.in
--- linux-hhl20/arch/ppc/config.in Wed May 23 15:46:02 2001
+++ hhl-sandpointx3/arch/ppc/config.in Wed Jul 25 15:30:19 2001
@@ -198,6 +198,10 @@
bool 'Thermal Management Support' CONFIG_TAU
fi
+if [ "$CONFIG_SANDPOINT" = "y" ]; then
+ bool 'Sandpoint X3' CONFIG_SANDPOINT_X3
+fi
+
# OpenFirmware is currently, and possibly only ever, found on machines which
# fall under CONFIG_WORKSTATION_PPC, so:
define_bool CONFIG_OPENFIRMWARE $CONFIG_WORKSTATION_PPC
diff -Naru linux-hhl20/arch/ppc/kernel/mpc10x.h hhl-sandpointx3/arch/ppc/kernel/mpc10x.h
--- linux-hhl20/arch/ppc/kernel/mpc10x.h Wed Apr 4 13:39:08 2001
+++ hhl-sandpointx3/arch/ppc/kernel/mpc10x.h Wed Jul 25 15:30:19 2001
@@ -46,6 +46,7 @@
PCI_VENDOR_ID_MOTOROLA)
#define MPC10X_BRIDGE_8240 ((0x0003 << 16) | PCI_VENDOR_ID_MOTOROLA)
#define MPC10X_BRIDGE_107 ((0x0004 << 16) | PCI_VENDOR_ID_MOTOROLA)
+#define MPC10X_BRIDGE_8245 ((0x0006 << 16) | PCI_VENDOR_ID_MOTOROLA)
/* Define the type of map to use */
#define MPC10X_MEM_MAP_A 1
diff -Naru linux-hhl20/arch/ppc/kernel/mpc10x_common.c hhl-sandpointx3/arch/ppc/kernel/mpc10x_common.c
--- linux-hhl20/arch/ppc/kernel/mpc10x_common.c Wed Apr 4 13:15:07 2001
+++ hhl-sandpointx3/arch/ppc/kernel/mpc10x_common.c Wed Jul 25 15:30:19 2001
@@ -85,6 +85,7 @@
case MPC10X_BRIDGE_106:
case MPC10X_BRIDGE_8240:
case MPC10X_BRIDGE_107:
+ case MPC10X_BRIDGE_8245:
break;
default:
if (ppc_md.progress)
diff -Naru linux-hhl20/arch/ppc/kernel/open_pic.c hhl-sandpointx3/arch/ppc/kernel/open_pic.c
--- linux-hhl20/arch/ppc/kernel/open_pic.c Wed May 23 15:46:03 2001
+++ hhl-sandpointx3/arch/ppc/kernel/open_pic.c Wed Jul 25 15:30:19 2001
@@ -48,6 +48,9 @@
void openpic_eoi(void);
static void openpic_set_priority(u_int pri);
static void openpic_set_spurious(u_int vector);
+static void openpic_enable_sie(void);
+static void openpic_eicr_set_clk(u_int clkval);
+static void openpic_reset(void);
#ifdef CONFIG_SMP
/* Interprocessor Interrupts */
@@ -71,7 +74,6 @@
* for completeness and future reference.
*/
#ifdef notused
-static void openpic_reset(void);
static void openpic_enable_8259_pass_through(void);
static u_int openpic_get_priority(void);
static u_int openpic_get_spurious(void);
@@ -269,6 +271,9 @@
return;
}
OpenPIC = (volatile struct OpenPIC *)OpenPIC_Addr;
+#ifdef CONFIG_SANDPOINT_X3
+ openpic_reset();
+#endif
if ( ppc_md.progress ) ppc_md.progress("openpic enter",0x122);
@@ -385,8 +390,15 @@
"82c59 cascade", NULL))
printk("Unable to get OpenPIC IRQ 0 for cascade\n");
}
- openpic_set_priority(0);
+#ifdef CONFIG_SANDPOINT_X3
openpic_disable_8259_pass_through();
+ openpic_eicr_set_clk(7); /* Slowest value until we know better */
+ openpic_enable_sie();
+ openpic_set_priority(0);
+#else
+ openpic_set_priority(0);
+ openpic_disable_8259_pass_through();
+#endif
if (ppc_md.progress) ppc_md.progress("openpic exit",0x222);
}
@@ -424,13 +436,15 @@
#endif
}
-#ifdef notused
static void openpic_reset(void)
{
openpic_setfield(&OpenPIC->Global.Global_Configuration0,
OPENPIC_CONFIG_RESET);
+ while (openpic_readfield(&OpenPIC->Global.Global_Configuration0,
+ OPENPIC_CONFIG_RESET) != 0);
}
+#ifdef notused
static void openpic_enable_8259_pass_through(void)
{
openpic_clearfield(&OpenPIC->Global.Global_Configuration0,
@@ -442,6 +456,18 @@
{
openpic_setfield(&OpenPIC->Global.Global_Configuration0,
OPENPIC_CONFIG_8259_PASSTHROUGH_DISABLE);
+}
+
+static void openpic_enable_sie(void)
+{
+ openpic_setfield(&OpenPIC->Global.Global_Configuration1,
+ OPENPIC_EICR_SIE);
+}
+
+static void openpic_eicr_set_clk(u_int clkval)
+{
+ openpic_writefield(&OpenPIC->Global.Global_Configuration1,
+ OPENPIC_EICR_S_CLK_MASK, (clkval << 28));
}
#ifdef CONFIG_SMP
diff -Naru linux-hhl20/arch/ppc/kernel/open_pic_defs.h hhl-sandpointx3/arch/ppc/kernel/open_pic_defs.h
--- linux-hhl20/arch/ppc/kernel/open_pic_defs.h Wed May 23 15:46:03 2001
+++ hhl-sandpointx3/arch/ppc/kernel/open_pic_defs.h Wed Jul 25 15:30:19 2001
@@ -206,6 +206,14 @@
#define OPENPIC_CONFIG_BASE_MASK 0x000fffff
/*
+ * Global Configuration Register 1
+ * This is the EICR on EPICs.
+ */
+
+#define OPENPIC_EICR_S_CLK_MASK 0x70000000
+#define OPENPIC_EICR_SIE 0x08000000
+
+ /*
* Vendor Identification Register
*/
diff -Naru linux-hhl20/arch/ppc/kernel/sandpoint.h hhl-sandpointx3/arch/ppc/kernel/sandpoint.h
--- linux-hhl20/arch/ppc/kernel/sandpoint.h Wed Mar 28 09:05:21 2001
+++ hhl-sandpointx3/arch/ppc/kernel/sandpoint.h Wed Jul 25 15:30:19 2001
@@ -21,11 +21,29 @@
#ifndef __PPC_KERNEL_SANDPOINT_H
#define __PPC_KERNEL_SANDPOINT_H
+#ifdef CONFIG_SANDPOINT_X3
+#define SANDPOINT_SIO_SLOT 0 /* Cascaded from EPIC IRQ 0 */
+#if 0
+/* The Sandpoint X3 allows the IDE interrupt to be directly connected
+ * from the Windbond (PCI INTC or INTD) to the serial EPIC. Someday
+ * we should try this, but it was easier to use the existing 83c553
+ * initialization than change it to route the different interrupts :-).
+ * -- Dan
+ */
+#define SANDPOINT_IDE_INT0 23 /* EPIC 7 */
+#define SANDPOINT_IDE_INT1 24 /* EPIC 8 */
+#else
+#define SANDPOINT_IDE_INT0 14 /* 8259 Test */
+#define SANDPOINT_IDE_INT1 15 /* 8259 Test */
+#endif
+#else
/*
* Define the PCI slot that the 8259 is sharing interrupts with.
* Valid values are 1 (PCI slot 2) and 2 (PCI slot 3).
*/
#define SANDPOINT_SIO_SLOT 1
+#endif
+
#define SANDPOINT_SIO_IRQ (SANDPOINT_SIO_SLOT + NUM_8259_INTERRUPTS)
void sandpoint_find_bridges(void);
diff -Naru linux-hhl20/arch/ppc/kernel/sandpoint_pci.c hhl-sandpointx3/arch/ppc/kernel/sandpoint_pci.c
--- linux-hhl20/arch/ppc/kernel/sandpoint_pci.c Tue Apr 3 11:47:38 2001
+++ hhl-sandpointx3/arch/ppc/kernel/sandpoint_pci.c Wed Jul 25 15:30:19 2001
@@ -45,10 +45,24 @@
{ SANDPOINT_SIO_IRQ,
0, 0, 0 }, /* IDSEL 11 - i8259 on Winbond */
{ 0, 0, 0, 0 }, /* IDSEL 12 - unused */
+#ifdef CONFIG_SANDPOINT_X3
+#if 0 /* This is what it _should_ look like -- Dan */
+ { 17, 20, 19, 18 }, /* IDSEL 13 - PCI slot 1 */
+ { 18, 17, 20, 19 }, /* IDSEL 14 - PCI slot 2 */
+ { 19, 18, 17, 20 }, /* IDSEL 15 - PCI slot 3 */
+ { 20, 19, 18, 17 }, /* IDSEL 16 - PCI slot 4 */
+#else
+ { 18, 21, 20, 19 }, /* IDSEL 13 - PCI slot 1 */
+ { 19, 18, 21, 20 }, /* IDSEL 14 - PCI slot 2 */
+ { 20, 19, 18, 21 }, /* IDSEL 15 - PCI slot 3 */
+ { 21, 20, 19, 18 }, /* IDSEL 16 - PCI slot 4 */
+#endif
+#else
{ 16, 19, 18, 17 }, /* IDSEL 13 - PCI slot 1 */
{ 17, 16, 19, 18 }, /* IDSEL 14 - PCI slot 2 */
{ 18, 17, 16, 19 }, /* IDSEL 15 - PCI slot 3 */
{ 19, 18, 17, 16 }, /* IDSEL 16 - PCI slot 4 */
+#endif
};
const long min_idsel = 11, max_idsel = 16, irqs_per_slot = 4;
diff -Naru linux-hhl20/arch/ppc/kernel/sandpoint_setup.c hhl-sandpointx3/arch/ppc/kernel/sandpoint_setup.c
--- linux-hhl20/arch/ppc/kernel/sandpoint_setup.c Thu Mar 29 21:41:29 2001
+++ hhl-sandpointx3/arch/ppc/kernel/sandpoint_setup.c Wed Jul 25 15:30:19 2001
@@ -36,6 +36,25 @@
* S5: up
* S6: down
*
+ * Up/Down are obviously relative to the way the board is installed in
+ * your system :-). "Down" is toward the PPMC module (which is actually
+ * "up" in my system). -- Dan
+ *
+ * Since Motorola listened to our suggestions for improvement, we now have
+ * the Sandpoint X3 board. All of the PCI slots are available, it uses
+ * the serial interrupt interface (just a hardware thing we need to
+ * configure properly).
+ *
+ * Use the default X3 switch settings. The interrupts are then:
+ * EPIC Source
+ * 0 SIOINT (8259, active low)
+ * 1 PCI #1
+ * 2 PCI #2
+ * 3 PCI #3
+ * 4 PCI #4
+ * 7 Winbond INTC (IDE interrupt)
+ * 8 Winbond INTD (IDE interrupt)
+ *
* *** IMPORTANT ***
*
* This port will not work properly as is. You must apply the following patch:
@@ -120,11 +139,25 @@
0, /* 13 */
0, /* 14 */
0, /* 15 */
+#ifdef CONFIG_SANDPOINT_X3
+ 1, /* 16: EPIC IRQ 0: Active Low -- SIOINT (8259) */
+ 0, /* AACK! Shouldn't need this.....see sandpoint_pci.c for more info */
+ 1, /* 17: EPIC IRQ 1: Active Low -- PCI Slot 1 */
+ 1, /* 18: EPIC IRQ 2: Active Low -- PCI Slot 2 */
+ 1, /* 19: EPIC IRQ 3: Active Low -- PCI Slot 3 */
+ 1, /* 20: EPIC IRQ 4: Active Low -- PCI Slot 4 */
+ 0, /* 21 -- Unused */
+ 0, /* 22 -- Unused */
+ 1, /* 23 -- IDE (Winbond INT C) */
+ 1, /* 24 -- IDE (Winbond INT D) */
+ /* 35 - 31 (EPIC 9 - 15) Unused */
+#else
1, /* 16: EPIC IRQ 0: Active Low -- PCI intrs */
1, /* 17: EPIC IRQ 1: Active Low -- PCI (possibly 8259) intrs */
1, /* 18: EPIC IRQ 2: Active Low -- PCI (possibly 8259) intrs */
1 /* 19: EPIC IRQ 3: Active Low -- PCI intrs */
/* 20: EPIC IRQ 4: Not used */
+#endif
};
static void __init
@@ -242,6 +275,9 @@
* Slot numbering is confusing. Sometimes in the documentation they
* use 0,1,2,3 and others 1,2,3,4. We will use slots 1,2,3,4 and
* map this to IRQ 16, 17, 18, 19.
+ * For Sandpoint X3, this has been better designed. The 8259 is
+ * cascaded from EPIC IRQ0, IRQ1-4 map to PCI slots 1-4, IDE is on
+ * EPIC 7 and 8.
*/
static void __init
sandpoint_init_IRQ(void)
@@ -444,9 +480,9 @@
sandpoint_ide_probe();
if (base == sandpoint_ide_regbase[0])
- return 14;
+ return SANDPOINT_IDE_INT0;
else if (base == sandpoint_ide_regbase[1])
- return 15;
+ return SANDPOINT_IDE_INT1;
else
return 0;
}
@@ -504,11 +540,11 @@
if (data_port == sandpoint_ide_regbase[0]) {
alt_status_base = sandpoint_ide_ctl_regbase[0] + 2;
- hw->irq = 14;
+ hw->irq = SANDPOINT_IDE_INT0;
}
else if (data_port == sandpoint_ide_regbase[1]) {
alt_status_base = sandpoint_ide_ctl_regbase[1] + 2;
- hw->irq = 15;
+ hw->irq = SANDPOINT_IDE_INT1;
}
else {
alt_status_base = 0;
diff -Naru linux-hhl20/arch/ppc/kernel/setup.c hhl-sandpointx3/arch/ppc/kernel/setup.c
--- linux-hhl20/arch/ppc/kernel/setup.c Wed May 23 15:46:03 2001
+++ hhl-sandpointx3/arch/ppc/kernel/setup.c Wed Jul 25 15:30:19 2001
@@ -434,6 +434,9 @@
case 0x0081:
len += sprintf(len+buffer, "82xx\n");
break;
+ case 0x8081:
+ len += sprintf(len+buffer, "8245\n");
+ break;
case 0x4011:
len += sprintf(len+buffer, "405GP\n");
break;
diff -Naru linux-hhl20/include/asm-ppc/processor.h hhl-sandpointx3/include/asm-ppc/processor.h
--- linux-hhl20/include/asm-ppc/processor.h Wed May 23 15:46:09 2001
+++ hhl-sandpointx3/include/asm-ppc/processor.h Wed Jul 25 15:32:58 2001
@@ -469,6 +469,7 @@
#define PVR_860 PVR_821
#define PVR_7400 0x000C0000
#define PVR_8240 0x00810100
+#define PVR_8245 0x80810100
#define PVR_8260 PVR_8240
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
@ 2001-08-15 6:27 James F Dougherty
0 siblings, 0 replies; 15+ messages in thread
From: James F Dougherty @ 2001-08-15 6:27 UTC (permalink / raw)
To: mgreer, dan; +Cc: jfd, anj, mporter, linuxppc-embedded, cort, jfd
Very cool! My MPC8240 board is off for PCI rework, when I get it
back, I will try it out (PCI slot problems with Promise PDC20262).
More later ...
-James
>
> "Mark A. Greer" wrote:
>
> > I took a look around and I think I deleted what I had.....
>
> Attached is a patch that works with Sandpoint X3, adds the new
> serial mode interrupt stuff, and 8245. You may have to manually
> apply it, but it gets you started.
>
> It's on my check-in list, but I have higher priority things at
> the moment. Like Mark said, I would like to see a better OpenPIC
> solution that could also include EPIC and be a little more configurable.
> I was hoping this would have happened by now, as I would have rather
> added to that instead of propagating more hacks.
>
>
> -- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: MPC8240 EPIC Driver (Attached)
@ 2001-08-15 6:31 James F Dougherty
0 siblings, 0 replies; 15+ messages in thread
From: James F Dougherty @ 2001-08-15 6:31 UTC (permalink / raw)
To: jfd, anj, mporter, dan, linuxppc-embedded, cort, jfd, mgreer
No problem. I will let you know what I find out
with Dan's patch.
More later ..
>
> James,
>
> I took a look around and I think I deleted what I had. It really wasn't that
much
> code anyway. The important things are to get the functionality and not cause
> wholesale changes to the existing code.
>
> Please let me know if you're going to work on it and I'll wait to see what you
come up
> with. Otherwise, now that there seems to be interest, I'll start working on
it when
> I'm done with my current project (in a few weeks).
>
> Mark
> --
>
> "Mark A. Greer" wrote:
>
> > James F Dougherty wrote:
> >
> > > Mark,
> > >
> > > Send me your changes and I'll
> > > gladly test them...
> >
> > I never finished them. I had some changes in an old 2.4.0-testxxx kernel
but never
> > finished what I started.
> > This was several months ago so I kinda forget but I was going to make the
> > initsenses table look something like what gets passed to openpic_initirq
plus a
> > field to specify the offset in from OpenPIC_addr/OpenPIC. I also added a
couple
> > routines to set the epic in serial or direct mode and I think that was about
it.
> >
> > I may have some of this laying around. I'll take a look this afternoon & if
its
> > worth sending, I'll send it to you.
> >
> > Mark
> >
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2001-08-15 6:31 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-14 7:43 MPC8240 EPIC Driver (Attached) James F Dougherty
2001-08-14 17:45 ` Mark A. Greer
2001-08-14 21:37 ` Mark A. Greer
2001-08-14 23:20 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2001-08-15 6:31 James F Dougherty
2001-08-15 6:27 James F Dougherty
2001-08-11 7:18 James F Dougherty
2001-08-11 23:47 ` Dan Malek
2001-08-13 15:56 ` Andrew Johnson
2001-08-13 12:54 ` Matt Porter
2001-08-13 18:00 ` Mark A. Greer
2001-08-13 19:56 ` Andrew Johnson
2001-08-13 20:38 ` Mark A. Greer
2001-08-13 21:30 ` Andrew Johnson
2001-08-13 21:47 ` Mark A. Greer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).