* Re: [Cbe-oss-dev] [patch 1/5] cell: pmi remove support for mutiple devices.
From: Akinobu Mita @ 2007-06-25 1:44 UTC (permalink / raw)
To: Christian Krafft
Cc: Akinobu Mita, cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org
In-Reply-To: <20070622161039.2d863fd9@localhost>
>> > -kfree(dev->dev.driver_data);
>> > +kfree(data);
>>
>> Shouldn't it set data = NULL here?
>>
>> I guess we will get "pmi: driver has already been initialized" message
>> and -EBUSY on reloading pmi driver.
>>
>> >
>> > return 0;
>> > }
>
> That problem did actually not occur.
> Anyway, I added the line for completeness and consistency.
The data is located in module data. So unloading module clean up
the data, too. I missed it.
In order to test the problem I said, we need to re-probe pmi driver
without unloading pmi driver. (http://lwn.net/Articles/143397/)
I hope your updated version of patch fixes the problem.
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Kumar Gala @ 2007-06-25 1:49 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20070624224652.2950.qmail@farnsworth.org>
On Jun 24, 2007, at 5:46 PM, Dale Farnsworth wrote:
> In article <200706241552.31483.yur@emcraft.com> you write:
>> This patch fixes the issue of erroneously involving the
>> arch/powerpc/sysdev/mv64x60*.c files into the compilation
>> process for ppc- (not powerpc-) based platforms (e.g.,
>> P3M750).
>>
>> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
>>
>> --
>>
>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
>> Makefile
>> index c3ce0bd..25eaa14 100644
>> --- a/arch/powerpc/sysdev/Makefile
>> +++ b/arch/powerpc/sysdev/Makefile
>> @@ -17,7 +17,9 @@ obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
>> obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
>> obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
>> mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
>
> Shouldn't the above line also be placed inside the of following ifeq ?
>
>> +ifeq ($(CONFIG_PPC_MERGE),y)
>> obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
>> +endif
>>
>> # contains only the suspend handler for time
>> obj-$(CONFIG_PM) += timer.o
Also, lets just move these into the existing ifeq
($CONFIG_PPC_MERGE,y) block in that makefile rather than introducing
a new one.
- k
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Olof Johansson @ 2007-06-25 2:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, linuxppc-dev, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <200706250335.56739.arnd@arndb.de>
On Mon, Jun 25, 2007 at 03:35:56AM +0200, Arnd Bergmann wrote:
> On Monday 25 June 2007, Olof Johansson wrote:
> > ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> > MMIO addresses, and remapped at an offset that's well above 16 bits in
> > some cases.
> >
> > While the type is exported to userspace, there hasn't been any platforms
> > with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> > any existing users.
>
> I just realized that this argument is bogus, because the user space tools
> are probably, or at least potentially, built as 32 bit binaries, which
> means that any interface using these _will_ break.
Fortunately, on the userspace ABI, it should just be the cardmgr
ioctls that are affected. In this case there are no current 64-bit PPC
platforms with PCMCIA, so there are no existing users to regress. New
users (with 32-bit userspace) shouldn't be using the cardmgr tools.
So yes, someone who takes an old 32-bit userspace with cardmgr, moves
it to a new 64-bit platform and expects the old 32-bit tools to work
will find that they don't. Not that they would have otherwise either.
> However, I could not find any actual user space interfaces in 2.6.22-rc
> that are built around ioaddr_t. What are they, or have the been removed
> by now?
Last time I posted this I got the answer from Christoph that it's cardmgr
and the ioctl interface it uses, and there's still users out there that
have been neglecting the error messages, etc.
Unfortunately, ioaddr_t is used both in the ioctl interface as well as
to pass around some of the same structures within the kernel. So I could
either do major overhaul of the PCMCIA stack, or change this type for
ppc64. I went for the latter given that MIPS and ARM obviously already
got away with doing it.
-Olof
^ permalink raw reply
* Re: [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver
From: David Gibson @ 2007-06-25 3:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <ba34492532ac9dfd43bd9f2ae427deef@kernel.crashing.org>
On Fri, Jun 22, 2007 at 09:56:24AM +0200, Segher Boessenkool wrote:
> > Hrm. It seems rather specific. Can we do this more generally, by
> > creating an of_platform device which binds to rtc nodes, then
> > registers an appropriate platform device for each so that the generic
> > rtc drivers pick them up. Obviously we'd need some sort of table
> > mapping the device node compatible properties to the appropriate
> > platform device names.
>
> >> + * RTC_PORT(x) is hardcoded in asm/mc146818rtc.h. Verify that the
> >> + * address provided by the device node matches.
> >> + */
> >> + if (res.start != RTC_PORT(0)) {
> >> + of_node_put(np);
> >> + return -ENODEV;
> >> + }
> >
> > This looks totally bogus. If we have a device tree we should be using
> > the address information from there, not using hardcoded magic. Sounds
> > like asm/mc146818rtc.h needs some serious fixing.
>
> Both of your comments would be nice extensions (and the right
> way forwards), but Wade's patch is good as-is already.
True enough.
--
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: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Christoph Hellwig @ 2007-06-25 5:53 UTC (permalink / raw)
To: Olof Johansson; +Cc: akpm, linuxppc-dev, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <20070625005439.GA31289@lixom.net>
On Sun, Jun 24, 2007 at 07:54:39PM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.
Drivers should be using kio_addr_t, please fix up the remaining drivers
to do this instead of chaning the user-visible type.
^ permalink raw reply
* Re: [PATCH] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Christoph Hellwig @ 2007-06-25 5:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Russell King, linux-pcmcia, linux-kernel
In-Reply-To: <20070625010311.GA31355@lixom.net>
> +static int bus_notify(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + struct device *dev = data;
> +
> + printk("bus notify called\n");
> +
> + /* We are only intereted in device addition */
> + if (action != BUS_NOTIFY_ADD_DEVICE)
> + return 0;
> +
> + /* We use the direct ops for localbus */
> + dev->archdata.dma_ops = &dma_direct_ops;
> +
> + return 0;
> +}
Sorry for not coming back to you after the last posting of the patch,
but I still really this bit of the code. We don't set dma ops from
a driver anywhere else in the tree, so I'd really prefer if you could
handle this in architecture code somewhere. Especially as dma_direct_ops
and the pcmcia_bug_type shouldn't really be something exported to users.
Also this code is unlogic if not buggy. Just because you have one
electra bridge it doesn't mean all pcmcia is driven by it. In fact I'm
pretty sure there are cardbus/pcmcia bridges that can be plugged into
plain pci slots.
^ permalink raw reply
* Fwd: PowerPC 8248
From: 张乐 @ 2007-06-25 6:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <be40b9670706242309y338390b6j1ff91d0c9d5e8995@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Dear Sir：
I am a graduate student from Tsinghua University, China, I came to the
same problem that seems once you got and wrote on the PPC embeded forum,
that, with u-boot 1.1.1 from freesacle, I can not port my 8248/8272 from 2.4to
2.6 kernel.
I saw your answer is that to edit "arch/ppc/platforms/pq2ads.h" and
change the "#define BCSR_ADDR ((uint) 0xf4500000)" to match the u-boot
"u-boot/include/configs/MPC8260ADS.h".
I follow this, and it still no lucky, but there is a difference
between the two kernel, before I edited BCSR_ADDR, the new kernel just hang,
after I edit it, the new kernel is just restart the right place where it
hangs.
I got my kernel from kernel.org (2.6.13), and I wonder is there
something else I should pay attention, or got my kernel from someother
place?
I am looking forward to your reply and best regards!
--
张乐
Zhangle
CERNET, Tsinghua University
zhangyuting@gmail.com
Mobile: +861369-309-1200
Office: 010-62603928
Lab: 010-62603318
Addr: FIT 4-204, TSINGHUA UNIV., China
Lab Addr: FIT 1-210, TSINGHUA UNIV., China
Postcode: 100084
--
张乐
Zhangle
CERNET, Tsinghua University
zhangyuting@gmail.com
Mobile: +861369-309-1200
Office: 010-62603928
Lab: 010-62603318
Addr: FIT 4-204, TSINGHUA UNIV., China
Lab Addr: FIT 1-210, TSINGHUA UNIV., China
Postcode: 100084
[-- Attachment #2: Type: text/html, Size: 2366 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: setup Marvell mv64x60 platform devices for EDAC
From: Paul Mackerras @ 2007-06-25 6:30 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, dfarnsworth
In-Reply-To: <20070522232432.GA26046@blade.az.mvista.com>
Dave Jiang writes:
> The mv64x60 EDAC driver can be found at:
> http://bluesmoke.sourceforge.net/
>
> It's in development to be pushed into the kernel.
Am I correct in thinking this patch is useless without that driver?
Is that driver being submitted for 2.6.23? If so, who is submitting
it and to whom? Does it look like it will be accepted?
Paul.
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-06-25 8:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200706242221.57507.arnd@arndb.de>
Hi,
On Sun, Jun 24, 2007 at 10:21:57PM +0200, Arnd Bergmann wrote:
> On Sunday 24 June 2007, Clifford Wolf wrote:
> > I'm working on an MPC8349E based project and as some of you might know this
> > chip has a four channel (bus-) memory-to-memory DMA controller.
> >
> > Unfortunately the linux kernel is atm lacking a generic interface for such
> > DMA controllers.
>
> So what's wrong with the include/linux/dmaengine.h API? I thought it was
> designed to cover this sort of DMA controller?
nothing. I was just to blind to find it.. ;-)
though there are some points:
on the first glimpse it seams like this api does not support scatter/gather
and fifo mode, right? in fact that's no problem at all for my project but
it would be a pity to lose that hardware functionality because of the api..
i have also had a quick look at the ioatdma driver and it apears to me that
it can only operate on address regions which are visible on the pci bus.
The MPC8349E dma can operate on everything which is visible on the coherent
local bus, i.e. everything that is also visible to the cpu. there seams to
be no way to specify the bus a dma channel is needed for when requesting a
channel thru this interface.
It also appears to me that the dmaengine.h API is not capable of
overcommiting. I.e. assigning a small pool of dma channels to a big pool of
drivers in the hope that not all of the drivers are doing dma transfers at
the same time (and schedule transfers if this assumtion turns out to be
wrong).
Wouldn't it be better to let the backend handle stuff like binding dma
channels to specific cpus and let the user just commit dma requests which
are then scheduled to the dma channel which fits the needs best (or done in
cpu if no dma channel exists which would be capable of doing this kind of
transfer)?
yours,
- clifford
--
"The generation of random numbers is too important to be left to chance."
- Robert R. Coveyou, Oak Ridge National Laboratory.
^ permalink raw reply
* Re: [patch] PS3: Fix USB return value
From: Greg KH @ 2007-06-25 7:30 UTC (permalink / raw)
To: Geoff Levand; +Cc: owen, gregkh, Paul Mackerras, linux-usb-devel, linuxppc-dev
In-Reply-To: <4669E4BD.7060002@am.sony.com>
On Fri, Jun 08, 2007 at 04:22:37PM -0700, Geoff Levand wrote:
> Fix a minor error on the return value of ps3_ehci_driver_register()
> and ps3_ohci_driver_register() when running on non-PS3 systems.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> Hi Greg,
>
> Testers found a problem with my latest PS3 USB patch. Please
> add it in.
I've merged this with your previous one so that no one hits the bug when
doing a 'git bisect'.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Yuri Tikhonov @ 2007-06-25 8:47 UTC (permalink / raw)
To: linuxppc-dev
Hi Dale, Kumar,
Thank you for your comments. All they make sense. Here is an update.
--
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index c3ce0bd..37c37a9 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,8 +16,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
-mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
-obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
@@ -26,6 +24,8 @@ ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
+mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
+obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
endif
# Temporary hack until we have migrated to asm-powerpc
^ permalink raw reply related
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Segher Boessenkool @ 2007-06-25 9:11 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev
In-Reply-To: <200706251247.51518.yur@emcraft.com>
> +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
> +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
> mv64x60_dev.o
How about
mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
mv64x60_dev.o
obj-$(CONFIG_MV64X60) += mv64x60.o
so you can build it is a module, too (although other things
might be preventing that right now)?
Segher
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Yuri Tikhonov @ 2007-06-25 9:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <c14777659bdfd350085cf8c3ae648b20@kernel.crashing.org>
Hi Segher,
The mv64x60 driver has no support for compiling as a module. Built-in only.
And I think there is no much sense in making the driver which provide you
with such a base stuff as a boot console, ethernet, etc. to be a LKM.
Regards, Yuri.
On Monday 25 June 2007 13:11, you wrote:
> > +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
> > +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
> > mv64x60_dev.o
>
> How about
>
> mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
> mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
> mv64x60_dev.o
> obj-$(CONFIG_MV64X60) += mv64x60.o
>
> so you can build it is a module, too (although other things
> might be preventing that right now)?
>
>
> Segher
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Ming Liu @ 2007-06-25 10:03 UTC (permalink / raw)
To: mamsadegh; +Cc: akonovalov, linuxppc-embedded
In-Reply-To: <BAY115-W543A1618F5BCC720DEFE8B2150@phx.gbl>
Dear Mohammad,
>The results are as follows:
>PC-->ML403
>TCP_SENDFILE : 38Mbps
>
>ML403--->PC
>TCP_SENDFILE: 155Mbps
This result is unreasonable. Because PC is more powerful than your board,
so PC->board should be faster than board->PC.
>The transfer rate from ML403 to PC has improved by a factor of 2,
>I see on the posts here in the mailing list that you have reached a band
width of 301Mbps.
Yes, with all features which could improve performance enabled, we can get
around 300Mbps for TCP transfer. one more hint, did you enable caches on
your system? perhaps it will help. Anyway, double check your hardware
design to make sure all features are enabled.That's all I can suggest.
BR
Ming
>
>
>
>
>----------------------------------------
> > From: eemingliu@hotmail.com
> > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > Date: Sat, 23 Jun 2007 19:10:16 +0000
> >
> > Use the following command in Linux please:
> >
> > ifconfig eth0 mtu 8982
> >
> > As well you should do that on your PC in the measurement.
> >
> > Ming
> >
> >
> > >From: Mohammad Sadegh Sadri
> > >To: Ming Liu ,
> > ,,
> >
> > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > >
> > >
> > >Dear Ming,
> > >
> > >Really thanks for reply,
> > >
> > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > >
> > >but what about enabling jumbo frames? should I do any thing special to
> > enable Jumbo fram support?
> > >
> > >we were thinking that it is enabled by default. Is it?
> > >
> > >thanks
> > >
> > >
> > >
> > >
> > >----------------------------------------
> > > > From: eemingliu@hotmail.com
> > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > >
> > > > Dear Mohammad,
> > > > There are some parameters which could be adjusted to improve the
> > > > performance. They are: TX and RX_Threshold TX and RX_waitbound. In
my
> > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
waitbound=1.
> > > >
> > > > Also Jumbo frame of 8982 could be enable.
> > > >
> > > > Try those hints and share your improvement with us.
> > > >
> > > > BR
> > > > Ming
> > > >
> > > > >From: Mohammad Sadegh Sadri
> > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > PPC, Grant Likely
> > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > >
> > > > >
> > > > >Dear all,
> > > > >
> > > > >Recently we did a set of tests on performance of virtex 4FX hard
TEMAC
> > > > module using ML403
> > > > >
> > > > >we studied all of the posts here carefully: these are the system
> > > > characteristics;
> > > > >
> > > > >Board : ML403
> > > > >EDK : EDK9.1SP2
> > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > >PPC clock frequency : 300MHz
> > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing
near
> > one
> > > > week ago
> > > > >DMA type: 3 (sg dma)
> > > > >DRE : enabled for TX and RX, (2)
> > > > >CSUM offload is enabled for both of TX and RX
> > > > >tx and rx fifo sizes : 131072 bits
> > > > >
> > > > >the board comes up over NFS root file system completely and
without
> > any
> > > > problems.
> > > > >
> > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > 2Gigabytes
> > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > >We have tested the PC system band width and it can easily reach
> > 966mbits/s
> > > > when connected to the same PC. ( using the same cross cable used
for
> > ml403
> > > > test)
> > > > >
> > > > >Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
> > > > >
> > > > >(from board to PC)
> > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m
> > 16384 -s
> > > > 87380 -S 87380
> > > > >
> > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > >It is also true for netperf from PC to board.
> > > > >
> > > > >we do not have any more idea about what we should do to improve
the
> > > > bandwidth.
> > > > >any help or ideas is appreciated...
> > > > >
> > > > >_________________________________________________________________
> > > > >Connect to the next generation of MSN
> > > >
> >
Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> >
> > > >
> > > > >_______________________________________________
> > > > >Linuxppc-embedded mailing list
> > > > >Linuxppc-embedded@ozlabs.org
> > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > >
> > > > _________________________________________________________________
> > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > >
> > >
> > >_________________________________________________________________
> > >News, entertainment and everything you care about at Live.com. Get it
now!
> > >http://www.live.com/getstarted.aspx
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> >
>
>_________________________________________________________________
>Discover the new Windows Vista
>http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Segher Boessenkool @ 2007-06-25 10:14 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev
In-Reply-To: <200706251351.55868.yur@emcraft.com>
> The mv64x60 driver has no support for compiling as a module. Built-in
> only.
Yeah I expected that that is the case right now. Could be
fixed later though.
> And I think there is no much sense in making the driver which provide
> you
> with such a base stuff as a boot console, ethernet, etc. to be a LKM.
That's orthogonal to expressing it as one "module" in Kbuild,
which is really just about grouping highly interdependent
stuff together.
But anyway, your patch looks good, I was just suggesting to
clean it up some more. You don't have to do it now if you
don't want to, I'm sure it will happen later :-)
[Oh, and don't top-post.]
>>> +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
>>> +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
>>> mv64x60_dev.o
>>
>> How about
>>
>> mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
>> mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
>> mv64x60_dev.o
>> obj-$(CONFIG_MV64X60) += mv64x60.o
>>
>> so you can build it is a module, too (although other things
>> might be preventing that right now)?
Segher
^ permalink raw reply
* [PATCH] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Tony Breeds @ 2007-06-25 10:58 UTC (permalink / raw)
To: LinuxPPC-dev, Paul Mackerras
Hi Paul,
It'd be nice if this made it into 2.6.22, esp. now that more
distros are shipping glibc's that will use the VDSO.
I think I got the asm right, it works on pSerie, either way feedback
welcome.
From: Tony Breeds <tony@bakeyournoodle.com>
Fix VDSO gettimeofday() when called with NULL struct timeval.
Consider the prototype for gettimeofday():
int gettimofday(struct timeval *tv, struct timezone *tz);
AFAICT it is valid to call with /either/ tv or tz being NULL, the C version
of sys_gettimeofday() supports this, the current version of gettimeofday() in
the VDSO will SEGV if called with a NULL tv.
This patch fixes this.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 13 +++++++------
arch/powerpc/kernel/vdso64/gettimeofday.S | 8 +++++---
2 files changed, 12 insertions(+), 9 deletions(-)
Index: working/arch/powerpc/kernel/vdso32/gettimeofday.S
===================================================================
--- working.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:35:47.000000000 +1000
+++ working/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:40:34.000000000 +1000
@@ -32,8 +32,10 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r4 /* r11 saves tz */
bl __get_datapage@local /* get data page */
mr r9, r3 /* datapage ptr in r9 */
+ cmpli cr0,r10,0 /* check if tv is NULL */
+ beq 1f
bl __do_get_xsec@local /* get xsec from tb & kernel */
- bne- 2f /* out of line -> do syscall */
+ bne- 3f /* out of line -> do syscall */
/* seconds are xsec >> 20 */
rlwinm r5,r4,12,20,31
@@ -50,20 +52,19 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mulhwu r5,r5,r6
stw r5,TVAL32_TV_USEC(r10)
- cmpli cr0,r11,0 /* check if tz is NULL */
- beq 1f
+1: cmpli cr0,r11,0 /* check if tz is NULL */
+ beq 2f
lwz r4,CFG_TZ_MINUTEWEST(r9)/* fill tz */
lwz r5,CFG_TZ_DSTTIME(r9)
stw r4,TZONE_TZ_MINWEST(r11)
stw r5,TZONE_TZ_DSTTIME(r11)
-1: mtlr r12
+2: mtlr r12
crclr cr0*4+so
li r3,0
blr
-2:
- mtlr r12
+3: mtlr r12
mr r3,r10
mr r4,r11
li r0,__NR_gettimeofday
Index: working/arch/powerpc/kernel/vdso64/gettimeofday.S
===================================================================
--- working.orig/arch/powerpc/kernel/vdso64/gettimeofday.S 2007-06-25 19:35:52.000000000 +1000
+++ working/arch/powerpc/kernel/vdso64/gettimeofday.S 2007-06-25 19:42:45.000000000 +1000
@@ -32,6 +32,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r3 /* r11 holds tv */
mr r10,r4 /* r10 holds tz */
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
+ cmpldi cr0,r11,0 /* check if tv is NULL */
+ beq 1f
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
ori r7,r7,16960
@@ -43,14 +45,14 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
* XSEC_PER_SEC
*/
rldicl r0,r0,44,20
- cmpldi cr0,r10,0 /* check if tz is NULL */
+1: cmpldi cr0,r10,0 /* check if tz is NULL */
std r0,TVAL64_TV_USEC(r11) /* store usec in tv */
- beq 1f
+ beq 2f
lwz r4,CFG_TZ_MINUTEWEST(r3)/* fill tz */
lwz r5,CFG_TZ_DSTTIME(r3)
stw r4,TZONE_TZ_MINWEST(r10)
stw r5,TZONE_TZ_DSTTIME(r10)
-1: mtlr r12
+2: mtlr r12
crclr cr0*4+so
li r3,0 /* always success */
blr
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Matt Sealey @ 2007-06-25 11:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200706242221.57507.arnd@arndb.de>
IOAT and Intel's DMA engine driver is very IOAT specific in places..
I had a peek at it as I have a little interest in the concept; at least the
two platforms Genesi has been supporting (Pegasos and Efika) have quite
competant DMA engines which are woefully underused (i.e. not at all).
There exists a Marvell DMA driver somewhere (I have a copy, someone on
this list posted it about a year ago) and while the MPC5200B doesn't have
explicit support for DMA from memory to memory (although memory to SRAM
might work in chunks, or memory to a FIFO wired as a loopback like in
the docs..??)
There is so much you can do with most SoC DMA controllers, and it's not
even limited to PowerPC (most ARM/XScale SoCs have very capable devices
inside too). I can only imagine that nobody got excited over IOAT because
the entire programming interface stinks of "offloading gigabit ethernet"
and not much else.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Arnd Bergmann wrote:
> On Sunday 24 June 2007, Clifford Wolf wrote:
>> I'm working on an MPC8349E based project and as some of you might know this
>> chip has a four channel (bus-) memory-to-memory DMA controller.
>>
>> Unfortunately the linux kernel is atm lacking a generic interface for such
>> DMA controllers.
>
> So what's wrong with the include/linux/dmaengine.h API? I thought it was
> designed to cover this sort of DMA controller?
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Bhupender Saharan @ 2007-06-25 11:52 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Andrei Konovalov, Linux PPC Linux PPC
In-Reply-To: <BAY115-W1188529D49F71948165AF6B2160@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]
Hi,
We need to findout where is the bottlenect.
1. Run vmstat on the ML403 board and find out the percentage CPU is busy
when you are transferring the file. That will show if cpu is busy or not.
2. Run oprofile and find out which are the routines eating away the cpu
time.
Once we have data from both the above routines, we can find out the
bottlenecks.
Regards
Bhupi
On 6/23/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
>
> Dear all,
>
> Recently we did a set of tests on performance of virtex 4FX hard TEMAC
> module using ML403
>
> we studied all of the posts here carefully: these are the system
> characteristics;
>
> Board : ML403
> EDK : EDK9.1SP2
> Hard TEMAC version and PLTEMAC version are both 3.0.a
> PPC clock frequency : 300MHz
> Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing near one
> week ago
> DMA type: 3 (sg dma)
> DRE : enabled for TX and RX, (2)
> CSUM offload is enabled for both of TX and RX
> tx and rx fifo sizes : 131072 bits
>
> the board comes up over NFS root file system completely and without any
> problems.
>
> PC system used for these tests is : CPU P4 Dual Core, 3.4GHz , 2Gigabytes
> memory, Dual gigabit ethernet port, running linux 2.6.21.3
> We have tested the PC system band width and it can easily reach 966mbits/s
> when connected to the same PC. ( using the same cross cable used for ml403
> test)
>
> Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
>
> (from board to PC)
> netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m 16384 -s
> 87380 -S 87380
>
> the measured bandwidth for this test was just 40.66Mbits.
> It is also true for netperf from PC to board.
>
> we do not have any more idea about what we should do to improve the
> bandwidth.
> any help or ideas is appreciated...
>
> _________________________________________________________________
> Connect to the next generation of MSN Messenger
>
> http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2871 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Benjamin Herrenschmidt @ 2007-06-25 12:39 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20070625105836.GE9768@bakeyournoodle.com>
> Index: working/arch/powerpc/kernel/vdso32/gettimeofday.S
> ===================================================================
> --- working.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:35:47.000000000 +1000
> +++ working/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:40:34.000000000 +1000
> @@ -32,8 +32,10 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mr r11,r4 /* r11 saves tz */
> bl __get_datapage@local /* get data page */
> mr r9, r3 /* datapage ptr in r9 */
> + cmpli cr0,r10,0 /* check if tv is NULL */
> + beq 1f
Please use cmplwi here.
> bl __do_get_xsec@local /* get xsec from tb & kernel */
> - bne- 2f /* out of line -> do syscall */
> + bne- 3f /* out of line -> do syscall */
>
> /* seconds are xsec >> 20 */
> rlwinm r5,r4,12,20,31
> @@ -50,20 +52,19 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mulhwu r5,r5,r6
> stw r5,TVAL32_TV_USEC(r10)
>
> - cmpli cr0,r11,0 /* check if tz is NULL */
> - beq 1f
> +1: cmpli cr0,r11,0 /* check if tz is NULL */
> + beq 2f
And fix that one while at it :-) It's the same thing, but at least one
is explicit on the size of the comparison. Also, I don't think you need
to renumber the labels, or did I miss something ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Josh Boyer @ 2007-06-25 12:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <70d005ce549921cc56481fe0b26faaa4@kernel.crashing.org>
On Sat, 2007-06-23 at 17:50 +0200, Segher Boessenkool wrote:
> > For the 83xx, 85xx, and 86xx device trees, add a "local-mac-address"
> > property
> > to every Ethernet node that didn't have one. Add a comment indicating
> > that
> > the "address" and/or "mac-address" properties are deprecated in DTS
> > files
> > and will be removed at a later time. Change all MAC address
> > properties to
> > have a zero MAC address value.
>
> Shouldn't you use the "??" notation instead, or is that
> still not implemented?
Not implemented.
josh
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clemens Koller @ 2007-06-25 12:53 UTC (permalink / raw)
To: Matt Sealey; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FA0EA.3000607@genesi-usa.com>
Hello, Matt!
Matt Sealey schrieb:
> IOAT and Intel's DMA engine driver is very IOAT specific in places..
>
> I had a peek at it as I have a little interest in the concept; at least the
> two platforms Genesi has been supporting (Pegasos and Efika) have quite
> competant DMA engines which are woefully underused (i.e. not at all).
True.
> There exists a Marvell DMA driver somewhere (I have a copy, someone on
> this list posted it about a year ago) and while the MPC5200B doesn't have
> explicit support for DMA from memory to memory (although memory to SRAM
> might work in chunks, or memory to a FIFO wired as a loopback like in
> the docs..??)
>
> There is so much you can do with most SoC DMA controllers, and it's not
> even limited to PowerPC (most ARM/XScale SoCs have very capable devices
> inside too). I can only imagine that nobody got excited over IOAT because
> the entire programming interface stinks of "offloading gigabit ethernet"
> and not much else.
The main question remains: Is it possible to have a flexible cross platform
DMA API which handles even complex requests and does scheduling, prioritizing,
queuing, locking, (re-)building/caching of SG lists... automagically.
It could fall back to CPU's memcpy if the hardware doesn't have
the ability to use the DMA machine because all channels are already busy,
or the requested memory isn't DMAable or the request is just too small
that it doesn't make sense to setup a DMA channel.
Filling memory with zero is also a simple task for a DMA engine.
(Thinking about malloc() and memset())
The problem is IMHO similar to video acceleration. Within the
Xorg's XAA/EXA/whatever framework, the drivers accelerate certain
calls if the hardware has the capability to do so. Other calls fall back
to some default non accelerated memcpy() & friends.
Sounds like a lot of fun... replacing kernel's and libc's memcpy() with
memcpy_with_dma_if_possible(). :-)
Best regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Segher Boessenkool @ 2007-06-25 13:35 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20070625105836.GE9768@bakeyournoodle.com>
> It'd be nice if this made it into 2.6.22, esp. now that more
> distros are shipping glibc's that will use the VDSO.
Yeah. Not really vital though, no sane program would call
gettimeofday() with a NULL timeval (since that doesn't do
anything). Or did you find such a program (other than a
testsuite)?
> +++ working/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25
> 19:40:34.000000000 +1000
> @@ -32,8 +32,10 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mr r11,r4 /* r11 saves tz */
> bl __get_datapage@local /* get data page */
> mr r9, r3 /* datapage ptr in r9 */
> + cmpli cr0,r10,0 /* check if tv is NULL */
cmplwi r10,0
cmpli with two or three arguments is not an existing PowerPC
instruction. Also, don't write cr0 if you don't do the same
in the accompanying branch insn, it only confuses things.
> + beq 1f
> bl __do_get_xsec@local /* get xsec from tb & kernel */
> - bne- 2f /* out of line -> do syscall */
> + bne- 3f /* out of line -> do syscall */
No need to renumber the labels. Either pick a higher
number for your new label (nothing says they need to be
in order); or reuse some other number (both your new and
the original 1: can be 1: without any problem, these are
local labels after all); or you can use 0: since that's
a valid local label as well.
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-25 14:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <3372b921591ca9731d2703f04e6c35f1@kernel.crashing.org>
Segher Boessenkool wrote:
>> Note that 745x processors have L3 cache installed and may have the same
>> problem requiring similar code modifications to use L3 hardware flushing
>> mechanism.
>
>
> What does the erratum say?
The erratum says nothing about any HW bugs with L3 cache flush. I just
mentioned that the L3 cache flush operation described in MPC7450
Reference manual is similar to the L2 using the L3 cache hardware
flushing mechanism. For instance, it requires a complete L3 locking
before flushing.
>
> The L3 is a very different beast from the L2, IIRC it is
> a pure victim cache so it cannot have this problem at all?
I'm not sure if it is a pure victim cache. I read the MPC7450 reference
manual and see that the L3 cache operates similarly to the L2. The main
difference between those caches is that L3 uses an external SRAM memory
while L2 is a pure on-chip cache.
Vlad.
>
>
> Segher
>
^ permalink raw reply
* libfdt merged into DTC repo!
From: Jon Loeliger @ 2007-06-25 14:25 UTC (permalink / raw)
To: linuxppc-dev, u-boot-users
Folks,
David Gibson has successfully wrestled the libfdt legal beast!
As a result, I have merged the current versions of the libfdt
into the DTC repository as maintained on jdl.com.
Enjoy,
jdl
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Matt Sealey @ 2007-06-25 14:31 UTC (permalink / raw)
To: Clemens Koller; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FBABD.9040103@anagramm.de>
Clemens Koller wrote:
> Hello, Matt!
>
>> There is so much you can do with most SoC DMA controllers, and it's not
>> even limited to PowerPC (most ARM/XScale SoCs have very capable devices
>> inside too). I can only imagine that nobody got excited over IOAT because
>> the entire programming interface stinks of "offloading gigabit ethernet"
>> and not much else.
>
> The main question remains: Is it possible to have a flexible cross platform
> DMA API which handles even complex requests and does scheduling,
> prioritizing, queuing, locking, (re-)building/caching of SG lists... automagically.
I would think so. I think there is a fairly generic example in many parts
of the Linux kernel. Dare I say the Via Unichrome AGP subsystem? And a
bunch of the ARM/OMAP platforms..? A lot of the code is even identical,
I wonder why it isn't some library rather than platform drivers.
> Filling memory with zero is also a simple task for a DMA engine.
> (Thinking about malloc() and memset())
Also xor and logical operations, byte swapping huge chunks of data, that
kind of thing. Most DMA engines in SoCs have cute features like that. I
think BestComm can even calculate CRCs for IP packets.
> The problem is IMHO similar to video acceleration. Within the
> Xorg's XAA/EXA/whatever framework, the drivers accelerate certain
> calls if the hardware has the capability to do so. Other calls fall back
> to some default non accelerated memcpy() & friends.
>
> Sounds like a lot of fun... replacing kernel's and libc's memcpy() with
> memcpy_with_dma_if_possible(). :-)
Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise
it (it should be possible) or simply add to it, or if making a powerpc
specific dma engine abstraction would be an easier idea.
Probably the latter to be merged with the former at a later date would
be easier to manage. Take inspiration but don't be bound by Intel's
weird "new" (i.e. 15 year old) concept?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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