* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Jean Delvare @ 2007-10-16 19:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Stefan Roese, i2c, David Gibson
In-Reply-To: <fa686aa40710152121o2fe0d7c9m156170901fd3bf98@mail.gmail.com>
On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > In fact I think it may be acceptle to do the idx++ thing in this
> > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > the horrible mess that is the Linux i2c subsystem. It means that bus
> > numbers are theoretically unstable, but that's increasingly true of
> > devices of all sorts - it's up to udev to assign meaningful labels at
> > the user level.
David, after such a rant against the Linux i2c subsystem, I sure hope
that you're going to contribute patches to make it better (whatever you
think needs to be improved, as you didn't say.)
> I think the real problem here comes into play when there are 2 types
> of i2c busses in the system. If they both maintain their own idx++
> values; then they will conflict. If an auto assigned bus number is
> used; then it needs to be assigned by the i2c infrastructure; not by
> the driver.
Very true. If you aren't going to define the i2c bus numbers at
platform data level, then you shouldn't be defining them _at all_.
Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
i2c-core choose an appropriate a bus number.
--
Jean Delvare
^ permalink raw reply
* vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Joseph Fannin @ 2007-10-16 19:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-fbdev-devel
vga16fb is an available config option on powerpc, but it won't link
with my .config:
ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
I'm guessing this is because include/asm-powerpc/vga.h declares
vgacon_remap_base:
extern unsigned long vgacon_remap_base;
...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
#ifdef CONFIG_VGA_CONSOLE
unsigned long vgacon_remap_base;
EXPORT_SYMBOL(vgacon_remap_base);
#endif
So CONFIG_VGA_CONSOLE=n and CONFIG_FB_VGA16=[y|m] won't work.
I've also noticed that the only places in the tree that ever assign
anything to config_remap_base are under arch/ppc. And
include/asm-powerpc/vga.h also does this:
#ifdef __powerpc64__
#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
#else
#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
#endif
So VGACON probably doesn't work either on 32bit. I'm guessing arch/powerpc
doesn't support PREP.
How best could this be fixed up? Or should I just let the thing
be? This is obviously not a new thing, and I don't have any hardware
that supports this stuff either.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* Re: cross compilation issue
From: Wolfgang Denk @ 2007-10-16 19:07 UTC (permalink / raw)
To: Leisner, Martin
Cc: linuxppc-embedded,
linuxppc-embedded-bounces+ravi.rao=rflelect.com
In-Reply-To: <556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net>
Dear Martin,
in message <556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net> you wrote:
>
> #! /bin/bash
>
> exec make ARCH=powerpc CROSS_COMPILE=/opt/denx/eldk4.1/usr/bin/ppc_74xx- INSTALL_MOD_PATH=${PWD}/root $*
Note that this is *NOT* a suppoted value for CROSS_COMPILE. Please set
your PATH to include the /opt/denx/eldk4.1/usr/bin directory, and set
CROSS_COMPILE=ppc_74xx-
> I know hardhat linux had a strategy to make . files hiding the names of ARCH/CROSS_COMPILE -- so typing make
> would work once configured...
>
> IMHO it should be hardcoded in the Makefile after configuration -- it causes a lot of grief if you FORGET
> to specify one of these and just type "make".
I disagree. Such an approach will hit you as soon as you run a command
not from "make", but from the command line.
Instead, please set and export thse variables in your shell
environment, where each tool can pick it up.
If you have to switch environments frequently you can use some shell
functions to do so. For example, ELDK 4.1 which you use comes with
the "eldk_init" script ("/opt/denx/eldk4.1/eldk_init" in your
installation) which can be "sourced" from the shell like this:
$ source /opt/denx/eldk4.1/eldk_init 74xx
ARCH=ppc
CROSS_COMPILE=ppc_74xx-
DEPMOD=/opt/denx/eldk4.1/usr/bin/depmod.pl
PATH=/opt/denx/eldk4.1/usr/bin:/opt/denx/eldk4.1/bin: ...
$
ELDK 4.2 will use a much cleverer script "eldk-switch" which allows
to select versions and board like this:
-> eldk-switch -r4.1 sequoia
[ sequoia is using PPC440EPx ]
Setup for ppc_4xxFP (using ELDK 4.1)
-> eldk-switch -r4.2 TQM8540
[ TQM8540 is using MPC8540 ]
Setup for ppc_85xx (using ELDK 4.2)
-> eldk-switch -r4.0 MPC860
Setup for ppc_8xx (using ELDK 4.0)
-> eldk-switch MPC7448
Setup for ppc_74xx (using ELDK 4.2)
> One of the things I want to do is look at how the linux make system works now (I recall at times I edit the Makefile
> to hardcode these things).
Never edit the Makefile - this is always a Bad Thing (TM) to do.
Make sure to either set the ARCH and CROSS_COMPILE ariables in your
environment (this is IMHO the more convenient way) or pass them on
the make command line.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen.
-- Goethe, Invektiven
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Stephen Hemminger @ 2007-10-16 18:53 UTC (permalink / raw)
To: benh; +Cc: netdev, Dreier, Roland, David S. Miller, linuxppc-dev list
In-Reply-To: <1192513792.19073.23.camel@pasglop>
On Tue, 16 Oct 2007 15:49:52 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> net: Add __napi_sycnhronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> (Use correct address for Stephen this time)
>
> If the approach is accepted, I would like to have this merged now
> so the EMAC patch to make it work again can follow :-)
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handle this ?
So this is really just like synchronize_irq()? Using msleep is bogus
because you want to spin, you are only waiting for a softirq on the other
cpu to finish. If you wait for a whole millisecond and sleep that
is far longer than the napi routine should take.
You could even optimize it like synchronize_irq() for the non-SMP case.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [UNTESTED PATCH v2] 8xx: Convert mpc866ads to the new device binding.
From: Vitaly Bordug @ 2007-10-16 17:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008224847.GA4053@loki.buserror.net>
Hi Scott,
orig one does not build (not your issue apparently):
CC drivers/net/fs_enet/fs_enet-main.o
drivers/net/fs_enet/fs_enet-main.c: In function `fs_enet_probe':
drivers/net/fs_enet/fs_enet-main.c:1252: error: implicit declaration of
function `SET_MODULE_OWNER'
drivers/net/fs_enet/fs_enet-main.c:1292: error: structure has no member
named `poll'
drivers/net/fs_enet/fs_enet-main.c:1293: error: structure has no member
named `weight'
make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
make[2]: *** [drivers/net/fs_enet] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
because net_device does not have 'poll' and 'weight' anymore.
Moreover, with the patch, it does not seem to boot(with upper lines commented out to get it build). I'm investigating the reason right now.
On Mon, 8 Oct 2007 17:48:47 -0500
Scott Wood <scottwood@freescale.com> wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Whoops, forgot the localbus node last time.
>
> arch/powerpc/boot/dts/mpc866ads.dts | 137 +++++++------
> arch/powerpc/platforms/8xx/Kconfig | 1 +
> arch/powerpc/platforms/8xx/mpc86xads.h | 44 ----
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 289 +++++++-------------------
> 4 files changed, 156 insertions(+), 315 deletions(-)
>
[...]
--
Sincerely,
Vitaly
^ permalink raw reply
* Describing devices in the device tree
From: Alan Bennett @ 2007-10-16 18:36 UTC (permalink / raw)
To: linuxppc-dev
I'm using a modified ep8248e.dts to describe my hardware and I want to
enable the use of 3 standard interrupts.
1. irq5
2. timer1
3. timer2
How bad does this look?
soc --> cpm -->
timer {
device_type = "timer";
compatible = "fsl,mpc8248-timer";
interrupts = <c 8 d 8>;
interrupt-parent = <&PIC>;
};
irq5 {
device_type = "irq5";
compatible = "fsl,mpc8248-irq5";
interrupts = <17 8>;
interrupt-parent = <&PIC>;
};
-Alan
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-16 18:24 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Wolfgang Reissnegger, Leonid,
microblaze-uclinux
In-Reply-To: <20071015155223.7403.39615.stgit@trillian.cg.shawcable.net>
> + n) Xilinx EMAC and Xilinx TEMAC
> +
> + Xilinx Ethernet devices. Uses common properties from=20
> other Ethernet
> + devices with the following constraints:
> + =20
> + Required properties:
> + - compatible : Must include one of: "xilinx,plb-temac",
> + "xilinx,plb-emac", "xilinx-opb-emac"
> + - dma-mode : Must be one of "none", "simple", "sg" (sg=20
> =3D=3D scatter gather)
I think it's going to be a significant headache to remap things like the
dma-mode from the xilinx configurations to something else, and then
interpret them correctly in the drivers.
Although it lacks a bit in style, perhaps, I'd greatly prefer having
something like:
Ethernet_MAC {
xilinx,C_DMA_PRESENT =3D <1>;
...
}
(which happens to correspond to "none" above)
DMA mode is perhaps a bad example, since the Xilinx EDK encoding for
this is so unnecessarily obfuscated, but I'd like to avoid setting
precedent for defining a new set of parameterizations here. In the long
term, I'm afraid this will just be an added source of confusion and more
code to maintain.
Steve
^ permalink raw reply
* current -git adbhid.c build error
From: Joseph Fannin @ 2007-10-16 18:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dmitry Torokhov
Hello.
Commit b981d8b3f5e008ff10d993be633ad00564fc22cd in Linus's git tree
did this:
@@ -374,9 +373,9 @@ adbhid_input_keycode(int id, int scancode, int repeat)
#endif /* CONFIG_PPC_PMAC */
}
- if (adbhid[id]->keycode[keycode]) {
- input_report_key(adbhid[id]->input,
- adbhid[id]->keycode[keycode],
adbhid[id]->!up_flag);
+ key = adbhid[id]->keycode[keycode];
+ if (key) {
+ input_report_key(adbhid[id]->input, key, !up_flag);
input_sync(adbhid[id]->input);
} else
printk(KERN_INFO "Unhandled ADB key (scancode %#02x)
%s.\n", keycode,
... but did not define "key":
drivers/macintosh/adbhid.c: In function ‘adbhid_input_keycode’:
drivers/macintosh/adbhid.c:376: error: ‘key’ undeclared (first use in this function)
Gitweb says something about a merge conflict in this file, so maybe
Linus did this, and not Dmitry?
I'll leave it up to someone else to decide how best this variable
should be defined.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* RE: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-16 18:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000901c81006$7303b490$bb3ca688@LGE.NET>
The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
the ELDK 4.1 from Denx and the included cross compiler. The result is the
same... the Kernel stops at "Now booting the kernel". Now, we also have an
USB JTAG cable. So, we can debug the memory.
Probably, anyone has another idea.
Thanks,
Andreas
Sergey Oleynichenko wrote:
>
>
> I noticed this problem happens when on-chip memories are enabled in a
> design
> (it is 4th page in base system builder). Try to leave them "none" for both
> instruction and data.
>
> Sergey
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org] On
> Behalf Of aauer1
> Sent: Monday, October 15, 2007 1:47 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux booting problem on Xilinx ppc
>
>
> Hello
>
> I'm also working with ML403 board from Xilinx and have the same problem as
> you. The boot process stops after decompressing with the message "Now
> booting the kernel". We also used gcc-4.1.0 for the cross compilation. So,
> I
> would be glad to know, which gcc version have you used to get a working
> kernel!
>
> Thanks,
> Andreas
>
>
>
> Junqiang Hu wrote:
>>
>>
>> Hi Grant,
>>
>> Thank you so much for the reply! Fortunately I got it work now --
>> it's
>> the crosstool compiler problem. Originally I was using gcc-4.1.0, yet
>> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
>> miscompile the kernel, so I changed to another version, and now I can let
>> it go!
>>
>> Right now still not fully booted because of the SystemACE problem, or
>> maybe the partition is not correct. I'm still working on it, hopefully
>> to
>> get it solved soon :-)
>>
>> Thanks,
>> -J.
>>
>>
>> Grant Likely-2 wrote:
>>>
>>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>>
>>>>
>>>> Dear friends,
>>>>
>>>> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>>> board. The Linux version I'm using is 2.4; the cross-compiler is
>>>> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
>>>> loaded at: 00400000 004B51E4
>>>> board data at: 00000000 00000018
>>>> relocated to: 0040526C 00405284
>>>> zimage at: 00405B2B 004B177C
>>>> avail ram: 004B6000 60000000
>>>
>>> I strongly recommend moving to a 2.6 kernel. Recent mainline has
>>> support for the Xilinx ppc built in.
>>>>
>>>> Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>>> rw
>>>> Uncompressing Linux...done.
>>>> Now booting the kernel
>>>>
>>>> Then it hangs. First it seems to me that the "avail ram" is not
>>>> correct,
>>>> since I configured only 32MB SDRAM. Moreover, if it's first powered
>>>> on,
>>>> the
>>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>>> investigate
>>>> the problem using xmd. When launched, it says:
>>>
>>> (If you're using u-boot) You might have a mismatch between the board
>>> info structure used by u-boot and the one used by Linux.
>>>
>>> Also, you should use your debugger to inspect the __log_buf memory of
>>> the kernel. A common problem is the kernel starts booting, but the
>>> console is setup incorrectly and so you see nothing. But, you can
>>> read the console output directly from memory if you look at the
>>> __log_buf region (find the address in the System.map file; you might
>>> need to subtract 0xC0000000 from the address to view the memory)
>>>
>>> Cheers,
>>> g.
>>>
>>> --
>>> Grant Likely, B.Sc., P.Eng.
>>> Secret Lab Technologies Ltd.
>>> grant.likely@secretlab.ca
>>> (403) 399-0195
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13
> 219154
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13239003
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [UNTESTED PATCH v2] 8xx: Convert mpc866ads to the new device binding.
From: Scott Wood @ 2007-10-16 17:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071016215308.764d9922@vitb.ru.mvista.com>
Vitaly Bordug wrote:
> Hi Scott,
>
> orig one does not build (not your issue apparently):
>
> CC drivers/net/fs_enet/fs_enet-main.o
> drivers/net/fs_enet/fs_enet-main.c: In function `fs_enet_probe':
> drivers/net/fs_enet/fs_enet-main.c:1252: error: implicit declaration of
> function `SET_MODULE_OWNER'
> drivers/net/fs_enet/fs_enet-main.c:1292: error: structure has no member
> named `poll'
> drivers/net/fs_enet/fs_enet-main.c:1293: error: structure has no member
> named `weight'
> make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
> make[2]: *** [drivers/net/fs_enet] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
>
> because net_device does not have 'poll' and 'weight' anymore.
>
> Moreover, with the patch, it does not seem to boot(with upper lines commented out to get it build). I'm investigating the reason right now.
Yeah, I was working on cleaning up the mess when I got this message. :-)
Removing the napi_enable call should make it boot. I'm now trying to
get in to work with napi enabled...
-Scott
^ permalink raw reply
* RE: Refactor booting-without-of.txt
From: Stephen Neuendorffer @ 2007-10-16 17:24 UTC (permalink / raw)
To: David Gibson, Grant Likely
Cc: Olof Johansson, linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071016032415.GO26787@localhost.localdomain>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of David Gibson
> Sent: Monday, October 15, 2007 8:24 PM
> To: Grant Likely
> Cc: Olof Johansson; linuxppc-dev; microblaze-uclinux@itee.uq.edu.au
> Subject: Re: Refactor booting-without-of.txt
>=20
> On Mon, Oct 15, 2007 at 09:02:09PM -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> > > > On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> > > > > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > > > > > Adding the Linux expected device tree bindings to
> > > > > > booting-without-of.txt seems to be getting a little=20
> unwieldy. Plus
> > > > > > with more than one arch using the device tree=20
> (powerpc, sparc &
> > > > > > microblaze) the device tree bindings aren't=20
> necessarily powerpc only
> > > > > > (the Xilinx devices certainly fall in this category).
> > > > > >
> > > > > > Anyone have comments about splitting the expected=20
> device tree bindings
> > > > > > out of booting-without-of.txt into a separate directory?
> > > > >
> > > > > The flat device tree is, in spite of what some people=20
> would like it to be,
> > > > > not open firmware, nor is it the same as their=20
> bindings. So I think we'd
> > > > > be doing ourselves a disservice by continuing to=20
> associate them together.
> > > > > All it would take is a rename of the directory,=20
> unfortunately i don't
> > > > > have any suggestions on better names though.
> > > >
> > > > I think I need to stick with the of prefix. All the=20
> support API in
> > > > include/linux/of_* is prefixed with "of_" already, so=20
> convention is
> > > > established.
> > > >
> > > > How about Documentation/of-device-tree?
> > >
> > > It seems a little counterintuitive to change names from "booting
> > > *without* of" to "of *"...
> >=20
> > Heh; true. The *only* reason I think it should be=20
> 'of-<anything>' is
> > because *all* the support APIs are named that way. I'll happily use
>=20
> No, not all, just most...
>=20
> And do bear in mind that a lot of those accessor functions are at
> least valid both on of and flat-tree systems.
>=20
> > another name if I get the impression that most of us in our little
> > group think it should be something else.
> >=20
> > Cheers,
> > g.
> >=20
> >=20
>
How about just 'device-tree', referring to any source, and then
of-device-tree and flat-device-tree to document how the device tree is
constructed.
The fact that the API is poorly named is something that can always be
fixed (and perhaps should be earlier rather than later).
Steve
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-16 17:17 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071016171417.64605230209@mail24-fra.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> On a similar note, is there interest in actually factoring the device
> tree code out from the different architectures into a common codebase?
It's already happened somewhat. (Look in drivers/of and include/linux/of*.h)
However, I don't think any of the stuff specific to flattened device
trees is being factored out of arch/powerpc yet.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Refactor booting-without-of.txt
From: Stephen Neuendorffer @ 2007-10-16 17:13 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710150908o55d1f5d2t264cbb8ed800a12f@mail.gmail.com>
On a similar note, is there interest in actually factoring the device
tree code out from the different architectures into a common codebase?
Steve=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Grant Likely
> Sent: Monday, October 15, 2007 9:09 AM
> To: linuxppc-dev; microblaze-uclinux@itee.uq.edu.au
> Subject: Refactor booting-without-of.txt
>=20
> Adding the Linux expected device tree bindings to
> booting-without-of.txt seems to be getting a little unwieldy. Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
>=20
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?
>=20
> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
>=20
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth,=20
> MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit=20
> anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
>=20
> Thoughts?
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Jens Axboe @ 2007-10-16 16:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.62.0710161642200.20196@pademelon.sonytel.be>
On Tue, Oct 16 2007, Geert Uytterhoeven wrote:
> Hi Arnd, Jens,
>
> The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> unsupported ioctls more verbose. E.g. on the PS3 I get:
>
> | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
>
> The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> The others are triggered by me running hdparm.
>
> Was this intentional?
Nope, not intential to me at least. I'll check up on it.
--
Jens Axboe
^ permalink raw reply
* RE: cross compilation issue
From: Leisner, Martin @ 2007-10-16 16:36 UTC (permalink / raw)
To: ravi.rao, avenkatesh
Cc: linuxppc-embedded-bounces+ravi.rao=rflelect.com,
linuxppc-embedded
In-Reply-To: <OF1782007A.A1A7A36C-ON85257376.005181BD-85257376.00519317@rflelect.com>
I sometimes found this painful...
I have a simple script in a configured directory "make-line" which looks =
like
bash2 :2 mleisner@linuxcom-01 11:53:58; cat make-line
#! /bin/bash
exec make ARCH=3Dpowerpc =
CROSS_COMPILE=3D/opt/denx/eldk4.1/usr/bin/ppc_74xx- =
INSTALL_MOD_PATH=3D${PWD}/root $*
I know hardhat linux had a strategy to make . files hiding the names of =
ARCH/CROSS_COMPILE -- so typing make
would work once configured...
IMHO it should be hardcoded in the Makefile after configuration -- it =
causes a lot of grief if you FORGET
to specify one of these and just type "make".
One of the things I want to do is look at how the linux make system =
works now (I recall at times I edit the Makefile
to hardcode these things).
marty
________________________________________
From: linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org] =
On Behalf Of ravi.rao@rflelect.com
Sent: Tuesday, October 16, 2007 10:52 AM
To: avenkatesh@hcl.in
Cc: linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org; =
linuxppc-embedded@ozlabs.org
Subject: Re: cross compilation issue
Hi,=20
=A0Easiest way is to edit the x86 Makefile so that gcc and ld points to =
Ur tool chain's ppc_6xx-gcc & ppc_6xx-ld..=20
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com=20
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863=20
=A0=20
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or =
legally privileged information.=A0 The Information is intended only for =
the use of the individual or entity named on this e-mail .=A0 If you are =
not the intended recipient, you are hereby notified that any disclosure, =
copying, distribution, or the taking of any action in reliance on the =
contents of this transmitted Information is strictly prohibited.=A0 =
Further, if you are not the intended recipient, please notify us by =
return e-mail and delete the Information promptly.=20
=A0=20
=A0=20
=A0=20
"Venkatesh Ananthakrishnan, TLS-Chennai" <avenkatesh@hcl.in>=20
Sent by: linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org=20
10/16/2007 10:24 AM=20
To
<linuxppc-embedded@ozlabs.org>=20
cc
Subject
cross compilation issue
Hai=20
I am newbi to linux.=20
I wrote the application usb libusb which works fine with x86 pc.=20
I want to compile the application for ppc. I have cross compiled libusb. =
I have tool chain also.=20
If I give ppc_6xx-gcc filename.c=20
It gives the error message as usb.h No such a file or directory.=20
How to give include path and library path during compilation?=20
Please do the needful=20
=A0=20
Regards,=20
Venkatesh=20
=A0=20
DISCLAIMER:
-------------------------------------------------------------------------=
----------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and =
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its =
affiliates. Any views or opinions presented in=20
this email are solely those of the author and may not necessarily =
reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, =
modification, distribution and / or publication of=20
this message without the prior written consent of the author of this =
e-mail is strictly prohibited. If you have=20
received this email in error please delete it and notify the sender =
immediately. Before opening any mail and=20
attachments please check them for viruses and defect.
-------------------------------------------------------------------------=
----------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded=20
^ permalink raw reply
* Re: Serial init / BRG
From: Scott Wood @ 2007-10-16 16:31 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710160719r44099b19jbda55af2ef88e9f8@mail.gmail.com>
Alan Bennett wrote:
> A few questions: To use 3 brgs, should I have 1 brg entry and X reg
> values or three brg entries in my device tree?
The current brg entry describes all 8 BRGs... don't touch it. :-)
> what are the third and fourth reg values of the brg item in the
> device tree. I'll need 3 separate baud rates on the serial lines.
> Should I just add code to initialize the brg's in u-boot or figure
> out how to get the kernel to do it?
No, the kernel should do it. Are you associating the BRG with the SCC
in the CMXSCR register, and setting up the pins required by SCC1 and
SCC4, in either u-boot or your platform code?
> boot sequence
> ===========
> CPM UART serial mem=e0011a80 pram=e0000000
> ttyCPM0 at MMIO 0xe0011a80 (irq = 16) is a CPM UART
>
> CPM UART serial mem=e0011a00 pram=e0008000
> CPM uart[1]:init_scc - sup = e0008000
> ttyCPM1 at MMIO 0xe0011a00 (irq = 40) is a CPM UART
>
> CPM UART serial mem=e0011a60 pram=e0008300
> CPM uart[2]:init_scc - sup = e0008300
> ttyCPM2 at MMIO 0xe0011a60 (irq = 43) is a CPM UART
>
> BRG Values after above
> =================
> brgc1: 0x00000000
> brgc2: 0x00000000
> brgc3: 0x00000000
> brgc4: 0x00000000
> brgc5: 0x00000000
> brgc6: 0x00000000
> brgc7: 0x0001004e
> brgc8: 0x00000000
This is expected if you haven't opened the other serial ports yet... it
doesn't initialize the brg until then.
-Scott
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-16 16:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <20071015233839.959F4247BB@gemini.denx.de>
Wolfgang Denk wrote:
> In message <4713A08C.3060204@freescale.com> you wrote:
>> keng_629 wrote:
>>>
>>> i am proting linux2.63.23 to mpc860t board with uboot1.1.4 as bootloader.
>>> my bootargs is root=/dev/ram rw init=/linuxrc.
>>> i use debugger to see the regedits, find pc is run in the cpu_idle().
>>> what is wrong with my kernel, plese give me some advice.thank you .
>> Posting the same thing over and over again isn't going to change the
>> response. Try head-of-Linus's-git, make sure you're using arch/powerpc,
>> and post the device tree you're using. Without more information, we
>> can't help you.
>
> Just to point out the obvious: U-Boot 1.1.4 is *way* too old to
> support any device-tree based kernel, so the fist step is to update
> U-Boot to a somewhat recent version (i. e. 1.3.0-rcX).
Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
think there's any device tree support for 8xx yet, so for now he should
boot with cuImage.
-Scott
^ permalink raw reply
* [PATCH 5/5] IB/ehca: Enable large page MRs by default
From: Joachim Fenkes @ 2007-10-16 15:31 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index d477dc3..2f51c13 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -65,7 +65,7 @@ int ehca_port_act_time = 30;
int ehca_poll_all_eqs = 1;
int ehca_static_rate = -1;
int ehca_scaling_code = 0;
-int ehca_mr_largepage = 0;
+int ehca_mr_largepage = 1;
module_param_named(open_aqp1, ehca_open_aqp1, int, S_IRUGO);
module_param_named(debug_level, ehca_debug_level, int, S_IRUGO);
--
1.5.2
^ permalink raw reply related
* [PATCH 4/5] IB/ehca: Change meaning of hca_cap_mr_pgsize
From: Joachim Fenkes @ 2007-10-16 15:31 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
ehca_shca.hca_cap_mr_pgsize now contains all supported page sizes ORed
together. This makes some checks easier to code and understand, plus we can
return this value verbatim in query_hca(), fixing a problem with SRP
(reported by Anton Blanchard -- thanks!).
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_classes.h | 1 -
drivers/infiniband/hw/ehca/ehca_hca.c | 1 +
drivers/infiniband/hw/ehca/ehca_main.c | 18 ++++++++++++-
drivers/infiniband/hw/ehca/ehca_mrmw.c | 38 ++++++++++++++--------------
4 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 0f7a55d..365bc5d 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -323,7 +323,6 @@ extern int ehca_static_rate;
extern int ehca_port_act_time;
extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
-extern int ehca_mr_largepage;
struct ipzu_queue_resp {
u32 qe_size; /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index 4aa3ffa..15806d1 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -77,6 +77,7 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
}
memset(props, 0, sizeof(struct ib_device_attr));
+ props->page_size_cap = shca->hca_cap_mr_pgsize;
props->fw_ver = rblock->hw_ver;
props->max_mr_size = rblock->max_mr_size;
props->vendor_id = rblock->vendor_id >> 8;
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index 403467f..d477dc3 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -260,13 +260,20 @@ static struct cap_descr {
{ HCA_CAP_MINI_QP, "HCA_CAP_MINI_QP" },
};
-int ehca_sense_attributes(struct ehca_shca *shca)
+static int ehca_sense_attributes(struct ehca_shca *shca)
{
int i, ret = 0;
u64 h_ret;
struct hipz_query_hca *rblock;
struct hipz_query_port *port;
+ static const u32 pgsize_map[] = {
+ HCA_CAP_MR_PGSIZE_4K, 0x1000,
+ HCA_CAP_MR_PGSIZE_64K, 0x10000,
+ HCA_CAP_MR_PGSIZE_1M, 0x100000,
+ HCA_CAP_MR_PGSIZE_16M, 0x1000000,
+ };
+
rblock = ehca_alloc_fw_ctrlblock(GFP_KERNEL);
if (!rblock) {
ehca_gen_err("Cannot allocate rblock memory.");
@@ -329,8 +336,15 @@ int ehca_sense_attributes(struct ehca_shca *shca)
if (EHCA_BMASK_GET(hca_cap_descr[i].mask, shca->hca_cap))
ehca_gen_dbg(" %s", hca_cap_descr[i].descr);
- shca->hca_cap_mr_pgsize = rblock->memory_page_size_supported;
+ /* translate supported MR page sizes; always support 4K */
+ shca->hca_cap_mr_pgsize = EHCA_PAGESIZE;
+ if (ehca_mr_largepage) { /* support extra sizes only if enabled */
+ for (i = 0; i < ARRAY_SIZE(pgsize_map); i += 2)
+ if (rblock->memory_page_size_supported & pgsize_map[i])
+ shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
+ }
+ /* query max MTU from first port -- it's the same for all ports */
port = (struct hipz_query_port *)rblock;
h_ret = hipz_h_query_port(shca->ipz_hca_handle, 1, port);
if (h_ret != H_SUCCESS) {
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index b9a788c..bb97915 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -79,9 +79,7 @@ static u32 ehca_encode_hwpage_size(u32 pgsize)
static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
{
- if (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)
- return EHCA_MR_PGSIZE16M;
- return EHCA_MR_PGSIZE4K;
+ return 1UL << ilog2(shca->hca_cap_mr_pgsize);
}
static struct ehca_mr *ehca_mr_new(void)
@@ -288,7 +286,7 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
container_of(pd->device, struct ehca_shca, ib_device);
struct ehca_pd *e_pd = container_of(pd, struct ehca_pd, ib_pd);
struct ehca_mr_pginfo pginfo;
- int ret;
+ int ret, page_shift;
u32 num_kpages;
u32 num_hwpages;
u64 hwpage_size;
@@ -343,19 +341,20 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
/* determine number of MR pages */
num_kpages = NUM_CHUNKS((virt % PAGE_SIZE) + length, PAGE_SIZE);
/* select proper hw_pgsize */
- if (ehca_mr_largepage &&
- (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)) {
- int page_shift = PAGE_SHIFT;
- if (e_mr->umem->hugetlb) {
- /* determine page_shift, clamp between 4K and 16M */
- page_shift = (fls64(length - 1) + 3) & ~3;
- page_shift = min(max(page_shift, EHCA_MR_PGSHIFT4K),
- EHCA_MR_PGSHIFT16M);
- }
- hwpage_size = 1UL << page_shift;
- } else
- hwpage_size = EHCA_MR_PGSIZE4K; /* ehca1 only supports 4k */
- ehca_dbg(pd->device, "hwpage_size=%lx", hwpage_size);
+ page_shift = PAGE_SHIFT;
+ if (e_mr->umem->hugetlb) {
+ /* determine page_shift, clamp between 4K and 16M */
+ page_shift = (fls64(length - 1) + 3) & ~3;
+ page_shift = min(max(page_shift, EHCA_MR_PGSHIFT4K),
+ EHCA_MR_PGSHIFT16M);
+ }
+ hwpage_size = 1UL << page_shift;
+
+ /* now that we have the desired page size, shift until it's
+ * supported, too. 4K is always supported, so this terminates.
+ */
+ while (!(hwpage_size & shca->hca_cap_mr_pgsize))
+ hwpage_size >>= 4;
reg_user_mr_fallback:
num_hwpages = NUM_CHUNKS((virt % hwpage_size) + length, hwpage_size);
@@ -801,8 +800,9 @@ struct ib_fmr *ehca_alloc_fmr(struct ib_pd *pd,
ib_fmr = ERR_PTR(-EINVAL);
goto alloc_fmr_exit0;
}
- hw_pgsize = ehca_get_max_hwpage_size(shca);
- if ((1 << fmr_attr->page_shift) != hw_pgsize) {
+
+ hw_pgsize = 1 << fmr_attr->page_shift;
+ if (!(hw_pgsize & shca->hca_cap_mr_pgsize)) {
ehca_err(pd->device, "unsupported fmr_attr->page_shift=%x",
fmr_attr->page_shift);
ib_fmr = ERR_PTR(-EINVAL);
--
1.5.2
^ permalink raw reply related
* RE: Linux booting problem on Xilinx ppc
From: Sergey Oleynichenko @ 2007-10-16 15:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13219154.post@talk.nabble.com>
I noticed this problem happens when on-chip memories are enabled in a design
(it is 4th page in base system builder). Try to leave them "none" for both
instruction and data.
Sergey
-----Original Message-----
From: linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org] On
Behalf Of aauer1
Sent: Monday, October 15, 2007 1:47 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linux booting problem on Xilinx ppc
Hello
I'm also working with ML403 board from Xilinx and have the same problem as
you. The boot process stops after decompressing with the message "Now
booting the kernel". We also used gcc-4.1.0 for the cross compilation. So, I
would be glad to know, which gcc version have you used to get a working
kernel!
Thanks,
Andreas
Junqiang Hu wrote:
>
>
> Hi Grant,
>
> Thank you so much for the reply! Fortunately I got it work now -- it's
> the crosstool compiler problem. Originally I was using gcc-4.1.0, yet
> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
> miscompile the kernel, so I changed to another version, and now I can let
> it go!
>
> Right now still not fully booted because of the SystemACE problem, or
> maybe the partition is not correct. I'm still working on it, hopefully to
> get it solved soon :-)
>
> Thanks,
> -J.
>
>
> Grant Likely-2 wrote:
>>
>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>
>>>
>>> Dear friends,
>>>
>>> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>> board. The Linux version I'm using is 2.4; the cross-compiler is
>>> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
>>> loaded at: 00400000 004B51E4
>>> board data at: 00000000 00000018
>>> relocated to: 0040526C 00405284
>>> zimage at: 00405B2B 004B177C
>>> avail ram: 004B6000 60000000
>>
>> I strongly recommend moving to a 2.6 kernel. Recent mainline has
>> support for the Xilinx ppc built in.
>>>
>>> Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>> rw
>>> Uncompressing Linux...done.
>>> Now booting the kernel
>>>
>>> Then it hangs. First it seems to me that the "avail ram" is not correct,
>>> since I configured only 32MB SDRAM. Moreover, if it's first powered on,
>>> the
>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>> investigate
>>> the problem using xmd. When launched, it says:
>>
>> (If you're using u-boot) You might have a mismatch between the board
>> info structure used by u-boot and the one used by Linux.
>>
>> Also, you should use your debugger to inspect the __log_buf memory of
>> the kernel. A common problem is the kernel starts booting, but the
>> console is setup incorrectly and so you see nothing. But, you can
>> read the console output directly from memory if you look at the
>> __log_buf region (find the address in the System.map file; you might
>> need to subtract 0xC0000000 from the address to view the memory)
>>
>> Cheers,
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>> grant.likely@secretlab.ca
>> (403) 399-0195
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13
219154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Stephen Rothwell @ 2007-10-16 15:27 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Q Klein, Jeff Garzik, Mackerras, netdev, Jan-Bernd Themann,
LKML, LinuxPPC-Dev, Christoph Raisch, Paul Mackerras, Marcus Eder,
Paul, Stefan Roscher
In-Reply-To: <200710162320.00630.fenkes@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Tue, 16 Oct 2007 23:20:00 +0200 Joachim Fenkes <fenkes@de.ibm.com> wrote:
>
One small change - I intend to remove the name and owner fields from
struct of_platform_driver, so you should not bother initialising the name
field and just initialise the name field of the embedded struct
device_driver instead. This, of course, means that you don't need
drv->driver.name = drv->name;
in ibmebus_register_driver.
Sorry for not picking this up earlier.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/5] IB/ehca: Fix ehca_encode_hwpage_size() and alloc_fmr()
From: Joachim Fenkes @ 2007-10-16 15:26 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Simplify ehca_encode_hwpage_size(), fixing an infinite loop for pgsize == 0
in the process. Fix the bug in alloc_fmr() that triggered the loop.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_mrmw.c | 15 ++++-----------
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 16c9efd..b9a788c 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -72,17 +72,9 @@ enum ehca_mr_pgsize {
static u32 ehca_encode_hwpage_size(u32 pgsize)
{
- u32 idx = 0;
- pgsize >>= 12;
- /*
- * map mr page size into hw code:
- * 0, 1, 2, 3 for 4K, 64K, 1M, 64M
- */
- while (!(pgsize & 1)) {
- idx++;
- pgsize >>= 4;
- }
- return idx;
+ int log = ilog2(pgsize);
+ WARN_ON(log < 12 || log > 24 || log & 3);
+ return (log - 12) / 4;
}
static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
@@ -826,6 +818,7 @@ struct ib_fmr *ehca_alloc_fmr(struct ib_pd *pd,
/* register MR on HCA */
memset(&pginfo, 0, sizeof(pginfo));
+ pginfo.hwpage_size = hw_pgsize;
/*
* pginfo.num_hwpages==0, ie register_rpages() will not be called
* but deferred to map_phys_fmr()
--
1.5.2
^ permalink raw reply related
* [PATCH 2/5] IB/ehca: Fix masking error in {,re}reg_phys_mr()
From: Joachim Fenkes @ 2007-10-16 15:25 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_mrmw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..16c9efd 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -259,7 +259,7 @@ struct ib_mr *ehca_reg_phys_mr(struct ib_pd *pd,
pginfo.u.phy.num_phys_buf = num_phys_buf;
pginfo.u.phy.phys_buf_array = phys_buf_array;
pginfo.next_hwpage =
- ((u64)iova_start & ~(hw_pgsize - 1)) / hw_pgsize;
+ ((u64)iova_start & ~PAGE_MASK) / hw_pgsize;
ret = ehca_reg_mr(shca, e_mr, iova_start, size, mr_access_flags,
e_pd, &pginfo, &e_mr->ib.ib_mr.lkey,
@@ -547,7 +547,7 @@ int ehca_rereg_phys_mr(struct ib_mr *mr,
pginfo.u.phy.num_phys_buf = num_phys_buf;
pginfo.u.phy.phys_buf_array = phys_buf_array;
pginfo.next_hwpage =
- ((u64)iova_start & ~(hw_pgsize - 1)) / hw_pgsize;
+ ((u64)iova_start & ~PAGE_MASK) / hw_pgsize;
}
if (mr_rereg_mask & IB_MR_REREG_ACCESS)
new_acl = mr_access_flags;
--
1.5.2
^ permalink raw reply related
* [PATCH 1/5] IB/ehca: Supply QP token for SRQ base QPs
From: Joachim Fenkes @ 2007-10-16 15:24 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Because hardware reports the SRQ token in RWQEs of SRQ base QPs, supply the
base QP token as SRQ token, so we can properly find the SRQ base QP.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index e2bd62b..de18264 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -451,7 +451,6 @@ static struct ehca_qp *internal_create_qp(
has_srq = 1;
parms.ext_type = EQPT_SRQBASE;
parms.srq_qpn = my_srq->real_qp_num;
- parms.srq_token = my_srq->token;
}
if (is_llqp && has_srq) {
@@ -583,6 +582,9 @@ static struct ehca_qp *internal_create_qp(
goto create_qp_exit1;
}
+ if (has_srq)
+ parms.srq_token = my_qp->token;
+
parms.servicetype = ibqptype2servicetype(qp_type);
if (parms.servicetype < 0) {
ret = -EINVAL;
--
1.5.2
^ permalink raw reply related
* [PATCH 0/5] IB/ehca: SRQ and MR/MW fixes
From: Joachim Fenkes @ 2007-10-16 15:22 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
Here are some more fixes for the eHCA driver, fixing some problems we found
during internal system test.
[1/5] fixes the QP pointer determination for SRQ base QPs
[2/5] fixes a masking error in {,re}reg_phys_mr()
[3/5] fixes a bug in alloc_fmr() and simplifies some code
[4/5] refactors hca_cap_mr_pgsize and fixes a problem with ib_srp
[5/5] enables large page MRs by default
I built the patches on top of Roland's for-2.6.24 git branch. Please review
and queue them for 2.6.24-rc1 if you're okay with them. Thanks!
Cheers,
Joachim
=2D-=20
Joachim Fenkes =A0-- =A0eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH =A0-- =A0Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 =A0-- =A071032 Boeblingen =A0-- =A0Germany
eMail: fenkes@de.ibm.com
^ 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