* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Olof Johansson @ 2006-09-29 20:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <451D7DE8.8020504@freescale.com>
On Fri, 29 Sep 2006 15:11:20 -0500 Timur Tabi <timur@freescale.com> wrote:
> I have a SATA drive attached to a PowerPC 8349E board, using the SIL 3114 controller. I'm running the latest code from Paul Mackerras (PowerPC maintainer) (2.6.18-blabla).
>
> I'm experiencing a number of I/O errors with the SATA drive. fdisk can see the partition table, but when I issue the "w" command, I get this output:
>
> The odd thing is that this works in 2.6.13, so something is broken. I don't know if it's a bug in the sata_sil driver, or a configuration issue. Can anyone help?
>
Do you use MSDOS or MAC partition (or other) type? Make sure you have
the one you use in the config.
It looks like the arch/powerpc/configs/mpc83* defconfigs enable neither.
-Olof
^ permalink raw reply
* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Timur Tabi @ 2006-09-29 20:29 UTC (permalink / raw)
To: Chris Boot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <BA55C0C9-B58F-473E-9412-B582411D017A@bootc.net>
Chris Boot wrote:
> Timur,
>
> fdisk manipulates DOS-style partition maps. Have you compiled these into
> your latest kernel? You don't actually have any errors in the below
> messages, other than the partition map being unreadable...
Yes, that was it! Thank you very much. All I had to do was select "PC BIOS (MSDOS partition tables) support" configuration option, and that was it.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Chris Boot @ 2006-09-29 20:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <451D7DE8.8020504@freescale.com>
Timur,
fdisk manipulates DOS-style partition maps. Have you compiled these
into your latest kernel? You don't actually have any errors in the
below messages, other than the partition map being unreadable...
Chris
On 29 Sep 2006, at 21:11, Timur Tabi wrote:
> I have a SATA drive attached to a PowerPC 8349E board, using the
> SIL 3114 controller. I'm running the latest code from Paul
> Mackerras (PowerPC maintainer) (2.6.18-blabla).
>
> I'm experiencing a number of I/O errors with the SATA drive. fdisk
> can see the partition table, but when I issue the "w" command, I
> get this output:
>
> Calling ioctl() to re-read partition table.
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> Syncing disks.
>
> I cannot mount any partitions. On boot, I see this:
>
> sata_sil 0000:00:10.0: Applying R_ERR on DMA activate FIS errata fix
> ata1: SATA max UDMA/100 cmd 0xD100E080 ctl 0xD100E08A bmdma
> 0xD100E000 irq 22
> ata2: SATA max UDMA/100 cmd 0xD100E0C0 ctl 0xD100E0CA bmdma
> 0xD100E008 irq 22
> ata3: SATA max UDMA/100 cmd 0xD100E280 ctl 0xD100E28A bmdma
> 0xD100E200 irq 22
> ata4: SATA max UDMA/100 cmd 0xD100E2C0 ctl 0xD100E2CA bmdma
> 0xD100E208 irq 22
> scsi0 : sata_sil
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth
> 0/32)
> ata1.00: ata1: dev 0 multi count 0
> ata1.00: configured for UDMA/100
> scsi1 : sata_sil
> ata2: SATA link down (SStatus 0 SControl 310)
> scsi2 : sata_sil
> ata3: SATA link down (SStatus 0 SControl 310)
> scsi3 : sata_sil
> ata4: SATA link down (SStatus 0 SControl 310)
> scsi 0:0:0:0: Direct-Access ATA HDT722516DLA380 V43O PQ:
> 0 ANSI: 5
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> sd 0:0:0:0: Attached scsi disk sda
> sd 0:0:0:0: Attached scsi generic sg0 type 0
>
> The odd thing is that this works in 2.6.13, so something is
> broken. I don't know if it's a bug in the sata_sil driver, or a
> configuration issue. Can anyone help?
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* Need help on PPC8343E bringup
From: Reeve Yang @ 2006-09-29 21:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following error
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
>BKM>
!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
Taken]
>BKM>
Does anyone has experiece to bring up this CPU, and could shed some lights
on it? Thank you in advance.
- Reeve
[-- Attachment #2: Type: text/html, Size: 822 bytes --]
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 21:33 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609291408w2dbf7e5ckf5e4cf7023d2000@mail.gmail.com>
>Hello linux-ppc experts,
>
>I'm trying to use using wind river jtag probe to download uboot to our
>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
>JTAG software I'm using is visionclick8.
>
>The problem now is that I even couldn't erash flash, with following error
>message:
>
>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
>Erasing Flash(s) ... Failed
>!ERROR! - [msg100000] Failed while erasing the device(s)
>>BKM>
>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
>Taken]
>>BKM>
>
>Does anyone has experiece to bring up this CPU, and could shed some lights
>on it? Thank you in advance.
>
>- Reeve
Your flash part[s] are almost certainly write-protected, or part of them
is. Get the data-sheet for them and find what combination to write to
them to un-protect them and try again. For the parts I'm using (micron
MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
the trick.
-michael
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 21:39 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <200609292133.k8TLXUUv072654@penguin.ncube.com>
>>Hello linux-ppc experts,
>>
>>I'm trying to use using wind river jtag probe to download uboot to our
>>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
>>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
>>JTAG software I'm using is visionclick8.
>>
>>The problem now is that I even couldn't erash flash, with following error
>>message:
>>
>>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
>>Erasing Flash(s) ... Failed
>>!ERROR! - [msg100000] Failed while erasing the device(s)
>>>BKM>
>>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
>>Taken]
>>>BKM>
>>
>>Does anyone has experiece to bring up this CPU, and could shed some lights
>>on it? Thank you in advance.
>>
>>- Reeve
>
>Your flash part[s] are almost certainly write-protected, or part of them
>is. Get the data-sheet for them and find what combination to write to
>them to un-protect them and try again. For the parts I'm using (micron
>MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
>the trick.
>
>-michael
I must be lonely, responding to my own email :-).
The other option you have is re-build u-boot to run from ram (presumably
at some lower address), then use u-boot itself to clear the write
protect bits on your flash. U-boot's makefile has config targets for
ram & flash for some target boards which you may be able to take
advantage of. My first solution is probably still quicker if you're not
trying to debug u-boot itself.
-michael
^ permalink raw reply
* [PATCH] Add DOS partition support to mpc834x_itx_defconfig
From: timur @ 2006-09-29 21:42 UTC (permalink / raw)
To: linuxppc-dev
From: Timur Tabi <timur@freescale.com>
The default configuration file for the MPC8349E-mITX reference board,
mpc834x_itx_defconfig, did not include support for DOS partition types.
This support is necessary because the hard drive that comes with the ITX
is formatted with this partition type. Without this config option,
the drive cannot be mounted.
---
arch/powerpc/configs/mpc834x_itx_defconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
index cd3535e..0561b73 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -1248,7 +1248,7 @@ # CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
-# CONFIG_MSDOS_PARTITION is not set
+CONFIG_MSDOS_PARTITION=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
--
1.4.2.1
^ permalink raw reply related
* Re: Need help on PPC8343E bringup
From: Reeve Yang @ 2006-09-29 22:03 UTC (permalink / raw)
To: Michael Galassi; +Cc: linuxppc-embedded
In-Reply-To: <200609292139.k8TLdV10081103@penguin.ncube.com>
[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]
Thanks Machael.
On my flash data sheet, there are some command about security:
Lock Block | Block Address | 0060h | Block Address | 0001h
Unlock Block|Block Address| 0060h | Block Address | 00d0h
So I guess it needs two write cycle to perfomr the command, and the unlock
command should be 006000d0. I tried that but still get the same error. Bad!
:(
Another questions is that is there any way to change CPU register directy?
For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
change on 0Xff400c08, but visionclick reject me to write on that address.
- Reeve
On 9/29/06, Michael Galassi <mgalassi@c-cor.com> wrote:
>
>
> >>Hello linux-ppc experts,
> >>
> >>I'm trying to use using wind river jtag probe to download uboot to our
> >>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
> >>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M.
> The
> >>JTAG software I'm using is visionclick8.
> >>
> >>The problem now is that I even couldn't erash flash, with following
> error
> >>message:
> >>
> >>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
> >>Erasing Flash(s) ... Failed
> >>!ERROR! - [msg100000] Failed while erasing the device(s)
> >>>BKM>
> >>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404
> [EVENT
> >>Taken]
> >>>BKM>
> >>
> >>Does anyone has experiece to bring up this CPU, and could shed some
> lights
> >>on it? Thank you in advance.
> >>
> >>- Reeve
> >
> >Your flash part[s] are almost certainly write-protected, or part of them
> >is. Get the data-sheet for them and find what combination to write to
> >them to un-protect them and try again. For the parts I'm using (micron
> >MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
> >the trick.
> >
> >-michael
>
> I must be lonely, responding to my own email :-).
>
> The other option you have is re-build u-boot to run from ram (presumably
> at some lower address), then use u-boot itself to clear the write
> protect bits on your flash. U-boot's makefile has config targets for
> ram & flash for some target boards which you may be able to take
> advantage of. My first solution is probably still quicker if you're not
> trying to debug u-boot itself.
>
> -michael
>
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 22:14 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609291503s7be0200ehf72925c2cae07787@mail.gmail.com>
>Thanks Machael.
>
>On my flash data sheet, there are some command about security:
>
>Lock Block | Block Address | 0060h | Block Address | 0001h
>Unlock Block|Block Address| 0060h | Block Address | 00d0h
>
>So I guess it needs two write cycle to perfomr the command, and the unlock
>command should be 006000d0. I tried that but still get the same error. Bad!
>:(
>
>Another questions is that is there any way to change CPU register directy?
>For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
>change on 0Xff400c08, but visionclick reject me to write on that address.
>
>- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
^ permalink raw reply
* RE: Need help on PPC8343E bringup
From: Mathews, Phil @ 2006-09-29 22:43 UTC (permalink / raw)
To: Michael Galassi, Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <200609292214.k8TMEZfw006857@penguin.ncube.com>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
From: linuxppc-embedded-bounces+phil.mathews=innocon.com@ozlabs.org on behalf of Michael Galassi
Sent: Fri 9/29/2006 6:14 PM
To: Reeve Yang
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Need help on PPC8343E bringup
>Thanks Machael.
>
>On my flash data sheet, there are some command about security:
>
>Lock Block | Block Address | 0060h | Block Address | 0001h
>Unlock Block|Block Address| 0060h | Block Address | 00d0h
>
>So I guess it needs two write cycle to perfomr the command, and the unlock
>command should be 006000d0. I tried that but still get the same error. Bad!
>:(
>
>Another questions is that is there any way to change CPU register directy?
>For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
>change on 0Xff400c08, but visionclick reject me to write on that address.
>
>- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
Actually the comands should be:
mw l 0xff000000 0x00600060
mw l 0xff000000 0x00d000d0
BTW - you don't have to bellow the post, you can just type them quietly :-)
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2988 bytes --]
^ permalink raw reply
* [PATCH 0/6]: powerpc/cell spidernet ethernet patches
From: Linas Vepstas @ 2006-09-29 23:05 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
Please apply and forward upstream as appropriate.
Although these patches have not been baking in
any -mm tree, they have been tested and are
generally available as a part of the Cell SDK 2.0
overseen by Arnd Bergmann. (Arnd, if you want
to lend a voice of authority here, or to correct
me, please do so...)
The following sequence of six patches implement a
series of changes to the transmit side of the
spidernet ethernet device driver, significantly
improving performance for large packets.
This series of patches is almost identical to
those previously mailed on 18-20 August, with one
critical change: NAPI polling is used instead of
homegrown polling.
Although these patches improve things, I am not
satisfied with how this driver behaves, and so
plan to do additional work next week.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
--linas
^ permalink raw reply
* [PATCH 1/6]: powerpc/cell spidernet burst alignment patch.
From: Linas Vepstas @ 2006-09-29 23:15 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
This patch increases the Burst Address alignment from 64 to 1024 in the
Spidernet driver. This improves transmit performance for large packets.
From: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 14:11:21.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 16:33:49.000000000 -0500
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000002
+#define SPIDER_NET_GDTDCEIDIS 0x00000302
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
^ permalink raw reply
* [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-09-29 23:17 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Implement basic low-watermark support for the transmit queue.
Hardware low-watermarks allow a properly configured kernel
to continously stream data to a device and not have to handle
any interrupts at all in doing so. Correct zero-interrupt
operation can be actually observed for this driver, when the
socket buffer is made large enough.
The basic idea of a low-watermark interrupt is as follows.
The device driver queues up a bunch of packets for the hardware
to transmit, and then kicks the hardware to get it started.
As the hardware drains the queue of pending, untransmitted
packets, the device driver will want to know when the queue
is almost empty, so that it can queue some more packets.
If the queue drains down to the low waterark, then an interrupt
will be generated. However, if the kernel/driver continues
to add enough packets to keep the queue partially filled,
no interrupt will actually be generated, and the hardware
can continue streaming packets indefinitely in this mode.
The impelmentation is done by setting the DESCR_TXDESFLG flag
in one of the packets. When the hardware sees this flag, it will
interrupt the device driver. Because this flag is on a fixed
packet, rather than at fixed location in the queue, the
code below needs to move the flag as more packets are
queued up. This implementation attempts to keep the flag
at about 1/4 from "empty".
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 56 ++++++++++++++++++++++++++++++++++++++++++-----
drivers/net/spider_net.h | 6 +++--
2 files changed, 55 insertions(+), 7 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 14:11:20.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:46.000000000 -0500
@@ -703,6 +703,39 @@ spider_net_release_tx_descr(struct spide
dev_kfree_skb_any(skb);
}
+static void
+spider_net_set_low_watermark(struct spider_net_card *card)
+{
+ int status;
+ int cnt=0;
+ int i;
+ struct spider_net_descr *descr = card->tx_chain.tail;
+
+ /* Measure the length of the queue. */
+ while (descr != card->tx_chain.head) {
+ status = descr->dmac_cmd_status & SPIDER_NET_DESCR_NOT_IN_USE;
+ if (status == SPIDER_NET_DESCR_NOT_IN_USE)
+ break;
+ descr = descr->next;
+ cnt++;
+ }
+ if (cnt == 0)
+ return;
+
+ /* Set low-watermark 3/4th's of the way into the queue. */
+ descr = card->tx_chain.tail;
+ cnt = (cnt*3)/4;
+ for (i=0;i<cnt; i++)
+ descr = descr->next;
+
+ /* Set the new watermark, clear the old wtermark */
+ descr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
+ if (card->low_watermark && card->low_watermark != descr)
+ card->low_watermark->dmac_cmd_status =
+ card->low_watermark->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
+ card->low_watermark = descr;
+}
+
/**
* spider_net_release_tx_chain - processes sent tx descriptors
* @card: adapter structure
@@ -720,6 +753,7 @@ spider_net_release_tx_chain(struct spide
{
struct spider_net_descr_chain *chain = &card->tx_chain;
int status;
+ int rc=0;
spider_net_read_reg(card, SPIDER_NET_GDTDMACCNTR);
@@ -732,8 +766,10 @@ spider_net_release_tx_chain(struct spide
break;
case SPIDER_NET_DESCR_CARDOWNED:
- if (!brutal)
- return 1;
+ if (!brutal) {
+ rc = 1;
+ goto done;
+ }
/* fallthrough, if we release the descriptors
* brutally (then we don't care about
* SPIDER_NET_DESCR_CARDOWNED) */
@@ -750,12 +786,15 @@ spider_net_release_tx_chain(struct spide
default:
card->netdev_stats.tx_dropped++;
- return 1;
+ rc = 1;
+ goto done;
}
spider_net_release_tx_descr(card);
}
-
- return 0;
+done:
+ if (rc == 1)
+ spider_net_set_low_watermark(card);
+ return rc;
}
/**
@@ -1460,6 +1499,10 @@ spider_net_interrupt(int irq, void *ptr,
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
+ if (status_reg & SPIDER_NET_TXINT ) {
+ spider_net_cleanup_tx_ring(card);
+ netif_wake_queue(netdev);
+ }
if (status_reg & SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
@@ -1621,6 +1664,9 @@ spider_net_open(struct net_device *netde
if (spider_net_init_chain(card, &card->tx_chain, card->descr,
PCI_DMA_TODEVICE, card->tx_desc))
goto alloc_tx_failed;
+
+ card->low_watermark = NULL;
+
if (spider_net_init_chain(card, &card->rx_chain,
card->descr + card->rx_desc,
PCI_DMA_FROMDEVICE, card->rx_desc))
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 14:47:50.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 16:33:43.000000000 -0500
@@ -47,7 +47,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_TX_DESCRIPTORS_MIN 16
#define SPIDER_NET_TX_DESCRIPTORS_MAX 512
-#define SPIDER_NET_TX_TIMER 20
+#define SPIDER_NET_TX_TIMER (HZ/5)
#define SPIDER_NET_RX_CSUM_DEFAULT 1
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000302
+#define SPIDER_NET_GDTDCEIDIS 0x00000300
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
@@ -349,6 +349,7 @@ enum spider_net_int2_status {
#define SPIDER_NET_DESCR_FORCE_END 0x50000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_CARDOWNED 0xA0000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_NOT_IN_USE 0xF0000000
+#define SPIDER_NET_DESCR_TXDESFLG 0x00800000
struct spider_net_descr {
/* as defined by the hardware */
@@ -433,6 +434,7 @@ struct spider_net_card {
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
+ struct spider_net_descr *low_watermark;
struct net_device_stats netdev_stats;
^ permalink raw reply
* [PATCH 3/6]: powerpc/cell spidernet stop error printing patch.
From: Linas Vepstas @ 2006-09-29 23:19 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Turn off mis-interpretation of the queue-empty interrupt
status bit as an error. This bit is set as a part of
the previous low-watermark patch.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 15:01:55.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:43.000000000 -0500
@@ -1282,12 +1282,15 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_PHYINT:
case SPIDER_NET_GMAC2INT:
case SPIDER_NET_GMAC1INT:
- case SPIDER_NET_GIPSINT:
case SPIDER_NET_GFIFOINT:
case SPIDER_NET_DMACINT:
case SPIDER_NET_GSYSINT:
break; */
+ case SPIDER_NET_GIPSINT:
+ show_error = 0;
+ break;
+
case SPIDER_NET_GPWOPCMPINT:
/* PHY write operation completed */
show_error = 0;
@@ -1346,9 +1349,10 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GDTDCEINT:
/* chain end. If a descriptor should be sent, kick off
* tx dma
- if (card->tx_chain.tail == card->tx_chain.head)
+ if (card->tx_chain.tail != card->tx_chain.head)
spider_net_kick_tx_dma(card);
- show_error = 0; */
+ */
+ show_error = 0;
break;
/* case SPIDER_NET_G1TMCNTINT: not used. print a message */
@@ -1462,8 +1466,9 @@ spider_net_handle_error_irq(struct spide
}
if ((show_error) && (netif_msg_intr(card)))
- pr_err("Got error interrupt, GHIINT0STS = 0x%08x, "
+ pr_err("Got error interrupt on %s, GHIINT0STS = 0x%08x, "
"GHIINT1STS = 0x%08x, GHIINT2STS = 0x%08x\n",
+ card->netdev->name,
status_reg, error_reg1, error_reg2);
/* clear interrupt sources */
^ permalink raw reply
* [PATCH 4/6]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-09-29 23:21 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
From: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 3 +++
drivers/net/spider_net.h | 2 ++
drivers/net/spider_net_ethtool.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 15:05:05.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:39.000000000 -0500
@@ -55,6 +55,7 @@ MODULE_AUTHOR("Utz Bacher <utz.bacher@de
"<Jens.Osterkamp@de.ibm.com>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT;
static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT;
@@ -2303,6 +2304,8 @@ static struct pci_driver spider_net_driv
*/
static int __init spider_net_init(void)
{
+ printk("spidernet Version %s.\n",VERSION);
+
if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MIN) {
rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_MIN;
pr_info("adjusting rx descriptors to %i.\n", rx_descriptors);
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 15:01:55.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 15:18:12.000000000 -0500
@@ -24,6 +24,8 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
+#define VERSION "1.1 A"
+
#include "sungem_phy.h"
extern int spider_net_stop(struct net_device *netdev);
Index: linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net_ethtool.c 2006-09-29 14:11:18.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c 2006-09-29 15:18:12.000000000 -0500
@@ -76,7 +76,7 @@ spider_net_ethtool_get_drvinfo(struct ne
/* clear and fill out info */
memset(drvinfo, 0, sizeof(struct ethtool_drvinfo));
strncpy(drvinfo->driver, spider_net_driver_name, 32);
- strncpy(drvinfo->version, "0.1", 32);
+ strncpy(drvinfo->version, VERSION, 32);
strcpy(drvinfo->fw_version, "no information");
strncpy(drvinfo->bus_info, pci_name(card->pdev), 32);
}
^ permalink raw reply
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Tom Rini @ 2006-09-29 23:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060927234304.0cf4d22d.kim.phillips@freescale.com>
On Wed, Sep 27, 2006 at 11:43:04PM -0500, Kim Phillips wrote:
> On Wed, 27 Sep 2006 08:58:53 -0700
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> > > On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> > [snip]
> > > > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > > > powerpc/platforms/83xx/mpc834x_itx.c
> > > > index 969fbb6..8c676d7 100644
> > > > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > > > return 1;
> > > > }
> > > >
> > > > +#ifdef CONFIG_RTC_CLASS
> > > > +late_initcall(rtc_class_hookup);
> > > > +#endif
> > >
> > > Any reason we can't just do this in setup_arch?
> >
> > I think because of rtc-over-i2c and similar where we need the whole rest
> > of the system 'up' before we can try and use the RTC (which might not be
> > the case for this specific board, but for consistency it looks like a
> > good thing to always do it like this).
> >
> this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine. In the early assignment case, the kernel oopses early in rtc_class_open().
>
> During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions. Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:
>
> http://lkml.org/lkml/2005/12/20/220
>
> so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).
>
> So we should just configure RTC_CLASS and the specific chip and we're done. :)
Does this mean we can then rip out some existing code, so long as
there's associated cleanup / rtc class support additions?
--
Tom Rini
^ permalink raw reply
* [PATCH 5/6]: powerpc/cell spidernet ethtool -i version number
From: Linas Vepstas @ 2006-09-29 23:26 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Jim, as the official maintainer, you should explicitly ack this patch.
--linas
This patch moves transmit queue cleanup code out of the
interrupt context, and into the NAPI polling routine.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 17:01:39.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 17:39:06.000000000 -0500
@@ -887,9 +887,10 @@ out:
* spider_net_cleanup_tx_ring - cleans up the TX ring
* @card: card structure
*
- * spider_net_cleanup_tx_ring is called by the tx_timer (as we don't use
- * interrupts to cleanup our TX ring) and returns sent packets to the stack
- * by freeing them
+ * spider_net_cleanup_tx_ring is called by either the tx_timer
+ * or from the NAPI polling routine.
+ * This routine releases resources associted with transmitted
+ * packets, including updating the queue tail pointer.
*/
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
@@ -1093,6 +1094,7 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
+ spider_net_cleanup_tx_ring(card);
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1505,10 +1507,8 @@ spider_net_interrupt(int irq, void *ptr,
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
- if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
- }
+ if (status_reg & SPIDER_NET_TXINT)
+ netif_rx_schedule(netdev);
if (status_reg & SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
^ permalink raw reply
* [PATCH 6/6]: powerpc/cell spidernet refine locking
From: Linas Vepstas @ 2006-09-29 23:29 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
The transmit side of the spider ethernet driver currently
places locks around some very large chunks of code. This
results in a fair amount of lock contention is some cases.
This patch makes the locks much more fine-grained, protecting
only the cirtical sections. One lock is used to protect
three locations: the queue head and tail pointers, and the
queue low-watermark location.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 77 ++++++++++++++++++++---------------------------
1 file changed, 34 insertions(+), 43 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 17:39:06.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 17:41:19.000000000 -0500
@@ -646,8 +646,9 @@ static int
spider_net_prepare_tx_descr(struct spider_net_card *card,
struct sk_buff *skb)
{
- struct spider_net_descr *descr = card->tx_chain.head;
+ struct spider_net_descr *descr;
dma_addr_t buf;
+ unsigned long flags;
buf = pci_map_single(card->pdev, skb->data, skb->len, PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(buf)) {
@@ -658,6 +659,10 @@ spider_net_prepare_tx_descr(struct spide
return -ENOMEM;
}
+ spin_lock_irqsave(&card->tx_chain.lock, flags);
+ descr = card->tx_chain.head;
+ card->tx_chain.head = card->tx_chain.head->next;
+
descr->buf_addr = buf;
descr->buf_size = skb->len;
descr->next_descr_addr = 0;
@@ -666,6 +671,8 @@ spider_net_prepare_tx_descr(struct spide
descr->dmac_cmd_status =
SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
+ spin_unlock_irqrestore(&card->tx_chain.lock, flags);
+
if (skb->protocol == htons(ETH_P_IP))
switch (skb->nh.iph->protocol) {
case IPPROTO_TCP:
@@ -676,37 +683,16 @@ spider_net_prepare_tx_descr(struct spide
break;
}
+ /* Chain the bus address, so that the DMA engine finds this descr. */
descr->prev->next_descr_addr = descr->bus_addr;
return 0;
}
-/**
- * spider_net_release_tx_descr - processes a used tx descriptor
- * @card: card structure
- * @descr: descriptor to release
- *
- * releases a used tx descriptor (unmapping, freeing of skb)
- */
-static inline void
-spider_net_release_tx_descr(struct spider_net_card *card)
-{
- struct spider_net_descr *descr = card->tx_chain.tail;
- struct sk_buff *skb;
-
- card->tx_chain.tail = card->tx_chain.tail->next;
- descr->dmac_cmd_status |= SPIDER_NET_DESCR_NOT_IN_USE;
-
- /* unmap the skb */
- skb = descr->skb;
- pci_unmap_single(card->pdev, descr->buf_addr, skb->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb_any(skb);
-}
-
static void
spider_net_set_low_watermark(struct spider_net_card *card)
{
+ unsigned long flags;
int status;
int cnt=0;
int i;
@@ -730,11 +716,13 @@ spider_net_set_low_watermark(struct spid
descr = descr->next;
/* Set the new watermark, clear the old wtermark */
+ spin_lock_irqsave(&card->tx_chain.lock, flags);
descr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
if (card->low_watermark && card->low_watermark != descr)
card->low_watermark->dmac_cmd_status =
card->low_watermark->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
card->low_watermark = descr;
+ spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
/**
@@ -753,22 +741,30 @@ static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
struct spider_net_descr_chain *chain = &card->tx_chain;
+ struct spider_net_descr *descr;
+ struct sk_buff *skb;
+ u32 buf_addr;
+ unsigned long flags;
int status;
int rc=0;
spider_net_read_reg(card, SPIDER_NET_GDTDMACCNTR);
while (chain->tail != chain->head) {
- status = spider_net_get_descr_status(chain->tail);
+ spin_lock_irqsave(&chain->lock, flags);
+ descr = chain->tail;
+
+ status = spider_net_get_descr_status(descr);
switch (status) {
case SPIDER_NET_DESCR_COMPLETE:
card->netdev_stats.tx_packets++;
- card->netdev_stats.tx_bytes += chain->tail->skb->len;
+ card->netdev_stats.tx_bytes += descr->skb->len;
break;
case SPIDER_NET_DESCR_CARDOWNED:
if (!brutal) {
rc = 1;
+ spin_unlock_irqrestore(&chain->lock, flags);
goto done;
}
/* fallthrough, if we release the descriptors
@@ -788,9 +784,19 @@ spider_net_release_tx_chain(struct spide
default:
card->netdev_stats.tx_dropped++;
rc = 1;
+ spin_unlock_irqrestore(&chain->lock, flags);
goto done;
}
- spider_net_release_tx_descr(card);
+
+ chain->tail = chain->tail->next;
+ descr->dmac_cmd_status |= SPIDER_NET_DESCR_NOT_IN_USE;
+ skb = descr->skb;
+ buf_addr = descr->buf_addr;
+ spin_unlock_irqrestore(&chain->lock, flags);
+
+ /* unmap the skb */
+ pci_unmap_single(card->pdev, buf_addr, skb->len, PCI_DMA_TODEVICE);
+ dev_kfree_skb_any(skb);
}
done:
if (rc == 1)
@@ -847,11 +853,8 @@ spider_net_xmit(struct sk_buff *skb, str
struct spider_net_card *card = netdev_priv(netdev);
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr = chain->head;
- unsigned long flags;
int result;
- spin_lock_irqsave(&chain->lock, flags);
-
spider_net_release_tx_chain(card, 0);
if (chain->head->next == chain->tail->prev) {
@@ -873,12 +876,9 @@ spider_net_xmit(struct sk_buff *skb, str
}
result = NETDEV_TX_OK;
-
spider_net_kick_tx_dma(card);
- card->tx_chain.head = card->tx_chain.head->next;
out:
- spin_unlock_irqrestore(&chain->lock, flags);
netif_wake_queue(netdev);
return result;
}
@@ -895,15 +895,9 @@ out:
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
{
- unsigned long flags;
-
- spin_lock_irqsave(&card->tx_chain.lock, flags);
-
if ((spider_net_release_tx_chain(card, 0) != 0) &&
(card->netdev->flags & IFF_UP))
spider_net_kick_tx_dma(card);
-
- spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
/**
@@ -1930,10 +1924,7 @@ spider_net_stop(struct net_device *netde
spider_net_disable_rxdmac(card);
/* release chains */
- if (spin_trylock(&card->tx_chain.lock)) {
- spider_net_release_tx_chain(card, 1);
- spin_unlock(&card->tx_chain.lock);
- }
+ spider_net_release_tx_chain(card, 1);
spider_net_free_chain(card, &card->tx_chain);
spider_net_free_chain(card, &card->rx_chain);
^ permalink raw reply
* Re: [PATCH] move drivers/macintosh variables to BSS
From: Paul Mackerras @ 2006-09-30 0:41 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060926201554.GA886@aepfle.de>
Olaf Hering writes:
> --- linux-2.6.18.orig/drivers/macintosh/ans-lcd.c
> +++ linux-2.6.18/drivers/macintosh/ans-lcd.c
> @@ -21,8 +21,8 @@
> #define ANSLCD_CTRL_IX 0x00
> #define ANSLCD_DATA_IX 0x10
>
> -static unsigned long anslcd_short_delay = 80;
> -static unsigned long anslcd_long_delay = 3280;
> +static unsigned long anslcd_short_delay;
> +static unsigned long anslcd_long_delay;
> static volatile unsigned char __iomem *anslcd_ptr;
>
> #undef DEBUG
> @@ -164,6 +164,8 @@ anslcd_init(void)
> printk(KERN_DEBUG "LCD: init\n");
> #endif
>
> + anslcd_short_delay = 80;
> + anslcd_long_delay = 3280;
What's the point of this? I can understand removing redundant "= 0"
initializers, but why fatten the code by 3 instructions just to remove
1 word from the data section?
Paul.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-09-30 0:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C62AC4D8-39E5-44D0-88A3-E8D8042FC828@kernel.crashing.org>
Kumar Gala writes:
> However, I'm not sure this really needs a node in the device tree.
> The BCSR isn't really the same from board to board last time I
> checked. I'd be interested in Paul's thinking about why it should be
> in the tree.
I just have a general preference for putting device addresses in the
device tree, because it increases the chance that you can reuse code
for multiple boards. If the BCSR is always completely unique on every
board then there isn't so much of an argument for it, I agree.
Paul.
^ permalink raw reply
* [PATCH] Fix boot wrapper invocation if CROSS_COMPILE contains spaces
From: Michael Ellerman @ 2006-09-30 1:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
My CROSS_COMPILE is "ccache /opt/compilers/blah", which confuses
the boot wrapper script. Quote CROSS_COMPILE and CROSS32_COMPILE
so they can safely contain spaces.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/boot/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: to-merge/arch/powerpc/boot/Makefile
===================================================================
--- to-merge.orig/arch/powerpc/boot/Makefile
+++ to-merge/arch/powerpc/boot/Makefile
@@ -105,10 +105,10 @@ wrapperbits := $(extra-y) $(addprefix $(
# Bits for building various flavours of zImage
ifneq ($(CROSS32_COMPILE),)
-CROSSWRAP := -C $(CROSS32_COMPILE)
+CROSSWRAP := -C "$(CROSS32_COMPILE)"
else
ifneq ($(CROSS_COMPILE),)
-CROSSWRAP := -C $(CROSS_COMPILE)
+CROSSWRAP := -C "$(CROSS_COMPILE)"
endif
endif
^ permalink raw reply
* Re: [PATCH 6/6]: powerpc/cell spidernet refine locking
From: Andrew Morton @ 2006-09-30 2:47 UTC (permalink / raw)
To: Linas Vepstas
Cc: jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20060929232911.GN6433@austin.ibm.com>
On Fri, 29 Sep 2006 18:29:11 -0500
linas@austin.ibm.com (Linas Vepstas) wrote:
> The transmit side of the spider ethernet driver currently
> places locks around some very large chunks of code. This
> results in a fair amount of lock contention is some cases.
> This patch makes the locks much more fine-grained, protecting
> only the cirtical sections. One lock is used to protect
> three locations: the queue head and tail pointers, and the
> queue low-watermark location.
You have spider_net_set_low_watermark() walking the tx_chain outside
tx_chain.lock. Are you sure about that?
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Dan Malek @ 2006-09-28 4:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927112201.293fef44@localhost.localdomain>
On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:
> Yes, also called "board port hell".
I tend to think people skilled to do a board port
will still create something elegant and functional
given whatever the existing model.
> .... So you can boot the same kernel binary on
> several boards, as long as the drivers are built in and the correct
> device tree is used. Has everyone missed/forgotten that objective
> completely?
That was never an objective when we started, although
it seems some people involved in the implementation
think it's the only objective. It just happens to be a side
effect when convenient.
If you could look back over the eight or more years
of embedded Linux development with PowerPC, this
discussion of supporting multiple boards with
single binaries has occurred. In all cases, we never
considered it a requirement, there are many others
more important in embedded systems. Our greatest
concern was sharing code among all platforms, but
in a way we could still configure the most compact
and highest performance code for a particular
processor and board.
Although processors are faster and memory is larger
today, embedded systems are still trying to do more with
less. We still try to run the slowest processor speed to
conserve power and meet environmental requirements.
Memory still costs money, and designs try to use the
minimum amount to be cost competitive. IMHO, the same
requirements for compact and efficient code are just
as important today as they were when we had the first
discussion years ago. Conversion of the information,
kernel code just hanging around in case it may be used
on some board but not another and reliance on a
particular version of boot code are things we have
always tried to avoid. We are competing against other
processor architectures that are more compact and
resource friendly, it would be nice to not lose in
those product designs.
> The device tree describes the system, not how to program it. I think
> that's where the confusion might be.
There is no confusion. This device tree discussion was started
several years ago by a couple of us trying to find a way to better
describe the wide variety of PowerPC SOC processor peripheral
variants. Kumar and I had many discussions about this, since
my old static internal memory maps weren't going to work well.
The IBM microelectronics folks were also looking for something
similar. We thought a _simple_ flat device tree along with
the platform data would be sufficient to define this internal
peripheral mapping. I wasn't too keen on the idea, but didn't
have the time to provide any alternative implementation
against the Freescale coding machine :-)
Now, we have something that is way more complex than
we initially thought was necessary, trying to describe nearly
everything addressable in the system instead of just the
internal memory map. I suspect the software to attain
(IMHO the useless) goal of a single binary for multiple
boards will create exponentially complex software,
something that highly reliable embedded systems
are trying to avoid.
> I.e. create a generic "board-controller" device node, and put a
> suitable "compatible" property in there, so the right board controller
> driver can be chosen based on it. Having the address of the controller
> in there helps too, especially if there are two boards out there with
> the same controller but at different memory location.
What value does this provide to my client trying
to create a cost effective wireless home networking
device? It certainly doesn't make the board port
from hell any easier, since cramming the software
into 4M of flash will likely cause the choice of a
processor other than PowerPC that can configure
a smaller kernel and use a tiny custom piece of
boot code. Highly configurable development/evaluation
boards running a single binary aren't high volume
products, and the additional resources required
by such software could ensure real products aren't
developed with PPCs. We need to be sensitive
to this.
Thanks.
-- Dan
^ permalink raw reply
* RE: [PATCH 6/9] qe_lib: Add QE SoC support
From: Li Yang-r58472 @ 2006-09-30 4:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <46197B66-B634-444C-B63D-115CDD15F1B7@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, September 29, 2006 10:13 PM
> To: Li Yang-r58472
> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 6/9] qe_lib: Add QE SoC support
>=20
>=20
> On Sep 29, 2006, at 5:35 AM, Li Yang wrote:
>=20
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> >
> > ---
> > arch/powerpc/sysdev/qe_lib/qe.c | 176 ++++++++++++++++++++++++++++
> > +++++++++++
> > include/linux/fsl_devices.h | 39 ++++++++-
> > 2 files changed, 214 insertions(+), 1 deletions(-)
>=20
> As I've stated in the past make this use of_device instead of
> platform_device.
As I've argued before, there are currently many off-the-tree user of ppc
arch on 8360, and we must still support that. Change the ucc_geth
driver to use of_device will add the effort of maintaining two versions
of ucc_geth driver for us (one for ppc, one for powerpc). Do you really
think it is so important to replace platform_device with of_device? I
didn't see any true benefit of doing so.
- Leo
^ permalink raw reply
* Re: [PATCH 6/9] qe_lib: Add QE SoC support
From: Kumar Gala @ 2006-09-30 5:06 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19DB0D@zch01exm20.fsl.freescale.net>
On Sep 29, 2006, at 11:37 PM, Li Yang-r58472 wrote:
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, September 29, 2006 10:13 PM
>> To: Li Yang-r58472
>> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH 6/9] qe_lib: Add QE SoC support
>>
>>
>> On Sep 29, 2006, at 5:35 AM, Li Yang wrote:
>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>>>
>>> ---
>>> arch/powerpc/sysdev/qe_lib/qe.c | 176 ++++++++++++++++++++++++++++
>>> +++++++++++
>>> include/linux/fsl_devices.h | 39 ++++++++-
>>> 2 files changed, 214 insertions(+), 1 deletions(-)
>>
>> As I've stated in the past make this use of_device instead of
>> platform_device.
>
> As I've argued before, there are currently many off-the-tree user
> of ppc
> arch on 8360, and we must still support that. Change the ucc_geth
> driver to use of_device will add the effort of maintaining two
> versions
> of ucc_geth driver for us (one for ppc, one for powerpc). Do you
> really
> think it is so important to replace platform_device with of_device? I
> didn't see any true benefit of doing so.
I dont see why you need to maintain an arch/ppc version as everything
related to 8360 is arch/powerpc. If you guys have some internal
stuff that is your own issue to manage. This is a new device and
thus should use of_device. My goal is to eventually move the other
users of platform_device over to of_device when they aren't being
sured with arch/ppc in the public tree.
- kumar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox