* How to access DCR registers in powerpc440gx? Got err when use macro def in Linux kernel
From: g r1x @ 2009-09-11 4:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8abf57fa0909101024n668ad353kf8be038898305c28@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]
Now, I'm writing a DMA driver on powerpc
440gx platform(2.6.26.5), as the only way to set up DMA Controller is
to access it's dcr registers with 'mfdcr' and 'mtdcr'.
I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
u wrote to my driver module directory, and include them, but when I
compile my driver, gcc complains following err messages:
--------------------------------------------------------
{standard input}: Assembler messages:
{standard input}:83: Error: unsupported relocation against dmanr
---------------------------------------------------------
code I copy from kernel 2.6.26.5 (arch/ppc/syslib/ppc4xx_dma.c)
--------------------------------------------
#include "dcr.h"
/* #inlcude <asm/dcr-native.h> */
ppc_dma_ch_t dma_channels[MAX_PPC4xx_DMA_CHANNELS];
int ppc4xx_get_dma_status(void)
{
return (mfdcr(DCRN_DMASR));
}
void ppc4xx_enable_dma(unsigned int dmanr)
{
unsigned int control;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
.........
/ * for other xfer modes, the addresses are already set */
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8)); <----------------err
}
void ppc4xx_set_src_addr(int dmanr, phys_addr_t src_addr)
{
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("set_src_addr: bad channel: %d\n", dmanr);
return;
}
#ifdef PPC4xx_DMA_64BIT
mtdcr(DCRN_DMASAH0 + dmanr*2, (u32)(src_addr >> 32));
#else
mtdcr(DCRN_DMASA0 + dmanr*2, (u32)src_addr);
#endif
}
--------------------------------------------------
DCR access micro I copied:
----------------------------------
#define mfdcr(rn) \
({ \
unsigned long rval; \
asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
rval; \
})
#define mtdcr(rn, val) \
asm volatile("mtdcr %0,%1" : : "i"(rn), "r"(val))
-----------------------------------------------------
Makefile I worte
-------------------------
obj-m := dmatest.o
dmatest-objs += dma.o core.o
KBUILD_CFLAGS += -m440 -mregnames -Wa, -booke
KBUILD_ASFAGS += -m440 -mregnames -Wa, -booke
---------
KBUILD_CFLAGS += -m440 -mregnames -Wa, -booke
KBUILD_ASFAGS += -m440 -mregnames -Wa, -booke
I add these two sentences when I read these
http://sourceware.org/ml/binutils/2004-09/msg00161.html.
When I change it to mfdcr(DCRN_DMACR0); then everything is fine. but
from the result I got when I insmod my module driver, dcr reg is not
changed.
It seems that it's the problem with gnu assembler, my GNU assembler ver is 2.17
The attachments are the c source file I copy from linux 2.6.26.5, and
I use these dma function to directly manipulate dcr registers, but
when I make my driver module outside kernel source tree, it complains
the error I mentioned above.
Thanks!
[-- Attachment #2: ppc4xx_dma.c --]
[-- Type: application/octet-stream, Size: 18648 bytes --]
/*
* IBM PPC4xx DMA engine core library
*
* Copyright 2000-2004 MontaVista Software Inc.
*
* Cleaned up and converted to new DCR access
* Matt Porter <mporter@kernel.crashing.org>
*
* Original code by Armin Kuster <akuster@mvista.com>
* and Pete Popov <ppopov@mvista.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/miscdevice.h>
#include <linux/init.h>
#include <linux/module.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/dma.h>
#include <asm/ppc4xx_dma.h>
ppc_dma_ch_t dma_channels[MAX_PPC4xx_DMA_CHANNELS];
int
ppc4xx_get_dma_status(void)
{
return (mfdcr(DCRN_DMASR));
}
void
ppc4xx_set_src_addr(int dmanr, phys_addr_t src_addr)
{
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("set_src_addr: bad channel: %d\n", dmanr);
return;
}
#ifdef PPC4xx_DMA_64BIT
mtdcr(DCRN_DMASAH0 + dmanr*2, (u32)(src_addr >> 32));
#else
mtdcr(DCRN_DMASA0 + dmanr*2, (u32)src_addr);
#endif
}
void
ppc4xx_set_dst_addr(int dmanr, phys_addr_t dst_addr)
{
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("set_dst_addr: bad channel: %d\n", dmanr);
return;
}
#ifdef PPC4xx_DMA_64BIT
mtdcr(DCRN_DMADAH0 + dmanr*2, (u32)(dst_addr >> 32));
#else
mtdcr(DCRN_DMADA0 + dmanr*2, (u32)dst_addr);
#endif
}
void
ppc4xx_enable_dma(unsigned int dmanr)
{
unsigned int control;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
unsigned int status_bits[] = { DMA_CS0 | DMA_TS0 | DMA_CH0_ERR,
DMA_CS1 | DMA_TS1 | DMA_CH1_ERR,
DMA_CS2 | DMA_TS2 | DMA_CH2_ERR,
DMA_CS3 | DMA_TS3 | DMA_CH3_ERR};
if (p_dma_ch->in_use) {
printk("enable_dma: channel %d in use\n", dmanr);
return;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("enable_dma: bad channel: %d\n", dmanr);
return;
}
if (p_dma_ch->mode == DMA_MODE_READ) {
/* peripheral to memory */
ppc4xx_set_src_addr(dmanr, 0);
ppc4xx_set_dst_addr(dmanr, p_dma_ch->addr);
} else if (p_dma_ch->mode == DMA_MODE_WRITE) {
/* memory to peripheral */
ppc4xx_set_src_addr(dmanr, p_dma_ch->addr);
ppc4xx_set_dst_addr(dmanr, 0);
}
/* for other xfer modes, the addresses are already set */
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
control &= ~(DMA_TM_MASK | DMA_TD); /* clear all mode bits */
if (p_dma_ch->mode == DMA_MODE_MM) {
/* software initiated memory to memory */
control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
}
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
/*
* Clear the CS, TS, RI bits for the channel from DMASR. This
* has been observed to happen correctly only after the mode and
* ETD/DCE bits in DMACRx are set above. Must do this before
* enabling the channel.
*/
mtdcr(DCRN_DMASR, status_bits[dmanr]);
/*
* For device-paced transfers, Terminal Count Enable apparently
* must be on, and this must be turned on after the mode, etc.
* bits are cleared above (at least on Redwood-6).
*/
if ((p_dma_ch->mode == DMA_MODE_MM_DEVATDST) ||
(p_dma_ch->mode == DMA_MODE_MM_DEVATSRC))
control |= DMA_TCE_ENABLE;
/*
* Now enable the channel.
*/
control |= (p_dma_ch->mode | DMA_CE_ENABLE);
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
p_dma_ch->in_use = 1;
}
void
ppc4xx_disable_dma(unsigned int dmanr)
{
unsigned int control;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (!p_dma_ch->in_use) {
printk("disable_dma: channel %d not in use\n", dmanr);
return;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("disable_dma: bad channel: %d\n", dmanr);
return;
}
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
control &= ~DMA_CE_ENABLE;
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
p_dma_ch->in_use = 0;
}
/*
* Sets the dma mode for single DMA transfers only.
* For scatter/gather transfers, the mode is passed to the
* alloc_dma_handle() function as one of the parameters.
*
* The mode is simply saved and used later. This allows
* the driver to call set_dma_mode() and set_dma_addr() in
* any order.
*
* Valid mode values are:
*
* DMA_MODE_READ peripheral to memory
* DMA_MODE_WRITE memory to peripheral
* DMA_MODE_MM memory to memory
* DMA_MODE_MM_DEVATSRC device-paced memory to memory, device at src
* DMA_MODE_MM_DEVATDST device-paced memory to memory, device at dst
*/
int
ppc4xx_set_dma_mode(unsigned int dmanr, unsigned int mode)
{
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("set_dma_mode: bad channel 0x%x\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
p_dma_ch->mode = mode;
return DMA_STATUS_GOOD;
}
/*
* Sets the DMA Count register. Note that 'count' is in bytes.
* However, the DMA Count register counts the number of "transfers",
* where each transfer is equal to the bus width. Thus, count
* MUST be a multiple of the bus width.
*/
void
ppc4xx_set_dma_count(unsigned int dmanr, unsigned int count)
{
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
#ifdef DEBUG_4xxDMA
{
int error = 0;
switch (p_dma_ch->pwidth) {
case PW_8:
break;
case PW_16:
if (count & 0x1)
error = 1;
break;
case PW_32:
if (count & 0x3)
error = 1;
break;
case PW_64:
if (count & 0x7)
error = 1;
break;
default:
printk("set_dma_count: invalid bus width: 0x%x\n",
p_dma_ch->pwidth);
return;
}
if (error)
printk
("Warning: set_dma_count count 0x%x bus width %d\n",
count, p_dma_ch->pwidth);
}
#endif
count = count >> p_dma_ch->shift;
mtdcr(DCRN_DMACT0 + (dmanr * 0x8), count);
}
/*
* Returns the number of bytes left to be transferred.
* After a DMA transfer, this should return zero.
* Reading this while a DMA transfer is still in progress will return
* unpredictable results.
*/
int
ppc4xx_get_dma_residue(unsigned int dmanr)
{
unsigned int count;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_get_dma_residue: bad channel 0x%x\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
count = mfdcr(DCRN_DMACT0 + (dmanr * 0x8));
return (count << p_dma_ch->shift);
}
/*
* Sets the DMA address for a memory to peripheral or peripheral
* to memory transfer. The address is just saved in the channel
* structure for now and used later in enable_dma().
*/
void
ppc4xx_set_dma_addr(unsigned int dmanr, phys_addr_t addr)
{
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_set_dma_addr: bad channel: %d\n", dmanr);
return;
}
#ifdef DEBUG_4xxDMA
{
int error = 0;
switch (p_dma_ch->pwidth) {
case PW_8:
break;
case PW_16:
if ((unsigned) addr & 0x1)
error = 1;
break;
case PW_32:
if ((unsigned) addr & 0x3)
error = 1;
break;
case PW_64:
if ((unsigned) addr & 0x7)
error = 1;
break;
default:
printk("ppc4xx_set_dma_addr: invalid bus width: 0x%x\n",
p_dma_ch->pwidth);
return;
}
if (error)
printk("Warning: ppc4xx_set_dma_addr addr 0x%x bus width %d\n",
addr, p_dma_ch->pwidth);
}
#endif
/* save dma address and program it later after we know the xfer mode */
p_dma_ch->addr = addr;
}
/*
* Sets both DMA addresses for a memory to memory transfer.
* For memory to peripheral or peripheral to memory transfers
* the function set_dma_addr() should be used instead.
*/
void
ppc4xx_set_dma_addr2(unsigned int dmanr, phys_addr_t src_dma_addr,
phys_addr_t dst_dma_addr)
{
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_set_dma_addr2: bad channel: %d\n", dmanr);
return;
}
#ifdef DEBUG_4xxDMA
{
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
int error = 0;
switch (p_dma_ch->pwidth) {
case PW_8:
break;
case PW_16:
if (((unsigned) src_dma_addr & 0x1) ||
((unsigned) dst_dma_addr & 0x1)
)
error = 1;
break;
case PW_32:
if (((unsigned) src_dma_addr & 0x3) ||
((unsigned) dst_dma_addr & 0x3)
)
error = 1;
break;
case PW_64:
if (((unsigned) src_dma_addr & 0x7) ||
((unsigned) dst_dma_addr & 0x7)
)
error = 1;
break;
default:
printk("ppc4xx_set_dma_addr2: invalid bus width: 0x%x\n",
p_dma_ch->pwidth);
return;
}
if (error)
printk
("Warning: ppc4xx_set_dma_addr2 src 0x%x dst 0x%x bus width %d\n",
src_dma_addr, dst_dma_addr, p_dma_ch->pwidth);
}
#endif
ppc4xx_set_src_addr(dmanr, src_dma_addr);
ppc4xx_set_dst_addr(dmanr, dst_dma_addr);
}
/*
* Enables the channel interrupt.
*
* If performing a scatter/gatter transfer, this function
* MUST be called before calling alloc_dma_handle() and building
* the sgl list. Otherwise, interrupts will not be enabled, if
* they were previously disabled.
*/
int
ppc4xx_enable_dma_interrupt(unsigned int dmanr)
{
unsigned int control;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_enable_dma_interrupt: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
p_dma_ch->int_enable = 1;
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
control |= DMA_CIE_ENABLE; /* Channel Interrupt Enable */
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
return DMA_STATUS_GOOD;
}
/*
* Disables the channel interrupt.
*
* If performing a scatter/gatter transfer, this function
* MUST be called before calling alloc_dma_handle() and building
* the sgl list. Otherwise, interrupts will not be disabled, if
* they were previously enabled.
*/
int
ppc4xx_disable_dma_interrupt(unsigned int dmanr)
{
unsigned int control;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_disable_dma_interrupt: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
p_dma_ch->int_enable = 0;
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
control &= ~DMA_CIE_ENABLE; /* Channel Interrupt Enable */
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
return DMA_STATUS_GOOD;
}
/*
* Configures a DMA channel, including the peripheral bus width, if a
* peripheral is attached to the channel, the polarity of the DMAReq and
* DMAAck signals, etc. This information should really be setup by the boot
* code, since most likely the configuration won't change dynamically.
* If the kernel has to call this function, it's recommended that it's
* called from platform specific init code. The driver should not need to
* call this function.
*/
int
ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
unsigned int polarity;
uint32_t control = 0;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
DMA_MODE_READ = (unsigned long) DMA_TD; /* Peripheral to Memory */
DMA_MODE_WRITE = 0; /* Memory to Peripheral */
if (!p_init) {
printk("ppc4xx_init_dma_channel: NULL p_init\n");
return DMA_STATUS_NULL_POINTER;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_init_dma_channel: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
polarity = 0;
#endif
/* Setup the control register based on the values passed to
* us in p_init. Then, over-write the control register with this
* new value.
*/
control |= SET_DMA_CONTROL;
/* clear all polarity signals and then "or" in new signal levels */
polarity &= ~GET_DMA_POLARITY(dmanr);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
/* save these values in our dma channel structure */
memcpy(p_dma_ch, p_init, sizeof (ppc_dma_ch_t));
/*
* The peripheral width values written in the control register are:
* PW_8 0
* PW_16 1
* PW_32 2
* PW_64 3
*
* Since the DMA count register takes the number of "transfers",
* we need to divide the count sent to us in certain
* functions by the appropriate number. It so happens that our
* right shift value is equal to the peripheral width value.
*/
p_dma_ch->shift = p_init->pwidth;
/*
* Save the control word for easy access.
*/
p_dma_ch->control = control;
mtdcr(DCRN_DMASR, 0xffffffff); /* clear status register */
return DMA_STATUS_GOOD;
}
/*
* This function returns the channel configuration.
*/
int
ppc4xx_get_channel_config(unsigned int dmanr, ppc_dma_ch_t * p_dma_ch)
{
unsigned int polarity;
unsigned int control;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_get_channel_config: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
memcpy(p_dma_ch, &dma_channels[dmanr], sizeof (ppc_dma_ch_t));
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
polarity = 0;
#endif
p_dma_ch->polarity = polarity & GET_DMA_POLARITY(dmanr);
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
p_dma_ch->cp = GET_DMA_PRIORITY(control);
p_dma_ch->pwidth = GET_DMA_PW(control);
p_dma_ch->psc = GET_DMA_PSC(control);
p_dma_ch->pwc = GET_DMA_PWC(control);
p_dma_ch->phc = GET_DMA_PHC(control);
p_dma_ch->ce = GET_DMA_CE_ENABLE(control);
p_dma_ch->int_enable = GET_DMA_CIE_ENABLE(control);
p_dma_ch->shift = GET_DMA_PW(control);
#ifdef CONFIG_PPC4xx_EDMA
p_dma_ch->pf = GET_DMA_PREFETCH(control);
#else
p_dma_ch->ch_enable = GET_DMA_CH(control);
p_dma_ch->ece_enable = GET_DMA_ECE(control);
p_dma_ch->tcd_disable = GET_DMA_TCD(control);
#endif
return DMA_STATUS_GOOD;
}
/*
* Sets the priority for the DMA channel dmanr.
* Since this is setup by the hardware init function, this function
* can be used to dynamically change the priority of a channel.
*
* Acceptable priorities:
*
* PRIORITY_LOW
* PRIORITY_MID_LOW
* PRIORITY_MID_HIGH
* PRIORITY_HIGH
*
*/
int
ppc4xx_set_channel_priority(unsigned int dmanr, unsigned int priority)
{
unsigned int control;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_set_channel_priority: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
if ((priority != PRIORITY_LOW) &&
(priority != PRIORITY_MID_LOW) &&
(priority != PRIORITY_MID_HIGH) && (priority != PRIORITY_HIGH)) {
printk("ppc4xx_set_channel_priority: bad priority: 0x%x\n", priority);
}
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
control |= SET_DMA_PRIORITY(priority);
mtdcr(DCRN_DMACR0 + (dmanr * 0x8), control);
return DMA_STATUS_GOOD;
}
/*
* Returns the width of the peripheral attached to this channel. This assumes
* that someone who knows the hardware configuration, boot code or some other
* init code, already set the width.
*
* The return value is one of:
* PW_8
* PW_16
* PW_32
* PW_64
*
* The function returns 0 on error.
*/
unsigned int
ppc4xx_get_peripheral_width(unsigned int dmanr)
{
unsigned int control;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_get_peripheral_width: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
control = mfdcr(DCRN_DMACR0 + (dmanr * 0x8));
return (GET_DMA_PW(control));
}
/*
* Clears the channel status bits
*/
int
ppc4xx_clr_dma_status(unsigned int dmanr)
{
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk(KERN_ERR "ppc4xx_clr_dma_status: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
mtdcr(DCRN_DMASR, ((u32)DMA_CH0_ERR | (u32)DMA_CS0 | (u32)DMA_TS0) >> dmanr);
return DMA_STATUS_GOOD;
}
#ifdef CONFIG_PPC4xx_EDMA
/*
* Enables the burst on the channel (BTEN bit in the control/count register)
* Note:
* For scatter/gather dma, this function MUST be called before the
* ppc4xx_alloc_dma_handle() func as the chan count register is copied into the
* sgl list and used as each sgl element is added.
*/
int
ppc4xx_enable_burst(unsigned int dmanr)
{
unsigned int ctc;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk(KERN_ERR "ppc4xx_enable_burst: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) | DMA_CTC_BTEN;
mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
return DMA_STATUS_GOOD;
}
/*
* Disables the burst on the channel (BTEN bit in the control/count register)
* Note:
* For scatter/gather dma, this function MUST be called before the
* ppc4xx_alloc_dma_handle() func as the chan count register is copied into the
* sgl list and used as each sgl element is added.
*/
int
ppc4xx_disable_burst(unsigned int dmanr)
{
unsigned int ctc;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk(KERN_ERR "ppc4xx_disable_burst: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) &~ DMA_CTC_BTEN;
mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
return DMA_STATUS_GOOD;
}
/*
* Sets the burst size (number of peripheral widths) for the channel
* (BSIZ bits in the control/count register))
* must be one of:
* DMA_CTC_BSIZ_2
* DMA_CTC_BSIZ_4
* DMA_CTC_BSIZ_8
* DMA_CTC_BSIZ_16
* Note:
* For scatter/gather dma, this function MUST be called before the
* ppc4xx_alloc_dma_handle() func as the chan count register is copied into the
* sgl list and used as each sgl element is added.
*/
int
ppc4xx_set_burst_size(unsigned int dmanr, unsigned int bsize)
{
unsigned int ctc;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk(KERN_ERR "ppc4xx_set_burst_size: bad channel: %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) &~ DMA_CTC_BSIZ_MSK;
ctc |= (bsize & DMA_CTC_BSIZ_MSK);
mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
return DMA_STATUS_GOOD;
}
EXPORT_SYMBOL(ppc4xx_enable_burst);
EXPORT_SYMBOL(ppc4xx_disable_burst);
EXPORT_SYMBOL(ppc4xx_set_burst_size);
#endif /* CONFIG_PPC4xx_EDMA */
EXPORT_SYMBOL(ppc4xx_init_dma_channel);
EXPORT_SYMBOL(ppc4xx_get_channel_config);
EXPORT_SYMBOL(ppc4xx_set_channel_priority);
EXPORT_SYMBOL(ppc4xx_get_peripheral_width);
EXPORT_SYMBOL(dma_channels);
EXPORT_SYMBOL(ppc4xx_set_src_addr);
EXPORT_SYMBOL(ppc4xx_set_dst_addr);
EXPORT_SYMBOL(ppc4xx_set_dma_addr);
EXPORT_SYMBOL(ppc4xx_set_dma_addr2);
EXPORT_SYMBOL(ppc4xx_enable_dma);
EXPORT_SYMBOL(ppc4xx_disable_dma);
EXPORT_SYMBOL(ppc4xx_set_dma_mode);
EXPORT_SYMBOL(ppc4xx_set_dma_count);
EXPORT_SYMBOL(ppc4xx_get_dma_residue);
EXPORT_SYMBOL(ppc4xx_enable_dma_interrupt);
EXPORT_SYMBOL(ppc4xx_disable_dma_interrupt);
EXPORT_SYMBOL(ppc4xx_get_dma_status);
EXPORT_SYMBOL(ppc4xx_clr_dma_status);
[-- Attachment #3: dcr-native.h --]
[-- Type: application/octet-stream, Size: 3320 bytes --]
/*
* (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
* <benh@kernel.crashing.org>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
* the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#ifndef _ASM_POWERPC_DCR_NATIVE_H
#define _ASM_POWERPC_DCR_NATIVE_H
#ifdef __KERNEL__
#ifndef __ASSEMBLY__
#include <linux/spinlock.h>
typedef struct {
unsigned int base;
} dcr_host_t;
#define DCR_MAP_OK(host) (1)
#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base = (dcr_n) })
#define dcr_unmap(host, dcr_c) do {} while (0)
#define dcr_read(host, dcr_n) mfdcr(dcr_n + host.base)
#define dcr_write(host, dcr_n, value) mtdcr(dcr_n + host.base, value)
/* Device Control Registers */
void __mtdcr(int reg, unsigned int val);
unsigned int __mfdcr(int reg);
#define mfdcr(rn) \
({unsigned int rval; \
if (__builtin_constant_p(rn)) \
asm volatile("mfdcr %0," __stringify(rn) \
: "=r" (rval)); \
else \
rval = __mfdcr(rn); \
rval;})
#define mtdcr(rn, v) \
do { \
if (__builtin_constant_p(rn)) \
asm volatile("mtdcr " __stringify(rn) ",%0" \
: : "r" (v)); \
else \
__mtdcr(rn, v); \
} while (0)
/* R/W of indirect DCRs make use of standard naming conventions for DCRs */
extern spinlock_t dcr_ind_lock;
static inline unsigned __mfdcri(int base_addr, int base_data, int reg)
{
unsigned long flags;
unsigned int val;
spin_lock_irqsave(&dcr_ind_lock, flags);
__mtdcr(base_addr, reg);
val = __mfdcr(base_data);
spin_unlock_irqrestore(&dcr_ind_lock, flags);
return val;
}
static inline void __mtdcri(int base_addr, int base_data, int reg,
unsigned val)
{
unsigned long flags;
spin_lock_irqsave(&dcr_ind_lock, flags);
__mtdcr(base_addr, reg);
__mtdcr(base_data, val);
spin_unlock_irqrestore(&dcr_ind_lock, flags);
}
static inline void __dcri_clrset(int base_addr, int base_data, int reg,
unsigned clr, unsigned set)
{
unsigned long flags;
unsigned int val;
spin_lock_irqsave(&dcr_ind_lock, flags);
__mtdcr(base_addr, reg);
val = (__mfdcr(base_data) & ~clr) | set;
__mtdcr(base_data, val);
spin_unlock_irqrestore(&dcr_ind_lock, flags);
}
#define mfdcri(base, reg) __mfdcri(DCRN_ ## base ## _CONFIG_ADDR, \
DCRN_ ## base ## _CONFIG_DATA, \
reg)
#define mtdcri(base, reg, data) __mtdcri(DCRN_ ## base ## _CONFIG_ADDR, \
DCRN_ ## base ## _CONFIG_DATA, \
reg, data)
#define dcri_clrset(base, reg, clr, set) __dcri_clrset(DCRN_ ## base ## _CONFIG_ADDR, \
DCRN_ ## base ## _CONFIG_DATA, \
reg, clr, set)
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_NATIVE_H */
[-- Attachment #4: dcr.h --]
[-- Type: application/octet-stream, Size: 6308 bytes --]
#ifndef _PPC_BOOT_DCR_H_
#define _PPC_BOOT_DCR_H_
#define mfdcr(rn) \
({ \
unsigned long rval; \
asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
rval; \
})
#define mtdcr(rn, val) \
asm volatile("mtdcr %0,%1" : : "i"(rn), "r"(val))
/* 440GP/440GX SDRAM controller DCRs */
#define DCRN_SDRAM0_CFGADDR 0x010
#define DCRN_SDRAM0_CFGDATA 0x011
#define SDRAM0_READ(offset) ({\
mtdcr(DCRN_SDRAM0_CFGADDR, offset); \
mfdcr(DCRN_SDRAM0_CFGDATA); })
#define SDRAM0_WRITE(offset, data) ({\
mtdcr(DCRN_SDRAM0_CFGADDR, offset); \
mtdcr(DCRN_SDRAM0_CFGDATA, data); })
#define SDRAM0_B0CR 0x40
#define SDRAM0_B1CR 0x44
#define SDRAM0_B2CR 0x48
#define SDRAM0_B3CR 0x4c
static const unsigned long sdram_bxcr[] = { SDRAM0_B0CR, SDRAM0_B1CR,
SDRAM0_B2CR, SDRAM0_B3CR };
#define SDRAM_CONFIG_BANK_ENABLE 0x00000001
#define SDRAM_CONFIG_SIZE_MASK 0x000e0000
#define SDRAM_CONFIG_BANK_SIZE(reg) \
(0x00400000 << ((reg & SDRAM_CONFIG_SIZE_MASK) >> 17))
/* 440GP External Bus Controller (EBC) */
#define DCRN_EBC0_CFGADDR 0x012
#define DCRN_EBC0_CFGDATA 0x013
#define EBC_NUM_BANKS 8
#define EBC_B0CR 0x00
#define EBC_B1CR 0x01
#define EBC_B2CR 0x02
#define EBC_B3CR 0x03
#define EBC_B4CR 0x04
#define EBC_B5CR 0x05
#define EBC_B6CR 0x06
#define EBC_B7CR 0x07
#define EBC_BXCR(n) (n)
#define EBC_BXCR_BAS 0xfff00000
#define EBC_BXCR_BS 0x000e0000
#define EBC_BXCR_BANK_SIZE(reg) \
(0x100000 << (((reg) & EBC_BXCR_BS) >> 17))
#define EBC_BXCR_BU 0x00018000
#define EBC_BXCR_BU_OFF 0x00000000
#define EBC_BXCR_BU_RO 0x00008000
#define EBC_BXCR_BU_WO 0x00010000
#define EBC_BXCR_BU_RW 0x00018000
#define EBC_BXCR_BW 0x00006000
#define EBC_B0AP 0x10
#define EBC_B1AP 0x11
#define EBC_B2AP 0x12
#define EBC_B3AP 0x13
#define EBC_B4AP 0x14
#define EBC_B5AP 0x15
#define EBC_B6AP 0x16
#define EBC_B7AP 0x17
#define EBC_BXAP(n) (0x10+(n))
#define EBC_BEAR 0x20
#define EBC_BESR 0x21
#define EBC_CFG 0x23
#define EBC_CID 0x24
/* 440GP Clock, PM, chip control */
#define DCRN_CPC0_SR 0x0b0
#define DCRN_CPC0_ER 0x0b1
#define DCRN_CPC0_FR 0x0b2
#define DCRN_CPC0_SYS0 0x0e0
#define CPC0_SYS0_TUNE 0xffc00000
#define CPC0_SYS0_FBDV_MASK 0x003c0000
#define CPC0_SYS0_FWDVA_MASK 0x00038000
#define CPC0_SYS0_FWDVB_MASK 0x00007000
#define CPC0_SYS0_OPDV_MASK 0x00000c00
#define CPC0_SYS0_EPDV_MASK 0x00000300
/* Helper macros to compute the actual clock divider values from the
* encodings in the CPC0 register */
#define CPC0_SYS0_FBDV(reg) \
((((((reg) & CPC0_SYS0_FBDV_MASK) >> 18) - 1) & 0xf) + 1)
#define CPC0_SYS0_FWDVA(reg) \
(8 - (((reg) & CPC0_SYS0_FWDVA_MASK) >> 15))
#define CPC0_SYS0_FWDVB(reg) \
(8 - (((reg) & CPC0_SYS0_FWDVB_MASK) >> 12))
#define CPC0_SYS0_OPDV(reg) \
((((reg) & CPC0_SYS0_OPDV_MASK) >> 10) + 1)
#define CPC0_SYS0_EPDV(reg) \
((((reg) & CPC0_SYS0_EPDV_MASK) >> 8) + 1)
#define CPC0_SYS0_EXTSL 0x00000080
#define CPC0_SYS0_RW_MASK 0x00000060
#define CPC0_SYS0_RL 0x00000010
#define CPC0_SYS0_ZMIISL_MASK 0x0000000c
#define CPC0_SYS0_BYPASS 0x00000002
#define CPC0_SYS0_NTO1 0x00000001
#define DCRN_CPC0_SYS1 0x0e1
#define DCRN_CPC0_CUST0 0x0e2
#define DCRN_CPC0_CUST1 0x0e3
#define DCRN_CPC0_STRP0 0x0e4
#define DCRN_CPC0_STRP1 0x0e5
#define DCRN_CPC0_STRP2 0x0e6
#define DCRN_CPC0_STRP3 0x0e7
#define DCRN_CPC0_GPIO 0x0e8
#define DCRN_CPC0_PLB 0x0e9
#define DCRN_CPC0_CR1 0x0ea
#define DCRN_CPC0_CR0 0x0eb
#define CPC0_CR0_SWE 0x80000000
#define CPC0_CR0_CETE 0x40000000
#define CPC0_CR0_U1FCS 0x20000000
#define CPC0_CR0_U0DTE 0x10000000
#define CPC0_CR0_U0DRE 0x08000000
#define CPC0_CR0_U0DC 0x04000000
#define CPC0_CR0_U1DTE 0x02000000
#define CPC0_CR0_U1DRE 0x01000000
#define CPC0_CR0_U1DC 0x00800000
#define CPC0_CR0_U0EC 0x00400000
#define CPC0_CR0_U1EC 0x00200000
#define CPC0_CR0_UDIV_MASK 0x001f0000
#define CPC0_CR0_UDIV(reg) \
((((reg) & CPC0_CR0_UDIV_MASK) >> 16) + 1)
#define DCRN_CPC0_MIRQ0 0x0ec
#define DCRN_CPC0_MIRQ1 0x0ed
#define DCRN_CPC0_JTAGID 0x0ef
#define DCRN_MAL0_CFG 0x180
#define MAL_RESET 0x80000000
/* 440EP Clock/Power-on Reset regs */
#define DCRN_CPR0_ADDR 0xc
#define DCRN_CPR0_DATA 0xd
#define CPR0_PLLD0 0x60
#define CPR0_OPBD0 0xc0
#define CPR0_PERD0 0xe0
#define CPR0_PRIMBD0 0xa0
#define CPR0_SCPID 0x120
#define CPR0_PLLC0 0x40
/* 405GP Clocking/Power Management/Chip Control regs */
#define DCRN_CPC0_PLLMR 0xb0
#define DCRN_405_CPC0_CR0 0xb1
#define DCRN_405_CPC0_CR1 0xb2
#define DCRN_405_CPC0_PSR 0xb4
/* 405EP Clocking/Power Management/Chip Control regs */
#define DCRN_CPC0_PLLMR0 0xf0
#define DCRN_CPC0_PLLMR1 0xf4
#define DCRN_CPC0_UCR 0xf5
/* 440GX Clock control etc */
#define DCRN_CPR0_CLKUPD 0x020
#define DCRN_CPR0_PLLC 0x040
#define DCRN_CPR0_PLLD 0x060
#define DCRN_CPR0_PRIMAD 0x080
#define DCRN_CPR0_PRIMBD 0x0a0
#define DCRN_CPR0_OPBD 0x0c0
#define DCRN_CPR0_PERD 0x0e0
#define DCRN_CPR0_MALD 0x100
#define DCRN_SDR0_CONFIG_ADDR 0xe
#define DCRN_SDR0_CONFIG_DATA 0xf
/* SDR read/write helper macros */
#define SDR0_READ(offset) ({\
mtdcr(DCRN_SDR0_CONFIG_ADDR, offset); \
mfdcr(DCRN_SDR0_CONFIG_DATA); })
#define SDR0_WRITE(offset, data) ({\
mtdcr(DCRN_SDR0_CONFIG_ADDR, offset); \
mtdcr(DCRN_SDR0_CONFIG_DATA, data); })
#define DCRN_SDR0_UART0 0x0120
#define DCRN_SDR0_UART1 0x0121
#define DCRN_SDR0_UART2 0x0122
#define DCRN_SDR0_UART3 0x0123
/* CPRs read/write helper macros - based off include/asm-ppc/ibm44x.h */
#define DCRN_CPR0_CFGADDR 0xc
#define DCRN_CPR0_CFGDATA 0xd
#define CPR0_READ(offset) ({\
mtdcr(DCRN_CPR0_CFGADDR, offset); \
mfdcr(DCRN_CPR0_CFGDATA); })
#define CPR0_WRITE(offset, data) ({\
mtdcr(DCRN_CPR0_CFGADDR, offset); \
mtdcr(DCRN_CPR0_CFGDATA, data); })
#endif /* _PPC_BOOT_DCR_H_ */
^ permalink raw reply
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Sachin Sant @ 2009-09-11 4:26 UTC (permalink / raw)
To: rostedt; +Cc: linuxppc-dev
In-Reply-To: <1252638353.18996.62.camel@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Thu, 2009-09-10 at 11:02 +0530, Sachin Sant wrote:
>
>> Steven Rostedt wrote:
>>
>>> Ah, seems the bug happens to be in the module handling. Does the call
>>> back always have .mod_return_to_handler?
>>>
>>>
>> Yes. Every time it ends up in .mod_return_to_handler
>>
>
> BTW, do you have CONFIG_IRQSTACK set?
>
Yes. That option is enabled.
CONFIG_DEBUGGER=y
CONFIG_IRQSTACKS=y
# CONFIG_VIRQ_DEBUG is not set
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Cleanup handling of execute permission v2
From: David Gibson @ 2009-09-11 4:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250658034.4810.9.camel@pasglop>
On Wed, Aug 19, 2009 at 03:00:34PM +1000, Benjamin Herrenschmidt wrote:
> This is an attempt at cleaning up a bit the way we handle execute
> permission on powerpc. _PAGE_HWEXEC is gone, _PAGE_EXEC is now only
> defined by CPUs that can do something with it, and the myriad of
> #ifdef's in the I$/D$ coherency code is reduced to 2 cases that
> hopefully should cover everything.
>
> The logic on BookE is a little bit different than what it was though
> not by much. Since now, _PAGE_EXEC will be set by the generic code
> for executable pages, we need to filter out if they are unclean and
> recover it. However, I don't expect the code to be more bloated than
> it already was in that area due to that change.
>
> I could boast that this brings proper enforcing of per-page execute
> permissions to all BookE and 40x but in fact, we've had that now for
> some time as a side effect of my previous rework in that area (and
> I didn't even know it :-) We would only enable execute permission if
> the page was cache clean and we would only cache clean it if we took
> and exec fault. Since we now enforce that the later only work if
> VM_EXEC is part of the VMA flags, we de-fact already enforce per-page
> execute permissions... Unless I missed something
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Stefan Roese @ 2009-09-11 5:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
azilkie
In-Reply-To: <1252637074.8566.56.camel@pasglop>
On Friday 11 September 2009 04:44:34 Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:
> > There is also a patch that was submitted for 440EPX a couple of years
> > back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
> > commands. Whether MRM is used or not depends on the value of
> > PCI_CACHE_LINE_SIZE register. I see that the changes are no longer
> > present in linux 2.6.30+ kernels. Although the patch certainly resolved
> > the hang issue with Silicon Image 680 PATA card as the 680 driver
> > attempts to use MRM commands - I don't know if it would resolve the data
> > corruption issue. It is certainly worth trying in my opinion. Below is a
> > link to the patch submission:
> >
> > http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=cffefde924123e685327
> > 48dd58fcb780eab5e219
>
> The changes in the above repository is a quick hack that can't be merged
> as-is (and afaik hasn't been submitted).
>
> If indeed we need to clamp the PCI cache line size on those critters,
> then we need something in ppc4xx_pci.c to detect the need, set
> pci_cache_line_size to 0 and eventually fixup the existing values in
> devices in case u-boot don't have them right.
>
> Care to send a patch ? :-)
It's already there. See commit:
5ce4b59653b2c2053cd9a011918ac1e4747f24cc
powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
Cheers,
Stefan
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 5:17 UTC (permalink / raw)
To: Stefan Roese
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
linuxppc-dev, azilkie
In-Reply-To: <200909110712.11858.sr@denx.de>
On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
>
> It's already there. See commit:
>
> 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
>
> powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
Ok, that's another way to do it. Will catch nasty drivers who
try to write directly rather than clear pci_cache_line_size I suppose...
Cheers,
Ben.
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Stefan Roese @ 2009-09-11 5:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
azilkie
In-Reply-To: <1252646270.8566.64.camel@pasglop>
On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...
Correct. IIRC, some PATA driver as Pravin already mentioned.
Cheers,
Stefan
^ permalink raw reply
* Re: How to access DCR registers in powerpc440gx? Got err when use macro def in Linux kernel
From: David Gibson @ 2009-09-11 5:31 UTC (permalink / raw)
To: g r1x; +Cc: linuxppc-dev
In-Reply-To: <8abf57fa0909102114hf935c21h5dd727ba2a9a4825@mail.gmail.com>
On Fri, Sep 11, 2009 at 12:14:55PM +0800, g r1x wrote:
> Now, I'm writing a DMA driver on powerpc
> 440gx platform(2.6.26.5), as the only way to set up DMA Controller is
> to access it's dcr registers with 'mfdcr' and 'mtdcr'.
>
> I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
> u wrote to my driver module directory, and include them, but when I
> compile my driver, gcc complains following err messages:
[snip]
> #define mfdcr(rn) \
> ({ \
> unsigned long rval; \
> asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
> rval; \
> })
This form of mfdcr macro will only work when passed a constant DCR
number. That's a limitation in the actual CPU implementation of the
mfdcr instruction (the DCR number is part of the instruction opcode).
Some newer cores have an indirect for of mfdcr which allows the DCR
number to be specified in a register, but I don't know if 440gx is one
of them.
In current kernels we have some DCR macros that use a big table of
pre-generated instructions in order to allow accesses to runtime
computed DCR numbers. But either they didn't exist in 2.6.26, or they
have a different name, I don't remember.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Pravin Bathija @ 2009-09-11 5:35 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, azilkie
In-Reply-To: <200909110725.36208.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
> Stefan Roese wrote:
> Correct. IIRC, some PATA driver as Pravin already mentioned.
> Cheers,
> Stefan
Thanks Stefan. The whole intention of the patch/hack (or whatever one might call it :) ) was to avoid rogue drivers from setting pci_cache_line_size to non-zero value even though the underlying hardware doesn't support MRM calls. Nonetheless this approach works only if the drivers use the kernel API for PCI config space access provided by the powerpc platform driver.
Regards,
Pravin
On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...
[-- Attachment #2: Type: text/html, Size: 1486 bytes --]
^ permalink raw reply
* [PATCH] powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline
From: Benjamin Herrenschmidt @ 2009-09-11 5:37 UTC (permalink / raw)
To: linuxppc-dev list
That code uses dma_mapping_error() with a NULL device, which is
a bad idea :-) The proper fix might be to start using some kind
of pseudo device for all these low level mappings with the
hypervisor but that will be for another day. Since it directly
calls into the low level iommu code, I see no problem in having
it directly test against DMA_ERROR_CODE instead of using the
accessors with a NULL argument for now.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/iseries/mf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index fef4d51..0d9343d 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -872,7 +872,7 @@ static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
count = 256 - off;
dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_mapping_error(NULL, dma_addr))
+ if (dma_addr == DMA_ERROR_CODE)
return -ENOMEM;
memset(page, 0, off + count);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 5:40 UTC (permalink / raw)
To: Pravin Bathija
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, Stefan Roese,
linuxppc-dev, azilkie
In-Reply-To: <9D1E2BDCB5C57B46B56E6D80843439EB0580C926@SDCEXCHANGE01.ad.amcc.com>
On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
>
Do you know many drivers that do config space accesses without using
the config space accessors ?
Such drivers should be banned to oblivion.
Cheers,
Ben.
^ permalink raw reply
* RMO ? (in the prom_init.c)
From: HongWoo Lee @ 2009-09-11 6:33 UTC (permalink / raw)
To: linuxppc-dev list
Hi ~
Can anybody tell me what the RMO is ?? in the linux kernel.
(arch/powerpc/kernel/prom_init.c)
Through googling and guessing, I found "Read Memory Only" and "Relaxed
Memory Order".
But none of these are not properly understood in the context.
Thanks in advance.
HongWoo.
^ permalink raw reply
* Re: [RESEND][PATCH] sata_fsl: hard and soft reset split
From: Jeff Garzik @ 2009-09-11 6:37 UTC (permalink / raw)
To: ashish kalra; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <Pine.WNT.4.64.0906291854180.2640@B00888-02.fsl.freescale.net>
On 06/29/2009 09:26 AM, ashish kalra wrote:
> Split sata_fsl_softreset() into hard and soft resets to make
> error-handling more efficient & device and PMP detection more reliable.
>
> Also includes fix for PMP support, driver tested with Sil3726, Sil4726 &
> Exar PMP controllers.
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
can you rediff this and 'AN' support against latest upstream?
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2009-09-11 7:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev list, Andrew Morton, Ingo Molnar, Linux Kernel list,
FUJITA Tomonori
Hi Linus !
This is the powerpc batch for 2.6.32.
You will notice a bunch of generic swiotlb changes along with
corresponding changes to arch/sparc and arch/x86 from Fujita Tomonori.
There are due to my tree having pulled Ingo's iommu tree do sort out
various dependencies. If you pull Ingo's first, you'll already have
all these.
I'm happy for you to defer the pulling of my tree until you have those
bits via Ingo if you prefer, and I'll then send a pull request cleared
of that noise.
Among other non-arch/powerpc patches: Some PS3 and PowerMac specific
driver changes (yes, I think we are still the only users of
generic_nvram), some changes to HVC console and that should be it.
Cheers,
Ben.
The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db:
Linus Torvalds (1):
Linux 2.6.31-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
Anton Blanchard (3):
powerpc: Move 64bit VDSO to improve context switch performance
powerpc: Rearrange SLB preload code
powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE
Anton Vorontsov (7):
powerpc/83xx: Add support for MPC8377E-WLAN boards
powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards
powerpc/85xx: Add eSDHC support for MPC8536DS boards
powerpc/82xx: Fix BCSR bits for MPC8272ADS boards
powerpc/82xx: Add CPM USB Gadget support for MPC8272ADS boards
powerpc/85xx: Add QE USB support for MPC8569E-MDS boards
Arnd Bergmann (1):
dma-ops: Remove flush_write_buffers() in dma-mapping-common.h
Bastian Blank (1):
powerpc: Remove SMP warning from PowerMac cpufreq
Becky Bruce (1):
powerpc: Name xpn & x fields in HW Hash PTE format
Benjamin Herrenschmidt (37):
powerpc: Rename exception.h to exception-64s.h
powerpc: Use names rather than numbers for SPRGs (v2)
powerpc: Remove use of a second scratch SPRG in STAB code
powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
powerpc/pmac: Fix PowerSurge SMP IPI allocation
powerpc: Change PACA from SPRG3 to SPRG1
powerpc: Add compat_sys_truncate
powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h
powerpc/of: Remove useless register save/restore when calling OF back
powerpc/mm: Add HW threads support to no_hash TLB management
powerpc/mm: Add opcode definitions for tlbivax and tlbsrx.
powerpc/mm: Add more bit definitions for Book3E MMU registers
powerpc/mm: Add support for early ioremap on non-hash 64-bit processors
powerpc: Modify some ppc_asm.h macros to accomodate 64-bits Book3E
powerpc/mm: Make low level TLB flush ops on BookE take additional args
powerpc/mm: Call mmu_context_init() from ppc64
powerpc: Clean ifdef usage in copy_thread()
powerpc: Move definitions of secondary CPU spinloop to header file
powerpc/mm: Rework & cleanup page table freeing code path
powerpc: Add SPR definitions for new 64-bit BookE
powerpc: Add memory management headers for new 64-bit BookE
powerpc: Add definitions used by exception handling on 64-bit Book3E
powerpc: Add PACA fields specific to 64-bit Book3E processors
powerpc/mm: Move around mmu_gathers definition on 64-bit
powerpc: Add TLB management code for 64-bit Book3E
powerpc/mm: Add support for SPARSEMEM_VMEMMAP on 64-bit Book3E
powerpc: Remaining 64-bit Book3E support
powerpc/mm: Fix encoding of page table cache numbers
Merge commit 'paulus-perf/master' into next
Merge commit 'origin/master' into next
powerpc/mm: Cleanup handling of execute permission
Merge commit 'kumar/next' into next
Merge commit 'tip/iommu-for-powerpc' into next
powerpc: Properly start decrementer on BookE secondary CPUs
powerpc: Fix some late PowerMac G5 with PCIe ATI graphics
powerpc/booke: Don't set DABR on 64-bit BookE, use DAC1 instead
powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline
Benjamin Krill (1):
powerpc/prom_init: Evaluate mem kernel parameter for early allocation
Brian King (1):
powerpc/pseries: Fix to handle slb resize across migration
Casey Dahlin (1):
lib/swiotlb.c: Fix strange panic message selection logic when swiotlb fills up
Christoph Hellwig (2):
powerpc/sputrace: Use the generic event tracer
powerpc: Switch to asm-generic/hardirq.h
FUJITA Tomonori (29):
swiotlb: remove unused swiotlb_alloc_boot()
swiotlb: remove unused swiotlb_alloc()
swiotlb: remove swiotlb_arch_range_needs_mapping
swiotlb: remove unnecessary swiotlb_bus_to_virt
x86: add dma_capable() to replace is_buffer_dma_capable()
x86: replace is_buffer_dma_capable() with dma_capable
ia64: add dma_capable() to replace is_buffer_dma_capable()
powerpc: add dma_capable() to replace is_buffer_dma_capable()
swiotlb: use dma_capable()
powerpc: remove unncesary swiotlb_arch_address_needs_mapping
remove is_buffer_dma_capable()
x86, IA64, powerpc: add phys_to_dma() and dma_to_phys()
swiotlb: use phys_to_dma and dma_to_phys
powerpc: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
x86: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
IA64: Remove NULL flush_write_buffers
sparc: Use dma_map_ops struct
sparc: Use asm-generic/dma-mapping-common.h
sparc: Remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
sparc: Replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
sparc: Use asm-generic/pci-dma-compat
sparc: Add CONFIG_DMA_API_DEBUG support
powerpc: Remove addr_needs_map in struct dma_mapping_ops
powerpc: Remove swiotlb_pci_dma_ops
dma: Add set_dma_mask hook to struct dma_map_ops
powerpc: use dma_map_ops struct
powerpc: Use asm-generic/dma-mapping-common.h
powerpc: Handle SWIOTLB mapping error properly
powerpc: Add CONFIG_DMA_API_DEBUG support
Frans Pop (1):
powerpc: Makefile simplification through use of cc-ifversion
Gautham R Shenoy (1):
powerpc/pseries: Reduce the polling interval in __cpu_up()
Geert Uytterhoeven (1):
powerpc/cell: Move CBE_IOPTE_* to <asm/cell-regs.h>
Geoff Levand (1):
powerpc/ps3: Workaround for flash memory I/O error
Geoff Thorpe (1):
powerpc: expose the multi-bit ops that underlie single-bit ops.
Gerhard Pircher (1):
powerpc/amigaone: Convert amigaone_init() to a machine_device_initcall()
Grant Likely (3):
powerpc/pci: Remove dead checks for CONFIG_PPC_OF
powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
Heiko Schocher (2):
powerpc/82xx: mgcoge - updates for 2.6.32
powerpc/82xx: mgcoge - updated defconfig
Josh Boyer (1):
powerpc: Fix __flush_icache_range on 44x
Julia Lawall (5):
powerpc/fsl_rio: Add kmalloc NULL tests
powerpc/ipic: introduce missing kfree
powerpc/qe: introduce missing kfree
hvc_console: Drop unnecessary NULL test
powerpc: Use DIV_ROUND_CLOSEST in time init code
Kumar Gala (14):
powerpc/mm: Fix switch_mmu_context to iterate of the proper list of cpus
powerpc/85xx: Move mpc8536ds.dts to address-cells/size-cells = <2>
powerpc/85xx: Added 36-bit physical device tree for mpc8536ds board
powerpc/mm: Fix assert_pte_locked to work properly on uniprocessor
powerpc/booke: Move MMUCSR definition into mmu-book3e.h
powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
powerpc/book3e-64: Move the default cpu table entry
powerpc/book3e-64: Wait til generic_calibrate_decr to enable decrementer
powerpc/book3e-64: Add helper function to setup IVORs
powerpc/book3e-64: Add support to initial_tlb_book3e for non-HES TLB
powerpc/pci: Pull ppc32 PCI features into common
powerpc/book3e: Add missing page sizes
powerpc/fsl-booke: Use HW PTE format if CONFIG_PTE_64BIT
powerpc/85xx: Fix SMP compile error and allow NULL for smp_ops
Liang Li (4):
powerpc/83xx: Remove second USB node from SBC834x DTS
powerpc/83xx: Add localbus node and MTD partitions for SBC834x
powerpc/83xx: Fix incorrect PCI interrupt map in SBC834x DTS
powerpc/85xx: sbc8560 - Fix warm reboot with board specific reset function
Lucian Adrian Grijincu (1):
powerpc: Update boot wrapper script with the new location of dtc
Lyonel Vincent (1):
powerpc/powermac: Thermal control turns system off too eagerly
Martyn Welch (5):
powerpc/86xx: Correct reading of information presented in cpuinfo
powerpc/86xx: Enable XMC site on GE Fanuc SBC310
powerpc/86xx: Update GE Fanuc sbc310 DTS
powerpc/nvram: Allow byte length reads from mmio NVRAM driver
powerpc/nvram: Enable use Generic NVRAM driver for different size chips
Michael Barkowski (1):
powerpc/qe_lib: Set gpio data before changing the direction to output
Michael Ellerman (4):
powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
kmemleak: Allow kmemleak to be built on powerpc
powerpc: Enable GCOV
powerpc/vmlinux.lds: Move _edata down
Michael Wolf (1):
powerpc: Adjust base and index registers in Altivec macros
Michel Dänzer (2):
agp/uninorth: Allow larger aperture sizes on pre-U3 bridges.
agp/uninorth: Simplify cache flushing.
Paul Gortmaker (4):
powerpc/83xx: sbc8349 - update defconfig, enable MTD, USB storage
powerpc/85xx: issue fsl_soc reboot warning only when applicable
powerpc/85xx: sbc8560 - remove "has-rstcr" from global utilities block
powerpc: derive COMMAND_LINE_SIZE from asm-generic
Paul Mackerras (5):
powerpc/32: Always order writes to halves of 64-bit PTEs
powerpc: Allow perf_counters to access user memory at interrupt time
perf_counter: powerpc: Add callchain support
powerpc: Fix bug where perf_counters breaks oprofile
powerpc/perf_counters: Reduce stack usage of power_check_constraints
Peter Huewe (1):
hvc_console: Add __init and __exit to hvc_vio
Poonam Aggrwal (1):
powerpc/85xx: Add support for P2020RDB board
Roel Kluin (2):
powerpc/fsl-booke: read buffer overflow
powerpc/hvsi: Avoid calculating possibly-invalid address
Sebastian Andrzej Siewior (1):
powerpc/ipic: unmask all interrupt sources
Solomon Peachy (1):
powerpc/40x: Add support for the ESTeem 195E (PPC405EP) SBC
Stefan Roese (7):
powerpc: Add AMCC 460EX/460GT Rev. B support to cputable.c
powerpc/44x: Add NAND support to Canyonlands dts
powerpc/40x: Update Kilauea dts to support NAND, RTC and HWMON
powerpc/44x: Update Canyonlands defconfig to support NOR, NAND and RTC
powerpc/40x: Update kilauea defconfig to support NAND, RTC and HWMON
powerpc/44x: Update Arches dts
powerpc/44x: Update Arches defconfig
Stephen Rothwell (1):
powerpc: use consistent types in mktree
Stoyan Gaydarov (1):
powerpc: ARRAY_SIZE changes in pasemi and powermac code
Tiejun Chen (2):
powerpc/405ex: provide necessary fixup function to support cuImage
powerpc/405ex: support cuImage via included dtb
Wolfram Sang (1):
powerpc/irq: Improve nanodoc
fkan@amcc.com (1):
powerpc/44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
roel kluin (3):
powerpc/cell: Replace strncpy by strlcpy
powerpc: Missing tests for NULL after ioremap()
powerpc/macio: Don't the address of an array element before boundchecking
arch/ia64/include/asm/dma-mapping.h | 19 +-
arch/powerpc/Kconfig | 29 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/4xx.c | 142 +++
arch/powerpc/boot/4xx.h | 1 +
arch/powerpc/boot/Makefile | 6 +-
arch/powerpc/boot/cuboot-hotfoot.c | 142 +++
arch/powerpc/boot/cuboot-kilauea.c | 49 +
arch/powerpc/boot/dcr.h | 4 +-
arch/powerpc/boot/dts/arches.dts | 50 +
arch/powerpc/boot/dts/canyonlands.dts | 49 +-
arch/powerpc/boot/dts/eiger.dts | 421 +++++++
arch/powerpc/boot/dts/gef_sbc310.dts | 64 +-
arch/powerpc/boot/dts/hotfoot.dts | 294 +++++
arch/powerpc/boot/dts/kilauea.dts | 44 +-
arch/powerpc/boot/dts/mgcoge.dts | 53 +
arch/powerpc/boot/dts/mpc8272ads.dts | 8 +
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_wlan.dts | 464 ++++++++
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8536ds.dts | 40 +-
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 475 ++++++++
arch/powerpc/boot/dts/mpc8548cds.dts | 20 +
arch/powerpc/boot/dts/mpc8569mds.dts | 45 +
arch/powerpc/boot/dts/p2020rdb.dts | 586 +++++++++
arch/powerpc/boot/dts/sbc8349.dts | 60 +-
arch/powerpc/boot/dts/sbc8560.dts | 1 -
arch/powerpc/boot/mktree.c | 10 +-
arch/powerpc/boot/ppcboot-hotfoot.h | 133 +++
arch/powerpc/boot/wrapper | 3 +-
arch/powerpc/configs/40x/kilauea_defconfig | 298 ++++-
arch/powerpc/configs/44x/arches_defconfig | 382 ++++++-
arch/powerpc/configs/44x/canyonlands_defconfig | 350 +++++-
arch/powerpc/configs/44x/eiger_defconfig | 1252 ++++++++++++++++++++
arch/powerpc/configs/83xx/sbc834x_defconfig | 320 +++++-
arch/powerpc/configs/mgcoge_defconfig | 86 ++-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/include/asm/bitops.h | 194 +---
arch/powerpc/include/asm/cell-regs.h | 11 +
arch/powerpc/include/asm/cputhreads.h | 16 +
arch/powerpc/include/asm/device.h | 7 +-
arch/powerpc/include/asm/dma-mapping.h | 323 +-----
arch/powerpc/include/asm/exception-64e.h | 205 ++++
.../include/asm/{exception.h => exception-64s.h} | 25 +-
arch/powerpc/include/asm/hardirq.h | 30 +-
arch/powerpc/include/asm/hw_irq.h | 5 +
arch/powerpc/include/asm/iommu.h | 10 -
arch/powerpc/include/asm/irq.h | 7 +-
arch/powerpc/include/asm/machdep.h | 6 +-
arch/powerpc/include/asm/mmu-40x.h | 3 +
arch/powerpc/include/asm/mmu-44x.h | 6 +
arch/powerpc/include/asm/mmu-8xx.h | 3 +
arch/powerpc/include/asm/mmu-book3e.h | 208 +++-
arch/powerpc/include/asm/mmu-hash32.h | 16 +-
arch/powerpc/include/asm/mmu-hash64.h | 22 +-
arch/powerpc/include/asm/mmu.h | 46 +
arch/powerpc/include/asm/mmu_context.h | 15 +-
arch/powerpc/include/asm/nvram.h | 3 +
arch/powerpc/include/asm/paca.h | 23 +-
arch/powerpc/include/asm/page.h | 4 +
arch/powerpc/include/asm/page_64.h | 10 +
arch/powerpc/include/asm/pci-bridge.h | 40 +-
arch/powerpc/include/asm/pci.h | 11 +-
arch/powerpc/include/asm/pgalloc.h | 46 +-
arch/powerpc/include/asm/pgtable-ppc32.h | 9 +-
arch/powerpc/include/asm/pgtable-ppc64-64k.h | 4 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 67 +-
arch/powerpc/include/asm/pgtable.h | 6 +-
arch/powerpc/include/asm/pmc.h | 16 +-
arch/powerpc/include/asm/ppc-opcode.h | 6 +
arch/powerpc/include/asm/ppc-pci.h | 1 -
arch/powerpc/include/asm/ppc_asm.h | 26 +-
arch/powerpc/include/asm/pte-40x.h | 2 +-
arch/powerpc/include/asm/pte-44x.h | 2 +-
arch/powerpc/include/asm/pte-8xx.h | 1 -
arch/powerpc/include/asm/pte-book3e.h | 84 ++
arch/powerpc/include/asm/pte-common.h | 25 +-
arch/powerpc/include/asm/pte-fsl-booke.h | 9 +-
arch/powerpc/include/asm/pte-hash32.h | 1 -
arch/powerpc/include/asm/reg.h | 141 +++-
arch/powerpc/include/asm/reg_booke.h | 50 +-
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/asm/smp.h | 10 +
arch/powerpc/include/asm/swiotlb.h | 8 +-
arch/powerpc/include/asm/systbl.h | 4 +-
arch/powerpc/include/asm/tlb.h | 38 +-
arch/powerpc/include/asm/tlbflush.h | 11 +-
arch/powerpc/include/asm/vdso.h | 3 +-
arch/powerpc/kernel/Makefile | 21 +-
arch/powerpc/kernel/asm-offsets.c | 21 +-
arch/powerpc/kernel/cpu_setup_6xx.S | 2 +-
arch/powerpc/kernel/cputable.c | 62 +-
arch/powerpc/kernel/dma-iommu.c | 2 +-
arch/powerpc/kernel/dma-swiotlb.c | 99 +--
arch/powerpc/kernel/dma.c | 13 +-
arch/powerpc/kernel/entry_32.S | 20 +-
arch/powerpc/kernel/entry_64.S | 102 +-
arch/powerpc/kernel/exceptions-64e.S | 1001 ++++++++++++++++
arch/powerpc/kernel/exceptions-64s.S | 97 +-
arch/powerpc/kernel/fpu.S | 2 +-
arch/powerpc/kernel/head_32.S | 40 +-
arch/powerpc/kernel/head_40x.S | 124 +-
arch/powerpc/kernel/head_44x.S | 58 +-
arch/powerpc/kernel/head_64.S | 83 ++-
arch/powerpc/kernel/head_8xx.S | 13 +-
arch/powerpc/kernel/head_booke.h | 50 +-
arch/powerpc/kernel/head_fsl_booke.S | 100 +-
arch/powerpc/kernel/ibmebus.c | 2 +-
arch/powerpc/kernel/lparcfg.c | 3 +
arch/powerpc/kernel/misc_32.S | 7 +
arch/powerpc/kernel/of_platform.c | 2 +-
arch/powerpc/kernel/paca.c | 3 +
arch/powerpc/kernel/pci-common.c | 133 ++-
arch/powerpc/kernel/pci_32.c | 105 +--
arch/powerpc/kernel/pci_64.c | 335 +-----
arch/powerpc/kernel/pci_of_scan.c | 358 ++++++
arch/powerpc/kernel/perf_callchain.c | 527 ++++++++
arch/powerpc/kernel/perf_counter.c | 68 +-
arch/powerpc/kernel/process.c | 16 +-
arch/powerpc/kernel/prom_init.c | 107 ++-
arch/powerpc/kernel/rtas.c | 7 +-
arch/powerpc/kernel/setup_32.c | 8 +
arch/powerpc/kernel/setup_64.c | 34 +-
arch/powerpc/kernel/smp.c | 15 +-
arch/powerpc/kernel/sys_ppc32.c | 12 +
arch/powerpc/kernel/sysfs.c | 3 +
arch/powerpc/kernel/time.c | 33 +-
arch/powerpc/kernel/vdso.c | 7 +-
arch/powerpc/kernel/vdso32/Makefile | 1 +
arch/powerpc/kernel/vdso64/Makefile | 2 +
arch/powerpc/kernel/vector.S | 2 +-
arch/powerpc/kernel/vio.c | 2 +-
arch/powerpc/kernel/vmlinux.lds.S | 8 +-
arch/powerpc/kvm/booke_interrupts.S | 18 +-
arch/powerpc/mm/40x_mmu.c | 4 +-
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/hash_low_32.S | 4 +-
arch/powerpc/mm/hugetlbpage.c | 8 +-
arch/powerpc/mm/init_32.c | 2 -
arch/powerpc/mm/init_64.c | 55 +-
arch/powerpc/mm/mmu_context_nohash.c | 96 +-
arch/powerpc/mm/mmu_decl.h | 37 +-
arch/powerpc/mm/pgtable.c | 179 ++-
arch/powerpc/mm/pgtable_32.c | 2 +-
arch/powerpc/mm/pgtable_64.c | 59 +-
arch/powerpc/mm/slb.c | 83 +-
arch/powerpc/mm/stab.c | 11 +-
arch/powerpc/mm/tlb_hash32.c | 3 +
arch/powerpc/mm/tlb_hash64.c | 20 +-
arch/powerpc/mm/tlb_low_64e.S | 770 ++++++++++++
arch/powerpc/mm/tlb_nohash.c | 268 ++++-
arch/powerpc/mm/tlb_nohash_low.S | 87 ++-
arch/powerpc/platforms/40x/Kconfig | 10 +
arch/powerpc/platforms/40x/ppc40x_simple.c | 3 +-
arch/powerpc/platforms/44x/Kconfig | 12 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
arch/powerpc/platforms/82xx/mgcoge.c | 69 +-
arch/powerpc/platforms/82xx/mpc8272_ads.c | 22 +-
arch/powerpc/platforms/83xx/Kconfig | 4 +-
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 28 +-
arch/powerpc/platforms/83xx/mpc83xx.h | 4 +
arch/powerpc/platforms/85xx/Kconfig | 9 +
arch/powerpc/platforms/85xx/Makefile | 3 +-
arch/powerpc/platforms/85xx/mpc8536_ds.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
arch/powerpc/platforms/85xx/sbc8560.c | 39 +-
arch/powerpc/platforms/85xx/smp.c | 23 -
arch/powerpc/platforms/86xx/gef_ppc9a.c | 37 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 3 +-
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 1 -
arch/powerpc/platforms/Kconfig.cputype | 38 +-
arch/powerpc/platforms/amigaone/setup.c | 6 +-
arch/powerpc/platforms/cell/Kconfig | 7 -
arch/powerpc/platforms/cell/celleb_setup.c | 3 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/cell/smp.c | 2 -
arch/powerpc/platforms/cell/spufs/Makefile | 3 +-
arch/powerpc/platforms/cell/spufs/context.c | 1 +
arch/powerpc/platforms/cell/spufs/file.c | 1 +
arch/powerpc/platforms/cell/spufs/sched.c | 2 +
arch/powerpc/platforms/cell/spufs/spufs.h | 5 -
arch/powerpc/platforms/cell/spufs/sputrace.c | 272 -----
arch/powerpc/platforms/cell/spufs/sputrace.h | 39 +
arch/powerpc/platforms/iseries/exception.S | 59 +-
arch/powerpc/platforms/iseries/exception.h | 6 +-
arch/powerpc/platforms/iseries/mf.c | 2 +-
arch/powerpc/platforms/pasemi/idle.c | 2 +-
arch/powerpc/platforms/powermac/cpufreq_32.c | 8 -
arch/powerpc/platforms/powermac/feature.c | 13 +-
arch/powerpc/platforms/powermac/pci.c | 61 +
arch/powerpc/platforms/powermac/smp.c | 2 +-
arch/powerpc/platforms/ps3/mm.c | 2 +-
arch/powerpc/platforms/ps3/system-bus.c | 6 +-
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +-
arch/powerpc/platforms/pseries/reconfig.c | 9 +-
arch/powerpc/platforms/pseries/setup.c | 4 -
arch/powerpc/platforms/pseries/smp.c | 2 -
arch/powerpc/sysdev/fsl_rio.c | 18 +-
arch/powerpc/sysdev/fsl_soc.c | 6 +-
arch/powerpc/sysdev/ipic.c | 7 +-
arch/powerpc/sysdev/mmio_nvram.c | 32 +
arch/powerpc/sysdev/mpic.c | 13 +-
arch/powerpc/sysdev/qe_lib/gpio.c | 4 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 5 +-
arch/powerpc/xmon/Makefile | 2 +
arch/powerpc/xmon/xmon.c | 2 +-
arch/sparc/Kconfig | 2 +
arch/sparc/include/asm/dma-mapping.h | 145 +--
arch/sparc/include/asm/pci.h | 3 +
arch/sparc/include/asm/pci_32.h | 105 --
arch/sparc/include/asm/pci_64.h | 88 --
arch/sparc/kernel/Makefile | 2 +-
arch/sparc/kernel/dma.c | 175 +---
arch/sparc/kernel/dma.h | 14 -
arch/sparc/kernel/iommu.c | 20 +-
arch/sparc/kernel/ioport.c | 190 ++--
arch/sparc/kernel/pci.c | 2 +-
arch/sparc/kernel/pci_sun4v.c | 30 +-
arch/x86/include/asm/dma-mapping.h | 18 +
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/kernel/pci-gart_64.c | 5 +-
arch/x86/kernel/pci-nommu.c | 29 +-
arch/x86/kernel/pci-swiotlb.c | 25 -
drivers/block/ps3vram.c | 2 +-
drivers/char/agp/uninorth-agp.c | 49 +-
drivers/char/generic_nvram.c | 27 +-
drivers/char/hvc_console.c | 2 -
drivers/char/hvc_vio.c | 4 +-
drivers/char/hvsi.c | 3 +-
drivers/macintosh/macio_asic.c | 6 +-
drivers/macintosh/therm_windtunnel.c | 4 +-
drivers/ps3/ps3stor_lib.c | 65 +-
drivers/video/ps3fb.c | 2 +-
include/asm-generic/dma-mapping-common.h | 6 -
include/linux/dma-mapping.h | 6 +-
include/linux/pci_ids.h | 1 +
include/linux/swiotlb.h | 11 -
kernel/gcov/Kconfig | 2 +-
lib/Kconfig.debug | 2 +-
lib/swiotlb.c | 124 +--
244 files changed, 12124 insertions(+), 3266 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hotfoot.c
create mode 100644 arch/powerpc/boot/cuboot-kilauea.c
create mode 100644 arch/powerpc/boot/dts/eiger.dts
create mode 100644 arch/powerpc/boot/dts/hotfoot.dts
create mode 100644 arch/powerpc/boot/dts/mpc8377_wlan.dts
create mode 100644 arch/powerpc/boot/dts/mpc8536ds_36b.dts
create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/boot/ppcboot-hotfoot.h
create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
create mode 100644 arch/powerpc/include/asm/exception-64e.h
rename arch/powerpc/include/asm/{exception.h => exception-64s.h} (94%)
create mode 100644 arch/powerpc/include/asm/pte-book3e.h
create mode 100644 arch/powerpc/kernel/exceptions-64e.S
create mode 100644 arch/powerpc/kernel/pci_of_scan.c
create mode 100644 arch/powerpc/kernel/perf_callchain.c
create mode 100644 arch/powerpc/mm/tlb_low_64e.S
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
delete mode 100644 arch/powerpc/platforms/cell/spufs/sputrace.c
create mode 100644 arch/powerpc/platforms/cell/spufs/sputrace.h
delete mode 100644 arch/sparc/kernel/dma.h
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Mikhail Zolotaryov @ 2009-09-11 7:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Prodyut Hazarika, tburns, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <1252634270.8566.14.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
>
>> Hi Tom,
>>
>> In my case __dma_sync() calls flush_dcache_range() (it's due to
>> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
>> dcbi - that's the difference as dcbf is not privileged.
>>
>
> What it calls depends on the direction of the transfer.
Would not agree with you in this point as __dma_sync() code is:
case DMA_FROM_DEVICE:
/*
* invalidate only when cache-line aligned otherwise
there is
* the potential for discarding uncommitted data from
the cache
*/
if ((start & (L1_CACHE_BYTES - 1)) || (size &
(L1_CACHE_BYTES - 1)))
flush_dcache_range(start, end);
else
invalidate_dcache_range(start, end);
break;
So, actual instruction used depends on address/size alignment.
> The tasklet runs
> in priviledged mode, dcbi should work just fine... if passed a correct
> address :-)
>
> Cheers,
> Ben.
>
>
>> Tom Burns wrote:
>>
>>> Hi Mikhail,
>>>
>>> Sorry, this DMA code is in a tasklet. Are you suggesting the
>>> processor is in supervisor mode at that time? Calling
>>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
>>> the OOPS. The entire oops is as follows, if it's relevant:
>>>
>>> Oops: kernel access of bad area, sig: 11 [#1]
>>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
>>> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
>>> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
>>> DEAR: 3fd39000, ESR: 00800000
>>> TASK = de5db7d0[157] 'cat' THREAD: df116000
>>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
>>> 0079a169
>>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
>>> 10177000
>>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
>>> e11f59cc
>>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
>>> 87d39009
>>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
>>> LR [c0010c30] __dma_sync+0x58/0xac
>>> Call Trace:
>>> [df117c80] [0000000a] 0xa (unreliable)
>>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
>>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
>>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
>>> [df117d10] [c00067a8] do_softirq+0x54/0x58
>>> [df117d20] [c001edb4] irq_exit+0x48/0x58
>>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
>>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
>>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
>>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
>>> [df117ec0] [c00171ac] mmput+0x50/0xd4
>>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
>>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
>>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
>>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
>>> Instruction dump:
>>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
>>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
>>> 7c0004ac
>>> Kernel panic - not syncing: Aiee, killing interrupt handler!
>>> Rebooting in 180 seconds..
>>>
>>>
>>> Cheers,
>>> Tom
>>>
>>> Mikhail Zolotaryov wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> possible solution could be to use tasklet to perform DMA-related job
>>>> (as in most cases DMA transfer is interrupt driven - makes sense).
>>>>
>>>>
>>>> Tom Burns wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> With the default config for the Sequoia board on 2.6.24, calling
>>>>> pci_dma_sync_sg_for_cpu() results in executing
>>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
>>>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
>>>>> the assembly instruction dcbi, which can only be executed in
>>>>> supervisor mode. We tried that before resorting to manual cache
>>>>> line management with usermode-safe assembly calls.
>>>>>
>>>>> Regards,
>>>>> Tom Burns
>>>>> International Datacasting Corporation
>>>>>
>>>>> Mikhail Zolotaryov wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Why manage cache lines manually, if appropriate code is a part of
>>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>>>>
>>>>>> Prodyut Hazarika wrote:
>>>>>>
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>>>>
>>>>>>>>
>>>>>>> (using
>>>>>>>
>>>>>>>
>>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
>>>>>>>> timing)
>>>>>>>> end up being partially corrupted when we try to parse the data in
>>>>>>>> the
>>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>>>>
>>>>>>>>
>>>>>>> memory
>>>>>>>
>>>>>>>
>>>>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>>>>> corrupted, we see a random portion of it (always a multiple of
>>>>>>>> 16byte
>>>>>>>> cache lines) is overwritten with old data from the last time the
>>>>>>>>
>>>>>>>>
>>>>>>> buffer
>>>>>>>
>>>>>>>
>>>>>>>> was used.
>>>>>>>>
>>>>>>> This looks like a cache coherency problem.
>>>>>>> Can you ensure that the TLB entries corresponding to the DMA
>>>>>>> region has
>>>>>>> the CacheInhibit bit set.
>>>>>>> You will need a BDI connected to your system.
>>>>>>>
>>>>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>>>>> since in 440 cores,
>>>>>>> L1Cache coherency is managed entirely by software.
>>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
>>>>>>> example on
>>>>>>> how to do it.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Prodyut
>>>>>>>
>>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>>>>
>>>>>>>>
>>>>>>> board)
>>>>>>>
>>>>>>>
>>>>>>>> have L2Cache.
>>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
>>>>>>>> 440EPx
>>>>>>>> has a 440 cpu core, but no L2Cache.
>>>>>>>> Could you please tell me which SoC you are using?
>>>>>>>> You can also refer to the appropriate dts file to see if there is
>>>>>>>> L2C.
>>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>>>>> entry.
>>>>>>>> L2C0: l2c {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I am seeing this problem with our custom IDE driver which is
>>>>>>>>> based on
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>>>>
>>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
>>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
>>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
>>>>>>>>> you suggest.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Could you give more details on the consistency problem? It is a good
>>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
>>>>>>>> should
>>>>>>>> work too
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
>>>>>>>> Herrenschmidt wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Adam,
>>>>>>>>>>
>>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> section:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> #ifdef CONFIG_44x
>>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> _PAGE_GUARDED)
>>>>>>>>
>>>>>>>>
>>>>>>>>>> #else
>>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>>>>> #endif
>>>>>>>>>>
>>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> that
>>>>>>>>
>>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> which
>>>>>>>>
>>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> masked
>>>>>>>>
>>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>>>>
>>>>>>>>>
>>>>>>> AFAIK,
>>>>>>>
>>>>>>>
>>>>>>>>> the 440 core just ignores M.
>>>>>>>>>
>>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>>>>
>>>>>>>>>
>>>>>>>> isn't
>>>>>>>>
>>>>>>>>
>>>>>>>>> enabled or not working ?
>>>>>>>>>
>>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>>>>
>>>>>>>>>
>>>>>>>> sure
>>>>>>>>
>>>>>>>>
>>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ben.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
>
^ permalink raw reply
* Re: Debian on MPC8572DS
From: Isaac Gomez Morales @ 2009-09-11 7:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090910163244.GA24878@b07421-ec1.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
Hello,
I'll try the "linutronix-lenny-gnuspe/" distro option, because i prefer a
option without a fp emulation.
Thanks u all.
2009/9/10 Scott Wood <scottwood@freescale.com>
> On Thu, Sep 10, 2009 at 05:01:53PM +0200, Isaac Gomez Morales wrote:
> > Hello,
> >
> > I'm trying to get a Linux distro such as Debian in the following system
> >
> > System:
> > mpc8572ds HW
>
> The 8572 does not have classic PowerPC floating point. The Debian
> binaries use this, so they cannot run without emulation.
>
> Emulation is slow, so you probably want something like this instead:
>
> http://groups.google.com/group/linux.debian.ports.powerpc/browse_thread/thread/235607517fd7ae1e/f4638a2cdef09bf7?lnk=raot
> http://download.breakpoint.cc/debian/linutronix-lenny-gnuspe/
>
> -Scott
>
[-- Attachment #2: Type: text/html, Size: 1443 bytes --]
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 7:31 UTC (permalink / raw)
To: Mikhail Zolotaryov
Cc: Prodyut Hazarika, tburns, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA9F98E.2010800@lebon.org.ua>
On Fri, 2009-09-11 at 10:17 +0300, Mikhail Zolotaryov wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
> >
> >> Hi Tom,
> >>
> >> In my case __dma_sync() calls flush_dcache_range() (it's due to
> >> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
> >> dcbi - that's the difference as dcbf is not privileged.
> >>
> >
> > What it calls depends on the direction of the transfer.
> Would not agree with you in this point as __dma_sync() code is:
Well, it -does- depend on the direction of the transfer... and -also- on
the size & alignement :-)
Anyway, that is probably not the problem. From the log I've seen, it
just looks like a page fault due to a bad virtual address passed there.
Cheers,
Ben.
> case DMA_FROM_DEVICE:
> /*
> * invalidate only when cache-line aligned otherwise
> there is
> * the potential for discarding uncommitted data from
> the cache
> */
> if ((start & (L1_CACHE_BYTES - 1)) || (size &
> (L1_CACHE_BYTES - 1)))
> flush_dcache_range(start, end);
> else
> invalidate_dcache_range(start, end);
> break;
>
> So, actual instruction used depends on address/size alignment.
>
> > The tasklet runs
> > in priviledged mode, dcbi should work just fine... if passed a correct
> > address :-)
> >
> > Cheers,
> > Ben.
> >
> >
> >> Tom Burns wrote:
> >>
> >>> Hi Mikhail,
> >>>
> >>> Sorry, this DMA code is in a tasklet. Are you suggesting the
> >>> processor is in supervisor mode at that time? Calling
> >>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
> >>> the OOPS. The entire oops is as follows, if it's relevant:
> >>>
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> >>> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
> >>> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
> >>> DEAR: 3fd39000, ESR: 00800000
> >>> TASK = de5db7d0[157] 'cat' THREAD: df116000
> >>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> >>> 0079a169
> >>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> >>> 10177000
> >>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> >>> e11f59cc
> >>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> >>> 87d39009
> >>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> >>> LR [c0010c30] __dma_sync+0x58/0xac
> >>> Call Trace:
> >>> [df117c80] [0000000a] 0xa (unreliable)
> >>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> >>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> >>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> >>> [df117d10] [c00067a8] do_softirq+0x54/0x58
> >>> [df117d20] [c001edb4] irq_exit+0x48/0x58
> >>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> >>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> >>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> >>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> >>> [df117ec0] [c00171ac] mmput+0x50/0xd4
> >>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> >>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> >>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> >>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> >>> Instruction dump:
> >>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> >>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> >>> 7c0004ac
> >>> Kernel panic - not syncing: Aiee, killing interrupt handler!
> >>> Rebooting in 180 seconds..
> >>>
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> Mikhail Zolotaryov wrote:
> >>>
> >>>> Hi Tom,
> >>>>
> >>>> possible solution could be to use tasklet to perform DMA-related job
> >>>> (as in most cases DMA transfer is interrupt driven - makes sense).
> >>>>
> >>>>
> >>>> Tom Burns wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> With the default config for the Sequoia board on 2.6.24, calling
> >>>>> pci_dma_sync_sg_for_cpu() results in executing
> >>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
> >>>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
> >>>>> the assembly instruction dcbi, which can only be executed in
> >>>>> supervisor mode. We tried that before resorting to manual cache
> >>>>> line management with usermode-safe assembly calls.
> >>>>>
> >>>>> Regards,
> >>>>> Tom Burns
> >>>>> International Datacasting Corporation
> >>>>>
> >>>>> Mikhail Zolotaryov wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Why manage cache lines manually, if appropriate code is a part of
> >>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
> >>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>>>>
> >>>>>> Prodyut Hazarika wrote:
> >>>>>>
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
> >>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>>>>
> >>>>>>>>
> >>>>>>> (using
> >>>>>>>
> >>>>>>>
> >>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> >>>>>>>> timing)
> >>>>>>>> end up being partially corrupted when we try to parse the data in
> >>>>>>>> the
> >>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>>>>
> >>>>>>>>
> >>>>>>> memory
> >>>>>>>
> >>>>>>>
> >>>>>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>>>>> corrupted, we see a random portion of it (always a multiple of
> >>>>>>>> 16byte
> >>>>>>>> cache lines) is overwritten with old data from the last time the
> >>>>>>>>
> >>>>>>>>
> >>>>>>> buffer
> >>>>>>>
> >>>>>>>
> >>>>>>>> was used.
> >>>>>>>>
> >>>>>>> This looks like a cache coherency problem.
> >>>>>>> Can you ensure that the TLB entries corresponding to the DMA
> >>>>>>> region has
> >>>>>>> the CacheInhibit bit set.
> >>>>>>> You will need a BDI connected to your system.
> >>>>>>>
> >>>>>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>>>>> since in 440 cores,
> >>>>>>> L1Cache coherency is managed entirely by software.
> >>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
> >>>>>>> example on
> >>>>>>> how to do it.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Prodyut
> >>>>>>>
> >>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>>>>
> >>>>>>>>
> >>>>>>> board)
> >>>>>>>
> >>>>>>>
> >>>>>>>> have L2Cache.
> >>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
> >>>>>>>> 440EPx
> >>>>>>>> has a 440 cpu core, but no L2Cache.
> >>>>>>>> Could you please tell me which SoC you are using?
> >>>>>>>> You can also refer to the appropriate dts file to see if there is
> >>>>>>>> L2C.
> >>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>>>>> entry.
> >>>>>>>> L2C0: l2c {
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I am seeing this problem with our custom IDE driver which is
> >>>>>>>>> based on
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>
> >>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
> >>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
> >>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
> >>>>>>>>> you suggest.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Could you give more details on the consistency problem? It is a good
> >>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
> >>>>>>>> should
> >>>>>>>> work too
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
> >>>>>>>> Herrenschmidt wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> section:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #ifdef CONFIG_44x
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> _PAGE_GUARDED)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #else
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>>>>> #endif
> >>>>>>>>>>
> >>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> that
> >>>>>>>>
> >>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> which
> >>>>>>>>
> >>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> masked
> >>>>>>>>
> >>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> AFAIK,
> >>>>>>>
> >>>>>>>
> >>>>>>>>> the 440 core just ignores M.
> >>>>>>>>>
> >>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> isn't
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> enabled or not working ?
> >>>>>>>>>
> >>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> sure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>>>>> needed.
> >>>>>>>>>
> >>>>>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ben.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
> >
> >
^ permalink raw reply
* Re: RMO ? (in the prom_init.c)
From: Benjamin Herrenschmidt @ 2009-09-11 7:39 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev list
In-Reply-To: <4AA9EF51.1050506@gmail.com>
On Fri, 2009-09-11 at 15:33 +0900, HongWoo Lee wrote:
> Hi ~
>
> Can anybody tell me what the RMO is ?? in the linux kernel.
> (arch/powerpc/kernel/prom_init.c)
> Through googling and guessing, I found "Read Memory Only" and "Relaxed
> Memory Order".
> But none of these are not properly understood in the context.
It's actually a bad name and should probably be "RMA" , aka Real Mode
Area.
This is a "feature" of the POWER architecture for servers, when running
under a hypervisor. Not all of memory can be accessed when the processor
is in "real mode" (MSR:IR and/or DR off).
The reason is obvious, since the OS doesn't have access to real memory
but virtualized logical addresses. And since all of the virtualization
normally goes through the MMU hash table, "real mode" accesses that
bypass the hash table are problematic to allow in an OS.
The "solution" used by those processors is to have a HW feature that
allows a chunk of physical memory to be made accessible to the partition
in "real" mode, which is called the RMA.
That means in practice that the kernel can only access that portion of
it's logical address space while in real mode, it needs to use
translations in the hash table to access the whole of it.
The value in prom_init.c is used to constrain some allocations to that
range for things that will be accessed while running in real mode (such
as RTAS), though it's also abused to constrain those allocations to a
subset of memory even without hypervisors to work around things like
firmware bugs etc...
Cheers,
Ben.
^ permalink raw reply
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Pravin Bathija @ 2009-09-11 9:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, Stefan Roese,
linuxppc-dev, azilkie
In-Reply-To: <1252647621.8566.67.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Benjamin Herrenschmidt wrote:
> Do you know many drivers that do config space accesses without using
> the config space accessors ?
> Such drivers should be banned to oblivion.
> Cheers,
> Ben.
I'm not aware of such drivers in the 2.6.30+ kernel.
Thanks,
Pravin
On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
>
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ permalink raw reply
* PCI: ioread8 on MPC8323E-RDB cause kernel oops message
From: Grzegorz Jakubowski @ 2009-09-11 11:06 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I try to install NIC VIA-Rhine III on PCI in MPC8323E-RDB.
I have used BSP in ver. 1.0-rt (MPC8323E-RDB-20070507),
after that LTIB was build, I have marked in kernel configuration menu to
build driver for NIC as module in PIO mode (via-rhine.ko).
lspci return:
~ # lspci -vv
00:10.0 USB Controller: NEC Corporation USB (rev 44) (prog-if 10 [OHCI])
Subsystem: NEC Corporation Hama USB 2.0 CardBus
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.1 USB Controller: NEC Corporation USB 2.0 (rev 05) (prog-if 20 [EHCI])
Subsystem: NEC Corporation USB 2.0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (4000ns min, 8500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 90001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III]
(rev 86)
Subsystem: VIA Technologies, Inc. Unknown device 0105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (750ns min, 2000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at d0000000 [size=256]
Region 1: Memory at 90001100 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
after modprobe via-rhine I'got kernel oops message:
~ # modprobe via-rhine
via-rhine.c:v1.10-LK1.4.2 Sept-11-2006 Written by Donald Becker
drivers/net/via-rhine.c <453>: ioread8(3489660928 + 131)
Unable to handle kernel paging request for data at address 0xd00
00083
Faulting instruction address: 0xc0011b58
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in: via_rhine
NIP: C0011B58 LR: C501FEAC CTR: C0011B54
REGS: c307fc80 TRAP: 0300 Not tainted (2.6.20.6-rt8)
MSR: 00009032 <EE,ME,IR,DR> CR: 44004422 XER: 00000000
DAR: D0000083, DSISR: 20000000
TASK = c042f030[798] 'modprobe' THREAD: c307e000
GPR00: C501FEA4 C307FD30 C042F030 D0000083 00001485 FFFFFFFF C01
6136C 00000033
GPR08: C042F030 C02E0000 00009032 C0011B54 24004422 1001C7AC 000
00000 00000000
GPR16: 00000000 00000000 000000A5 00000124 C03DBC48 00000001 C50
20000 C5022BF4
GPR24: C04E62C0 C04E6000 D0000000 00000100 D0000000 D0000083 C04
E62C0 D0000000
NIP [C0011B58] ioread8+0x4/0x18
LR [C501FEAC] rhine_power_init+0x64/0x19c [via_rhine]
Call Trace:
[C307FD30] [C501FEA4] rhine_power_init+0x5c/0x19c [via_rhine] (u
nreliable)
[C307FD50] [C50203A4] rhine_init_one+0x220/0x650 [via_rhine]
[C307FDA0] [C014A434] pci_device_probe+0x80/0xa0
[C307FDC0] [C0165794] really_probe+0x64/0x134
[C307FDE0] [C0165BB4] __driver_attach+0x84/0x88
[C307FE00] [C01647F8] bus_for_each_dev+0x54/0x90
[C307FE30] [C0165518] driver_attach+0x24/0x34
[C307FE40] [C0164E68] bus_add_driver+0x88/0x1b4
[C307FE60] [C0165E8C] driver_register+0x68/0xb0
[C307FE70] [C0149E6C] __pci_register_driver+0x84/0xe4
[C307FE90] [C502602C] rhine_init+0x2c/0x90 [via_rhine]
[C307FEA0] [C004B670] sys_init_module+0xf4/0x1624
[C307FF40] [C000F4A4] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff70fe8
LR = 0x10002ac4
Instruction dump:
83e1001c 38210020 7c0803a6 4e800020 38800000 7c0803a6 4e800021 2
f830000
3860ffea 419eff04 4bffffac 7c0004ac <88630000> 0c030000 4c00012c
5463063e
Segmentation fault
~ #
failed funcftion was ioread8 called from rhine_power_init in via-rhine.c
drivers/net/via-rhine.c <453>: ioread8(d0000000 + 83)
I have no idea why this call was failed, thanks for any help.
Thanks in advance.
Best Regards, Gregory Jakubowski
ps. U-Boot and kernel boot messages:
U-Boot 1.1.6 (May 7 2007 - 14:10:46) MPC83XX
Clock configuration:
Coherent System Bus: 133 MHz
Core: 333 MHz
QE: 99 MHz
BRG: 49 MHz
Local Bus Controller: 133 MHz
Local Bus: 66 MHz
DDR: 266 MHz
SEC: 133 MHz
I2C1: 133 MHz
CPU: MPC8323E, Rev: 11 at 333.333 MHz
Board: Freescale MPC8323ERDB
I2C: ready
DRAM:
DDR RAM: 64 MB
FLASH: 16 MB
PCI clock is 33MHz
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Generic MII (2430d80)
FSL UEC0: Full Duplex
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
UEC: PHY is Generic MII (2430d80)
FSL UEC1: Full Duplex
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
Hit any key to stop autoboot: 6 ... 0
=> run tfpramboot
## Error: "tfpramboot" not defined
=> run tftpramboot
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/rootfs.ext2.gz.uboot'.
Load address: 0x1000000
Loading: *.#####################################################
...
. #############
done
Bytes transferred = 9050488 (8a1978 hex)
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/uImage'.
Load address: 0x200000
Loading: *.#####################################################
############
...
. ##########################################
done
Bytes transferred = 1545367 (179497 hex)
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/mpc832x_rdb.dtb'.
Load address: 0x400000
Loading: *.#
done
Bytes transferred = 5070 (13ce hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.20.6-rt8
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1545303 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 9050424 Bytes = 8.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 0370a000, end 03fab938 ... OK
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (grzegorz@matrix) (gcc version 4.0.2
20060628 (Wasabi)) #2 PREEMPT Tue Sep 8 14:41:52 CEST 2009
Found initrd at 0xc370a000:0xc3fab938
setup_arch: bootmem
mpc832x_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bu
s number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/ram ramdisk_size=25000 rw console
=ttyS0,115200
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (grzegorz@matrix) (gcc version 4.0.2
20060628 (Wasabi)) #2 PREEMPT Tue Sep 8 14:41:52 CEST 2009
Found initrd at 0xc370a000:0xc3fab938
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bu
s number: 0->0
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/ram ramdisk_size=25000 rw console
=ttyS0,115200
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 52736k/65536k available (2912k kernel code, 12740k reser
ved, 204k data, 120k bss, 136k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 4, 65536 bytes)
TCP bind hash table entries: 1024 (order: 2, 28672 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks
like an initrd
Freeing initrd memory: 8838k freed
prom_parse: Bad cell count for /qe@e0100000/mdio@3120/ethernet-p
hy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@3120/ethernet-p
hy@04
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (32
seconds)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 25000K size 1024 blo
cksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
UCC Ethernet Controller MII Bus: probed
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC2 at 0xe0103000 (irq = 21)
eth0: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=178
4,sk_buff=152)
ucc_geth: UCC3 at 0xe0102200 (irq = 34)
eth1: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=178
4,sk_buff=152)
SKB Handler initialized(max=64)
ICPlus IP175C: Registered new driver
usbmon: debugfs is not available
ehci_hcd 0000:00:10.1: EHCI Host Controller
ehci_hcd 0000:00:10.1: new USB bus registered, assigned bus numb
er 1
ehci_hcd 0000:00:10.1: irq 19, io mem 0x90001000
ehci_hcd 0000:00:10.1: USB 2.0 started, EHCI 1.00, driver 10 Dec
2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd 0000:00:10.0: OHCI Host Controller
ohci_hcd 0000:00:10.0: new USB bus registered, assigned bus numb
er 2
ohci_hcd 0000:00:10.0: irq 19, io mem 0x90000000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
Time: timebase clocksource has been installed.
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 136k init
Setting the hostname to freescale
Mounting filesystems
Setting up networking on loopback device:
Setting up networking on eth1:
udhcpc (v0.9.9-pre) started
udhcpc[725]: udhcpc (v0.9.9-pre) started
Sending discover...
udhcpc[725]: Sending discover...
PHY: e0103120:04 - Link is Up - 100/Full
Sending discover...
udhcpc[725]: Sending discover...
Sending select for 192.168.0.206...
udhcpc[725]: Sending select for 192.168.0.206...
Lease of 192.168.0.206 obtained, lease time 3600
udhcpc[725]: Lease of 192.168.0.206 obtained, lease time 3600
deleting routers
SIOCDELRT: No such process
adding dns 192.168.1.10
adding dns 192.168.1.9
adding dns 194.204.159.1
Setting up networking on eth0:
Adding static route for default gateway to 192.168.2.1:
Setting nameserver to 192.168.2.1 in /etc/resolv.conf:
Starting the boa webserver:
/sbin/ip
Starting dhcpd
Internet Systems Consortium DHCP Server V3.0.3b1
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 0 leases to leases file.
Listening on LPF/eth0/00:04:9f:ef:03:02/192.168.2/24
Sending on LPF/eth0/00:04:9f:ef:03:02/192.168.2/24
Sending on Socket/fallback/fallback-net
Done
PHY: e0103120:00 - Link is Up - 100/Full
Welcome to Freescale Semiconductor Embedded Linux Environment
^ permalink raw reply
* RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
From: Aggrwal Poonam-B10812 @ 2009-09-11 11:47 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20090910160233.GA24085@iram.es>
=20
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]=20
> Sent: Thursday, September 10, 2009 9:33 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each=20
> core in CAMPmodefor P2020RDB
>=20
> On Thu, Sep 10, 2009 at 08:48:38PM +0530, Aggrwal Poonam-B10812 wrote:
> > =20
> >=20
> > > -----Original Message-----
> > > From: Gabriel Paubert [mailto:paubert@iram.es]
> > > Sent: Thursday, September 10, 2009 3:03 PM
> > > To: Aggrwal Poonam-B10812
> > > Cc: linuxppc-dev@ozlabs.org
> > > Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for=20
> each core in=20
> > > CAMPmode for P2020RDB
> > >=20
> > > On Thu, Sep 10, 2009 at 02:27:11PM +0530, Poonam Aggrwal wrote:
> > > > This patch creates the dts files for each core and splits
> > > the devices
> > > > between the two cores for P2020RDB.
> > > >=20
> > > > core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto,=20
> > > > global-util, pci0
> > > > core1 has L2, dma2, eth0, pci1, msi.
> > >=20
> > > Surely you mean eth1 and eth2 for core0, no?
> > Yes you are right , I'll fix this.
> > >=20
> > > At least it's what I gather from the code.
> > >=20
> > > Also both cores have a node called serial0, at different=20
> addresses=20
> > > but with the same interrupt!
> > Yes both the UARTS use the same int line in shared mode.=20
> > >=20
> > > But in the mpic comment line there is "serial1", and=20
> interrupt 42 is=20
> > > the only number which appears in both lists of mpic protected=20
> > > interrupts.
> > I am not sure how to handle the shared interrupts in AMP scenario,=20
> > although this has been tested and both serials are working=20
> one on each=20
> > core.
>=20
> Ok, I wrongly understood protected interrupts as reserved for=20
> one core. However, I still dislike two devices having the same name.
>=20
> Otherwise it may work if every interrupt is delivered to both=20
> cores although statistically only one core will actually have=20
> some work to do. Doesn't the kernel complain about unhandled=20
> irqs however?=20
>=20
We don't see any such messages of unhandled interrupts, although I
checked the corresponding files for mpc8572ds, they do not have the
interrupts property for the serial ports at all, in both the core0 and
core1 dts.
Don't know the reason.
> Regards,
> Gabriel
>=20
> > > > +
> > > > + serial0: serial@4500 {
> > > > + cell-index =3D <0>;
> > > > + device_type =3D "serial";
> > > > + compatible =3D "ns16550";
> > > > + reg =3D <0x4500 0x100>;
> > > > + clock-frequency =3D <0>;
> > > > + interrupts =3D <42 2>;
> > > > + interrupt-parent =3D <&mpic>;
> > > > + };
>=20
> > > > +
> > > > + mpic: pic@40000 {
> > > > + interrupt-controller;
> > > > + #address-cells =3D <0>;
> > > > + #interrupt-cells =3D <2>;
> > > > + reg =3D <0x40000 0x40000>;
> > > > + compatible =3D "chrp,open-pic";
> > > > + device_type =3D "open-pic";
> > > > + protected-sources =3D <
> > > > + 42 76 77 78 79 /* serial1 , dma2 */
> > > > + 29 30 34 26 /* enet0, pci1 */
> > > > + 0xe0 0xe1 0xe2 0xe3 /* msi */
> > > > + 0xe4 0xe5 0xe6 0xe7
> > > > + >;
> > > > + };
> > > > +
> > > > +
>=20
> > > > + serial0: serial@4600 {
> > > > + cell-index =3D <1>;
> > > > + device_type =3D "serial";
> > > > + compatible =3D "ns16550";
> > > > + reg =3D <0x4600 0x100>;
> > > > + clock-frequency =3D <0>;
> > > > + interrupts =3D <42 2>;
> > > > + interrupt-parent =3D <&mpic>;
> > > > + };
> > > > +
> > > > +
>=20
> > > > + mpic: pic@40000 {
> > > > + interrupt-controller;
> > > > + #address-cells =3D <0>;
> > > > + #interrupt-cells =3D <2>;
> > > > + reg =3D <0x40000 0x40000>;
> > > > + compatible =3D "chrp,open-pic";
> > > > + device_type =3D "open-pic";
> > > > + protected-sources =3D <
> > > > + 17 18 43 42 59 47 /*ecm, mem,=20
> i2c, serial0, spi,gpio */
> > > > + 16 20 21 22 23 28 /* L2,=20
> dma1, USB */
> > > > + 03 35 36 40 31 32 33 /*=20
> mdio, enet1, enet2 */
> > > > + 72 45 58 25 /*=20
> sdhci, crypto , pci */
> > > > + >;
> > > > + };
> > > > +
>=20
>=20
^ permalink raw reply
* Re: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
From: Gabriel Paubert @ 2009-09-11 11:52 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev
In-Reply-To: <1BD5CFC378ED0946B688E0C9BA2EF0951FD33A@zin33exm24.fsl.freescale.net>
On Fri, Sep 11, 2009 at 05:17:50PM +0530, Aggrwal Poonam-B10812 wrote:
>
>
> > -----Original Message-----
> > From: Gabriel Paubert [mailto:paubert@iram.es]
> > Sent: Thursday, September 10, 2009 9:33 PM
> > To: Aggrwal Poonam-B10812
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each
> > core in CAMPmodefor P2020RDB
> >
> > Ok, I wrongly understood protected interrupts as reserved for
> > one core. However, I still dislike two devices having the same name.
> >
> > Otherwise it may work if every interrupt is delivered to both
> > cores although statistically only one core will actually have
> > some work to do. Doesn't the kernel complain about unhandled
> > irqs however?
> >
> We don't see any such messages of unhandled interrupts, although I
> checked the corresponding files for mpc8572ds, they do not have the
> interrupts property for the serial ports at all, in both the core0 and
> core1 dts.
> Don't know the reason.
Well it may depend on the irqdebug (or actually it seems to
be noirqdebug) kernel parameter.
But if serial is used for console, the message rate could
go ballistic.
Gabriel
^ permalink raw reply
* Re:linux booting fine but running slow
From: Gao Ya'nan @ 2009-09-11 11:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: stevan
Hi, stevan, I had met a similarly problem with U-Boot-v2009.08 and
DENX-v2.6.30.3 Linux.
Today, I add some options to Linux, everythings worked well, but I got
a fat kernel. Do you solve it now ?
Gao Ya'nan
^ permalink raw reply
* Re: linux booting fine but running slow
From: Frank Svendsbøe @ 2009-09-11 13:06 UTC (permalink / raw)
To: Gao Ya'nan; +Cc: linuxppc-dev, stevan
In-Reply-To: <d15e5cf90909110459p221d4bc3nc9e1d45b95bce6bd@mail.gmail.com>
Hi Gao and Stevan
I've observed the same slow-down issue on an MPC875 a while now, but
haven't had the time to do a git-bisect
and find the patch that causes the problem. So far, I'm running
torvalds 2.6.29-rc6, and the slow-down problem
was introduced somewhere between 2.6.26-rc6 and 2.6.30-rc2.
What options did you specify to improve the performance?
Regards,
Frank
On Fri, Sep 11, 2009 at 1:59 PM, Gao Ya'nan <abutter.gao@gmail.com> wrote:
> Hi, stevan, I had met a similarly problem with U-Boot-v2009.08 and
> DENX-v2.6.30.3 Linux.
>
> Today, I add some options to Linux, everythings worked well, but I got
> a fat kernel. Do you solve it now ?
>
> Gao Ya'nan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [RESEND][PATCH] sata_fsl: hard and soft reset split
From: Kalra Ashish-B00888 @ 2009-09-11 13:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <4AA9F038.6030207@garzik.org>
Hello Jeff,
I will do the rediff and resubmit the patch.
Thanks,
Ashish=20
-----Original Message-----
From: Jeff Garzik [mailto:jeff@garzik.org]=20
Sent: Friday, September 11, 2009 12:08 PM
To: Kalra Ashish-B00888
Cc: linux-ide@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [RESEND][PATCH] sata_fsl: hard and soft reset split
On 06/29/2009 09:26 AM, ashish kalra wrote:
> Split sata_fsl_softreset() into hard and soft resets to make=20
> error-handling more efficient & device and PMP detection more
reliable.
>
> Also includes fix for PMP support, driver tested with Sil3726, Sil4726
> & Exar PMP controllers.
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
can you rediff this and 'AN' support against latest upstream?
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Tom Burns @ 2009-09-11 13:51 UTC (permalink / raw)
To: benh; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie, lebon
In-Reply-To: <1252634148.8566.11.camel@pasglop>
Hi Ben,
Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 09:43 -0400, Tom Burns wrote:
>
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().
>> This OOPses on PPC440 since it tries to call directly the assembly
>> instruction dcbi, which can only be executed in supervisor mode. We
>> tried that before resorting to manual cache line management with
>> usermode-safe assembly calls.
>>
>
> Wait a minute.... usermode ? You are doing all of that from userspace ?
> I don't understand the story here. You can't call all those kernel APIs
> form userspace in the first place, indeed... But then an IDE driver has
> nothing to do in userspace neither.
>
Sorry, I was referring to whether or not the CPU is in supervisor mode.
Our code is all in the kernel, not userspace :). I can see now from the
value of MSR at the time of the OOPS that the processor was in
supervisor mode, I missed that earlier. Looks like you're right about
the bad address, I will investigate.
Thanks,
Tom
> Cheers,
> Ben.
>
>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>
>>> Hi,
>>>
>>> Why manage cache lines manually, if appropriate code is a part of
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>
>>>> Hi Adam,
>>>>
>>>>
>>>>
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>
>>>>>
>>>> (using
>>>>
>>>>
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>
>>>>>
>>>> memory
>>>>
>>>>
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>
>>>>>
>>>> buffer
>>>>
>>>>
>>>>> was used.
>>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>
>>>>
>>>>> Hi Adam,
>>>>>
>>>>>
>>>>>
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>
>>>>>>
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>
>>>>>
>>>> board)
>>>>
>>>>
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>> L2C0: l2c {
>>>>> ...
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>>>
>>>>>>
>>>>
>>>>
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>
>>>>>>
>>>> the
>>>>
>>>>
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page.
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>
>>>>>>
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut
>>>>>
>>>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>>>
>>>>>
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>
>>>>>>>
>>>>> section:
>>>>>
>>>>>
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>
>>>>>>>
>>>>> _PAGE_GUARDED)
>>>>>
>>>>>
>>>>>>> #else
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>
>>>>>>>
>>>>> that
>>>>>
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>
>>>>>>>
>>>>> which
>>>>>
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>
>>>>>>>
>>>>> the
>>>>>
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>
>>>>>>>
>>>>> masked
>>>>>
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>
>>>>>>>
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>
>>>>>>
>>>> AFAIK,
>>>>
>>>>
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>
>>>>>>
>>>>> isn't
>>>>>
>>>>>
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>
>>>>>>
>>>>> sure
>>>>>
>>>>>
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
>
>
>
^ 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