* RE: BogoMIPS no longer supported on PowerPC?
From: Li Yang-r58472 @ 2006-08-23 10:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1156329453.3914.13.camel@ux156>
Ok, I rephrase my question as is it no longer needed? Sometimes people
may use this value as a rough estimation of CPU performance. There are
people even maintained a list of bogoMIPS of most CPUs. Maybe it is
still needed for some legacy reasons. I'm not very sure. :) At leave
we need to inform people who do look at this magic number and find it
amazingly low.
Best Regards,
Leo
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> Sent: Wednesday, August 23, 2006 6:38 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: BogoMIPS no longer supported on PowerPC?
>=20
> On Wed, 2006-08-23 at 18:25 +0800, Li Yang-r58472 wrote:
> > I noticed a recent modification to __delay has changed from using
empty
> > loops to reading timebase. Thus, breaks the calculation of
bogomips,
> > and makes it terribly low. Is the bogomips no longer being
supported on
> > powerpc arch?
>=20
> What's there to be 'supported'? The only purpose of bogomips is
> calibrating the delay loop, and that has changed now by using
timebase,
> hence bogomips no longer have a purpose. There was even a patch to
> remove it from /proc/cpuinfo but I'm not sure whether that got applied
> or not.
>=20
> johannes
^ permalink raw reply
* [PATCH] uninorth: Add module param 'aperture' for aperture size
From: Michel Dänzer @ 2006-08-23 11:15 UTC (permalink / raw)
To: davej; +Cc: linuxppc-dev
In-Reply-To: <1156285033.21752.107.camel@localhost.localdomain>
In contrast to most if not all PC BIOSes, OpenFirmware (OF) on PowerMacs with
UniNorth bridges does not allow changing the aperture size. The size set up by
OF is usually 16 MB, which is too low for graphics intensive environments.
Hence, add a module parameter that allows changing the aperture size at driver
initialization time. When the parameter is not specified, the default is 32 MB.
Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
---
Note that I made the default size 32 MB (instead of 64 MB as discussed on the
linuxppc-dev list) to make this patch independent of the other uninorth patch I
sent out.
drivers/char/agp/uninorth-agp.c | 54 +++++++++++++++++++++++++--------------
1 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 78c8cb2..4770187 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -27,32 +27,42 @@ #include "agp.h"
static int uninorth_rev;
static int is_u3;
+static char __devinitdata *aperture = NULL;
static int uninorth_fetch_size(void)
{
- int i;
- u32 temp;
- struct aper_size_info_32 *values;
-
- pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_BASE, &temp);
- temp &= ~(0xfffff000);
- values = A_SIZE_32(agp_bridge->driver->aperture_sizes);
-
- for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
- if (temp == values[i].size_value) {
- agp_bridge->previous_size =
- agp_bridge->current_size = (void *) (values + i);
- agp_bridge->aperture_size_idx = i;
- return values[i].size;
+ int i, size = 0;
+ struct aper_size_info_32 *values =
+ A_SIZE_32(agp_bridge->driver->aperture_sizes);
+
+ if (aperture) {
+ char *save = aperture;
+
+ size = memparse(aperture, &aperture) >> 20;
+ aperture = save;
+
+ for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
+ if (size == values[i].size)
+ break;
+
+ if (i == agp_bridge->driver->num_aperture_sizes) {
+ printk(KERN_ERR PFX "Invalid aperture size, using"
+ " default\n");
+ size = 0;
+ aperture = NULL;
}
}
- agp_bridge->previous_size =
- agp_bridge->current_size = (void *) (values + 1);
- agp_bridge->aperture_size_idx = 1;
- return values[1].size;
+ if (!size) {
+ for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
+ if (32 == values[i].size)
+ break;
+ }
- return 0;
+ agp_bridge->previous_size =
+ agp_bridge->current_size = (void *)(values + i);
+ agp_bridge->aperture_size_idx = i;
+ return values[i].size;
}
static void uninorth_tlbflush(struct agp_memory *mem)
@@ -668,5 +678,11 @@ static void __exit agp_uninorth_cleanup(
module_init(agp_uninorth_init);
module_exit(agp_uninorth_cleanup);
+module_param(aperture, charp, 0);
+MODULE_PARM_DESC(aperture,
+ "Aperture size, must be power of two between 4MB and an\n"
+ "\t\tupper limit specific to the UniNorth revision.\n"
+ "\t\tDefault: 32M");
+
MODULE_AUTHOR("Ben Herrenschmidt & Paul Mackerras");
MODULE_LICENSE("GPL");
--
1.4.1.1
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
* RE: [PATCH] powerpc: update mpc7448hpc2 board irq support usingdevice tree
From: Zang Roy-r61911 @ 2006-08-23 11:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
In-Reply-To: <1156304338.8433.21.camel@localhost.localdomain>
>=20
> Same comment as the other patch, it looks like it got wrapped=20
> by your mailer. Also make sure you don't add trailing=20
> whitespaces (if you quilt, the latest version detects them=20
> and has an option to fix them up for you).
>=20
> Appart from that, what the patch does looks good.
>=20
> Cheers,
> Ben.
>=20
The issue is imported by my mail client (updated several days ago).
It is strange. I am tired. Hope to solve it tomorrow :-).
Roy
^ permalink raw reply
* Re: ioremap() fails for >64 MB
From: Dan Malek @ 2006-08-23 11:51 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: Matt Porter, linuxppc-embedded
In-Reply-To: <1156327238.6735.9.camel@lamorak.int.avalon.com.au>
On Aug 23, 2006, at 6:00 AM, Phil Nitschke wrote:
> Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit
> processor, why do I need high memory at all?
Because the processor used virtual memory addressing, and
we divide this 4G virtual space up among application, kernel,
IO mapping, etc. The kernel can't map the whole 4G (or even
the 2G) physical space at one time.
> I avoided this simply because I wanted to load/unload my driver
> (during
> development),
My personal preference is to debug drivers in a development
mode by building them into the kernel. I find it easier to debug,
and you are also likely to be rebooting anyway :-)
-- Dan
^ permalink raw reply
* I2C Linux driver on 8260
From: Boris Shteinbock @ 2006-08-23 12:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
Is there any chance, that some of you, guys,
have a working version of I2C driver for 8260/CPM2
for the latest kernels. The driver posted last year
doesn't seem to work for me: the bus is not identified.
Thanks a lot,
Boris
^ permalink raw reply
* Re: [PATCH ] powerpc: pass UPIO_TSI flag to 8259 serial driver
From: Paul Mackerras @ 2006-08-23 13:08 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: Yang Xin-Xin-r48390, linuxppc-dev list
In-Reply-To: <44EC15A1.4090807@freescale.com>
Zang Roy-r61911 writes:
> Sorry. It seems imported by my mail client. Please pick up the following
> one.
Still busted, but don't worry, I fixed it up by hand.
Paul.
^ permalink raw reply
* Re: ioremap() fails for >64 MB
From: Matt Porter @ 2006-08-23 14:05 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <44EB717D.3080800@dlasys.net>
On Tue, Aug 22, 2006 at 05:05:01PM -0400, David H. Lynch Jr. wrote:
> is ioremap() failing or is vmalloc failing ?
>
> ioremap should just assign a virtual address to a physical address -
> does it actually allocate anything ?
> I beleive I am ioremap()ing a greater than 64MB Flash ROM and I do
> not think it is failing.
ioremap() allocates virtual address space in order to be able to
do the assignment. The ability to allocate this vmalloc space
(which is used by ioremap() and vmalloc() calls) varies based
on amount of memory, etc. in a system. It also depends on how
good of a quality of a board port is done. It's possible to do
some very stupid things that constrict availability of vmalloc
space. So YMMV versus others.
-Matt
^ permalink raw reply
* Re: update: consolidated flat device tree code
From: Hollis Blanchard @ 2006-08-23 14:42 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Pantelis Antoniou, Sachin P. Sant,
linuxppc-embedded
In-Reply-To: <17643.64011.666743.300278@cargo.ozlabs.ibm.com>
On Wed, 2006-08-23 at 16:47 +1000, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > Still haven't looked to merge Matt's changes (because I'm busy, the
> > current code works for me, and they haven't been accepted in u-boot
> > yet).
>
> The other version that was posted had support for modifying an
> existing flat tree, which I need for the wrapper code for prep. Are
> those "Matt's changes"? Are you thinking of adding that capability to
> your version?
You can do this now with the ft_set_prop() function, which is what I'm
using for Xen.
At the moment that function isn't able to modify the size of a property,
but Mark is going to adapt his code (which supports that).
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Olof Johansson @ 2006-08-23 14:51 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC20C@zch01exm20.fsl.freescale.net>
On Wed, Aug 23, 2006 at 06:55:26PM +0800, Li Yang-r58472 wrote:
> Ok, I rephrase my question as is it no longer needed? Sometimes people
> may use this value as a rough estimation of CPU performance. There are
> people even maintained a list of bogoMIPS of most CPUs. Maybe it is
> still needed for some legacy reasons. I'm not very sure. :) At leave
> we need to inform people who do look at this magic number and find it
> amazingly low.
Bogomips has never had anything to do with performance on PPC, it's just
a number that's based on the decrementer frequency. For processors with
external/fixed decrementer clock, it will not vary between different
processors in a meaningful way.
Every now and then someone will ask "why does my PPC box have such low
bogomips, is it really that much slower than my PC?". Removing all output
would certainly help avoid that confusion.
For reference, my G5 here has 66.56 bogomips, which corresponds well to
the 33MHz decrementer clock it uses.
-Olof
^ permalink raw reply
* Re: booting with BootX corrupts memory
From: Olaf Hering @ 2006-08-23 14:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Niels Kristian Bech Jensen
In-Reply-To: <1156195877.21752.39.camel@localhost.localdomain>
On Tue, Aug 22, Benjamin Herrenschmidt wrote:
>
> > > No, now I dont even get console= output on serial console.
> >
> > It doesnt work on a 7200, butit works on a beige G3.
> > But later it locks up in 'PM: Adding info for No Bus:target0:0',
> > after mesh init. This one is likely unrelated.
>
> Depends.... does it work if you netboot a zImage.coff ?
Have to try that, but 2.6.16 freezes as well.
^ permalink raw reply
* Re: TEMAC problem on ML403 with U-boot.
From: Frank D Lombardo @ 2006-08-23 15:08 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F391AE6DCE84284F62F4FEAB2460@phx.gbl>
Ming Liu wrote:
> Dear Frank,
> In your ML403 design which is booted by U-boot, do you use the normal
> 10/100M Enet MAC or TEMAC? Is TEMAC supported by U-Boot 1.1.4? In my
> design I use TEMAC and it works well when I boot my Linux directly
> using Xilinx EDK bootloader. However it fails when using U-boot......
>
> Thanks for your telling.
>
> Regards
> Ming
>
> _________________________________________________________________
> 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
Ming,
The ML403 reference design from Xilinx uses the 10/100 Ethernet MAC and
works with U-Boot 1.1.4. The Xilinx GSRD design uses the ll_temac and it
does not work with U-Boot. We have decided that it would not be worth
the effort to port the ll_temac driver to work with U-Boot. However, if
anybody has done so, I would be interested.
Frank
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Tim Bird @ 2006-08-23 16:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1156329453.3914.13.camel@ux156>
Johannes Berg wrote:
> On Wed, 2006-08-23 at 18:25 +0800, Li Yang-r58472 wrote:
> > I noticed a recent modification to __delay has changed from using empty
> > loops to reading timebase. Thus, breaks the calculation of bogomips,
> > and makes it terribly low. Is the bogomips no longer being supported on
> > powerpc arch?
>
> What's there to be 'supported'? The only purpose of bogomips is
> calibrating the delay loop, and that has changed now by using timebase,
> hence bogomips no longer have a purpose. There was even a patch to
> remove it from /proc/cpuinfo but I'm not sure whether that got applied
> or not.
I missed the patch for this, but I have a related question.
What is the status of the calibration code now for PPC?
Is it just skipped?
I assume that the ability to set a preset loops_per_jiffy
is no longer relevant?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Li Yang @ 2006-08-23 16:46 UTC (permalink / raw)
Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <44EC8338.3050203@am.sony.com>
On 8/24/06, Tim Bird <tim.bird@am.sony.com> wrote:
> Johannes Berg wrote:
> > On Wed, 2006-08-23 at 18:25 +0800, Li Yang-r58472 wrote:
> > > I noticed a recent modification to __delay has changed from using empty
> > > loops to reading timebase. Thus, breaks the calculation of bogomips,
> > > and makes it terribly low. Is the bogomips no longer being supported on
> > > powerpc arch?
> >
> > What's there to be 'supported'? The only purpose of bogomips is
> > calibrating the delay loop, and that has changed now by using timebase,
> > hence bogomips no longer have a purpose. There was even a patch to
> > remove it from /proc/cpuinfo but I'm not sure whether that got applied
> > or not.
>
> I missed the patch for this, but I have a related question.
> What is the status of the calibration code now for PPC?
> Is it just skipped?
The calibration is still used.
>
> I assume that the ability to set a preset loops_per_jiffy
> is no longer relevant?
However, loop is no longer true loop now. It should be called
timebase_change_per_jiffy. :)
- Leo
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Li Yang @ 2006-08-23 16:47 UTC (permalink / raw)
Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060823145138.GH614@pb15.lixom.net>
On 8/23/06, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Aug 23, 2006 at 06:55:26PM +0800, Li Yang-r58472 wrote:
> > Ok, I rephrase my question as is it no longer needed? Sometimes people
> > may use this value as a rough estimation of CPU performance. There are
> > people even maintained a list of bogoMIPS of most CPUs. Maybe it is
> > still needed for some legacy reasons. I'm not very sure. :) At leave
> > we need to inform people who do look at this magic number and find it
> > amazingly low.
>
> Bogomips has never had anything to do with performance on PPC, it's just
> a number that's based on the decrementer frequency. For processors with
> external/fixed decrementer clock, it will not vary between different
> processors in a meaningful way.
>
> Every now and then someone will ask "why does my PPC box have such low
> bogomips, is it really that much slower than my PC?". Removing all output
> would certainly help avoid that confusion.
>
> For reference, my G5 here has 66.56 bogomips, which corresponds well to
> the 33MHz decrementer clock it uses.
I think it's the new way to use timebase or RTC. Legacy bogomips is
calculated by counting empty loops, which at some degree reflects cpu
performance. Do you mean it has always been like this for PPC?
- Leo
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Olaf Hering @ 2006-08-23 16:50 UTC (permalink / raw)
To: Tim Bird; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <44EC8338.3050203@am.sony.com>
On Wed, Aug 23, Tim Bird wrote:
> I missed the patch for this, but I have a related question.
http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024708.html
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Linas Vepstas @ 2006-08-23 18:06 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060823145138.GH614@pb15.lixom.net>
On Wed, Aug 23, 2006 at 09:51:38AM -0500, Olof Johansson wrote:
>
> For reference, my G5 here has 66.56 bogomips,
H3y d00d3, 1ik3, my 12-year-old 486DX100 h4s m0r3 bogomips
th4n th4t! 486 r0x and p0w3rpc sux!
^ permalink raw reply
* atomic operations in user space
From: Terry Liang @ 2006-08-23 19:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Thanks. Arnd. My main concern is whether the operations are really atomic as they are in the kernel space. I have read some discussion in another forum that on other platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. from an user space application, they don't guarantee to be atomic. Thanks.
Regards,
Terry Liang
[-- Attachment #2: Type: text/html, Size: 820 bytes --]
^ permalink raw reply
* Philips isp1362 linux driver
From: Kartik Babu @ 2006-08-23 19:16 UTC (permalink / raw)
To: linuxppc-embedded, kylej
Hi,
I was looking through the ozlabs forums, and saw your post about the
driver for the Philips isp1362 USB host controller. You had offered to
put up the for this driver to another poster.
I was wondering if you would be able to share that code with me, I'm
working on getting USB working reliably on a Phytec PXA255 board, and
I'm having some issues. I was looking to see if the other drivers out
there would do a better job. (Currently using the driver from ELINOS).
Thanks in advance.
Kartik
^ permalink raw reply
* crashes on NFS
From: Wade Maxfield @ 2006-08-23 20:37 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi,
I accidentally posted some kernel crashes when running updatedb on an
ML403 using MontaVista tools. I was meaning to send them to MV.
I had swap enabled over NFS (128meg), and the NFS directory being exported
was about 2 gigabytes in sizes.
According to MontaVista, the problem was the kernel was running out of
memory. (There are 64 megs of ram on that board.)
I guess updatedb is very greedy.
thanks,
wade
[-- Attachment #2: Type: text/html, Size: 507 bytes --]
^ permalink raw reply
* PCI resource allocation MPC8540ADS
From: Clint Thomas @ 2006-08-23 21:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
Hey guys,
I have a development board based loosely off the MPC8540ADS design that
I am trying to move to the Linux kernel 2.6. I already have this system
working successfully in Linux Kernel 2.4, but after dealing with
compilation and load errors, i've come to the point where I can get to a
console. However, this problem at boot time keeps me from using a lot of
onboard hardware. When I enable PCI support in the Kernel configuration,
this is the text I get at boot time...
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 1 of PCI bridge 1
PCI: Cannot allocate resource region 2 of PCI bridge 1
PCI: bridge 1 resource 2 moved to 9ff00000..9fffffff
PCI: Cannot allocate resource region 1 of PCI bridge 2
PCI: Cannot allocate resource region 2 of PCI bridge 2
PCI: bridge 2 resource 2 moved to 9fe00000..9fefffff
PCI: Cannot allocate resource region 1 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000:00:14.0
PCI: Cannot allocate resource region 0 of device 0000:01:01.0
PCI: Cannot allocate resource region 1 of device 0000:01:01.0
PCI: Cannot allocate resource region 2 of device 0000:01:01.0
PCI: Cannot allocate resource region 0 of device 0000:01:05.0
PCI: Cannot allocate resource region 1 of device 0000:01:05.0
PCI: Cannot allocate resource region 2 of device 0000:01:05.0
PCI: Cannot allocate resource region 0 of device 0000:01:06.0
PCI: Cannot allocate resource region 0 of device 0000:01:06.1
PCI: Cannot allocate resource region 0 of device 0000:01:06.2
PCI: Failed to allocate mem resource #0:1000000@0 for 0000:01:01.0
PCI: Failed to allocate I/O resource #1:100@1000 for 0000:01:01.0
PCI: Failed to allocate mem resource #2:1000@0 for 0000:01:01.0
PCI: Failed to allocate mem resource #0:10000@0 for 0000:01:05.0
PCI: Failed to allocate mem resource #2:10000@0 for 0000:01:05.0
PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.0
PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.1
PCI: Failed to allocate mem resource #0:100@0 for 0000:01:06.2
the system is using a PLX PCI bridge chip. Like I said, this works fine
in my 2.4 distribution. Thanks for any and all help!
Clinton Thomas
cthomas@soneticom.com
[-- Attachment #2: Type: text/html, Size: 2937 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-23 21:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, James K Lewis, linux-kernel, netdev
In-Reply-To: <200608201203.15645.arnd@arndb.de>
On Sun, Aug 20, 2006 at 12:03:14PM +0200, Arnd Bergmann wrote:
> On Sunday 20 August 2006 08:31, Benjamin Herrenschmidt wrote:
> > > card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> > > mb();
> > > card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> > > card->low_watermark = card->low_watermark->next;
> > >
> > > when we queue another frame for TX.
> >
> > I would have expected those to be racy vs. the hardware... what if the
> > hardware is updating dmac_cmd_status just as your are trying to and the
> > bit out of it ?
>
> Right, that doesn't work. It is the only bit we use in that byte though,
> so maybe it can be done with a single byte write.
Thanks, you're right, I missed that. I'll change this to byte access
shortly. Any recommendations for style/api for byte access?
I could create a searate patch to change struct descr {} to split
the u32 into several u8's; there's a dozen spots that get touched.
Alternatel, I could do a cheesy cast to char[4] and access that way.
Opinions?
--linas
^ permalink raw reply
* Re: [PATCH 5/6]: powerpc/cell spidernet bottom half
From: Linas Vepstas @ 2006-08-23 21:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <200608190103.05649.arnd@arndb.de>
On Sat, Aug 19, 2006 at 01:03:04AM +0200, Arnd Bergmann wrote:
> using the NAPI poll function
Still fiddling with this. Getting side-tracked after noticing
that the RX side generates a *huge* numbe of interrupts, despite
code in the driver which superficially appears to be RX NAPI.
One step forward, two steps back, isn't there a dance like that?
--linas
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: David Miller @ 2006-08-23 22:03 UTC (permalink / raw)
To: linas; +Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20060823213642.GG4401@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Wed, 23 Aug 2006 16:36:42 -0500
> I could create a searate patch to change struct descr {} to split
> the u32 into several u8's; there's a dozen spots that get touched.
>
> Alternatel, I could do a cheesy cast to char[4] and access that way.
> Opinions?
The most portable scheme would be a "u32/u8[4]" union with
appropriate endianness checks when determining which byte
to access in the u8[] view.
^ permalink raw reply
* CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-23 22:16 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a custom board where we've hung a CompactFlash on the local bus
of an MPC8349 processor, intending to use it in 'True IDE' mode. The
closest thing I've found in the kernel tree is
drivers/ide/ppc/ide-m8xx.c, although it's *very* possible I'm not
looking in the right place.
I believe my chip's local bus is similar to the 8xx, so making this
driver work with my hardware doesn't seem like that big a deal. I fully
expect to have to monkey with UPM timings among other things. On the
other hand, this seems like something other people would have done,
maybe with one of the other PQ families like 82xx or 85xx.
Does anyone have a patch, suggestions or flames they can throw my way?
cheers,
Ben
^ permalink raw reply
* Re: [PATCH ] powerpc: pass UPIO_TSI flag to 8259 serial driver
From: Benjamin Herrenschmidt @ 2006-08-23 21:52 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <44EC15A1.4090807@freescale.com>
On Wed, 2006-08-23 at 16:45 +0800, Zang Roy-r61911 wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2006-08-23 at 10:20 +0800, Zang Roy-r61911 wrote:
> >
> >> The patch passes the UPIO_TSI flag to general 8259 serial driver
> >>
> >
> > Patch looks damaged to me... appart from that, what it does looks ok to
> > me.
> Sorry. It seems imported by my mail client. Please pick up the following
> one.
Seems to be damaged as well ! What mail client do you use ?
Ben.
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>
> ---
>
> arch/powerpc/kernel/legacy_serial.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c
> b/arch/powerpc/kernel/legacy_serial.c
> index 359ab89..07c2c00 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -115,6 +115,7 @@ static int __init add_legacy_soc_port(st
> u64 addr;
> u32 *addrp;
> upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
> + struct device_node *tsi = of_get_parent(np);
>
> /* We only support ports that have a clock frequency properly
> * encoded in the device-tree.
> @@ -134,7 +135,10 @@ static int __init add_legacy_soc_port(st
> /* Add port, irq will be dealt with later. We passed a translated
> * IO port value. It will be fixed up later along with the irq
> */
> - return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, flags, 0);
> + if (tsi && !strcmp(tsi->type, "tsi-bridge"))
> + return add_legacy_port(np, -1, UPIO_TSI, addr, addr, NO_IRQ,
> flags, 0);
> + else
> + return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ,
> flags, 0);
> }
>
> static int __init add_legacy_isa_port(struct device_node *np,
> @@ -464,7 +468,7 @@ static int __init serial_dev_init(void)
> fixup_port_irq(i, np, port);
> if (port->iotype == UPIO_PORT)
> fixup_port_pio(i, np, port);
> - if (port->iotype == UPIO_MEM)
> + if ((port->iotype == UPIO_MEM) || (port->iotype == UPIO_TSI))
> fixup_port_mmio(i, np, port);
> }
>
^ 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