* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-27 14:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708270724r3d1a3bd3jccbc161475e93343@mail.gmail.com>
Hi Grant,
Thank you for your response.
My u-boot bootargs is set to:
console=ttyUL0,9600 root=/dev/nfs rw nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp ip=::::virtex4-mirek:eth0:dhcp panic=1
where I can find __log_buf for kernel messages?
Best Regards
Mirek
On Mon, 27 Aug 2007, Grant Likely wrote:
> On 8/27/07, Mirek23 <miroslaw.dach@psi.ch> wrote:
> > 4. I am trying to start the kernel
> >
> > => bootm 0x1000000
> >
> > ## Booting image at 01000000 ...
> > Image Name: Linux-2.6.21-rc6
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 991375 Bytes = 968.1 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
>
> Have you looked in __log_buf for kernel messages?
> What does your u-boot env look like?
> Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?
>
> Cheers,
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: Broadcom HT1000/HT2000 or HT1100 support in IBM PowerPC 970MP/Fx
From: Benjamin Herrenschmidt @ 2007-08-27 14:33 UTC (permalink / raw)
To: Ashok Hegde; +Cc: linuxppc-embedded
In-Reply-To: <52C5E6AE59DB984B9ECCBCADFE1C5E15050DABBB@BNGWNEXC0001.bng.slr.com>
On Mon, 2007-08-27 at 19:36 +0530, Ashok Hegde wrote:
> Hi All,
>
>
>
> Is any of these broadcom HT1000/HT2000/HT1100 chipsets supported with
> IBM 970MP/FX?
>
> Could please anyone provide me the Linux kernel link for product with
> this combination (IBM 970MP/FX + HT1000/HT2000/HT1100)?
You can't plug one of these directly onto a 970, you need a northbridge
first, such as IBM CPC945 :-) But then, yes, those work fine behind that
bridge. Apple and IBM both used these on 970 + CPC945/U4 based products.
Ben.
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-27 14:24 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12347049.post@talk.nabble.com>
On 8/27/07, Mirek23 <miroslaw.dach@psi.ch> wrote:
> 4. I am trying to start the kernel
>
> => bootm 0x1000000
>
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.21-rc6
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 991375 Bytes = 968.1 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
Have you looked in __log_buf for kernel messages?
What does your u-boot env look like?
Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-27 14:21 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <46D2DCFC.40401@fz-juelich.de>
On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
> > Don't modify xparams by hand; it's not worth the trouble. Go into
> > software setting in your EDK project and select 'linux-2.6' as the OS.
> > Generate the libraries and copy the generated xparameters_ml40x.h
> > into your kernel tree.
> >
> >
> i dont have this option. do i need a update ?
Probably, but you can use the montavista 2.4 option also. You're only
interested in the xparameters.h file, not the whole BSP. (Letting EDK
generate files into your kernel tree is scary)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-27 14:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40708270609x453092eye6eaf83b65ac2dee@mail.gmail.com>
Grant Likely wrote:
> On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> im a student from germany and i try to run linux on a virtex-II with
>> integrated powerpc.
>> i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
>> now avnet)
>>
>> what is running :
>>
>> - Xilinx EDK project (standalone program running fine, and BSP files
>> are generated)
>> the project has only one UARTLITE, 82MB SDRAM and a few kByte
>> blockram, and the systemace interface
>>
>> - crosscompiler toolchain works
>>
>> - after modified some defines in the xparameters.h i got a linux 2.4.
>> kernel (linuxppc) without compiler errors
>>
>
> I strongly recommend trying to bring up a 2.6 kernel, it's much easier.
>
okay, i'll try it :)
>
>> and yes, the uartlite driver is enabled :)
>>
>
> Don't modify xparams by hand; it's not worth the trouble. Go into
> software setting in your EDK project and select 'linux-2.6' as the OS.
> Generate the libraries and copy the generated xparameters_ml40x.h
> into your kernel tree.
>
>
i dont have this option. do i need a update ?
G
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Broadcom HT1000/HT2000 or HT1100 support in IBM PowerPC 970MP/Fx
From: Ashok Hegde @ 2007-08-27 14:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hi All,
Is any of these broadcom HT1000/HT2000/HT1100 chipsets supported with IBM
970MP/FX?
Could please anyone provide me the Linux kernel link for product with this
combination (IBM 970MP/FX + HT1000/HT2000/HT1100)?
I could able to locate "tetrapower" but not able to get more info on Linux
front.
Thanks in advance.
Regards,
Ashok
[-- Attachment #2: Type: text/html, Size: 3126 bytes --]
^ permalink raw reply
* RE: Newbie and linux on virtex-II ppc
From: Ming Liu @ 2007-08-27 13:54 UTC (permalink / raw)
To: g.schardt, linuxppc-embedded
In-Reply-To: <46D2C9A5.9030708@fz-juelich.de>
Dear Georg,
>is it possible to run a kernel that way ? or need i some kind of
>bootloader ?
>or is this complete the wrong way ?
Yes, you can. Actually what I did is to include a bootloop in the hardware
bitstream and that will keep your CPU waiting until the kernel's running.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Linux doesn not boot from u-boot on ML403
From: Mirek23 @ 2007-08-27 13:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I run Linux 2.6.21 (by Grant) on my Avnet Virtex-4 evaluation board
(ML403 like). When I load zIinux.elf
via jtag to the board it runs properly:
loaded at: 00400000 004F9138
board data at: 004F7120 004F7138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F6EE6
avail ram: 004FA000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...done.
Now booting the kernel
[0.000000] Linux version 2.6.21-rc6 (root@pc5215) (gcc version 4.0.2) #11
Tue Aug 7 13:46:19 EST 2007
[0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
.
.
.
.
It goes to the successful end.
I have build u-boot 1.2.0 with uart lite and temac support.
When I am trying to run uImage (build out of zImage) it does not run.
The steps I do are as following:
1. I build uImage withing the kernel tree (make uImage)
2. I load via jtag the u-boot 1.2.0
XMD% dow u-boot.elf
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
3. I transfer uImage to the RAM memory of my Avnet board:
TFTP from server 129.129.144.113; our IP address is 129.129.144.157
Filename 'uImage'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
################################################################
done
Bytes transferred = 991438 (f20ce hex)
4. I am trying to start the kernel
=> bootm 0x1000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.21-rc6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 991375 Bytes = 968.1 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
After all system hangs
I have tried to change the Load Address and Entry Point to 0x400000 (mkimage
-a 0x400000 -e 0x400000)
but the system hangs like in the first case.
my bootargs are:
console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Those bootargs where tested with zImage.elf and seem to be fine.
Does somebody has some suggestion?
Thank you in advance for any hint on that.
Mirek
--
View this message in context: http://www.nabble.com/Linux-doesn-not-boot-from-u-boot-on-ML403-tf4335322.html#a12347049
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-27 13:09 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <46D2C9A5.9030708@fz-juelich.de>
On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
> im a student from germany and i try to run linux on a virtex-II with
> integrated powerpc.
> i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
> now avnet)
>
> what is running :
>
> - Xilinx EDK project (standalone program running fine, and BSP files
> are generated)
> the project has only one UARTLITE, 82MB SDRAM and a few kByte
> blockram, and the systemace interface
>
> - crosscompiler toolchain works
>
> - after modified some defines in the xparameters.h i got a linux 2.4.
> kernel (linuxppc) without compiler errors
I strongly recommend trying to bring up a 2.6 kernel, it's much easier.
> and yes, the uartlite driver is enabled :)
Don't modify xparams by hand; it's not worth the trouble. Go into
software setting in your EDK project and select 'linux-2.6' as the OS.
Generate the libraries and copy the generated xparameters_ml40x.h
into your kernel tree.
>
>
> but, when downloading the zImage.elf via XMD to the SDRAM and starting
> it with the run command nothing happens , or i think that nothings
> happens because the serial port is quiet.
You can always use System.map in the kernel tree to find out where
__log_buf was linked to. Look at that location with the debugger to
see if there is a crash message that didn't get printed out.
>
> is it possible to run a kernel that way ? or need i some kind of
> bootloader ?
> or is this complete the wrong way ?
Yes, I use this same method to bring up a kernel on Virtex boards
which don't have a bootloader.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-27 12:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
im a student from germany and i try to run linux on a virtex-II with
integrated powerpc.
i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
now avnet)
i hope my questions are not too stupid :-)
what is running :
- Xilinx EDK project (standalone program running fine, and BSP files
are generated)
the project has only one UARTLITE, 82MB SDRAM and a few kByte
blockram, and the systemace interface
- crosscompiler toolchain works
- after modified some defines in the xparameters.h i got a linux 2.4.
kernel (linuxppc) without compiler errors
and yes, the uartlite driver is enabled :)
but, when downloading the zImage.elf via XMD to the SDRAM and starting
it with the run command nothing happens , or i think that nothings
happens because the serial port is quiet.
is it possible to run a kernel that way ? or need i some kind of
bootloader ?
or is this complete the wrong way ?
Regards
Georg
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH, RFC] linkstation: implement standby
From: Johannes Berg @ 2007-08-27 11:32 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-pm
In-Reply-To: <Pine.LNX.4.60.0708260157330.3809@poirot.grange>
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
On Sun, 2007-08-26 at 02:03 +0200, Guennadi Liakhovetski wrote:
> +#ifdef CONFIG_PM
some of those probably want to be CONFIG_PM_SLEEP now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* MDIO bus hotplug
From: DI BACCO ANTONIO - technolabs @ 2007-08-27 11:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Hi,
I have an hot pluggable MDIO bus (connected to MDC, MDIO of an MPC880)
and thus I would like to rescan the bus on certain events (for example
fs_enet_open) to access the numerous PHYs I have on this bus. I saw that
it is "simply" a matter of calling mdiobus_register but I would like an
advice how to design the modification
MPC880 with linux-2.6.19.2
Best regards,
Antonio.
[-- Attachment #2: Type: text/html, Size: 1414 bytes --]
^ permalink raw reply
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayir @ 2007-08-27 11:08 UTC (permalink / raw)
To: Oliver Rutsch, linuxppc-embedded
In-Reply-To: <46CD3618.70801@sympatec.com>
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
Hi ,
i use 2.4.25 kernel and eldk 3.1.1 on TQM5200 board. i tried denx 2.6.19 kernel to port on TQM5200 but i couldn't.
Did you port 2.6 kernel on TQM5200? Did pci device start working succesfully after porting 2.6 kernel to TQM5200 board.
-----Original Message-----
From: linuxppc-embedded-bounces+mustafa.cayir=bte.mam.gov.tr@ozlabs.org on behalf of Oliver Rutsch
Sent: Thu 8/23/2007 10:24 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: STK5200 pci_enable_device problem
Hi Mustafa,
> Hi all,
>
[...]
>
> My pci driver is able to scan pci bus and find succesfully the pci
> device. After this point, pci_enable_device function returns
> following error:
>
> PCI: Device 00:18.0 not available because of resource collisions
>
Which ELDK and kernel do you use? I had the same problem on this board
with a PLX9054 based PCI card on a 2.4.25 kernel. I switched to the 2.6
kernel and the 4.1 ELDK and the card was scanned correctly.
But keep in mind that the linux PLX drivers do not work out of the box
with a big endian platform like the MPC5200. Although there is a
BIG_ENDIAN flag in the makefiles there are still some places left in the
driver code which have to be patched (the parts with int64 adresses).
It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
missing headers in the ppc architecture. I managed to build the drivers
for the 2.6.19 kernel and I was able to work with the card except the
DMA routines (still working on this issue).
Hope this helps. Bye,
--
Dipl. Ing. Oliver Rutsch
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2411 bytes --]
^ permalink raw reply
* how to debug the linux kernel with a BDI2000
From: jxnuxdy @ 2007-08-27 9:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
My kernel hanged in when passed the parameters to it, and I dump nothing from the log_buf, so I guss it is crashed at the very beginning. however I didn't know how to setup the KDB to load the kernel with the BDI2000 ethernet? is there anyone has even loaded and debugged the kernel with the BDI2000 ethernet? if so pls show me how it goes? ,Thanks- Denny
[-- Attachment #2: Type: text/html, Size: 794 bytes --]
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-27 9:47 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070826.185815.93042514.davem@davemloft.net>
On Monday 27 August 2007 03:58, David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Sun, 26 Aug 2007 20:36:20 +0100
>
> > David Miller wrote:
> > > From: James Chapman <jchapman@katalix.com>
> > > Date: Fri, 24 Aug 2007 18:16:45 +0100
> > >
> > >> Does hardware interrupt mitigation really interact well with NAPI?
> > >
> > > It interacts quite excellently.
> >
> > If NAPI disables interrupts and keeps them disabled while there are more
> > packets arriving or more transmits being completed, why do hardware
> > interrupt mitigation / coalescing features of the network silicon help?
>
> Because if your packet rate is low enough such that the cpu can
> process the interrupt fast enough and thus only one packet gets
> processed per NAPI poll, the cost of going into and out of NAPI mode
> dominates the packet processing costs.
As far as I understand your argumentation, NAPI is supposed to work well only
for HW with coalescing features (concerning dropping the interrupt rate).
NAPI itself does not provide a reliable functionality to reduce the
number of interrupts, especially not for systems with only 1 NIC.
NAPI will only wait for some time when the budget is exceeded
and the softIRQs don't call net_rx_action again. This seems to be the case
after 10 rounds. That means NAPI really waits after 300 x 10 packets
have been processed in a row (worst case).
As a matter of fact there is HW that does not have this feature. There seems
to be HW which does not work well with plain NAPI.
This HW performs well if the operation system supports HP timers
(and when they are used either in the device driver or polling engine).
So the question is simply: Do we want drivers that need (benefit from)
a timer based polling support to implement their own timers each,
or should there be a generic support?
Thanks,
Jan-Bernd
^ permalink raw reply
* pata_mpc52xx - no interrupts when using bestcomm/dma?
From: Domen Puncer @ 2007-08-27 9:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I'm taking a stab at adding DMA support to pata_mpc52xx driver.
It's based on patches from Freescale's ltib (old ide driver).
The problem is that I can't seem to get any interrupts
(not ata, not bestcomm task), when setting up MWDMA/UDMA mode.
Ideas?
My current patch:
---
drivers/ata/pata_mpc52xx.c | 491 +++++++++++++++++++++++++++++++++++++++++++--
include/linux/libata.h | 2
2 files changed, 477 insertions(+), 16 deletions(-)
Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
===================================================================
--- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
+++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
@@ -4,6 +4,7 @@
* libata driver for the Freescale MPC52xx on-chip IDE interface
*
* Copyright (C) 2006 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2005,2006 Freescale - Bernard Kuhn, John Rigby
* Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
*
* This file is licensed under the terms of the GNU General Public License
@@ -22,6 +23,8 @@
#include <asm/of_platform.h>
#include <asm/mpc52xx.h>
+#include <sysdev/bestcomm/bestcomm.h>
+#include <sysdev/bestcomm/ata.h>
#define DRV_NAME "mpc52xx_ata"
#define DRV_VERSION "0.1.0ac2"
@@ -31,6 +34,14 @@
struct mpc52xx_ata_timings {
u32 pio1;
u32 pio2;
+ u32 mdma1;
+ u32 mdma2;
+ u32 udma1;
+ u32 udma2;
+ u32 udma3;
+ u32 udma4;
+ u32 udma5;
+ int using_udma;
};
struct mpc52xx_ata_priv {
@@ -39,6 +50,12 @@ struct mpc52xx_ata_priv {
int ata_irq;
struct mpc52xx_ata_timings timings[2];
int csel;
+
+ /* dma stuff follows */
+ struct bcom_task * dmatsk;
+ const struct udmaspec * udmaspec;
+ const struct mdmaspec * mdmaspec;
+ int mpc52xx_ata_dma_last_write;
};
@@ -53,6 +70,102 @@ static const int ataspec_ta[5] = { 35
#define CALC_CLKCYC(c,v) ((((v)+(c)-1)/(c)))
+/* ATAPI-4 MDMA specs (in clocks) */
+struct mdmaspec {
+ u32 t0M[3];
+ u32 td[3];
+ u32 th[3];
+ u32 tj[3];
+ u32 tkw[3];
+ u32 tm[3];
+ u32 tn[3];
+};
+
+// -----------------------------------------------------------------------------------------------
+
+static const struct mdmaspec mdmaspec66 = {
+ {32, 10, 8},
+ {15, 6, 5},
+ {2, 1, 1},
+ {2, 1, 1},
+ {15, 4, 2},
+ {4, 2, 2},
+ {1, 1, 1}
+};
+
+static const struct mdmaspec mdmaspec132 = {
+ {64, 20, 16},
+ {29, 11, 10},
+ {3, 2, 2},
+ {3, 1, 1},
+ {29, 7, 4},
+ {7, 4, 4},
+ {2, 1, 1}
+};
+
+
+/* ATAPI-4 UDMA specs (in clocks) */
+struct udmaspec {
+ u32 tcyc[6];
+ u32 t2cyc[6];
+ u32 tds[6];
+ u32 tdh[6];
+ u32 tdvs[6];
+ u32 tdvh[6];
+ u32 tfs_min[6];
+ u32 tli_max[6];
+ u32 tmli[6];
+ u32 taz[6];
+ u32 tzah[6];
+ u32 tenv_min[6];
+ u32 tsr[6];
+ u32 trfs[6];
+ u32 trp[6];
+ u32 tack[6];
+ u32 tss[6];
+};
+
+static const struct udmaspec udmaspec66 = {
+ { 8, 5, 4, 3, 2, 2},
+ {16, 11, 8, 6, 4 , 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ { 5, 4, 3, 2, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {16, 14, 12, 9, 8, 6},
+ {10, 10, 10, 7, 8, 5},
+ { 2, 2, 2, 2, 2, 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 2, 2, 2, 2, 2, 2},
+ { 2, 2, 2, 2, 2, 2},
+ { 3, 2, 2, 2, 2, 2},
+ { 5, 5, 4, 4, 4, 4},
+ {11, 9, 7, 7, 7, 6},
+ { 2, 2, 2, 2, 2, 2},
+ { 4, 4, 4, 4, 4, 4}
+};
+
+static const struct udmaspec udmaspec132 = {
+ {15, 10, 6, 7, 2, 3},
+ {31, 21, 12, 12, 5, 6},
+ { 2, 2, 1, 1, 0, 1},
+ { 1, 1, 1, 1, 0, 1},
+ {10, 7, 5, 3, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {30, 27, 23, 15, 16, 12},
+ {20, 20, 20, 13, 14, 10},
+ { 3, 3, 3, 3, 2, 3},
+ { 2, 2, 2, 2, 1, 2},
+ { 3, 3, 3, 3, 2, 3},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 4, 3, 3, 2, 3},
+ {10, 10, 8, 8, 7, 7},
+ {22, 17, 14, 14, 13, 12},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 7, 7, 7, 6, 7},
+};
+
+// -----------------------------------------------------------------------------------------------
/* Bit definitions inside the registers */
#define MPC52xx_ATA_HOSTCONF_SMR 0x80000000UL /* State machine reset */
@@ -76,6 +189,10 @@ static const int ataspec_ta[5] = { 35
#define MPC52xx_ATA_DMAMODE_HUT 0x40 /* Host UDMA burst terminate */
+#define MAX_DMA_BUFFERS 128
+#define MAX_DMA_BUFFER_SIZE 0x20000u
+
+
/* Structure of the hardware registers */
struct mpc52xx_ata {
@@ -141,6 +258,19 @@ struct mpc52xx_ata {
/* MPC52xx low level hw control */
+static inline void
+mpc52xx_ata_wait_tip_bit_clear(struct mpc52xx_ata __iomem *regs)
+{
+ int timeout = 1000;
+
+ while (in_be32(®s->host_status) & MPC52xx_ATA_HOSTSTAT_TIP)
+ if (timeout-- == 0) {
+ printk(KERN_ERR "mpc52xx-ide: Timeout waiting for TIP clear\n");
+ break;
+ }
+ udelay(10); /* FIXME: Necessary ??? */
+}
+
static int
mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv *priv, int dev, int pio)
{
@@ -165,6 +295,96 @@ mpc52xx_ata_compute_pio_timings(struct m
return 0;
}
+static int
+mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t0M, td, tkw, tm, th, tj, tn;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t0M = priv->mdmaspec->t0M[speed];
+ td = priv->mdmaspec->td[speed];
+ tkw = priv->mdmaspec->tkw[speed];
+ tm = priv->mdmaspec->tm[speed];
+ th = priv->mdmaspec->th[speed];
+ tj = priv->mdmaspec->tj[speed];
+ tn = priv->mdmaspec->tn[speed];
+
+ /*
+ DPRINTK ("t0M = %d\n", t0M);
+ DPRINTK ("td = %d\n", td);
+ DPRINTK ("tkw = %d\n", tkw);
+ DPRINTK ("tm = %d\n", tm);
+ DPRINTK ("th = %d\n", th);
+ DPRINTK ("tj = %d\n", tj);
+ DPRINTK ("tn = %d\n", tn);
+ */
+ timing->mdma1 = (t0M << 24) | (td << 16) | (tkw << 8) | (tm);
+ timing->mdma2 = (th << 24) | (tj << 16) | (tn << 8);
+
+ timing->using_udma = 0;
+
+ return 0;
+}
+
+static int
+mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t2cyc, tcyc, tds, tdh, tdvs, tdvh, tfs, tli, tmli, taz, tenv, tsr, tss, trfs, trp, tack, tzah;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t2cyc = priv->udmaspec->t2cyc[speed];
+ tcyc = priv->udmaspec->tcyc[speed];
+ tds = priv->udmaspec->tds[speed];
+ tdh = priv->udmaspec->tdh[speed];
+ tdvs = priv->udmaspec->tdvs[speed];
+ tdvh = priv->udmaspec->tdvh[speed];
+ tfs = priv->udmaspec->tfs_min[speed];
+ tmli = priv->udmaspec->tmli[speed];
+ tenv = priv->udmaspec->tenv_min[speed];
+ tss = priv->udmaspec->tss[speed];
+ trp = priv->udmaspec->trp[speed];
+ tack = priv->udmaspec->tack[speed];
+ tzah = priv->udmaspec->tzah[speed];
+ taz = priv->udmaspec->taz[speed];
+ trfs = priv->udmaspec->trfs[speed];
+ tsr = priv->udmaspec->tsr[speed];
+ tli = priv->udmaspec->tli_max[speed];
+/*
+ DPRINTK ("UDMA t2cyc = %d\n", t2cyc);
+ DPRINTK ("UDMA tcyc = %d\n", tcyc);
+ DPRINTK ("UDMA tds = %d\n", tds);
+ DPRINTK ("UDMA tdh = %d\n", tdh);
+ DPRINTK ("UDMA tdvs = %d\n", tdvs);
+ DPRINTK ("UDMA tdvh = %d\n", tdvh);
+ DPRINTK ("UDMA tfs = %d\n", tfs);
+ DPRINTK ("UDMA tli = %d\n", tli);
+ DPRINTK ("UDMA tmli = %d\n", tmli);
+ DPRINTK ("UDMA taz = %d\n", taz);
+ DPRINTK ("UDMA tenv = %d\n", tenv);
+ DPRINTK ("UDMA tsr = %d\n", tsr);
+ DPRINTK ("UDMA tss = %d\n", tss);
+ DPRINTK ("UDMA trfs = %d\n", trfs);
+ DPRINTK ("UDMA trp = %d\n", trp);
+ DPRINTK ("UDMA tack = %d\n", tack);
+ DPRINTK ("UDMA tzah = %d\n", tzah);
+*/
+ timing->udma1 = (t2cyc << 24) | (tcyc << 16) | (tds << 8) | (tdh);
+ timing->udma2 = (tdvs << 24) | (tdvh << 16) | (tfs << 8) | (tli);
+ timing->udma3 = (tmli << 24) | (taz << 16) | (tenv << 8) | (tsr);
+ timing->udma4 = (tss << 24) | (trfs << 16) | (trp << 8) | (tack);
+ timing->udma5 = (tzah << 24);
+
+ timing->using_udma = 1;
+
+ return 0;
+}
+
static void
mpc52xx_ata_apply_timings(struct mpc52xx_ata_priv *priv, int device)
{
@@ -173,13 +393,13 @@ mpc52xx_ata_apply_timings(struct mpc52xx
out_be32(®s->pio1, timing->pio1);
out_be32(®s->pio2, timing->pio2);
- out_be32(®s->mdma1, 0);
- out_be32(®s->mdma2, 0);
- out_be32(®s->udma1, 0);
- out_be32(®s->udma2, 0);
- out_be32(®s->udma3, 0);
- out_be32(®s->udma4, 0);
- out_be32(®s->udma5, 0);
+ out_be32(®s->mdma1, timing->mdma1);
+ out_be32(®s->mdma2, timing->mdma2);
+ out_be32(®s->udma1, timing->udma1);
+ out_be32(®s->udma2, timing->udma2);
+ out_be32(®s->udma3, timing->udma3);
+ out_be32(®s->udma4, timing->udma4);
+ out_be32(®s->udma5, timing->udma5);
priv->csel = device;
}
@@ -234,6 +454,7 @@ mpc52xx_ata_set_piomode(struct ata_port
pio = adev->pio_mode - XFER_PIO_0;
+ // FIXME, can be called for dma mode?
rv = mpc52xx_ata_compute_pio_timings(priv, adev->devno, pio);
if (rv) {
@@ -245,6 +466,28 @@ mpc52xx_ata_set_piomode(struct ata_port
mpc52xx_ata_apply_timings(priv, adev->devno);
}
static void
+mpc52xx_ata_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ int rv;
+
+ if (adev->dma_mode >= XFER_UDMA_0) {
+ int dma = adev->dma_mode - XFER_UDMA_0;
+ rv = mpc52xx_ata_compute_udma_timings(priv, adev->devno, dma);
+ } else {
+ int dma = adev->dma_mode - XFER_MW_DMA_0;
+ rv = mpc52xx_ata_compute_mdma_timings(priv, adev->devno, dma);
+ }
+
+ if (rv) {
+ printk(KERN_ERR DRV_NAME
+ ": Trying to select invalid DMA mode %d\n", adev->dma_mode);
+ return;
+ }
+
+ mpc52xx_ata_apply_timings(priv, adev->devno);
+}
+static void
mpc52xx_ata_dev_select(struct ata_port *ap, unsigned int device)
{
struct mpc52xx_ata_priv *priv = ap->host->private_data;
@@ -258,10 +501,174 @@ mpc52xx_ata_dev_select(struct ata_port *
static void
mpc52xx_ata_error_handler(struct ata_port *ap)
{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+
+ printk(KERN_ALERT "%s: status: %08x; fifo_status_frame: %08x; fifo_status: %08x\n",
+ __func__, in_be32(®s->host_status),
+ in_be32(®s->fifo_status_frame),
+ in_be32(®s->fifo_status));
+
ata_bmdma_drive_eh(ap, ata_std_prereset, ata_std_softreset, NULL,
ata_std_postreset);
}
+static void
+mpc52xx_ata_exec_command(struct ata_port *ap, const struct ata_taskfile *tf)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ mpc52xx_ata_wait_tip_bit_clear(priv->ata_regs);
+
+ ata_exec_command(ap, tf);
+}
+
+static int
+mpc52xx_ata_build_dmatable(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ struct scatterlist *sg;
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE);
+ int count = 0;
+
+ if (read)
+ bcom_ata_rx_prepare(priv->dmatsk);
+ else
+ bcom_ata_tx_prepare(priv->dmatsk);
+
+
+ ata_for_each_sg(sg, qc) {
+ u32 cur_addr = sg_dma_address(sg);
+ u32 cur_len = sg_dma_len(sg);
+
+ while (cur_len) {
+ unsigned int tc = min(cur_len, MAX_DMA_BUFFER_SIZE);
+ struct bcom_ata_bd *bd;
+
+ bd = (struct bcom_ata_bd *)
+ bcom_prepare_next_buffer(priv->dmatsk);
+
+ if (read) {
+ bd->status = tc;
+ bd->dst_pa = cur_addr;
+ bd->src_pa = (__force u32)®s->fifo_data; // virt_to_phys?
+ } else {
+ bd->status = tc;
+ bd->dst_pa = (__force u32)®s->fifo_data; // virt_to_phys?
+ bd->src_pa = cur_addr;
+
+ /* and how does bestcomm know to increase one, and not other?
+ * XXX TODO */
+ }
+
+ bcom_submit_next_buffer(priv->dmatsk, phys_to_virt(cur_addr)); // qc is just a cookie
+
+ cur_addr += tc;
+ cur_len -= tc;
+ count++;
+
+ if (count == MAX_DMA_BUFFERS) {
+ printk(KERN_ALERT "%s: %i dma table too small\n",
+ __func__, __LINE__);
+ goto use_pio_instead;
+ }
+ }
+ }
+ return 1;
+
+ use_pio_instead:
+ bcom_ata_reset_bd(priv->dmatsk);
+ //pci_unmap_sg ???
+
+ return 0;
+}
+
+static void
+mpc52xx_bmdma_setup(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE);
+ u8 dma_mode;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ if (!mpc52xx_ata_build_dmatable(qc)) {
+ //ide_map_sg(drive, rq);
+ printk(KERN_ALERT "%s: %i, return 1?\n", __func__, __LINE__);
+ }
+
+ if (read) {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_READ |
+ MPC52xx_ATA_DMAMODE_FE;
+
+ /* Setup FIFO if direction changed */
+ if (priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 0;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, MPC52xx_ATA_DMAMODE_FR);
+ /* Configure it with granularity to 7 like sample code */
+ out_8(®s->fifo_control, 7);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ } else {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_WRITE;
+
+ /* Setup FIFO if direction changed */
+ if (!priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 1;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ /* Configure FIFO with granularity to 4 like sample code */
+ out_8(®s->fifo_control, 4);
+ //out_be16(®s->fifo_alarm, 256);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ }
+
+ if (priv->timings[qc->dev->devno].using_udma)
+ dma_mode |= MPC52xx_ATA_DMAMODE_UDMA;
+
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, dma_mode);
+
+ ap->ops->exec_command(ap, &qc->tf); // added, ata_bmdma_setup has it
+}
+
+static void
+mpc52xx_bmdma_start(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ //xlb_clear(); // WTF
+ bcom_enable(priv->dmatsk);
+}
+
+static void
+mpc52xx_bmdma_stop(struct ata_queued_cmd *qc)
+{
+ // uh? looks like destructor for setup not start
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ bcom_disable(priv->dmatsk);
+ //bcom_clear_irq(priv->dmatsk); //!!
+ bcom_ata_reset_bd(priv->dmatsk);
+
+ // mpc52xx_ata_destroy_dmatable();
+}
+// waiting_for_dma eliminated
+
+static u8
+mpc52xx_bmdma_status(struct ata_port *ap)
+{
+printk(KERN_ALERT "%s: %i TODO\n", __func__, __LINE__);
+ return 0;
+}
static struct scsi_host_template mpc52xx_ata_sht = {
@@ -282,25 +689,47 @@ static struct scsi_host_template mpc52xx
.bios_param = ata_std_bios_param,
};
+static void mpc52xx_ata_bmdma_freeze(struct ata_port *ap)
+{
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ ata_bmdma_freeze(ap);
+}
+static void mpc52xx_ata_bmdma_thaw(struct ata_port *ap)
+{
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ ata_bmdma_thaw(ap);
+}
+static void ata_dummy_noret(struct ata_port *ap)
+{
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+}
static struct ata_port_operations mpc52xx_ata_port_ops = {
.port_disable = ata_port_disable,
.set_piomode = mpc52xx_ata_set_piomode,
+ .set_dmamode = mpc52xx_ata_set_dmamode,
.dev_select = mpc52xx_ata_dev_select,
.tf_load = ata_tf_load,
.tf_read = ata_tf_read,
.check_status = ata_check_status,
- .exec_command = ata_exec_command,
- .freeze = ata_bmdma_freeze,
- .thaw = ata_bmdma_thaw,
+ .exec_command = mpc52xx_ata_exec_command,
+ .freeze = mpc52xx_ata_bmdma_freeze,
+ .thaw = mpc52xx_ata_bmdma_thaw,
.error_handler = mpc52xx_ata_error_handler,
.cable_detect = ata_cable_40wire,
.qc_prep = ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
- .irq_clear = ata_bmdma_irq_clear,
+// .irq_clear = ata_bmdma_irq_clear,
+ .irq_clear = ata_dummy_noret,
.irq_on = ata_irq_on,
.irq_ack = ata_irq_ack,
.port_start = ata_port_start,
+ .bmdma_setup = mpc52xx_bmdma_setup,
+ .bmdma_start = mpc52xx_bmdma_start,
+ .bmdma_stop = mpc52xx_bmdma_stop,
+ .bmdma_status = mpc52xx_bmdma_status,
+
+// not ide_dma_check int (*check_atapi_dma) (struct ata_queued_cmd *qc);
};
static int __devinit
@@ -309,7 +738,6 @@ mpc52xx_ata_init_one(struct device *dev,
struct ata_host *host;
struct ata_port *ap;
struct ata_ioports *aio;
- int rc;
host = ata_host_alloc(dev, 1);
if (!host)
@@ -317,9 +745,9 @@ mpc52xx_ata_init_one(struct device *dev,
ap = host->ports[0];
ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->pio_mask = 0x1f; /* Up to PIO4 */
- ap->mwdma_mask = 0x00; /* No MWDMA */
- ap->udma_mask = 0x00; /* No UDMA */
+ ap->pio_mask = ATA_PIO4; /* Up to PIO4 */
+ ap->mwdma_mask = 0x07; /* Up to MWDMA2 */
+ ap->udma_mask = ATA_UDMA2; /* Up to UDMA2 */
ap->ops = &mpc52xx_ata_port_ops;
host->private_data = priv;
@@ -359,6 +787,15 @@ mpc52xx_ata_remove_one(struct device *de
/* OF Platform driver */
/* ======================================================================== */
+static irqreturn_t
+mpc52xx_ata_task_irq(int irq, void *vpriv)
+{
+ struct mpc52xx_ata_priv *priv = vpriv;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ return IRQ_HANDLED;
+}
+
static int __devinit
mpc52xx_ata_probe(struct of_device *op, const struct of_device_id *match)
{
@@ -426,6 +863,30 @@ mpc52xx_ata_probe(struct of_device *op,
priv->ata_irq = ata_irq;
priv->csel = -1;
+ if (ipb_freq/1000000 == 66) {
+ priv->mdmaspec = &mdmaspec66;
+ priv->udmaspec = &udmaspec66;
+ } else {
+ priv->mdmaspec = &mdmaspec132;
+ priv->udmaspec = &udmaspec132;
+ }
+
+ priv->dmatsk = bcom_ata_init(MAX_DMA_BUFFERS, MAX_DMA_BUFFER_SIZE);
+ if (!priv->dmatsk) {
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ rv = -ENOMEM;
+ goto err;
+ }
+ // XXX task irq? nope, it doesn't get any irq's
+ {
+ int ret;
+ int task_irq = bcom_get_task_irq(priv->dmatsk);
+ printk(KERN_ALERT "%s: ata task irq: %i\n", __func__, task_irq);
+ ret = request_irq(task_irq, &mpc52xx_ata_task_irq, IRQF_DISABLED, "ata task", priv);
+ if (ret)
+ printk(KERN_ALERT "%s: request_irq failed with: %i\n", __func__, ret);
+ }
+
/* Init the hw */
rv = mpc52xx_ata_hw_init(priv);
if (rv) {
Index: work-powerpc.git/include/linux/libata.h
===================================================================
--- work-powerpc.git.orig/include/linux/libata.h
+++ work-powerpc.git/include/linux/libata.h
@@ -51,7 +51,7 @@
* compile-time options: to be removed as soon as all the drivers are
* converted to the new debugging mechanism
*/
-#undef ATA_DEBUG /* debugging output */
+#define ATA_DEBUG /* debugging output */
#undef ATA_VERBOSE_DEBUG /* yet more debugging output */
#undef ATA_IRQ_TRAP /* define to ack screaming irqs */
#undef ATA_NDEBUG /* define to disable quick runtime checks */
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Michel Dänzer @ 2007-08-27 8:37 UTC (permalink / raw)
To: Rogério Brito
Cc: Michal Piotrowski, Rogério Brito, linux-kernel,
Rafael J. Wysocki, linuxppc-dev, debian-powerpc,
Linux-pm mailing list
In-Reply-To: <20070827065246.GA21220@ime.usp.br>
On Mon, 2007-08-27 at 03:52 -0300, Rog=C3=A9rio Brito wrote:
>=20
> I did 13 compiles with git bisect and some of them were unsucessfuly
> compiled, which I am afraid that may miss the real cause if I tag them as
> being "bad" (which I did).
Yes, don't mark such cases as bad or good but look for a nearby commit
that compiles.
--=20
Earthling Michel D=C3=A4nzer | http://tungstengraphics.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-08-27 8:31 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827074955.GE7306@localhost.localdomain>
On Mon, 27 Aug 2007 17:49:55 +1000
David Gibson wrote:
> On Mon, Aug 27, 2007 at 10:31:36AM +0400, Vitaly Bordug wrote:
> > On Mon, 27 Aug 2007 11:15:16 +1000
> > David Gibson wrote:
> >
> > > On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
> [snip]
> > > > +void __devinit pci_process_bridge_OF_ranges(struct
> > > > pci_controller *hose,
> > > > + struct device_node
> > > > *dev, int prim) +{
> > > > + static unsigned int static_lc_ranges[256];
> > > > + const unsigned int *ranges;
> > > > + unsigned int *lc_ranges;
> > > > + unsigned int pci_space;
> > > > + unsigned long size = 0;
> > >
> > > size can be 64-bit on 32-bit systems, at least in theory.
> > >
> > hm, well, but later, we'll call ioremap (at least for IO region)
> > that has size passed as ulong type. And, such a size could be
> > consumed by the code,only if resource_size_t is 64bit too. I'll
> > look at it further.
>
> You should probably actually test for that condition though, rather
> than blithely truncating.
>
ok, makes sense.
> [snip]
> > > > + /* Map ranges to struct according to spec. */
> > > > + if (na >= 2) {
> > > > + ranges64 = (void *)ranges;
> > > > + ranges_amnt = rlen / sizeof(*ranges64);
> > > > + } else {
> > > > + ranges32 = (void *)ranges;
> > > > + ranges_amnt = rlen / sizeof(*ranges32);
> > > > + }
> > > > +
> > > > + hose->io_base_phys = 0;
> > > > + for (i = 0; i < ranges_amnt; i++) {
> > > > + res = NULL;
> > > > + if (ranges64) {
> > > > + if (ranges64[i].pci_space == 0)
> > > > + continue;
> > > > +
> > > > + pci_space = ranges64[i].pci_space;
> > > > + pci_addr =
> > > > + (u64) ranges64[i].pci_addr[0] <<
> > > > 32 | ranges64[i].
> > > > + pci_addr[1];
> > >
> > > Why not just define the pci_addr field in your structures as
> > > u64? You would have to define the structure with
> > > attribute((packed)), I guess.
> > >
> > that was in the first approach, but it gets really interesting
> > numbers (and with contents nothing to do with real stuff), on
> > platforms that are pure 32bit. I mean,
>
> I'm guessing that's because you didn't put the ((packed)) in: without
> it, gcc will align the 64-bit quantity to a 64-bit boundary, inserting
> 32-bits of padding into the structure between pci_space and pci_addr,
> so that it doesn't actually line up with the ranges property.
>
will check, but sounds reasonable.
> > u32 foo, foo1;
> > u64 foo64;
> >
> > foo = bar[1];
> > foo1 = bar[2];
> > foo64 = ((u64)foo << 32) | foo1;
> >
> > does not seem to work on 32bit board. I may need to write a clear
> > testcase and submit it here, maybe I'm missing something very
> > obvious.
>
> !?! shouldn't be anything wrong with that arithmetic...
>
Wrong example, I'll have real snippet if alignment trick won't work (and I hope it will)
> [snip]
> > > > + cpu_phys_addr =
> > > > + of_translate_address(dev,
> > > > ranges64[i].phys_addr);
> > > > + /*
> > > > + * I haven't observed 2 significant
> > > > size cells in kernel
> > > > + * code, so we're accounting only LSB
> > > > of size part
> > > > + * from ranges. -vitb
> > > > + */
> > > > + size = ranges64[i].size[1];
> > > > +#ifdef CONFIG_PPC64
> > > > + if (ranges64[i].size[0])
> > > > + size |=
> > > > ranges64[i].size[0]<<32; +#endif
> > > > + DBG("Observed: pci %llx phys %llx size
> > > > %x\n", pci_addr,
> > > > + cpu_phys_addr, size);
> > > > + } else {
> > > > + if (ranges32[i].pci_space == 0)
> > > > + continue;
> > > > +
> > > > + pci_space = (unsigned
> > > > int)ranges32[i].pci_space;
> > > > + pci_addr = (unsigned
> > > > int)ranges32[i].pci_addr[1];
> > > > + cpu_phys_addr = (unsigned
> > > > int)ranges32[i].phys_addr[0];
> > >
> > >
> > > We should really be using of_translate_address() in all cases -
> > > that's what it's for, after all.
> > >
> > being called, it gives 0 in 32bit branch of if () {. Since, iirc,
> > 32bit range parsing does not have it in original, variant,
> > I have it put as is. worths a brief investigation...
>
> Then we should fix of_translate_address() for 32-bit....
>
> I don't think this patch is actually required for the 44x pci support,
> yes? It might be better to leave this until later - it's only a tiny
> piece of all the consolidations we should do between ppc32 and ppc64
> PCI code. Currently there are a lot of silly, subtle differences
> between them :(.
Well, my point is:
- pci_32.c ranges parsing code is confusing and silly in many
ways
- there is no obvious way to enable 64bit phys addressed
handled correctly there.
possible approaches may bring more problems than solve.
- completely correct is going to be *hard* as David noted, but
we can consider effective merge(with code flow similar to existing funcs) of existing
bits a good starting point. Else, when a lot of stufpci_process_bridge_OF_rangesf would depend on
both functions, it would be too painful to rewrite.
(speaking about pci_process_bridge_OF_ranges here)
>
> > > > + size = ranges32[i].size[1];
> > > > +
> > > > + DBG("Observed: pci %x phys %x size
> > > > %x\n",
> > > > + (u32) pci_addr, (u32)
> > > > cpu_phys_addr, size);
> > > > + }
> > >
> > > You don't have any equivalent of the code that exists in both
> > > pre-existing versions to coalesce contiguous ranges. You probably
> > > want to use the 64-bit version, since that doesn't need a local
> > > copy of the ranges.
> > >
> > correct. yet, the whole aim of the upper seems to use summary size
> > of contiguous block and that's it.
> > How would we recognize IORESOURCE_PREFETCH then? (I know, my code
> > is missing that prefetch regions so far, but anyway).
> > >From the code, it seems to declare each resource that is part of
> > >contiguous block, with the size of entire block.
> >
> > That's prolly from binding, but can you please elaborate the logic
> > for better understanding?
>
> The attributes such as PREFETCH are encoded into cell 0 of the 3-cell
> OF PCI address. So, ranges with different attributes won't appear as
> contiguous in this space.
>
ok, I think there's no problem to implement it in the new func then.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Stefan Roese @ 2007-08-27 8:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827105507.768b1aad@localhost.localdomain>
On Monday 27 August 2007, Vitaly Bordug wrote:
> On Mon, 27 Aug 2007 11:57:19 +1000
>
> David Gibson wrote:
> > > + * Free Software Foundation; either version 2 of the License, or
> > > (at your
> > > + * option) any later version.
> > > + */
> >
> > Unless there really is something peculiar about the EPx bridge
> > compared to say the GP, EP and other 4xx bridges, this should have a
> > more general name.
>
> well, I'd rather extend the name once/when it would be validated to work on
> those GR, EP etc. But, if preferred, it does not hurt to change all the
> prefixes to ppc4xx_ with such a sole implementation, and fork() if required
> later.
>
> opinions?
I would prefer to move to a more generic name now (as already suggest).
Perhaps somebody (Josh?) has a chance to test this on Bamboo (440EP) soon.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: David Gibson @ 2007-08-27 7:49 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827103136.4e0ffc43@localhost.localdomain>
On Mon, Aug 27, 2007 at 10:31:36AM +0400, Vitaly Bordug wrote:
> On Mon, 27 Aug 2007 11:15:16 +1000
> David Gibson wrote:
>
> > On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
[snip]
> > > +void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> > > *hose,
> > > + struct device_node
> > > *dev, int prim) +{
> > > + static unsigned int static_lc_ranges[256];
> > > + const unsigned int *ranges;
> > > + unsigned int *lc_ranges;
> > > + unsigned int pci_space;
> > > + unsigned long size = 0;
> >
> > size can be 64-bit on 32-bit systems, at least in theory.
> >
> hm, well, but later, we'll call ioremap (at least for IO region) that has size passed as ulong type. And, such a size could be consumed by the code,only if resource_size_t is 64bit too. I'll look at it further.
You should probably actually test for that condition though, rather
than blithely truncating.
[snip]
> > > + /* Map ranges to struct according to spec. */
> > > + if (na >= 2) {
> > > + ranges64 = (void *)ranges;
> > > + ranges_amnt = rlen / sizeof(*ranges64);
> > > + } else {
> > > + ranges32 = (void *)ranges;
> > > + ranges_amnt = rlen / sizeof(*ranges32);
> > > + }
> > > +
> > > + hose->io_base_phys = 0;
> > > + for (i = 0; i < ranges_amnt; i++) {
> > > + res = NULL;
> > > + if (ranges64) {
> > > + if (ranges64[i].pci_space == 0)
> > > + continue;
> > > +
> > > + pci_space = ranges64[i].pci_space;
> > > + pci_addr =
> > > + (u64) ranges64[i].pci_addr[0] << 32 |
> > > ranges64[i].
> > > + pci_addr[1];
> >
> > Why not just define the pci_addr field in your structures as u64? You
> > would have to define the structure with attribute((packed)), I guess.
> >
> that was in the first approach, but it gets really interesting numbers (and with contents nothing to do with real stuff),
> on platforms that are pure 32bit. I mean,
I'm guessing that's because you didn't put the ((packed)) in: without
it, gcc will align the 64-bit quantity to a 64-bit boundary, inserting
32-bits of padding into the structure between pci_space and pci_addr,
so that it doesn't actually line up with the ranges property.
> u32 foo, foo1;
> u64 foo64;
>
> foo = bar[1];
> foo1 = bar[2];
> foo64 = ((u64)foo << 32) | foo1;
>
> does not seem to work on 32bit board. I may need to write a clear testcase and submit it here, maybe I'm missing something
> very obvious.
!?! shouldn't be anything wrong with that arithmetic...
[snip]
> > > + cpu_phys_addr =
> > > + of_translate_address(dev,
> > > ranges64[i].phys_addr);
> > > + /*
> > > + * I haven't observed 2 significant size
> > > cells in kernel
> > > + * code, so we're accounting only LSB of
> > > size part
> > > + * from ranges. -vitb
> > > + */
> > > + size = ranges64[i].size[1];
> > > +#ifdef CONFIG_PPC64
> > > + if (ranges64[i].size[0])
> > > + size |= ranges64[i].size[0]<<32;
> > > +#endif
> > > + DBG("Observed: pci %llx phys %llx size
> > > %x\n", pci_addr,
> > > + cpu_phys_addr, size);
> > > + } else {
> > > + if (ranges32[i].pci_space == 0)
> > > + continue;
> > > +
> > > + pci_space = (unsigned
> > > int)ranges32[i].pci_space;
> > > + pci_addr = (unsigned
> > > int)ranges32[i].pci_addr[1];
> > > + cpu_phys_addr = (unsigned
> > > int)ranges32[i].phys_addr[0];
> >
> >
> > We should really be using of_translate_address() in all cases - that's
> > what it's for, after all.
> >
> being called, it gives 0 in 32bit branch of if () {. Since, iirc,
> 32bit range parsing does not have it in original, variant,
> I have it put as is. worths a brief investigation...
Then we should fix of_translate_address() for 32-bit....
I don't think this patch is actually required for the 44x pci support,
yes? It might be better to leave this until later - it's only a tiny
piece of all the consolidations we should do between ppc32 and ppc64
PCI code. Currently there are a lot of silly, subtle differences
between them :(.
> > > + size = ranges32[i].size[1];
> > > +
> > > + DBG("Observed: pci %x phys %x size %x\n",
> > > + (u32) pci_addr, (u32) cpu_phys_addr,
> > > size);
> > > + }
> >
> > You don't have any equivalent of the code that exists in both
> > pre-existing versions to coalesce contiguous ranges. You probably
> > want to use the 64-bit version, since that doesn't need a local copy
> > of the ranges.
> >
> correct. yet, the whole aim of the upper seems to use summary size of
> contiguous block and that's it.
> How would we recognize IORESOURCE_PREFETCH then? (I know, my code is missing that prefetch regions so far, but anyway).
> >From the code, it seems to declare each resource that is part of contiguous block, with the size of entire block.
>
> That's prolly from binding, but can you please elaborate the logic for better understanding?
The attributes such as PREFETCH are encoded into cell 0 of the 3-cell
OF PCI address. So, ranges with different attributes won't appear as
contiguous in this space.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Tim Teulings @ 2007-08-27 7:14 UTC (permalink / raw)
To: Michal Piotrowski, Rogério Brito, linux-kernel, linuxppc-dev,
debian-powerpc, Rafael J. Wysocki, Linux-pm mailing list
In-Reply-To: <20070827065246.GA21220@ime.usp.br>
Hallo!
I also have 800MHz iBook (2.2, 2 USB) and had the same problem with the=20
21.6.22 kernel a while ago and reverted back to 2.6.21. I'm not a kernel =
guy but I think I remember from kernel traces that it looked like (wise=20
chosen words ;-)) that the problems had something to do with=20
deactivating the firewire "subsystem".
I don't have traces at hand and due to lack of time cannot reproduce it=20
up to tomorrow. However this hint may speed up your analysis!
[rather long To-list, is everybody happy with this?]
--=20
Gru=DF...
Tim
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Rogério Brito @ 2007-08-27 6:52 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Rogério Brito, linux-kernel, Rafael J. Wysocki, linuxppc-dev,
debian-powerpc, Linux-pm mailing list
In-Reply-To: <6bffcb0e0708261621q25316becqce7b3ae2176f45a8@mail.gmail.com>
Hi, Thanks, Michal.
I didn't know who to include as the wizards of the matter.
On Aug 27 2007, Michal Piotrowski wrote:
> [Adding STR wizards to CC]
>
> On 26/08/07, Rogério Brito <rbrito@gmail.com> wrote:
> > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > taken from kernel.org), then I can't make the machine sleep: when I
> > press the button, it acts like if I had, in sequence, pressed anything
> > to wake it up (say, like pressing shift).
Things are getting now a little bit fishy.
Before, I was using gnome and all the little daemons that come with it
(even though I just prefer a plain window manager), but, as I mentioned
before, it didn't matter if I pressed the power button on X or on a
console.
I had the gnomee power-thingy sounding like an alarm (an ambulance!) on me
when I pressed the power button with Debian kernels 2.6.22, for instance. I
compiled my own (this time, from kernel.org) 2.6.23-rc3, with many modules
and subsystems removed (e.g., bluetooth, as this laptop doesn't have it)
and I got the exact same behavior.
If I booted, OTOH, with Debian's kernel 2.6.18, things were fine and the
machine would go to sleep without any problems.
I am now suspecting of some module that prevented the machine from going to
sleep and I now using just a fluxbox as my window manager. This time, even
with a 2.6.23-rc3 kernel (again, from kernel.org) the machine went to sleep
normally.
I did 13 compiles with git bisect and some of them were unsucessfuly
compiled, which I am afraid that may miss the real cause if I tag them as
being "bad" (which I did). (This was with just a bare minimum installation
of Debian).
The course of action that I am taking right now is to pull GNOME and see if
my current 23-rc3 kernel has any problems and see which modules are loaded.
If things progress well, I will incrementally include features on the
kernel that I need (I left out, for instance, the Firewire subsystem, so
that compilation wouldn't take more than an hour here, despite the fact
that I do need Firewire support on the kernel) and see the point where
things are not normal.
Again, I am willing to test anything that is useful to getting PowerPC
working as well as it should with the final 2.6.23 release.
Please, don't hesitate to ask for any further information.
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Vitaly Bordug @ 2007-08-27 6:55 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827015719.GD12804@localhost.localdomain>
On Mon, 27 Aug 2007 11:57:19 +1000
David Gibson wrote:
> > + * Free Software Foundation; either version 2 of the License, or
> > (at your
> > + * option) any later version.
> > + */
>
> Unless there really is something peculiar about the EPx bridge
> compared to say the GP, EP and other 4xx bridges, this should have a
> more general name.
well, I'd rather extend the name once/when it would be validated to work on those GR, EP etc.
But, if preferred, it does not hurt to change all the prefixes to ppc4xx_ with such a sole implementation,
and fork() if required later.
opinions?
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Vitaly Bordug @ 2007-08-27 6:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827015417.GB12804@localhost.localdomain>
On Mon, 27 Aug 2007 11:54:17 +1000
David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> >
> > arch/powerpc/boot/dts/sequoia.dts | 26 ++++++++++++++++++++++++++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/sequoia.dts
> > b/arch/powerpc/boot/dts/sequoia.dts index ef6f41c..8eb258f 100644
> > --- a/arch/powerpc/boot/dts/sequoia.dts
> > +++ b/arch/powerpc/boot/dts/sequoia.dts
> > @@ -92,6 +92,32 @@
> > #size-cells = <1>;
> > ranges;
> > clock-frequency = <0>; /* Filled in by zImage */
> > +
> > + pci {
> > + /* irqs are routed to irq67, dependless of
> > devsel/PIRQx */
> > + interrupt-map-mask = <0 0 0 0>;
> > + interrupt-map = <0 0 0 0 &UIC2 3
> > 8>; +
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <3 8>;
> > +
> > + bus-range = <0 0>;
> > +
> > + /*
> > + * mem is at 80000000 set up indirectly
> > + * io is at 0001_e800_0000
> > + */
> > + ranges = <02000000 0 80000000 1 80000000 0
> > 10000000
> > + 01000000 0 00000000 1 e8000000 0
> > 00100000>; +
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > +
> > + reg = <1 eec00000 40 1 ef400000
> > 40>; /* phb cfg, phb reg */
> > + compatible = "ibm, 440epx";
> > + device_type = "pci";
>
> I usually put device_type, compatible and reg at the top of the block,
> to announce what the node actually is before giving all the details.
>
ok
> Also, apart from the stray space in the compatible, I'm guessing that
> the 440EPx bridge is actually more-or-less like the PCI bridges on
> other 4xx chips, so we should have a more general compatible string
> too.
>
heh, with a sole PCI impl on 4xx it does not hurt to have more general
stuff here.
what is proposed, "amcc,4xx"?
> Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> should be reflected in the name and compatible as well.
>
"The 32-bit PCI bridge is compatible with he PCI Specification, Version
2.2 (it does not support 5V operation) "
so seems to be vanilla PCI.
> > + };
> >
> > SDRAM0: sdram {
> > device_type = "memory-controller";
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Stefan Roese @ 2007-08-27 6:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827062135.GC7306@localhost.localdomain>
On Monday 27 August 2007, David Gibson wrote:
> On Mon, Aug 27, 2007 at 08:07:17AM +0200, Stefan Roese wrote:
> [snip]
>
> > > I usually put device_type, compatible and reg at the top of the block,
> > > to announce what the node actually is before giving all the details.
> > >
> > > Also, apart from the stray space in the compatible, I'm guessing that
> > > the 440EPx bridge is actually more-or-less like the PCI bridges on
> > > other 4xx chips, so we should have a more general compatible string
> > > too.
> >
> > Yes, it is "more-or-less" like any other 4xx PCI core. So it really would
> > make sense to define it more generally. Something like:
> >
> > compatible = "ibm,pci-440epx", "ibm,pci4xx";
> >
> > or even:
> >
> > compatible = "ibm,pci-440epx", "ibm,pci";
> >
> > ?
>
> Hrm.. "xx" is ugly, and "ibm,pci" isn't specific enough. I think
> we're better off just using the oldest similar chip. Since this is
> vanilla PCI, I think that makes it "ibm,pci-405gp"
Fine with me.
> > > Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> > > should be reflected in the name and compatible as well.
> >
> > It's a vanilla PCI bridge.
>
> Ok, so it is different from 440GP which is PCI-X.
Yes. There are some common parts (IIRC), but there are differences. Perhaps
both, IBM-PCI and IBM-PCI-X can be integrated into one source too, but I
think we should start with PCI-only right now.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ 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