* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: robert corley @ 2006-10-11 20:46 UTC (permalink / raw)
To: linuxppc-embedded
Ming;=0A=0AHere is what the EDK generates in this file:=0A=0AC:\EDK\project=
s\startup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\arch\ppc\platfo=
rms\xilinx_ocp\xparameters_ml300.h=0A=0A<snip>=0A#define XPAR_XTEMAC_NUM_IN=
STANCES 1=0A#define XPAR_PLB_TEMAC_0_BASEADDR 0x60000000=0A#define XPAR_PLB=
_TEMAC_0_HIGHADDR 0x60003FFF=0A#define XPAR_PLB_TEMAC_0_DEVICE_ID 0=0A#defi=
ne XPAR_PLB_TEMAC_0_IPIF_RDFIFO_DEPTH 131072=0A#define XPAR_PLB_TEMAC_0_IPI=
F_WRFIFO_DEPTH 131072=0A#define XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH 64=0A#defin=
e XPAR_PLB_TEMAC_0_DMA_TYPE 3=0A#define XPAR_PLB_TEMAC_0_TEMAC_DCR_HOST 0=
=0A#define XPAR_PLB_TEMAC_0_INCLUDE_DRE 1=0A<snip>=0A=0A=0AWhich is fine. =
However, the file in the linux distribution: linux_2_4_devel/drivers/net/xi=
linx_enet/adapter.c is looking for "XEMAC" instead of "XTEMAC" as above.=0A=
=0AAlso, when I look at the EDK project directory =0A=0A"C:\EDK\projects\st=
artup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\drivers\net\"=0A=0A=
I see that it is empty. Which means that nothing in the MVL tree will be o=
verwritten (specifically the adapter.c file, which uses the above defines).=
=0A=0ASo, it appears that the driver is not being properly insterted into t=
he tree as expected. Would you agree?=0A=0A-R=0A=0A
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Ming Liu @ 2006-10-11 20:24 UTC (permalink / raw)
To: rdcorle, linuxppc-embedded
In-Reply-To: <20061011161451.3292.qmail@web56312.mail.re3.yahoo.com>
Hi,
>So, right now I am trying to get the plb_temac to compile and get errors
about the defines XPAR_XTEMAC_* within the linux directories
../drivers/net/xilinx_enet. I see that the edk gets the defines within the
xparameters.h file of the xapp902 project. I also see that my
C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anything
for a plb_temac.
Yes. In MV3.1, there is no gige enet supported. You should include the
patch for TEMAC by yourself.
>Q: Is my error related to an incorrect setup of the linux or with the
EDK?
Try to check your xparameters.h file and find if there are the definations.
>Q: t is stated that the plb_temac drivers are in EDK 8.1. Can I stick
>with 7.1 or must I ugprade?
I don't think that's the problem of 7.1, if you can make sure you use a
correct core for TEMAC and generated correct BSP files.
>Q: Where in the linux tree should I look for the xtemac
>stuff? Is this what the EDK pushes on to the tree or is it released
>within the MVL distro?
Try to find the patch for TEMAC in this list.
>Q Based on posts by David and Ming, it
>appears that I must use xilinx_gige to get up to gigE speeds. Will the
>plb_temac support this data rate and, if so, is this a transparent
>support or do I need to go the route suggested to Ming and
>overwrite files in xilinx_enet?
Temac is tri-mode including 1000M/s speed. sorry that i cannot understand
this question very well.
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: [PATCH] powerpc: make MAL use the new DCR methods
From: Eugene Surovegin @ 2006-10-11 17:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160545539.6177.56.camel@localhost.localdomain>
On Wed, Oct 11, 2006 at 03:45:39PM +1000, Benjamin Herrenschmidt wrote:
> This is a test patch to validate the new DCR method code for the
> "native" case. It will ultimately be the first of a pile porting the
> EMAC driver to ARCH=powerpc and non-native DCRs.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h
> ===================================================================
> --- linux-cell.orig/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 13:01:59.000000000 +1000
> +++ linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 14:35:28.000000000 +1000
> @@ -24,6 +24,7 @@
> #include <linux/netdevice.h>
>
> #include <asm/io.h>
> +#include <asm/dcr.h>
>
> /*
> * These MAL "versions" probably aren't the real versions IBM uses for these
> @@ -191,6 +192,7 @@ struct mal_commac {
>
> struct ibm_ocp_mal {
> int dcrbase;
> + dcr_host_t dcrhost;
>
> struct list_head poll_list;
> struct net_device poll_dev;
> @@ -207,12 +209,12 @@ struct ibm_ocp_mal {
>
> static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
> {
> - return mfdcr(mal->dcrbase + reg);
> + return dcr_read(mal->dcrhost, mal->dcrbase + reg);
> }
>
> static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
> {
> - mtdcr(mal->dcrbase + reg, val);
> + dcr_write(mal->dcrhost, mal->dcrbase + reg, val);
> }
>
> /* Register MAL devices */
>
>
Looks fine to me.
Acked-by: Eugene Surovegin <ebs@ebshome.net>
^ permalink raw reply
* Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
From: James K Lewis @ 2006-10-11 16:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, jeff, netdev, linux-kernel, linuxppc-dev
In-Reply-To: <200610111802.43996.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]
Please don't be confused by the numbers in the 4M column, they don't
mean anything to the end user. We had a bit better performance (approx.
720 Mbps) at one time but at 100% CPU usage. These new patches lower the
max. to about 700 Mbps but decrease CPU usage down to about 30% which I
think will help all around. I have been testing this driver all night and
have not found a problem yet. Consider this my Acked-by: for all these
patches.
Jim Lewis
Advisory Software Engineer
IBM Linux Technology Center
512-838-7754
Arnd Bergmann <arnd@arndb.de>
10/11/2006 11:02 AM
To
Linas Vepstas <linas@austin.ibm.com>
cc
akpm@osdl.org, jeff@garzik.org, James K Lewis/Austin/IBM@ibmus,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org
Subject
Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
On Tuesday 10 October 2006 22:49, Linas Vepstas wrote:
> Andrew, please apply/forward upstream.
>
> The following set of 21 patches (!) are all aimed at the the
> spidernet ethernet device driver. The spidernet is an etherenet
> controller built into the Toshiba southbridge for the PowerPC Cell
> processor. (This is the only device in existance that with this
> ethernet hardware in it).
>
> These patches re-package/re-order/re-cleanup a previous
> set of patches I've previously mailed. Thus, some have
> been previously Acked-by lines, most do not. Most of
> these patches are tiny, and handle problems that cropped
> up during testing. Sorry about there being so many of them.
>
> The first set of 12 patches fix a large variety of mostly
> minor bugs.
>
> The important patches are 13 through 17: these overcome a
> debilitating performance problem on transmit (6 megabits
> per second !!) on transmit of patches 500 bytes or larger.
> After applying these, I am able to get the following:
>
> pkt sz speed (100K buffs) speed (4M buffs)
> ------ ----------------- ----------------
> 1500 700 Mbits/sec 951 Mbits/sec
> 1000 658 Mbits/sec 770
> 800 600 648
> 500 500 500
> 300 372 372
> 60 70 70
>
> Above buf size refers to /proc/sys/net/core/wmem_default
Excellent work! I guess this the best tx performance we've
seen so far on this hardware.
Consider this as an Acked-by: for all the patches, I'll save
the effort of replying to each one of them separately.
Jeff, do you plan on merging these fixes for 2.6.19?
Arnd <><
[-- Attachment #2: Type: text/html, Size: 4073 bytes --]
^ permalink raw reply
* PPChameleonEVB Newbie question
From: Adrian @ 2006-10-11 15:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi Folks.
I'm a newbie to embedded and am getting stuck.
I have a PPChameleonEVB board running a 405EP processor.
I have tried many things, and can now boot Linux 2.6.15 on the board using
an NFS share as both root fs and swap.
When I try to compile & install the kernel modules on the board, i get an
message about perl and then it errors.
So i'm trying to install perl. And failing.
Can someone tell me the following please, from a working setup (i.e. where
you can compile/install kernel 2.6.15 + modules) :-
1) Kernel version/Linux distroof the i386 PC used for the cross-compiling.
2) ELDK version and if there are any patches needed.
2) Perl version (or how to stop the Kernel build using perl)
I'm using Slack 8.1, kernel 2.4.18 and perl 5.6.1 on the cross-compiler pc.
Anything newer fell apart a lot earlier.
Many thanks in advance.
Adrian Atkins
IT Live Limited
tel: 0161 408 3327
fax: 08702 360 443
skype: adrianitlive
ES mob: (0034) 606806236
^ permalink raw reply
* plb_temac, ML403, linux 2.4.26, EDK 7.1
From: robert corley @ 2006-10-11 16:14 UTC (permalink / raw)
To: linuxppc-embedded
Some background:=0A ML403 devel board=0A EDK 7.1=0A compilation of=
reference design xapp902, modified to use linux and without loopback=0A =
use of linux_2_4_devel obtained from montavista via rsync=0A=0AI am trying=
to use the plb_temac rather than the ll_temac. In the long run, I'd prefe=
r to stick with linux 2.4. In addition, I will need to get both embedded E=
MAC's up and running, but first I just wanna get the xapp902 working. Also=
, I will need gigE support.=0A=0ASo, right now I am trying to get the plb_t=
emac to compile and get errors about the defines XPAR_XTEMAC_* within the l=
inux directories ../drivers/net/xilinx_enet. I see that the edk gets the d=
efines within the xparameters.h file of the xapp902 project. I also see th=
at my C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anyth=
ing for a plb_temac.=0A=0AQ: Is my error related to an incorrect setup o=
f the linux or with the EDK?=0A=0AQ: t is stated that the plb_temac driv=
ers are in EDK 8.1. Can I stick=0Awith 7.1 or must I ugprade?=0A=0AQ: W=
here in the linux tree should I look for the xtemac=0Astuff? Is this what =
the EDK pushes on to the tree or is it released=0Awithin the MVL distro?=0A=
=0AQ Based on posts by David and Ming, it=0Aappears that I must use xili=
nx_gige to get up to gigE speeds. Will the=0Aplb_temac support this data r=
ate and, if so, is this a transparent=0Asupport or do I need to go the rout=
e suggested to Ming and=0Aoverwrite files in xilinx_enet?=0A=0AR. Corley=0A=
=0A=0A=0A=0A
^ permalink raw reply
* Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
From: Arnd Bergmann @ 2006-10-11 16:02 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <20061010204946.GW4381@austin.ibm.com>
On Tuesday 10 October 2006 22:49, Linas Vepstas wrote:
> Andrew, please apply/forward upstream.
>=20
> The following set of 21 patches (!) are all aimed at the the=20
> spidernet ethernet device driver. The spidernet is an etherenet
> controller built into the Toshiba southbridge for the PowerPC Cell
> processor. (This is the only device in existance that with this
> ethernet hardware in it).
>=20
> These patches re-package/re-order/re-cleanup a previous
> set of patches I've previously mailed. Thus, some have
> been previously Acked-by lines, most do not. Most of
> these patches are tiny, and handle problems that cropped
> up during testing. Sorry about there being so many of them.
>=20
> The first set of 12 patches fix a large variety of mostly=20
> minor bugs.=20
>=20
> The important patches are 13 through 17: these overcome a=20
> debilitating performance problem on transmit (6 megabits
> per second !!) on transmit of patches 500 bytes or larger.
> After applying these, I am able to get the following:
>=20
> pkt sz =A0 speed (100K buffs) =A0 =A0 =A0 speed (4M buffs)
> ------ =A0 ----------------- =A0 =A0 =A0 =A0----------------
> 1500 =A0 =A0 700 Mbits/sec =A0 =A0 =A0 =A0 =A0 =A0951 Mbits/sec
> 1000 =A0 =A0 658 Mbits/sec =A0 =A0 =A0 =A0 =A0 =A0770
> 800 =A0 =A0 =A0600 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0648
> 500 =A0 =A0 =A0500 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0500
> 300 =A0 =A0 =A0372 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0372
> 60 =A0 =A0 =A0 =A070 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 70
>=20
> Above buf size refers to /proc/sys/net/core/wmem_default
Excellent work! I guess this the best tx performance we've
seen so far on this hardware.
Consider this as an Acked-by: for all the patches, I'll save
the effort of replying to each one of them separately.
Jeff, do you plan on merging these fixes for 2.6.19?
Arnd <><
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Geoff Levand @ 2006-10-11 15:47 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20061011152016.GU4381@austin.ibm.com>
Linas Vepstas wrote:
> On Tue, Oct 10, 2006 at 06:46:08PM -0700, Geoff Levand wrote:
>> > Linas Vepstas wrote:
>> >> The current driver code performs 512 DMA mappns of a bunch of
>> >> 32-byte structures. This is silly, as they are all in contiguous
>> >> memory. Ths patch changes the code to DMA map the entie area
>> >> with just one call.
>>
>> Linas,
>>
>> Is the motivation for this change to improve performance by reducing the overhead
>> of the mapping calls?
>
> Yes.
>
>> If so, there may be some benefit for some systems. Could
>> you please elaborate?
>
> I started writingthe patch thinking it will have some huge effect on
> performance, based on a false assumption on how i/o was done on this
> machine
>
> *If* this were another pSeries system, then each call to
> pci_map_single() chews up an actual hardware "translation
> control entry" (TCE) that maps pci bus addresses into
> system RAM addresses. These are somewhat limited resources,
> and so one shouldn't squander them. Furthermore, I thouhght
> TCE's have TLB's associated with them (similar to how virtual
> memory page tables are backed by hardware page TLB's), of which
> there are even less of. I was thinking that TLB thrashing would
> have a big hit on performance.
>
> Turns out that there was no difference to performance at all,
> and a quick look at "cell_map_single()" in arch/powerpc/platforms/cell
> made it clear why: there's no fancy i/o address mapping.
OK, thanks for the explanation. Actually, the current cell DMA mapping
implementation uses a simple 'linear' mapping, in that, all of RAM is
mapped into the bus DMA address space at once, and in fact, it is all
just done at system startup.
There is ongoing work to implement 'dynamic' mapping, where DMA pages are
mapped into the bus DMA address space on demand. I think a key point to
understand the benefit to this is that the cell processor's I/O controller
maps pages per device, so you can map one DMA page to one device. I
currently have this working for my platform, but have not released that
work. There is some overhead to managing the mapped buffers and to request
pages be mapped by the hypervisor, etc., so I was thinking that is this work
of yours to consolidate the memory buffers prior to requesting the mapping
could be of benefit if it was in an often executed code path.
-Geoff
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Linas Vepstas @ 2006-10-11 15:20 UTC (permalink / raw)
To: Geoff Levand
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <452C4CE0.5010607@am.sony.com>
On Tue, Oct 10, 2006 at 06:46:08PM -0700, Geoff Levand wrote:
> > Linas Vepstas wrote:
> >> The current driver code performs 512 DMA mappns of a bunch of
> >> 32-byte structures. This is silly, as they are all in contiguous
> >> memory. Ths patch changes the code to DMA map the entie area
> >> with just one call.
>
> Linas,
>
> Is the motivation for this change to improve performance by reducing the overhead
> of the mapping calls?
Yes.
> If so, there may be some benefit for some systems. Could
> you please elaborate?
I started writingthe patch thinking it will have some huge effect on
performance, based on a false assumption on how i/o was done on this
machine
*If* this were another pSeries system, then each call to
pci_map_single() chews up an actual hardware "translation
control entry" (TCE) that maps pci bus addresses into
system RAM addresses. These are somewhat limited resources,
and so one shouldn't squander them. Furthermore, I thouhght
TCE's have TLB's associated with them (similar to how virtual
memory page tables are backed by hardware page TLB's), of which
there are even less of. I was thinking that TLB thrashing would
have a big hit on performance.
Turns out that there was no difference to performance at all,
and a quick look at "cell_map_single()" in arch/powerpc/platforms/cell
made it clear why: there's no fancy i/o address mapping.
Thus, the patch has only mrginal benefit; I submit it only in the
name of "its the right thing to do anyway".
--linas
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: jf simon @ 2006-10-11 15:06 UTC (permalink / raw)
To: Michel �; +Cc: linuxppc-dev
In-Reply-To: <1160574593.23225.56.camel@thor.lorrainebruecke.local>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8; format=flowed, Size: 1079 bytes --]
>>I have ported the x86emu x86 emulator to IBM PIBS firmware on a Maple
>>platform. I am now trying to emulate a PCI ATI RADEON RV100 VGA BIOS.
>>It goes all the way and seems OK. When I boot Linux , the card is
>>recognized (it wasn't before),
>>
>>
>
>If the VGA BIOS POST works correctly, you should probably see some
>output in VGA text mode. Do you?
>
>
No can do. The Maple platform can't generate any PCI memory access below
0x8000.0000. So it can't access the VGA buffer. I have removed all
these accesses from being generated by the emulator. (all other acceses
to the card, including PCI I/O accesses to the VGA registers remain
though).
I am looking at the radeon driver. Maybe it is confused as it thinks it
is running on an OF based machine while at the same time locates a x86
VGA BIOS.
-jfs
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Demandez à ceux qui savent sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
^ permalink raw reply
* FYI: SM5xx toolchain project berliOS registration
From: Andrey Volkov @ 2006-10-11 14:36 UTC (permalink / raw)
To: bgat
Cc: linux-fbdev-devel, vince, ben-linux, linuxppc-embedded,
alexdeucher, gewang, syrjala
Hi all,
Yesterday I issued new SiliconMotion SM501 drivers
project request to berlios, and receive
approvement couple hours ago.
So project home page is:
http://developer.berlios.de/projects/sm5xx/
Anyone who wants admin/write-access, please register with
berlios and tell me your account.
SVN will be activated in nearest hours.
Berlios has direct shell access to your repos.
So if there are any svn/CVS-dumps to import or any
scripts to set up...
The central mailing list
sm5xx-devel@lists.berlios.de
will be active soon too.
--
Happy hacking ;),
Andrey Volkov
Varma Electronics Oy
-------- Original Message --------
Subject: BerliOS Developer Project Approved
Date: Wed, 11 Oct 2006 12:49:58 +0200 (CEST)
From: admin@berlios.de
To: avolkov@varma-el.com
Your project registration for BerliOS Developer has been approved.
Project Full Name: SM5xx Toolchain
Project Unix Name: sm5xx
CVS Server: cvs.berlios.de
SVN Server: svn.berlios.de
Shell Server: shell.berlios.de
Web Server: sm5xx.berlios.de
^ permalink raw reply
* Problems with DMA from user space on MPC834x (Cache coherency?)
From: Lauri Ehrenpreis @ 2006-10-11 14:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
^ permalink raw reply
* How to connect a CF to a MPC82xx in trueIDE mode with DMA/UDMA capability?
From: Miguel Valero (OS/EXA) @ 2006-10-11 14:07 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
Does anybody know whether it is possible to have a CF card directly
connected to a MPC82xx and have it working in trueIDE mode with either
multiword DMA or, preferibly, UDMA capabilities on?
We know how to have it connected and working in trueIDE mode, but
without DMA capabilities.
Is the MPC82xx DMA controller at all able to assist the CF in doing
multiword DMA or UDMA? How does one connect the DMA related CF pins to
the MPC82xx? How does one configure the UPM that controls the CF? Is
there a linux driver for MPC82xx that exploits the DMA/UDMA capabilities
of the CF?
Regards
Miguel A. Valero
R&D engineer
Ericsson AXXESSIT AS
[-- Attachment #2: Type: text/html, Size: 1326 bytes --]
^ permalink raw reply
* Problems with DMA from user space on MPC834x (Cache coherency?)
From: Lauri Ehrenpreis @ 2006-10-11 14:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: Michel Dänzer @ 2006-10-11 13:49 UTC (permalink / raw)
To: jean-francois simon; +Cc: linuxppc-dev
In-Reply-To: <20061010203620.771.qmail@web27502.mail.ukl.yahoo.com>
On Tue, 2006-10-10 at 22:36 +0200, jean-francois simon wrote:
> Hi,
> I have ported the x86emu x86 emulator to IBM PIBS firmware on a Maple
> platform. I am now trying to emulate a PCI ATI RADEON RV100 VGA BIOS.
> It goes all the way and seems OK. When I boot Linux , the card is
> recognized (it wasn't before),
If the VGA BIOS POST works correctly, you should probably see some
output in VGA text mode. Do you?
> but the screen just flickers a couple of time. I worry about the message:
> "radeonfb: Retrieved PLL infos from BIOS" since I don't have a BIOS.
It refers to the VGA BIOS.
> The PLL values may be bogus..
[...]
> radeonfb: Retrieved PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=150.00 Mhz,
> System=150.00 MHz
> radeonfb:
> PLL min 12000 max 35000
These look sane.
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type CRT found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
Is this correct?
> hStart = 1328, hEnd = 1440, hTotal = 1688
> vStart = 1025, vEnd = 1028, vTotal = 1066
Does the monitor support this mode?
> kobject_register failed for radeonfb (-17)
> Call Trace:
> [C000000000BFFB60] [C00000000000E97C] .show_stack+0x68/0x1b4
> (unreliable)
> [C000000000BFFC10] [C00000000017EC54] .kobject_register+0x5c/0x8c
> [C000000000BFFCA0] [C0000000001FAAF0] .bus_add_driver+0x7c/0x1b4
> [C000000000BFFD50] [C0000000001FBDC8] .driver_register+0xac/0xc8
> [C000000000BFFDD0] [C00000000018D084] .__pci_register_driver+0x8c/0xdc
> [C000000000BFFE60] [C0000000003CCC9C] .radeonfb_old_init+0x164/0x188
> [C000000000BFFF00] [C00000000000929C] .init+0x258/0x3d0
> [C000000000BFFF90] [C00000000001E848] .kernel_thread+0x4c/0x68
Could this be the problem?
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* help for sound support on PPC405EP
From: jagadeesh kali @ 2006-10-11 13:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 682 bytes --]
Hi,
I am working on AMCC PPC405EP Taihu board.
I created Linux kernel Image with kernel source 2.6.13(provided by AMCC) by
enabling inbuilt alsa-drivers(CA0106) for soundcard Creative Sound Blaster
Live 24bit! and I am using ELDK 4.0.
we have successfully installed alsa-libs and alsa-utils on the board using
ELDK 4.0 compilers.
The sound card is detecting properly when I type "aplay -l", but I am unable
to play audio file on the Taihu board.
I am getting some exceptions while playing audio files on the board.
The log file contains the errors.
Please let me know weather we have to made any kernel level configurations
for sound support?
Thanks and Regards,
Jagadeesh.
[-- Attachment #1.2: Type: text/html, Size: 762 bytes --]
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 5227 bytes --]
______________________________________________________________________________
With Sound Card (Creative Sound Blaster Live! 24 bit ) on the Taihu board
______________________________________________________________________________
bash-3.00# aplay
Aborted by signal Interrupt...
bash-3.00#
bash-3.00# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
bash-3.00#
bash-3.00# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
bash-3.00#
___________________________________________________________________________________________________
_____while playing audio files ____________________________________________________________________
bash-3.00# aplay audio1.wav
Playing WAVE 'audio1.wav' : Unsigned 8 bit, RateData machine check in kernel mode.
PLB0: BEAR= 0x3f107000 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: C0003730 LR: C00035BC SP: C73D3F40 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7785470[1290] 'aplay' THREAD: c73d2000
Last syscall: 3
GPR00: 00000000 C73D3F40 C7785470 00004000 00000001 00000000 C72E8978 00000000
GPR08: C778578C 00000004 00029032 C73D2000 22008028 100246D4 000002AA 00000000
GPR16: 10027BEC 00001000 00000000 00000000 00000000 00300C03 10027BF0 00080000
GPR24: 30038004 1001DB24 00000000 10036220 1001D7D0 00000000 0FFE7C58 FFFFE100
Call trace:
8000 Hz, Mono
Data machine check in kernel mode.
PLB0: BEAR= 0x3f107000 ACR= 0x00000000 BESR= 0x00800000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#2]
NIP: C0004958 LR: C0003510 SP: C02CCE30 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7785470[1290] 'aplay' THREAD: c73d2000
Last syscall: 3
GPR00: 08000000 C02CCE30 C7785470 C02CCE40 C02CF394 00000000 3B7F4486 3B7F4486
GPR08: C02CF398 C0003510 00021032 C0004958 07785638 100246D4 000002AA 00000000
GPR16: 10027BEC 00001000 00000000 00000000 00000000 00300C03 10027BF0 C7785554
GPR24: C7785520 C77854DC C02CCEF8 C0434B10 C77854DC 00000010 C7785470 C04462E0
Fixing recursive fault but reboot is needed!
Bus error
bash-3.00#
bash-3.00# arecord 1.wav
Recording WAVE '1.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
overrun!!! (at least 0.203 ms long)
Data machine check in kernel mode.
PLB0: BEAR= 0x3f117000 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#9]
NIP: C0003730 LR: C00035BC SP: C71F3F40 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7dde0b0[1296] 'arecord' THREAD: c71f2000
Last syscall: 167
GPR00: 00000000 C71F3F40 C7DDE0B0 00004000 00000001 00000000 C7226958 00000000
GPR08: C7DDE3CC 00000004 00029032 C71F2000 22048028 100246D4 3001E000 0FF6FA74
GPR16: 7FBDF4E0 0FF6F868 00000002 7FBDF500 00001008 7FBDF4B0 00000000 00000000
GPR24: 00000000 00000000 30028000 00000004 00000000 7FBDF4B0 0FFE79A8 7FBDF510
Call trace:
Bus error
bash-3.00#
__________________________________________________________________________________________________
___________________________________________________________________________________________________
____________________________________________________
Without Sound Card on the Taihu board
____________________________________________________
bash-3.00# aplay
ALSA lib confmisc.c:560:(snd_determine_driver) could not open control for card 0
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_concat returned error: No such device
ALSA lib confmisc.c:955:(snd_func_refer) error evaluating name
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such device
ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such device
ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM default
aplay: main:533: audio open error: No such device
bash-3.00#
bash-3.00# aplay -l
aplay: device_list:218: no soundcards found...
bash-3.00#
bash-3.00# arecord -l
arecord: device_list:218: no soundcards found...
bash-3.00#
^ permalink raw reply
* [PATCH] Add Makefile entry for MPC832x_mds support
From: Li Yang @ 2006-10-11 11:27 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
Add missing entry in Makefile for MPC832x MDS support. It
also change white space to tab in MPC8360 entry.
Signed-off-by: Li Yang <leoli@freescale.com>
---
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index e60fd75..f1aa7e2 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -5,4 +5,5 @@ obj-y := misc.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o
obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
-obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
+obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
+obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
^ permalink raw reply related
* [PATCH] Fix MPC8360EMDS PB board support
From: Li Yang @ 2006-10-11 11:04 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
MPC8360EMDS PB support is broken as some code was missing
in last submission. This patch adds missing code and makes
MPC8360EMDS PB support working.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
As Kim's patch to add Kconfig file hasn't been merged, I
include the fix in this patch.
arch/powerpc/platforms/83xx/Kconfig | 13 +++++++++++++
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/mpc8360e_pb.c | 19 +++++++++++++++++++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 0975e94..7edb6b4 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -32,6 +32,13 @@ config MPC834x_ITX
Be aware that PCI initialization is the bootloader's
responsiblilty.
+config MPC8360E_PB
+ bool "Freescale MPC8360E PB"
+ select DEFAULT_UIMAGE
+ select QUICC_ENGINE
+ help
+ This option enables support for the MPC836x EMDS Processor Board.
+
endchoice
config PPC_MPC832x
@@ -46,4 +53,10 @@ config MPC834x
select PPC_INDIRECT_PCI
default y if MPC834x_SYS || MPC834x_ITX
+config PPC_MPC836x
+ bool
+ select PPC_UDBG_16550
+ select PPC_INDIRECT_PCI
+ default y if MPC8360E_PB
+
endmenu
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 9387a11..e60fd75 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -5,3 +5,4 @@ obj-y := misc.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o
obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
+obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
index c019190..1a523c8 100644
--- a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
@@ -30,6 +30,7 @@ #include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
+#include <asm/of_device.h>
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/time.h>
@@ -141,6 +142,24 @@ #else
#endif
}
+static int __init mpc8360_declare_of_platform_devices(void)
+{
+ struct device_node *np;
+
+ for (np = NULL; (np = of_find_compatible_node(np, "network",
+ "ucc_geth")) != NULL;) {
+ int ucc_num;
+ char bus_id[BUS_ID_SIZE];
+
+ ucc_num = *((uint *) get_property(np, "device-id", NULL)) - 1;
+ snprintf(bus_id, BUS_ID_SIZE, "ucc_geth.%u", ucc_num);
+ of_platform_device_create(np, bus_id, NULL);
+ }
+
+ return 0;
+}
+device_initcall(mpc8360_declare_of_platform_devices);
+
void __init mpc8360_sys_init_IRQ(void)
{
^ permalink raw reply related
* Re: USB Disk Support...FIXED
From: Jeff Stevens @ 2006-10-11 10:54 UTC (permalink / raw)
To: linuxppc-embedded
For those interested, I figured out the issue. It was an incorrect PCIX PI=
M setting. Even though the comment on the PIM windows that are setup in lu=
an.c (the board specific platform file in the kernel) says 2GB window, the =
actual register setting is only for a 512MB window. I happend to have 1GB =
of memory in my system, and it must have been allocating an address above t=
he 512MB. In the Luan board, I only had 512MB, so that is why it worked th=
ere.=0A=0AMaybe in the next kernel release, the comment should be fixed to =
match the register setting.=0A=0A-Jeff Stevens=0A=0A----- Original Message =
----=0AFrom: Jeff Stevens <jsteve17@yahoo.com>=0ATo: Jeff Stevens <jsteve17=
@yahoo.com>; linuxppc-embedded@ozlabs.org=0ASent: Sunday, October 8, 2006 1=
2:26:17 PM=0ASubject: Re: USB Disk Support=0A=0AI have more information. I=
am using a Phillips=0AISP1562 USB host controller. I ran the same kernel=
=0Aconfig on the actual Luan board (with an ISP1563 PCI=0Aeval board from P=
hillips), and the USB storage works=0Afine. I compared the dmesg from both=
the Luan board=0Aand our 440SP custom system, and here are the=0Adifferenc=
es:=0A=0AThe custom system stops at:=0A...=0Ausb-storage: Command READ_CAPA=
CITY (10 bytes)=0Ausb-storage: 25 00 00 00 00 00 00 00 00 00=0Ausb-storage=
: Bulk Command S 0x43425355 T 0x3 L 8 F 128=0ATrg 0 LUN 0 CL 10=0Ausb-stora=
ge: usb_stor_bulk_transfer_buf: xfer 31 bytes=0Ausb-storage: Status code 0;=
transferred 31/31=0Ausb-storage: -- transfer complete=0Ausb-storage: Bulk =
command transfer result=3D0=0Ausb-storage: usb_stor_bulk_transfer_sglist: x=
fer 8=0Abytes, 1 entries=0Ausb-storage: Status code 0; transferred 8/8=0Aus=
b-storage: -- transfer complete=0Ausb-storage: Bulk data transfer result 0x=
0=0Ausb-storage: Attempting to get CSW...=0Ausb-storage: usb_stor_bulk_tran=
sfer_buf: xfer 13 bytes=0Ausb-storage: command_abort called=0Ausb-storage: =
usb_stor_stop_transport called=0Ausb-storage: -- cancelling URB=0A=0AIt see=
ms to fail on Attempting to get CSW... On the=0ALuan board it gets passed =
this:=0A=0Ausb-storage: Command READ_CAPACITY (10 bytes)=0Ausb-storage: 25=
00 00 00 00 00 00 00 00 00=0Ausb-storage: Bulk Command S 0x43425355 T 0x3 =
L 8 F 128=0ATrg 0 LUN 0 CL 10=0Ausb-storage: usb_stor_bulk_transfer_buf: xf=
er 31 bytes=0Ausb-storage: Status code 0; transferred 31/31=0Ausb-storage: =
-- transfer complete=0Ausb-storage: Bulk command transfer result=3D0=0Ausb-=
storage: usb_stor_bulk_transfer_sglist: xfer 8=0Abytes, 1 entries=0Ausb-sto=
rage: Status code 0; transferred 8/8=0Ausb-storage: -- transfer complete=0A=
usb-storage: Bulk data transfer result 0x0=0Ausb-storage: Attempting to get=
CSW...=0Ausb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes=0Ausb-stor=
age: Status code 0; transferred 13/13=0Ausb-storage: -- transfer complete=
=0Ausb-storage: Bulk status result =3D 0=0Ausb-storage: Bulk Status S 0x534=
25355 T 0x3 R 0 Stat=0A0x0=0Ausb-storage: scsi cmd done, result=3D0x0=0Ausb=
-storage: *** thread sleeping.=0Ausb-storage: queuecommand called=0Ausb-sto=
rage: *** thread awakened.=0Ausb-storage: Command MODE_SENSE (6 bytes)=0Aus=
b-storage: 1a 00 3f 00 c0 00=0Ausb-storage: Bulk Command S 0x43425355 T 0x=
4 L 192 F=0A128 Trg 0 LUN 0 CL 6=0Ausb-storage: usb_stor_bulk_transfer_buf:=
xfer 31 bytes=0Ausb-storage: Status code 0; transferred 31/31=0A... <conti=
nues>=0A=0ACould this be a noisy usb port? The USB controller=0Aused is th=
e same, the only difference is that on the=0Acustom board, the USB controll=
er is onboard, where as=0Aon the Luan board it is a PCI card. U-boot is al=
so=0Ausing practically the same board specific config file=0Aand board file=
, other than the flash and DDR stuff. =0AOn the custom board, the card read=
er never ends up in=0A/proc/scsi/scsi, but it does on the luan board.=0A=0A=
Thanks,=0A Jeff Stevens=0A=0A=0A--- Jeff Stevens <jsteve17@yahoo.com> wro=
te:=0A=0A> I am having issues getting a uDiskOnChip to mount or=0A> fdisk u=
nder linux. I have a board running U-Boot on=0A> a=0A> AMCC 440SP platform=
. Linux seems to find the=0A> uDiskOnChip fine, however, when I try to fdi=
sk or=0A> mount the device, the console hangs. I have added=0A> SCSI, SCSI=
storage, USB, USB OHCI, USB EHCI, USB=0A> Mass=0A> Storage. Here is my dm=
esg:=0A> =0A> bash-3.00# dmesg | grep -i usb=0A> usbcore: registered new dr=
iver usbfs=0A> usbcore: registered new driver hub=0A> usbmon: debugfs is no=
t available=0A> drivers/usb/core/inode.c: creating file 'devices'=0A> drive=
rs/usb/core/inode.c: creating file '001'=0A> ehci_hcd 0002:02:08.2: new USB=
bus registered,=0A> assigned bus number 1=0A> ehci_hcd 0002:02:08.2: suppo=
rts USB remote wakeup=0A> ehci_hcd 0002:02:08.2: USB 2.0 started, EHCI 0.95=
,=0A> driver 10 Dec 2004=0A> usb usb1: default language 0x0409=0A> usb usb1=
: new device strings: Mfr=3D3, Product=3D2,=0A> SerialNumber=3D1=0A> usb us=
b1: Product: EHCI Host Controller=0A> usb usb1: Manufacturer: Linux 2.6.17.=
9 ehci_hcd=0A> usb usb1: SerialNumber: 0002:02:08.2=0A> usb usb1: configura=
tion #1 chosen from 1 choice=0A> usb usb1: adding 1-0:1.0 (config #1, inter=
face 0)=0A> hub 1-0:1.0: usb_probe_interface=0A> hub 1-0:1.0: usb_probe_int=
erface - got id=0A> hub 1-0:1.0: USB hub found=0A> drivers/usb/core/inode.c=
: creating file '001'=0A> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host=0A> C=
ontroller=0A> (OHCI) Driver (PCI)=0A> drivers/usb/core/inode.c: creating fi=
le '002'=0A> ohci_hcd 0002:02:08.0: new USB bus registered,=0A> assigned bu=
s number 2=0A> usb usb2: default language 0x0409=0A> usb usb2: new device s=
trings: Mfr=3D3, Product=3D2,=0A> SerialNumber=3D1=0A> usb usb2: Product: O=
HCI Host Controller=0A> usb usb2: Manufacturer: Linux 2.6.17.9 ohci_hcd=0A>=
usb usb2: SerialNumber: 0002:02:08.0=0A> usb usb2: configuration #1 chosen=
from 1 choice=0A> usb usb2: adding 2-0:1.0 (config #1, interface 0)=0A> hu=
b 2-0:1.0: usb_probe_interface=0A> hub 2-0:1.0: usb_probe_interface - got i=
d=0A> hub 2-0:1.0: USB hub found=0A> hub 2-0:1.0: no power switching (usb 1=
.0)=0A> usb 1-1: new high speed USB device using ehci_hcd=0A> and=0A> addre=
ss 2=0A> usb 1-1: default language 0x0409=0A> usb 1-1: new device strings: =
Mfr=3D1, Product=3D2,=0A> SerialNumber=3D3=0A> usb 1-1: Product: uDiskOnChi=
p=0A> usb 1-1: Manufacturer: M-Systems=0A> usb 1-1: SerialNumber: 98B0FB510=
031E86E=0A> usb 1-1: configuration #1 chosen from 1 choice=0A> drivers/usb/=
core/inode.c: creating file '001'=0A> drivers/usb/core/inode.c: creating fi=
le '003'=0A> ohci_hcd 0002:02:08.1: new USB bus registered,=0A> assigned bu=
s number 3=0A> usb 1-1: adding 1-1:1.0 (config #1, interface 0)=0A> drivers=
/usb/core/inode.c: creating file '002'=0A> usb usb3: default language 0x040=
9=0A> usb usb3: new device strings: Mfr=3D3, Product=3D2,=0A> SerialNumber=
=3D1=0A> usb usb3: Product: OHCI Host Controller=0A> usb usb3: Manufacturer=
: Linux 2.6.17.9 ohci_hcd=0A> usb usb3: SerialNumber: 0002:02:08.1=0A> usb =
usb3: configuration #1 chosen from 1 choice=0A> usb usb3: adding 3-0:1.0 (c=
onfig #1, interface 0)=0A> hub 3-0:1.0: usb_probe_interface=0A> hub 3-0:1.0=
: usb_probe_interface - got id=0A> hub 3-0:1.0: USB hub found=0A> hub 3-0:1=
.0: no power switching (usb 1.0)=0A> drivers/usb/core/inode.c: creating fil=
e '001'=0A> Initializing USB Mass Storage driver...=0A> usb-storage 1-1:1.0=
: usb_probe_interface=0A> usb-storage 1-1:1.0: usb_probe_interface - got id=
=0A> usb-storage: USB Mass Storage device detected=0A> usb-storage: -- asso=
ciate_dev=0A> usb-storage: Vendor: 0x08ec, Product: 0x1000,=0A> Revision: 0=
x0200=0A> usb-storage: Interface Subclass: 0x06, Protocol:=0A> 0x50=0A> usb=
-storage: Transport: Bulk=0A> usb-storage: Protocol: Transparent SCSI=0A> s=
csi0 : SCSI emulation for USB Mass Storage devices=0A> usb-storage: *** thr=
ead sleeping.=0A> usbcore: registered new driver usb-storage=0A> USB Mass S=
torage support registered.=0A> usb-storage: device found at 2=0A> usb-stora=
ge: waiting for device to settle before=0A> scanning=0A> usb-storage: usb_s=
tor_control_msg: rq=3Dfe rqtype=3Da1=0A> value=3D0000 index=3D00 len=3D1=0A=
> usb-storage: GetMaxLUN command result is 1, data is=0A> 0=0A> usb-storage=
: queuecommand called=0A> usb-storage: *** thread awakened.=0A> usb-storage=
: Command INQUIRY (6 bytes)=0A> usb-storage: 12 00 00 00 24 00=0A> usb-sto=
rage: Bulk Command S 0x43425355 T 0x1 L 36 F=0A> 128 Trg 0 LUN 0 CL 6=0A> u=
sb-storage: usb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-storage: =
Status code 0; transferred 31/31=0A> usb-storage: -- transfer complete=0A> =
usb-storage: Bulk command transfer result=3D0=0A> usb-storage: usb_stor_bul=
k_transfer_sglist: xfer 36=0A> bytes, 1 entries=0A> usb-storage: Status cod=
e 0; transferred 36/36=0A> usb-storage: -- transfer complete=0A> usb-storag=
e: Bulk data transfer result 0x0=0A> usb-storage: Attempting to get CSW...=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 13/13=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk status result =3D 0=0A> usb-storage: Bulk Status S =
0x53425355 T 0x1 R 0 Stat=0A> 0x0=0A> usb-storage: scsi cmd done, result=3D=
0x0=0A> usb-storage: *** thread sleeping.=0A> usb-storage: queuecommand cal=
led=0A> usb-storage: *** thread awakened.=0A> usb-storage: Command TEST_UNI=
T_READY (6 bytes)=0A> usb-storage: 00 00 00 00 00 00=0A> usb-storage: Bulk=
Command S 0x43425355 T 0x2 L 0 F 0=0A> Trg 0 LUN 0 CL 6=0A> usb-storage: u=
sb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-storage: Status code 0=
; transferred 31/31=0A> usb-storage: -- transfer complete=0A> usb-storage: =
Bulk command transfer result=3D0=0A> usb-storage: Attempting to get CSW...=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 13/13=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk status result =3D 0=0A> usb-storage: Bulk Status S =
0x53425355 T 0x2 R 0 Stat=0A> 0x0=0A> usb-storage: scsi cmd done, result=3D=
0x0=0A> usb-storage: *** thread sleeping.=0A> usb-storage: queuecommand cal=
led=0A> usb-storage: *** thread awakened.=0A> usb-storage: Command READ_CAP=
ACITY (10 bytes)=0A> usb-storage: 25 00 00 00 00 00 00 00 00 00=0A> usb-st=
orage: Bulk Command S 0x43425355 T 0x3 L 8 F=0A> 128=0A> Trg 0 LUN 0 CL 10=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 31/31=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk command transfer result=3D0=0A> usb-storage: usb_st=
or_bulk_transfer_sglist: xfer 8=0A> bytes, 1 entries=0A> usb-storage: Statu=
s code 0; transferred 8/8=0A> usb-storage: -- transfer complete=0A> usb-sto=
rage: Bulk data transfer result 0x0=0A> usb-storage: Attempting to get CSW.=
..=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-s=
torage: command_abort called=0A> usb-storage: usb_stor_stop_transport calle=
d=0A> usb-storage: -- cancelling URB=0A> =0A> =0A>=0A----------------------=
---------------------------------=0A> And a few other things:=0A> =0A> bash=
-3.00# cat /proc/bus/usb/devices=0A> =0A> T: Bus=3D03 Lev=3D00 Prnt=3D00 P=
ort=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D12 MxCh=3D 1=0A> B: Alloc=3D 0/90=
0 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 1.10 Cls=3D09(hub ) Sub=
=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D0000 ProdID=3D00=
00 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ohci_hcd=0A> S: Produ=
ct=3DOHCI Host Controller=0A> S: SerialNumber=3D0002:02:08.1=0A> C:* #Ifs=
=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=3D 0 #EPs=3D 1 =
Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A> E: Ad=3D81(I) =
Atr=3D03(Int.) MxPS=3D 2 Ivl=3D255ms=0A> =0A> T: Bus=3D02 Lev=3D00 Prnt=
=3D00 Port=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D12 MxCh=3D 1=0A> B: Alloc=
=3D 0/900 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 1.10 Cls=3D09(hu=
b ) Sub=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D0000 Pro=
dID=3D0000 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ohci_hcd=0A> S=
: Product=3DOHCI Host Controller=0A> S: SerialNumber=3D0002:02:08.0=0A> C=
:* #Ifs=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=3D 0 #EP=
s=3D 1 Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A> E: Ad=
=3D81(I) Atr=3D03(Int.) MxPS=3D 2 Ivl=3D255ms=0A> =0A> T: Bus=3D01 Lev=
=3D00 Prnt=3D00 Port=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D480 MxCh=3D 2=0A> B=
: Alloc=3D 0/800 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 2.00 Cls=
=3D09(hub ) Sub=3D00 Prot=3D01 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D=
0000 ProdID=3D0000 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ehci_h=
cd=0A> S: Product=3DEHCI Host Controller=0A> S: SerialNumber=3D0002:02:08=
.2=0A> C:* #Ifs=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=
=3D 0 #EPs=3D 1 Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A>=
E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 2 Ivl=3D256ms=0A> =0A> T: Bus=3D0=
1 Lev=3D01 Prnt=3D01 Port=3D00 Cnt=3D01 Dev#=3D 2=0A> Spd=3D480 MxCh=3D 0=
=0A> D: Ver=3D 2.00 Cls=3D00(>ifc ) Sub=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=
=3D 1=0A> P: Vendor=3D08ec ProdID=3D1000 Rev=3D 2.00=0A> S: Manufacturer=
=3DM-Systems=0A> S: Product=3DuDiskOnChip=0A> S: SerialNumber=3D98B0FB510=
031E86E=0A> C:* #Ifs=3D 1 Cfg#=3D 1 Atr=3D80 MxPwr=3D140mA=0A> I: If#=3D 0=
Alt=3D 0 #EPs=3D 2 Cls=3D08(stor.) Sub=3D06=0A> Prot=3D50=0A> Driver=3Dusb=
-storage=0A> E: Ad=3D81(I) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms=0A> E: Ad=
=3D02(O) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms=0A> =0A> bash-3.00# cat /proc=
/scsi/scsi=0A> Attached devices:=0A> =0A> =0A> It's probably just a kernel =
config issue, but I'm=0A> not=0A> sure what else to try. I would appreciat=
e any=0A> input!=0A> =0A> Thanks,=0A> Jeff=0A> =0A> ____________________=
______________________________=0A> Do You Yahoo!?=0A> Tired of spam? Yahoo=
! Mail has the best spam=0A> protection around =0A> http://mail.yahoo.com =
=0A> _______________________________________________=0A> Linuxppc-embedded =
mailing list=0A> Linuxppc-embedded@ozlabs.org=0A>=0Ahttps://ozlabs.org/mail=
man/listinfo/linuxppc-embedded=0A> =0A=0A=0A_______________________________=
___________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the =
best spam protection around =0Ahttp://mail.yahoo.com =0A=0A=0A=0A=0A
^ permalink raw reply
* Re: I2C Driver for mpc8272
From: Roman Fietze @ 2006-10-11 9:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BE8B3EECA608414FB163FBA4576FCEBD88BAAF@EXNY.us.corp.aacisd.com>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
Hello Dwayne,
On Tuesday 10 October 2006 22:44, Folden Dwayne wrote:
> Please disregard the last notice, I was informed by my superiors
> that I cannot give this code out.
Then you shouldn't either build a monolithic kernel containing this
code or give your customers access to this code in case it's build
upon any existing GPL'ed code. I hope your superiors know the GPL as
mine do it for a few months now. :)
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Arnd Bergmann @ 2006-10-11 9:25 UTC (permalink / raw)
To: Geoff Levand
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <452C4CE0.5010607@am.sony.com>
On Wednesday 11 October 2006 03:46, Geoff Levand wrote:
> >=20
> > The others look good, but this one complicates the code and doesn't hav=
e any benefit. =C2=A020=20
> > for 21 isn't bad.
>=20
> Is the motivation for this change to improve performance by reducing the =
overhead
> of the mapping calls? =C2=A0If so, there may be some benefit for some sys=
tems. =C2=A0Could
> you please elaborate?
>=20
=46rom what I understand, this patch drastically reduces the number of
I/O PTEs that are needed in the iommu. With the current static IOMMU
mapping, it should only make a difference during initialization, but
any platform that uses a dynamic mapping of iommu entries will benefit
a lot from it, because:
=2D the card can do better prefetching of consecutive memory
=2D there are more I/O ptes available for other drivers.
Arnd <><
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Benjamin Herrenschmidt @ 2006-10-11 7:15 UTC (permalink / raw)
To: jschopp
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <452C2AAA.5070001@austin.ibm.com>
On Tue, 2006-10-10 at 18:20 -0500, jschopp wrote:
> Linas Vepstas wrote:
> > The current driver code performs 512 DMA mappns of a bunch of
> > 32-byte structures. This is silly, as they are all in contiguous
> > memory. Ths patch changes the code to DMA map the entie area
> > with just one call.
> >
> > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> > Cc: James K Lewis <jklewis@us.ibm.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
>
> The others look good, but this one complicates the code and doesn't have any benefit. 20
> for 21 isn't bad.
Hi Joel !
I'm not sure what you mean here.... (especially your 20 to 21 comment).
The patch looks perfectly fine to me, and in fact removes more lines of
code than it adds :)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] ppc: Add missing calls set_irq_regs
From: Kumar Gala @ 2006-10-11 7:06 UTC (permalink / raw)
To: Linus Torvalds, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In the timer_interrupt we were not calling set_irq_regs() and if we are
profiling we will end up calling get_irq_regs(). This causes bad things to
happen.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 6799b47da9c145fba3a855f74e20680acffe87a7
tree 30ed136bbebf14a71c5b0eeed76510ef884aee76
parent 53a5fbdc2dff55161a206ed1a1385a8fa8055c34
author Kumar Gala <galak@kernel.crashing.org> Wed, 11 Oct 2006 01:57:04 -0500
committer Kumar Gala <galak@kernel.crashing.org> Wed, 11 Oct 2006 01:57:04 -0500
arch/ppc/kernel/time.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
index d4b2cf7..18ee851 100644
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -62,6 +62,7 @@ #include <asm/nvram.h>
#include <asm/cache.h>
#include <asm/8xx_immap.h>
#include <asm/machdep.h>
+#include <asm/irq_regs.h>
#include <asm/time.h>
@@ -129,6 +130,7 @@ void wakeup_decrementer(void)
*/
void timer_interrupt(struct pt_regs * regs)
{
+ struct pt_regs *old_regs;
int next_dec;
unsigned long cpu = smp_processor_id();
unsigned jiffy_stamp = last_jiffy_stamp(cpu);
@@ -137,6 +139,7 @@ void timer_interrupt(struct pt_regs * re
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
+ old_regs = set_irq_regs(regs);
irq_enter();
while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) <= 0) {
@@ -188,6 +191,7 @@ void timer_interrupt(struct pt_regs * re
ppc_md.heartbeat();
irq_exit();
+ set_irq_regs(old_regs);
}
/*
^ permalink raw reply related
* [PATCH] powerpc: make MAL use the new DCR methods
From: Benjamin Herrenschmidt @ 2006-10-11 5:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev list
This is a test patch to validate the new DCR method code for the
"native" case. It will ultimately be the first of a pile porting the
EMAC driver to ARCH=powerpc and non-native DCRs.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h
===================================================================
--- linux-cell.orig/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 13:01:59.000000000 +1000
+++ linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 14:35:28.000000000 +1000
@@ -24,6 +24,7 @@
#include <linux/netdevice.h>
#include <asm/io.h>
+#include <asm/dcr.h>
/*
* These MAL "versions" probably aren't the real versions IBM uses for these
@@ -191,6 +192,7 @@ struct mal_commac {
struct ibm_ocp_mal {
int dcrbase;
+ dcr_host_t dcrhost;
struct list_head poll_list;
struct net_device poll_dev;
@@ -207,12 +209,12 @@ struct ibm_ocp_mal {
static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
{
- return mfdcr(mal->dcrbase + reg);
+ return dcr_read(mal->dcrhost, mal->dcrbase + reg);
}
static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
{
- mtdcr(mal->dcrbase + reg, val);
+ dcr_write(mal->dcrhost, mal->dcrbase + reg, val);
}
/* Register MAL devices */
^ permalink raw reply
* [PATCH] powerpc: New DCR access methods
From: Benjamin Herrenschmidt @ 2006-10-11 5:42 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cbe-oss-dev@ozlabs.org, Arnd Bergmann
Ѕubject: powerpc: generic DCR access
This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that
can be used by drivers to transparently address either native DCRs or
memory mapped DCRs. The implementation for memory mapped DCRs is done
after the binding being currently worked on for SLOF and the Axon
chipset. This patch enables it for the cell native platform
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Arnd: This will replace powerpc-generic-dcr.diff, though don't put it in
your tree just yet. I'll have other axon related patches including a new
one porting emac over and a new infrastructure for probing OF devices
in the upcoming few days. I'm posting this one early to get comments from
4xx folks.
Eugene: As you can see, the overhead for 4xx is nil. I have a patch hacking
the MAL driver to use those instead of mfdcr/mtdcr. I did it to quicky test
I didn't do anything stupid and it still builds with an ebony_defconfig with
ARCH=ppc. I'll send it separately.
Index: linux-cell/include/asm-powerpc/dcr.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-cell/include/asm-powerpc/dcr.h 2006-10-11 15:28:41.000000000 +1000
@@ -0,0 +1,40 @@
+/*
+ * (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_H
+#define _ASM_POWERPC_DCR_H
+#ifdef __KERNEL__
+
+#ifdef CONFIG_PPC_DCR_NATIVE
+#include <asm/dcr-native.h>
+#else
+#include <asm/dcr-mmio.h>
+#endif
+
+/*
+ * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
+ * base from the device-tree
+ */
+#ifdef CONFIG_PPC_MERGE
+extern int dcr_resource_start(struct device_node *np, unsigned int index);
+extern int dcr_resource_len(struct device_node *np, unsigned int index);
+#endif /* CONFIG_PPC_MERGE */
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_DCR_H */
Index: linux-cell/arch/powerpc/Kconfig
===================================================================
--- linux-cell.orig/arch/powerpc/Kconfig 2006-10-11 15:27:03.000000000 +1000
+++ linux-cell/arch/powerpc/Kconfig 2006-10-11 15:29:31.000000000 +1000
@@ -160,9 +160,11 @@ config PPC_86xx
config 40x
bool "AMCC 40x"
+ select PPC_DCR_NATIVE
config 44x
bool "AMCC 44x"
+ select PPC_DCR_NATIVE
config 8xx
bool "Freescale 8xx"
@@ -208,6 +210,19 @@ config PPC_FPU
bool
default y if PPC64
+config PPC_DCR_NATIVE
+ bool
+ default n
+
+config PPC_DCR_MMIO
+ bool
+ default n
+
+config PPC_DCR
+ bool
+ depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
+ default y
+
config BOOKE
bool
depends on E200 || E500
@@ -445,6 +460,7 @@ config PPC_CELL
config PPC_CELL_NATIVE
bool
select PPC_CELL
+ select PPC_DCR_MMIO
default n
config PPC_IBM_CELL_BLADE
Index: linux-cell/include/asm-powerpc/dcr-mmio.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-cell/include/asm-powerpc/dcr-mmio.h 2006-10-11 15:34:02.000000000 +1000
@@ -0,0 +1,51 @@
+/*
+ * (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_MMIO_H
+#define _ASM_POWERPC_DCR_MMIO_H
+#ifdef __KERNEL__
+
+#include <asm/io.h>
+
+typedef struct { void __iomem *token; unsigned int stride; } dcr_host_t;
+
+#define DCR_MAP_OK(host) ((host).token != NULL)
+
+extern dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
+ unsigned int dcr_c);
+extern void dcr_unmap(dcr_host_t host, unsigned int dcr_n, unsigned int dcr_c);
+
+static inline u32 dcr_read(dcr_host_t host, unsigned int dcr_n)
+{
+ return in_be32(host.token + dcr_n * host.stride);
+}
+
+static inline void dcr_write(dcr_host_t host, unsigned int dcr_n, u32 value)
+{
+ out_be32(host.token + dcr_n * host.stride, value);
+}
+
+extern u64 of_translate_dcr_address(struct device_node *dev,
+ unsigned int dcr_n,
+ unsigned int *stride);
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_DCR_MMIO_H */
+
+
Index: linux-cell/include/asm-powerpc/dcr-native.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-cell/include/asm-powerpc/dcr-native.h 2006-10-11 15:28:41.000000000 +1000
@@ -0,0 +1,39 @@
+/*
+ * (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__
+
+#include <asm/reg.h>
+
+typedef struct {} dcr_host_t;
+
+#define DCR_MAP_OK(host) (1)
+
+#define dcr_map(dev, dcr_n, dcr_c) {}
+#define dcr_unmap(host, dcr_n, dcr_c) {}
+#define dcr_read(host, dcr_n) mfdcr(dcr_n)
+#define dcr_write(host, dcr_n, value) mtdcr(dcr_n, value)
+
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_DCR_NATIVE_H */
+
+
Index: linux-cell/arch/ppc/Kconfig
===================================================================
--- linux-cell.orig/arch/ppc/Kconfig 2006-10-11 15:27:03.000000000 +1000
+++ linux-cell/arch/ppc/Kconfig 2006-10-11 15:28:41.000000000 +1000
@@ -77,9 +77,11 @@ config 6xx
config 40x
bool "40x"
+ select PPC_DCR_NATIVE
config 44x
bool "44x"
+ select PPC_DCR_NATIVE
config 8xx
bool "8xx"
@@ -95,6 +97,15 @@ endchoice
config PPC_FPU
bool
+config PPC_DCR_NATIVE
+ bool
+ default n
+
+config PPC_DCR
+ bool
+ depends on PPC_DCR_NATIVE
+ default y
+
config BOOKE
bool
depends on E200 || E500
Index: linux-cell/arch/powerpc/kernel/Makefile
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/Makefile 2006-10-11 15:27:03.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/Makefile 2006-10-11 15:28:41.000000000 +1000
@@ -60,6 +60,8 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
+obj-$(CONFIG_PPC_DCR) += dcr.o
+
module-$(CONFIG_PPC64) += module_64.o
obj-$(CONFIG_MODULES) += $(module-y)
Index: linux-cell/arch/powerpc/kernel/dcr.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-cell/arch/powerpc/kernel/dcr.c 2006-10-11 15:35:34.000000000 +1000
@@ -0,0 +1,120 @@
+/*
+ * (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
+ */
+
+#include <asm/prom.h>
+#include <asm/dcr.h>
+
+int dcr_resource_start(struct device_node *np, unsigned int index)
+{
+ unsigned int ds;
+ const u32 *dr = get_property(np, "dcr-reg", &ds);
+
+ if (dr == NULL || ds & 1 || index >= (ds / 8))
+ return -EINVAL;
+
+ return dr[index * 2];
+}
+
+int dcr_resource_len(struct device_node *np, unsigned int index)
+{
+ unsigned int ds;
+ const u32 *dr = get_property(np, "dcr-reg", &ds);
+
+ if (dr == NULL || ds & 1 || index >= (ds / 8))
+ return -EINVAL;
+
+ return dr[index * 2 + 1];
+}
+
+#ifndef CONFIG_PPC_DCR_NATIVE
+
+static struct device_node * find_dcr_parent(struct device_node * node)
+{
+ struct device_node *par, *tmp;
+ const u32 *p;
+
+ for (par = of_node_get(node); par;) {
+ if (get_property(par, "dcr-controller", NULL))
+ break;
+ p = get_property(par, "dcr-parent", NULL);
+ tmp = par;
+ if (p == NULL)
+ par = of_get_parent(par);
+ else
+ par = of_find_node_by_phandle(*p);
+ of_node_put(tmp);
+ }
+ return par;
+}
+
+u64 of_translate_dcr_address(struct device_node *dev,
+ unsigned int dcr_n,
+ unsigned int *stride)
+{
+ struct device_node *dp;
+ const u32 *p;
+ u64 ret;
+
+ dp = find_dcr_parent(dev);
+ if (dp == NULL)
+ return OF_BAD_ADDR;
+
+ /* Stride is not properly defined yet, default to 0x10 for Axon */
+ p = get_property(dp, "dcr-mmio-stride", NULL);
+ *stride = (p == NULL) ? 0x10 : *p;
+
+ p = get_property(dp, "dcr-mmio-range", NULL);
+ if (p == NULL)
+ return OF_BAD_ADDR;
+
+ /* Maybe could do some better range checking here */
+ ret = of_translate_address(dp, p);
+ if (ret != OF_BAD_ADDR)
+ ret += *stride * dcr_n;
+ return ret;
+}
+
+dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
+ unsigned int dcr_c)
+{
+ dcr_host_t ret = { .token = NULL, .stride = 0 };
+ u64 addr;
+
+ addr = of_translate_dcr_address(dev, dcr_n, &ret.stride);
+ if (addr == OF_BAD_ADDR)
+ return ret;
+ ret.token = ioremap(addr, dcr_c * ret.stride);
+ if (ret.token == NULL)
+ return ret;
+ ret.token -= dcr_n * ret.stride;
+ return ret;
+}
+
+void dcr_unmap(dcr_host_t host, unsigned int dcr_n, unsigned int dcr_c)
+{
+ dcr_host_t h = host;
+
+ if (h.token == NULL)
+ return;
+ h.token -= dcr_n * h.stride;
+ iounmap(h.token);
+ h.token = NULL;
+}
+
+#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
^ 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