* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-16 23:18 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <19548.1137399114@www099.gmx.net>
> Ah, okay. So at least the approach to use the Uninorth code was a step in
> the right direction. But that requires changes in the DRI and X server code,
> right?
Not you shouldn't... there are 2 different things here. One is how you
access the GART table itself. One is how you access the AGP memory (the
memory that is bound to the GART).
I'm not 100% sure what of the 2 above cases triggered an error with
ioremap, I'm not sure what approach should be used, because i don't know
what your chipset does. I would need more infos about the hw there. But
the basic idea is:
- For the GART table, you don't need to ioremap it (which is generally
a way to have it non-cacheable I suppose). You can just flush cache
entries after populating them (see uninorth_insert_memory(), it flushes
first the pages that are being inserted in the GART as AGP memory is not
cacheable neither, and at the end of the function, flushes the GART
entry proper).
- The AGP aperture itself. The main issue there is wether your chipset
makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
doesn't for example, it;'s only visible to the graphic chip. That is why
the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
generate AGP mappings by using the real memory pages and putting them
together into a virtual mapping instead of doing a direct mapping of the
AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
remapping of pages is enough.
Ben.
^ permalink raw reply
* Issue while linking c++ applicatiopn on Linux Power
From: Abhay Singh @ 2006-01-16 12:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi,
I am porting a huge c++ server application on Linux Power PC.
The compiler which I am using is IBM xlC 7.0 version. The gcc version
installed is 3.3.3.
I am using xlC for building the c++ application and shared objects, as
opposed for the gcc -fPIC option, Iam using -qpic=large for creating the
position independance code.
While linking one of out libraries, we encountered an issue like "
"relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc"
Then after using the -Wl,--relax as linker option we were able to create the
shared library.
Now but during the creation of the final executable during the link time, I
am facing a similar issue like
objws/opt/dcsdblk.o(.text+0xe620): In function `os_vector<DCWFormat
const*>::reserve(unsigned int)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
objws/opt/dcsdblk.o(.text+0xe70c): In function `os_allocator<DCWFormat
const*>::allocate(unsigned int, void const*)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
objws/opt/dcsdblk.o(.text+0xe790): In function `os_vector<DCWFormat
const*>::insert(DCWFormat const**, unsigned int, DCWFormat const* const&)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
Even the Wl,--relax option is noy helping us.
I saw one small c test program as
#include <stdio.h>
char realbig[36000032] = {1,2};
int main()
{
printf ("&realbig = %#lx\n", &realbig);
}
while compiling gives the same kind of error. Although this error vanishes,
if we do a 64 bit build using option -q64 for xlC and -m64 for gcc.
Please let me know, if there is any resolution for the above described
issue.
Thanks and regards,
Abhay Kumar Singh
Oracle India Private Limited.
Tel: 91-80-51086837
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2468 bytes --]
^ permalink raw reply
* [PATCH][UPDATE] powerpc: Add CONFIG_DEFAULT_UIMAGE to build a uImage by default for a board
From: Kumar Gala @ 2006-01-16 16:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Embedded boards that u-boot require a kernel image in the uImage format.
This allows a given board to specify it wants a uImage built by default.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit dc9904232f13395c8aa3a46a3cce759c82c03278
tree 7f2d49a2bfffdfb5eaae3693fb749a1243a94c1c
parent 7ba6450ca6461a19638f963af152e0b5ab00ef15
author Kumar Gala <galak@kernel.crashing.org> Mon, 16 Jan 2006 10:58:51 -0600
committer Kumar Gala <galak@kernel.crashing.org> Mon, 16 Jan 2006 10:58:51 -0600
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/Makefile | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index df338c5..80d114a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -83,6 +83,12 @@ config GENERIC_TBSYNC
default y if PPC32 && SMP
default n
+config DEFAULT_UIMAGE
+ bool
+ help
+ Used to allow a board to specify it wants a uImage built by default
+ default n
+
menu "Processor support"
choice
prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 44dd82b..15fc3e9 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -142,6 +142,7 @@ drivers-$(CONFIG_OPROFILE) += arch/power
# Default to zImage, override when needed
defaultimage-y := zImage
defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
^ permalink raw reply related
* Re: PPC440EP/Yosemite PCI misbehavior
From: David Hawkins @ 2006-01-16 16:56 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601151021.13798.sr@denx.de>
Hi Stefan,
> I have to admit, that PCI I/O can't have worked until now on
> Yosemite/Yellowstone. I just found a bug in
> arch/ppc/platforms/4xx/yosemite.h:
>
> -#define YOSEMITE_PCI_IO_BASE 0x00000000e0000000ULL
> +#define YOSEMITE_PCI_IO_BASE 0x00000000e8000000ULL
>
> Please give it a try and let me know if the problem is fixed.
Yes, that was it! Its all working now.
Thanks very much!
Dave
^ permalink raw reply
* RE: ppc4xx DMA fixes for simultaneous sg transfers
From: Peter Fercher @ 2006-01-16 16:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 'ductusrhe'
In-Reply-To: <518B77BB6246D54D9E88FC49AFB0389D4F26BD@seskoptronicmsx.optronic.local>
[-- Attachment #1: Type: text/plain, Size: 12460 bytes --]
can somebody provide an example usage of the ppc4xx_ scatter/gather dma
library by mvista ?
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of ductusrhe
Sent: Mittwoch, 7. Dezember 2005 22:33
To: linuxppc-embedded@ozlabs.org
Subject: ppc4xx DMA fixes for simultaneous sg transfers
Linux 2.4.20 (probably 2.6 as well?)
Conclusion:
Scatter/gather DMA is not thread safe.
Background:
1. We run all four dma channels simultaneously in SG mode on the PPC440EP,
starting and stopping them in different threads.
2. Also we need to change channel configs between different transfers, i.e.
run ppc4xx_init_dma_channel() to set read or write mode.
Problem and cause:
1. All is well when running one channel at a time, but when
starting/stopping a new channel during the time another is active can - if
you are unlucky - cause problems.
Because all channels SG start/stop bits are in the same register (ASGC),
it must not be read then changed and written to the way it was done.
That can cause a channel that is just done, to start again, or a newly
started channel to stop.
The register includes a feature that can be used as a semaphore - the
read enable (mask) bits, but it was not used correctly in the code, it was
enabled for all channels in the start-up.
2. It is said in the comment of ppc4xx_init_dma_channel() that it should
only be used once in the start-up. If you comply, you will not have any
problem with it.
However, when running this for a channel when other channels are active,
can cause channels to stop or maybe never give an interrupt or false
interrupts. The method clears the entire status register, not only the bits
for the given channel.
Solution:
1. - In ppc4xx_alloc_dma_handle(), do not touch the ASGC register!
- In ppc4xx_enable_dma_sgl() and ppc4xx_disable_dma_sgl(), when setting
the ASGC register, only change the given channel.
That's done without reading the register at all, just set/clear the
enable bit of the channel to change, then set the MASK_ENABLE for the same
channel.
Probably this is the way the register was intended to be handled?
2. - In ppc4xx_init_dma_channel(), only clear the correct bits of the DMASR
register, not the whole register.
(The polarity was also not set as it's supposed to in this function,
but there exists a patch for that)
I can send a patch with our changes, that works very well and stable, but
there are many changes and not all of them in line with the current official
version of the files (we handle the sg descriptor list differently). Maybe
someone feeling for it will take a look at the changes and make them into
the real code, since the above fixes does not interfere with the usage, only
improves thread safety.
I have no idea if this has been fixed in some patch already... but I have
not seen it on this list anyway.
I'm not a regular poster, just want to help others avoid some of the
struggle when running many channels.
/Ronnie Hedlund
Our changed code:
In "ppc4xx_dma.c"
-----------------------
/*
* The comment states that this function should only be run at start-up,
and never more.
* That is unacceptable, with the fix it can be run anywhere as long as the
given channel is not running.
*/
int ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
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};
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;
switch (dmanr) {
case 0:
/* clear all polarity signals and then "or" in new signal
levels */
polarity &= ~GET_DMA_POLARITY(0);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR0, control);
break;
case 1:
polarity &= ~GET_DMA_POLARITY(1);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR1, control);
break;
case 2:
polarity &= ~GET_DMA_POLARITY(2);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR2, control);
break;
case 3:
polarity &= ~GET_DMA_POLARITY(3);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR3, control);
break;
default:
return DMA_STATUS_BAD_CHANNEL;
}
/* 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;
/*
* clear status register for the channel
* only TS, CS and RI needs to be cleared.
*/
mtdcr(DCRN_DMASR, status_bits[dmanr]);
return DMA_STATUS_GOOD;
}
In "ppc4xx_sgdma.c"
-----------------------
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned
int dmanr)
{
sgl_list_info_t *psgl = NULL;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
//uint32_t sg_command;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n",
dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
if (!phandle) {
printk("ppc4xx_alloc_dma_handle: null handle pointer\n");
return DMA_STATUS_NULL_POINTER;
}
/* Get memory for the listinfo struct */
psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
if (psgl == NULL) {
*phandle = (sgl_handle_t) NULL;
return DMA_STATUS_OUT_OF_MEMORY;
}
memset(psgl, 0, sizeof(sgl_list_info_t));
/* dma_addr is unused now */
psgl->dmanr = dmanr;
/*
* Modify and save the control word. These words will be
* written to each sgl descriptor. The DMA engine then
* loads this control word into the control register
* every time it reads a new descriptor.
*/
psgl->control = p_dma_ch->control;
/* Clear all mode bits */
psgl->control &= ~(DMA_TM_MASK | DMA_TD);
/* Save control word and mode */
psgl->control |= (mode | DMA_CE_ENABLE);
/* PPC Errata? DMA else ignore count on first in list */
psgl->control |= SET_DMA_TCE(1);
/* In MM mode, we must set ETD/TCE */
if (mode == DMA_MODE_MM)
psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
if (p_dma_ch->int_enable) {
/* Enable channel interrupt */
psgl->control |= DMA_CIE_ENABLE;
} else {
psgl->control &= ~DMA_CIE_ENABLE;
}
/* we must not touch the SGC, it can cause problems to other
channels! */
psgl->sgl_control = SG_LINK;
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
{
/* reuse as Terminal Count Interrupt Enable on all
descr. */
psgl->sgl_control |= SG_TCI_ENABLE;
}
psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
}
*phandle = (sgl_handle_t) psgl;
return DMA_STATUS_GOOD;
}
void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
ppc_dma_ch_t *p_dma_ch;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_enable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_enable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
} else if (!psgl->phead) {
printk("ppc4xx_enable_dma_sgl: sg list empty\n");
return;
}
p_dma_ch = &dma_channels[psgl->dmanr];
psgl->ptail->control_count &= ~SG_LINK; /* make this the last
dscrptr */
if (p_dma_ch->int_enable)
{
/* Require Terminal Count interrupt on last */
psgl->ptail->control_count |= SG_TCI_ENABLE;
}
/* No more changes to tail object allowed */
//dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
dma_cache_wback_inv((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
sg_command = 0;
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_ENABLE | SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_ENABLE | SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_ENABLE | SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_ENABLE | SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_enable_dma_sgl: bad channel: %d\n",
psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* start transfer */
}
void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_disable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_disable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
}
sg_command = 0; //disable dma
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_disable_dma_sgl: bad channel: %d\n",
psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* stop transfer */
}
[-- Attachment #2: Type: text/html, Size: 30210 bytes --]
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Olaf Hering @ 2006-01-16 16:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1137426731.22151.8.camel@localhost.localdomain>
On Mon, Jan 16, Hollis Blanchard wrote:
> Are you suggesting that nobody should ever use linuxppc64-dev now? If
> so, patching MAINTAINERS doesn't seem like the right way to enforce
> that.
It felt like a good starting point for this kind of discussion. :-)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] fix spider compilation
From: Arnd Bergmann @ 2006-01-16 12:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, jgarzik, Jens Osterkamp
In-Reply-To: <20060116121157.GA7171@suse.de>
Olaf Hering <olh@suse.de> wrote on 01/16/2006 01:11:57 PM:
>
> linux-2.6.15/drivers/net/spider_net.c: In function
> `spider_net_set_txdescr_cmdstat':
> linux-2.6.15/drivers/net/spider_net.c:890: error: `IPPROTO_TCP'
> undeclared (first use in this function)
> linux-2.6.15/drivers/net/spider_net.c:890: error: (Each undeclared
> identifier is reported only once
> linux-2.6.15/drivers/net/spider_net.c:890: error: for each function
> it appears in.)
> linux-2.6.15/drivers/net/spider_net.c:892: error: `IPPROTO_UDP'
> undeclared (first use in this function)
>
> Signed-off-by: Olaf Hering <olh@suse.de>
Thanks. I already submitted the same patch to Jeff Garzik,
but had a problem with a quilt bug that caused another patch
in the series to fail.
Jeff, did you get the '[RESEND 2]' patches for spidernet?
Sorry for messing this up twice before, but I'm pretty
sure that I fixed up the diff now and the contents are
somewhat important, at least the compile fix.
Arnd <><
> drivers/net/spider_net.c | 1 +
> 1 files changed, 1 insertion(+)
>
> Index: linux-2.6.15/drivers/net/spider_net.c
> ===================================================================
> --- linux-2.6.15.orig/drivers/net/spider_net.c
> +++ linux-2.6.15/drivers/net/spider_net.c
> @@ -33,6 +33,7 @@
> #include <linux/init.h>
> #include <linux/ioport.h>
> #include <linux/ip.h>
> +#include <linux/in.h>
> #include <linux/kernel.h>
> #include <linux/mii.h>
> #include <linux/module.h>
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Hollis Blanchard @ 2006-01-16 15:52 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060116121244.GB7171@suse.de>
On Mon, 2006-01-16 at 13:12 +0100, Olaf Hering wrote:
> Everything is merged into arch/powerpc now.
> Stop cross-posting.
> --- linux-2.6.15-olh.orig/MAINTAINERS
> +++ linux-2.6.15-olh/MAINTAINERS
> @@ -527,7 +527,7 @@ S: Supported
> BROADBAND PROCESSOR ARCHITECTURE
> P: Arnd Bergmann
> M: arnd@arndb.de
> -L: linuxppc64-dev@ozlabs.org
> +L: linuxppc-dev@ozlabs.org
> W: http://linuxppc64.org
> S: Supported
Are you suggesting that nobody should ever use linuxppc64-dev now? If
so, patching MAINTAINERS doesn't seem like the right way to enforce
that.
Do we want to think about merging the mailing lists? Both seem fairly
high-volume right now (compare
http://ozlabs.org/pipermail/linuxppc64-dev/ and
http://ozlabs.org/pipermail/linuxppc-dev/). linuxppc-embedded is
separate. There are certainly lots of emails and patches that are common
to both 32- and 64-bit, though...
The subscriber lists don't overlap 100%, but the difference might be
small enough not to matter to many people.
-Hollis
^ permalink raw reply
* [PATCH] drop linuxppc64-dev
From: Olaf Hering @ 2006-01-16 12:12 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Everything is merged into arch/powerpc now.
Stop cross-posting.
Signed-off-by: Olaf Hering <olh@suse.de>
Documentation/powerpc/hvcs.txt | 2 +-
MAINTAINERS | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.15-olh/Documentation/powerpc/hvcs.txt
===================================================================
--- linux-2.6.15-olh.orig/Documentation/powerpc/hvcs.txt
+++ linux-2.6.15-olh/Documentation/powerpc/hvcs.txt
@@ -560,7 +560,7 @@ The proper channel for reporting bugs is
distribution company that provided your OS or by posting issues to the
ppc64 development mailing list at:
-linuxppc64-dev@lists.linuxppc.org
+linuxppc-dev@ozlabs.org
This request is to provide a documented and searchable public exchange
of the problems and solutions surrounding this driver for the benefit of
Index: linux-2.6.15-olh/MAINTAINERS
===================================================================
--- linux-2.6.15-olh.orig/MAINTAINERS
+++ linux-2.6.15-olh/MAINTAINERS
@@ -527,7 +527,7 @@ S: Supported
BROADBAND PROCESSOR ARCHITECTURE
P: Arnd Bergmann
M: arnd@arndb.de
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
W: http://linuxppc64.org
S: Supported
@@ -1606,7 +1606,7 @@ P: Anton Blanchard
M: anton@samba.org
M: anton@au.ibm.com
W: http://linuxppc64.org
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
S: Supported
LINUX SECURITY MODULE (LSM) FRAMEWORK
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] fix spider compilation
From: Olaf Hering @ 2006-01-16 12:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
linux-2.6.15/drivers/net/spider_net.c: In function `spider_net_set_txdescr_cmdstat':
linux-2.6.15/drivers/net/spider_net.c:890: error: `IPPROTO_TCP' undeclared (first use in this function)
linux-2.6.15/drivers/net/spider_net.c:890: error: (Each undeclared identifier is reported only once
linux-2.6.15/drivers/net/spider_net.c:890: error: for each function it appears in.)
linux-2.6.15/drivers/net/spider_net.c:892: error: `IPPROTO_UDP' undeclared (first use in this function)
Signed-off-by: Olaf Hering <olh@suse.de>
drivers/net/spider_net.c | 1 +
1 files changed, 1 insertion(+)
Index: linux-2.6.15/drivers/net/spider_net.c
===================================================================
--- linux-2.6.15.orig/drivers/net/spider_net.c
+++ linux-2.6.15/drivers/net/spider_net.c
@@ -33,6 +33,7 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/ip.h>
+#include <linux/in.h>
#include <linux/kernel.h>
#include <linux/mii.h>
#include <linux/module.h>
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-16 8:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137367531.4823.42.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Mon, 16 Jan 2006 10:25:31 +1100
>
> >Actually at least the bridge does everthing right until now (IMHO :-).
> >The bridge is detected and also the aperture size is read out correctly
> >from the registers. After that, the agp_backend_initialize() function in
> >drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
> >driver (articias_create_gatt_table). Based on the detected aperture size
> >and its definitions, this function allocates pages for the GATT table
> >(alloc_gatt_pages). The function then tries to map this pages with
> >ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))).
> >But ioremap_nocache() cannot remap the pages, because the following code
> >snipped in __ioremap (arch/ppc/mm/pgtable.c) is trigged:
>
> Yes, you are not allowed to ioremap RAM on ppc at least not with
> CONFIG_6xx. You should leave it cacheable and use explicit cache flush
> like the UniNorth driver.
Ah, okay. So at least the approach to use the Uninorth code was a step in
the right direction. But that requires changes in the DRI and X server code,
right?
Thanks!
regards,
Gerhard
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
^ permalink raw reply
* Re: [PATCH 00/10] Xilinx Virtex-* updates
From: Grant Likely @ 2006-01-16 7:30 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <43CB2EAB.7080307@dlasys.net>
David H. Lynch Jr. wrote:
> I merged your ml403 changes into my copy of the kernel.org linux-2.6 git
> repository, and I am working to adapt my Pico E12-Virtex-4 port to work
> with them. I have mostly succeeded, but I am still working through a few
> rough spots.
Cool, thanks! Let me know about anything you've got issues with.
It looks like I missed the merge window for 2.6.16, so this stuff
probably won't get in until 2.6.17. OTOH, that give us some time to get
the weeds out.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 00/10] Xilinx Virtex-* updates
From: David H. Lynch Jr. @ 2006-01-16 5:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <87u0c8q9f4.fsf@48ers.dk>
I merged your ml403 changes into my copy of the kernel.org linux-2.6 git
repository, and I am working to adapt my Pico E12-Virtex-4 port to work
with them. I have mostly succeeded, but I am still working through a few
rough spots.
Peter Korsgaard wrote:
>>>>>>"grant" == grant likely <grant.likely@secretlab.ca> writes:
>
>
> grant> Here's a repost of my Xilinx ML300 and ML403 patches with a few
> grant> cleanups, a bit of patch reordering, and rebased to 2.6.15.
>
> Nice, ..
>
> grant> I've tested on an ML403
> grant> Can someone test on an ML300? (I no longer have one)
>
> Works fine here on a ML300-alike board.
>
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-15 23:25 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <13039.1137366615@www38.gmx.net>
> Actually at least the bridge does everthing right until now (IMHO :-). The
> bridge is detected and also the aperture size is read out correctly from the
> registers. After that, the agp_backend_initialize() function in
> drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
> driver (articias_create_gatt_table). Based on the detected aperture size and
> its definitions, this function allocates pages for the GATT table
> (alloc_gatt_pages). The function then tries to map this pages with
> ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))). But
> ioremap_nocache() cannot remap the pages, because the following code snipped
> in __ioremap (arch/ppc/mm/pgtable.c) is trigged:
Yes, you are not allowed to ioremap RAM on ppc at least not with
CONFIG_6xx. You should leave it cacheable and use explicit cache flush
like the UniNorth driver.
> As it can be seen in the following log, the table address (0xde200000 ->
> virt_to_gart(table) = 0x1e200000) is lower than the maximum amount of memory
> 0x20000000 (512MB) and therefore __ioremap() does not remap the pages.
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-15 23:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Mon, 16 Jan 2006 08:48:28 +1100
>
> I don't understand. I would need to now more about what
> the bridge actually does to get any sense out of that.
Thanks for answering! It's hard to explain for me what the code does, but I
will try.
I included a cleaned-up version of the AGPGART driver code for the ArticiaS
(AmigaOne/Pegasos1). As mentioned, the driver is based on the VIA AGPGART
driver and uses the agp_generic_create_gatt_table() and
agp_generic_free_gatt_table() functions (well, I copied and renamed this
functions to insert debug code).
Actually at least the bridge does everthing right until now (IMHO :-). The
bridge is detected and also the aperture size is read out correctly from the
registers. After that, the agp_backend_initialize() function in
drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
driver (articias_create_gatt_table). Based on the detected aperture size and
its definitions, this function allocates pages for the GATT table
(alloc_gatt_pages). The function then tries to map this pages with
ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))). But
ioremap_nocache() cannot remap the pages, because the following code snipped
in __ioremap (arch/ppc/mm/pgtable.c) is trigged:
/*
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
*/
if ( mem_init_done && (p < virt_to_phys(high_memory)) )
{
printk("__ioremap(): phys addr "PHYS_FMT" is RAM lr %p\n", p,
__builtin_return_address(0));
return NULL;
}
As it can be seen in the following log, the table address (0xde200000 ->
virt_to_gart(table) = 0x1e200000) is lower than the maximum amount of memory
0x20000000 (512MB) and therefore __ioremap() does not remap the pages.
Debuglog:
agpgart: [ARTICIAS] articias_fetch_size()
agpgart: [ARTICIAS] * non masked temp = 0x6
agpgart: [ARTICIAS] * aperature size loop index #0
agpgart: [ARTICIAS] * values[0].size_value = 1
agpgart: [ARTICIAS] * aperature size loop index #1
agpgart: [ARTICIAS] * values[1].size_value = 2
agpgart: [ARTICIAS] * aperature size loop index #2
agpgart: [ARTICIAS] * values[2].size_value = 3
agpgart: [ARTICIAS] * aperature size loop index #3
agpgart: [ARTICIAS] * values[3].size_value = 4
agpgart: [ARTICIAS] * aperature size loop index #4
agpgart: [ARTICIAS] * values[4].size_value = 5
agpgart: [ARTICIAS] * aperature size loop index #5
agpgart: [ARTICIAS] * values[5].size_value = 6
agpgart: [ARTICIAS] * masked temp = 0x6
agpgart: [ARTICIAS] * values[5].size = 128 (128MB aperture size)
agpgart: [ARTICIAS] * current_size->size = 128
agpgart: [ARTICIAS] * current_size->page_order = 5
agpgart: [ARTICIAS] * current_size->num_entries = 32768
agpgart: [ARTICIAS] * current_size->size_value = 6
agpgart: [ARTICIAS] articias_create_gatt_table()
agpgart: [ARTICIAS] * table address = 0xde200000
agpgart: [ARTICIAS] * table end address = 0xde21ffff
agpgart: [ARTICIAS] * page = 0xc09c4400
agpgart: [ARTICIAS] * gatt_table_real = 0xde200000
agpgart: [ARTICIAS] * agp_gatt_table = 0xde200000
agpgart: [ARTICIAS] * virt_to_gart(table) = 0x1e200000
__ioremap() debug: addr = 0x1e200000
__ioremap() debug: phys addr = 0x1e200000
__ioremap() debug: size = 0x20000
__ioremap() debug: Highmem check
__ioremap() debug: high_memory = 0xe0000000
__ioremap() debug: virt_to_phys(high_memory) = 0x20000000
__ioremap(): phys addr 1e200000 is RAM lr c000f210
agpgart: [ARTICIAS] * gatt_table_real = 0x0
agpgart: unable to get memory for graphics translation table.
agpgart: agp_backend_initialize() failed.
agpgart-articias: probe of 0000:00:00.0 failed with error -12
How can I achieve it that ioremap_nocache() can map the pages or that
alloc_gatt_pages() returns valid pages for the GATT table?
Thanks again!
Regards,
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: articias-agp.c --]
[-- Type: text/x-csrc; name="articias-agp.c", Size: 11419 bytes --]
/*
* ArticiaS AGPGART routines.
*/
#include <linux/types.h>
#include <linux/module.h>
#include <linux/pagemap.h>
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <linux/init.h>
#include <linux/agp_backend.h>
#include "agp.h"
static struct pci_device_id agp_articias_pci_table[];
__u32 *agp_gatt_table;
#define ARTICIAS_AGP_EN 0x49 /* bit 0 -> AGP enable */
#define ARTICIAS_GART_EN 0x58 /* bit 6 -> GART enable */
#define ARTICIAS_APSIZE 0x59 /* bits 2:0 set size */
#define ARTICIAS_APBASE 0x59 /* TLB address Base [31:12]*/
#define ARTICIAS_GATTBASE 0x10 /* GART base address register */
#define ARTICIAS_TLB_BASE 0x5A /* bits 16:31 of TLB base address */
#define ARTICIAS_GATT_MASK 0xFFFFF000
#define ARTICIAS_SIZE_MASK 0x07 /* Mask aperture size bits. */
static int articias_fetch_size(void)
{
int i;
u8 temp;
struct aper_size_info_8 *values;
values = A_SIZE_8(agp_bridge->driver->aperture_sizes);
pci_read_config_byte(agp_bridge->dev, ARTICIAS_APSIZE, &temp);
/* Mask the GART/Aperture size selection bits. */
temp = temp & ARTICIAS_SIZE_MASK;
for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
if (temp == values[i].size_value) {
agp_bridge->previous_size =
agp_bridge->current_size = (void *) (values + i);
/* Geri: Was <(void *) (values)> before, but that
* didn't make sense to me!? Otherwise it would always
* point to the same value!
*/
agp_bridge->aperture_size_idx = i;
return values[i].size;
}
}
printk(KERN_ERR PFX "Unknown aperture size from AGP bridge (0x%x)\n", temp);
return 0;
}
static int articias_configure(void)
{
u32 temp = 0;
u16 shift16 = 0;
u8 shift8 = 0;
struct aper_size_info_8 *current_size;
/* Get current aperture size */
current_size = A_SIZE_8(agp_bridge->current_size);
temp = (u32) agp_bridge->gatt_table_real;
/* Get upper word from dword. Note that the ArticiaS should have 20
* bits for the TLB base address. Otherwise the PCI write config code
* for the aperture size below doesn't make sense!?
*/
shift16 = (u16) (temp>>16);
pci_write_config_word(agp_bridge->dev, ARTICIAS_TLB_BASE, shift16);
/* Get the byte 1 from dword and mask it out with the aperture size. */
shift8 = (u8) (temp>>8);
shift8 &= ~(ARTICIAS_SIZE_MASK);
shift8 |= current_size->size_value;
pci_write_config_byte(agp_bridge->dev, ARTICIAS_APBASE, shift8);
/* Get address to map too */
pci_read_config_dword(agp_bridge->dev, ARTICIAS_GATTBASE, (void *)&temp);
temp = temp & ARTICIAS_GATT_MASK;
agp_bridge->gart_bus_addr = temp;
/* GART control register */
/* Enable GART and bus concurrency */
pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, 0x41);
/* Enable AGP operation */
pci_write_config_byte(agp_bridge->dev, ARTICIAS_AGP_EN, 0x01);
return 0;
}
int articias_create_gatt_table(struct agp_bridge_data *bridge)
{
char *table;
char *table_end;
int size;
int page_order;
int num_entries;
int i;
void *temp;
struct page *page;
/* The generic routines can't handle 2 level gatt's */
if (bridge->driver->size_type == LVL2_APER_SIZE)
return -EINVAL;
table = NULL;
i = bridge->aperture_size_idx;
temp = bridge->current_size;
size = page_order = num_entries = 0;
if (bridge->driver->size_type != FIXED_APER_SIZE) {
do {
switch (bridge->driver->size_type) {
case U8_APER_SIZE:
size = A_SIZE_8(temp)->size;
page_order =
A_SIZE_8(temp)->page_order;
num_entries =
A_SIZE_8(temp)->num_entries;
break;
case U16_APER_SIZE:
size = A_SIZE_16(temp)->size;
page_order = A_SIZE_16(temp)->page_order;
num_entries = A_SIZE_16(temp)->num_entries;
break;
case U32_APER_SIZE:
size = A_SIZE_32(temp)->size;
page_order = A_SIZE_32(temp)->page_order;
num_entries = A_SIZE_32(temp)->num_entries;
break;
/* This case will never really happen. */
case FIXED_APER_SIZE:
case LVL2_APER_SIZE:
default:
size = page_order = num_entries = 0;
break;
}
table = alloc_gatt_pages(page_order);
if (table == NULL) {
i++;
switch (bridge->driver->size_type) {
case U8_APER_SIZE:
bridge->current_size = A_IDX8(bridge);
break;
case U16_APER_SIZE:
bridge->current_size = A_IDX16(bridge);
break;
case U32_APER_SIZE:
bridge->current_size = A_IDX32(bridge);
break;
/* This case will never really happen. */
case FIXED_APER_SIZE:
case LVL2_APER_SIZE:
default:
bridge->current_size =
bridge->current_size;
break;
}
temp = bridge->current_size;
} else {
bridge->aperture_size_idx = i;
}
} while (!table && (i < bridge->driver->num_aperture_sizes));
} else {
size = ((struct aper_size_info_fixed *) temp)->size;
page_order = ((struct aper_size_info_fixed *) temp)->page_order;
num_entries = ((struct aper_size_info_fixed *) temp)->num_entries;
table = alloc_gatt_pages(page_order);
}
if (table == NULL)
return -ENOMEM;
table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);
for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
SetPageReserved(page);
bridge->gatt_table_real = (u32 *) table;
agp_gatt_table = (void *) table;
bridge->driver->cache_flush();
bridge->gatt_table = ioremap_nocache(virt_to_gart(table),
(PAGE_SIZE * (1 << page_order)));
bridge->driver->cache_flush();
if (bridge->gatt_table == NULL) {
for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
ClearPageReserved(page);
free_gatt_pages(table, page_order);
return -ENOMEM;
}
bridge->gatt_bus_addr = virt_to_gart(bridge->gatt_table_real);
/* AK: bogus, should encode addresses > 4GB */
for (i = 0; i < num_entries; i++) {
writel(bridge->scratch_page, bridge->gatt_table+i);
readl(bridge->gatt_table+i); /* PCI Posting. */
}
return 0;
}
int articias_free_gatt_table(struct agp_bridge_data *bridge)
{
int page_order;
char *table, *table_end;
void *temp;
struct page *page;
temp = bridge->current_size;
switch (bridge->driver->size_type) {
case U8_APER_SIZE:
page_order = A_SIZE_8(temp)->page_order;
break;
case U16_APER_SIZE:
page_order = A_SIZE_16(temp)->page_order;
break;
case U32_APER_SIZE:
page_order = A_SIZE_32(temp)->page_order;
break;
case FIXED_APER_SIZE:
page_order = A_SIZE_FIX(temp)->page_order;
break;
case LVL2_APER_SIZE:
/* The generic routines can't deal with 2 level gatt's */
return -EINVAL;
break;
default:
page_order = 0;
break;
}
/* Do not worry about freeing memory, because if this is
* called, then all agp memory is deallocated and removed
* from the table. */
iounmap(bridge->gatt_table);
table = (char *) bridge->gatt_table_real;
table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);
for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
ClearPageReserved(page);
free_gatt_pages(bridge->gatt_table_real, page_order);
agp_gatt_table = NULL;
bridge->gatt_table = NULL;
bridge->gatt_table_real = NULL;
bridge->gatt_bus_addr = 0;
return 0;
}
#endif
static void articias_cleanup(void)
{
struct aper_size_info_8 *previous_size;
previous_size = A_SIZE_8(agp_bridge->previous_size);
pci_write_config_byte(agp_bridge->dev, ARTICIAS_APSIZE,
previous_size->size_value);
}
static void articias_tlbflush(struct agp_memory *mem)
{
u8 temp;
pci_read_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, &temp);
pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, (temp | 0x80));
pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, (temp & 0x7F));
return;
}
static struct aper_size_info_8 articias_generic_sizes[7] =
{
/* size, num_entries, page_order, size_value */
{4, 1024, 1, 1},
{8, 2048, 1, 2},
{16, 4096, 2, 3},
{32, 8192, 3, 4},
{64, 16384, 4, 5},
{128, 32768, 5, 6},
{256, 65536, 6, 7},
};
static struct agp_bridge_driver articias_driver = {
.owner = THIS_MODULE,
.aperture_sizes = articias_generic_sizes,
.size_type = U8_APER_SIZE,
.num_aperture_sizes = 7,
.configure = articias_configure,
.fetch_size = articias_fetch_size,
.cleanup = articias_cleanup,
.tlb_flush = articias_tlbflush,
.mask_memory = agp_generic_mask_memory,
.masks = NULL,
.agp_enable = agp_generic_enable,
.cache_flush = global_cache_flush,
.create_gatt_table = articias_create_gatt_table,
.free_gatt_table = articias_free_gatt_table,
.insert_memory = agp_generic_insert_memory,
.remove_memory = agp_generic_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
.agp_destroy_page = agp_generic_destroy_page,
};
static struct agp_device_ids articias_agp_device_ids[] __devinitdata =
{
{
.device_id = PCI_DEVICE_ID_MAI_ARTICIAS,
.chipset_name = "ArticiaS",
},
{ }, /* dummy final entry, always present */
};
static int __devinit agp_articias_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct agp_device_ids *devs = articias_agp_device_ids;
struct agp_bridge_data *bridge;
int j = 0;
u8 cap_ptr;
cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP);
if (!cap_ptr)
return -ENODEV;
j = ent - agp_articias_pci_table;
printk (KERN_INFO PFX "Detected MAI %s chipset\n", devs[j].chipset_name);
bridge = agp_alloc_bridge();
if (!bridge)
return -ENOMEM;
#ifdef ARTICIAS_DEBUG
/* Geri: Print all AGP relevant registers of the ArticiaS. */
articias_print_agp_register(pdev);
#endif
bridge->dev = pdev;
bridge->capndx = cap_ptr;
bridge->driver = &articias_driver;
/* Set a higher aperture size! Now it should be 128MB. */
pci_write_config_byte(pdev, ARTICIAS_APSIZE, 0x06);
return agp_add_bridge(bridge);
}
static void __devexit agp_articias_remove(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
agp_remove_bridge(bridge);
agp_put_bridge(bridge);
}
#ifdef CONFIG_PM
static int agp_articias_suspend(struct pci_dev *pdev, pm_message_t state)
{
pci_save_state (pdev);
pci_set_power_state (pdev, PCI_D3hot);
return 0;
}
static int agp_articias_resume(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
if (bridge->driver == &articias_driver)
return articias_configure();
return 0;
}
#endif /* CONFIG_PM */
/* must be the same order as name table above */
static struct pci_device_id agp_articias_pci_table[] = {
#define ID(x) \
{ \
.class = (PCI_CLASS_BRIDGE_HOST << 8), \
.class_mask = ~0, \
.vendor = PCI_VENDOR_ID_MAI, \
.device = x, \
.subvendor = PCI_ANY_ID, \
.subdevice = PCI_ANY_ID, \
}
ID(PCI_DEVICE_ID_MAI_ARTICIAS),
{ }
};
MODULE_DEVICE_TABLE(pci, agp_articias_pci_table);
static struct pci_driver agp_articias_pci_driver = {
.name = "agpgart-articias",
.id_table = agp_articias_pci_table,
.probe = agp_articias_probe,
.remove = agp_articias_remove,
#ifdef CONFIG_PM
.suspend = agp_articias_suspend,
.resume = agp_articias_resume,
#endif
};
static int __init agp_articias_init(void)
{
if (agp_off)
{
return -EINVAL;
}
return pci_register_driver(&agp_articias_pci_driver);
}
static void __exit agp_articias_cleanup(void)
{
pci_unregister_driver(&agp_articias_pci_driver);
}
module_init(agp_articias_init);
module_exit(agp_articias_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>");
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-15 21:48 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <19351.1137053713@www55.gmx.net>
> Please take a look at the end of my previous mail, where I included the
> debug messages of the driver and the driver code itself. The log shows that
> the physical address is mapped (IMHO) to the PCI memory range (>
> 0x0c0000000). Is this correct? Shouldn't it be mapped to the system memory
> address range?
I don't understand. I would need to now more about what the bridge
actually does to get any sense out of that.
> The aperture size is 4MB, page_order should be 1 and num_entries = 1024.
>
> Hope this helps!? :-)
>
> Thanks!
>
> Regards,
>
> Gerhard
>
> --
> DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
> GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
>
>
^ permalink raw reply
* Re: How to check which CPU we are using? PPC?
From: Wolfgang Denk @ 2006-01-15 17:19 UTC (permalink / raw)
To: jeanwelly; +Cc: Linuxppc-embedded
In-Reply-To: <43CA7AF1.11609B.03655>
In message <43CA7AF1.11609B.03655> you wrote:
> SG93IHRvIGNoZWNrIHdoaWNoIENQVSB3ZSBhcmUgdXNpbmc/IEFueSBtZXRob2RzPw0KDQoJDQpU
> aGFua3MhDQoNCqGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHkNCqGhoaGhoaGhoaGhoaGhoaFqZWFu
> d2VsbHlAMTI2LmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA2LTAxLTE1DQpfX19fX19fX19f
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eHBwYy1lbWJlZGRlZCBt
> YWlsaW5nIGxpc3QKTGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwpodHRwczovL296bGFicy5v
> cmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRlZA==
Please fix your mailer. Don't use base64 encsding. Post plain text,
please.
> How to check which CPU we are using? Any methods?
Check the print on the processor? Check the documentation? Check the
schematics?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Use C++ to confuse your enemies; use C to produce stable code.
^ permalink raw reply
* Re: [linux-usb-devel] Re: [2.6 patch] remove unused tmp_buf_sem's
From: Alan Cox @ 2006-01-15 15:46 UTC (permalink / raw)
To: Greg KH
Cc: akpm, Jes Sorensen, tony.luck, linux-ia64, linux-usb-devel,
linux-kernel, Adrian Bunk, linuxppc-dev, torvalds, R.E.Wolff
In-Reply-To: <20060114034903.GA23074@suse.de>
On Gwe, 2006-01-13 at 19:49 -0800, Greg KH wrote:
> On Sat, Jan 14, 2006 at 03:08:16AM +0100, Adrian Bunk wrote:
> > <-- snip -->
> >
> >
> > tmp_buf_sem sems to be a common name for something completely unused...
That would be correct. The old tty driver layer used to call ->write
from both kernel and user contexts according to a flag. Drivers then all
ended up with the same code copying it into a tmp buffer and using a
locking semaphore.
Linus took out that code and arranged that ->write always got a kernel
buffer so the remainders should indeed go.
Alan
^ permalink raw reply
* [PATCH] PPC32 CPM_UART: update to utilize the new TTY flip API
From: Vitaly Bordug @ 2006-01-15 15:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
This replaces old direct usage of tty->flip stuff with relative flip API
calls.
---
drivers/serial/cpm_uart/cpm_uart_core.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 16af562..5e25c2d 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -252,12 +252,9 @@ static void cpm_uart_int_rx(struct uart_
/* If we have not enough room in tty flip buffer, then we try
* later, which will be the next rx-interrupt or a timeout
*/
- if ((tty->flip.count + i) >= TTY_FLIPBUF_SIZE) {
- tty->flip.work.func((void *)tty);
- if ((tty->flip.count + i) >= TTY_FLIPBUF_SIZE) {
- printk(KERN_WARNING "TTY_DONT_FLIP set\n");
- return;
- }
+ if(tty_buffer_request_room(tty, i) < i) {
+ printk(KERN_WARNING "No room in flip buffer\n");
+ return;
}
/* get pointer */
@@ -276,9 +273,7 @@ static void cpm_uart_int_rx(struct uart_
continue;
error_return:
- *tty->flip.char_buf_ptr++ = ch;
- *tty->flip.flag_buf_ptr++ = flg;
- tty->flip.count++;
+ tty_insert_flip_char(tty, ch, flg);
} /* End while (i--) */
^ permalink raw reply related
* How to check which CPU we are using? PPC?
From: jeanwelly @ 2006-01-15 15:07 UTC (permalink / raw)
To: Linuxppc-embedded
SG93IHRvIGNoZWNrIHdoaWNoIENQVSB3ZSBhcmUgdXNpbmc/IEFueSBtZXRob2RzPw0KDQoJDQpU
aGFua3MhDQoNCqGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHkNCqGhoaGhoaGhoaGhoaGhoaFqZWFu
d2VsbHlAMTI2LmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA2LTAxLTE1DQo=
^ permalink raw reply
* Re: Download Eldk4.0
From: Wolfgang Denk @ 2006-01-15 14:39 UTC (permalink / raw)
To: Chinafeng; +Cc: Linuxppc-embedded
In-Reply-To: <43CA24BB.1EE448.29192>
In message <43CA24BB.1EE448.29192> you wrote:
> Why not download eldk4.0???
Because it's not released yet?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Business is like a wheelbarrow. Nothing ever happens until you start
pushing.
^ permalink raw reply
* Re: PPC440EP/Yosemite PCI misbehavior
From: Stefan Roese @ 2006-01-15 9:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43C88013.40800@ovro.caltech.edu>
Hi David,
On Saturday 14 January 2006 05:37, David Hawkins wrote:
> I'll go and play with the 440EP DMA controller and see if I can get
> that to burst to the PCI bus.
>
> > access to PCI I/O space causes a machine check exception.
>
> I still get this in 2.6.15, but Wolfgang Denx indicated that
> they'd tested PCI I/O pretty thoroughly, so I'm inclined to
> believe that its my driver that is at fault. I'll do a little
> more digging on that one.
I have to admit, that PCI I/O can't have worked until now on
Yosemite/Yellowstone. I just found a bug in
arch/ppc/platforms/4xx/yosemite.h:
-#define YOSEMITE_PCI_IO_BASE 0x00000000e0000000ULL
+#define YOSEMITE_PCI_IO_BASE 0x00000000e8000000ULL
Please give it a try and let me know if the problem is fixed.
Best regards,
Stefan
^ permalink raw reply
* Download Eldk4.0
From: Chinafeng @ 2006-01-15 9:48 UTC (permalink / raw)
To: Linuxppc-embedded
SGk6DQoNCiAgICAgICBXaHkgbm90IGRvd25sb2FkIGVsZGs0LjA/Pz8NCg0KICAgICAgIGZ0cCBo
YXMgc29tZSBlcnJvcnMgIHdoZW4gSSBkb3dubG9hZCBlbGRrNC4wICBieSBmdHAuLi4NCg0KICAg
ICAgIFNwZWVkIGlzIHZlcnkgdmVyeSAgc2xvdy4uLi4uDQoJDQogICAgICAgICAgICAgICAgICAg
ICBXSFk/DQqhoaGhoaGhoaGhoaGhoSAJCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaENCqGhoaGhoaGh
oaGhoaGhoaFjaGluYWZlbmcyMDA4QDE2My5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNi0w
MS0xNQ0K
^ permalink raw reply
* Re: Problems starting /sbin/init
From: David H. Lynch Jr. @ 2006-01-15 9:13 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A070E705B@CHN-SNR-MBX01.wipro.com>
srideep.devireddy@wipro.com wrote:
> Hello David ,
>
> I am bringing up Montavista Linux on mpc8272 custom board .But as we completed almost all the configurations and linux is booting well till the NFS or Ramdisk file system is mounted . then it hangs .. when i tried to debug i saw the /sbin/init in the init/main.c is not getting executed . i had printk and checked all the printks are executed but not the /sbin/init and the printks after the init is also executed .so this /sbin/init is not getting excecuting and i am not getting any messages .
>
> Thanks & Regards
> Srideep Reddy D
> Wipro Technologies
>
>
Srideep;
I was eventually able to resolve my problem. My serial console driver
was inadvertently using the physical address of the uart and not the
virtual address. When the TLB entry created in head_4xx.S for that
physical address eventually got overwritten - which coincidentally
occured after loading /init (or /bin/sh or ....) but prior to their
outputting anything.
It is possible but unlikely you are having a similar problem.
Regardless, you can isolate your problem further. You can sprinkle
prink's inside init/main.c to figure out exactly how far you are getting.
If you are actually getting to attempting to start /init, you can
change main.c to start the program of your choice instead of init.
I started with "Hello World" in ppc assmebler with no library dependencies.
You can enable SHOW_SYSCALLS and find out what system calls are
occuring immeditely prior to your system running off the rails.
And I am sure others may have even more and better ideas.
Dave
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL SOC library and setup code
From: Kumar Gala @ 2006-01-15 7:31 UTC (permalink / raw)
To: Olof Johansson; +Cc: Kumar Gala, linuxppc-embedded, linuxppc-dev
In-Reply-To: <20060115071533.GA932@pb15.lixom.net>
On Jan 15, 2006, at 1:15 AM, Olof Johansson wrote:
> On Sat, Jan 14, 2006 at 03:47:54PM -0800, Eugene Surovegin wrote:
>> On Sat, Jan 14, 2006 at 01:21:58PM -0600, Olof Johansson wrote:
>>>> +
>>>> +static phys_addr_t immrbase = -1;
>>>
>>> What does immr mean? Maybe a short comment would be good.
>>
>> IMHO, this is not needed because _everybody_ who is working
>> with these chips know what IMMR means. And there cannot be _any_
>> confusion about it. Let's not add useless comments.
>
> I haven't been exposed much yet to embedded 32-bit PPC, I thought at
> first that it was something chip-specific, not an architected feature
> common across the families. I agree, it doesn't really need further
> explanation in this case.
To be clear its a system level architecture feature on Freescale
SOCs. It goes by a few different names (immrbar, ccsrbar, eumbar),
but the purpose is the same.
- kumar
^ 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